Agent write-permission UX checklist: approvals, unsafe modes, and read-back

Last verified: 2026-06-16.

In short: Write-capable agents need a visible control surface, not just a confident chat interface. Before an AI agent writes to a database, repository, ticket system, or production workflow, check the proposed write, the permission boundary, the approval path, the audit/read-back story, the rollback plan, and any auto-approve or unsafe mode.

This article is a checklist, not a broad market guide. The prompt for it came from a narrow but useful release example: Simon Willison's note on datasette-agent 0.3a0 and the matching GitHub release for datasette-agent 0.3a0. Use that example to inspect the write-permission UX of any agent product, while avoiding the mistake of treating one Datasette release as proof for all database agents.

Why write access is a different product category

A read-only assistant can still be wrong, but the failure usually lands in a recommendation, a summary, or a draft. A write-capable agent can change state. It can add a database row, update a record, create a table, edit a migration, commit code, close a ticket, or trigger an external workflow.

That makes the product category different. Once an agent can write, the review cannot stop at model quality or prompt quality. The reviewer has to inspect the operational surface around the model:

• What can the agent write?
• Which identity and permission model does the write use?
• What does the human see before approval?
• Can approval be bypassed, pre-approved, or bundled into an unsafe mode?
• What is logged after the write?
• How does the product help the human read back what changed?
• What is the rollback path if the write was wrong?

This is why generic claims about a "safe agent" are not enough. A useful review has to name the safety surface: approval prompt, permission scope, audit trail, read-back, rollback, and unsafe-mode behavior.

The datasette-agent 0.3a0 example

The datasette-agent 0.3a0 release is useful because the write surface is explicit. The GitHub release says the new execute_write_sql tool "requests user approval and then writes to a database," while taking user permissions into account. Simon Willison's post repeats that point and shows the feature in the context of adding pelican sightings to a table.

The same release says datasette agent chat can execute tools that require user approval. It also adds three options for the chat command: --root to run as root, --yes to approve all ask-user questions, and --unsafe for both. Simon's post describes --unsafe as an auto-approving mode and says a command such as datasette agent chat content.db -m gpt-5.5 --unsafe can chat directly with a specific database and directly modify it through prompts like creating a notes table or adding a note.

Those are source-backed facts about this release. They are not a claim that every database agent has the same design, and they are not a recommendation to use --unsafe on production data. The useful lesson is the shape of the control surface: the product exposes a write tool, a permission claim, a terminal approval flow, and an explicit unsafe path that combines elevation and auto-approval.

That is enough for a Toolhalla checklist. It is not enough for a market-wide ranking of database agents.

The checklist: approval, permission, audit, rollback, unsafe mode

Use this checklist whenever an agent can write to a real system. The answer does not have to be perfect for every prototype, but the product should make the answer visible.

1. Approval: what is the human approving?

A good approval prompt should show more than "the agent wants to continue." It should identify the tool, the target, and the proposed write. For SQL, that means the database and the write statement or a faithful plain-language summary. For repositories, that means the files, diff, command, branch, or commit target. For tickets and CRMs, that means the record and fields.

Ask whether the user can say no without breaking the session. Ask whether the prompt separates read tools from write tools. Ask whether a multi-step plan bundles several writes behind one vague approval. The product does not need to bury a non-technical user in raw SQL, but it must give enough detail for a responsible approval.

2. Permission: whose authority does the agent use?

Approval is not a permission model by itself. The important question is which identity the write runs under. Does the agent inherit the current user's database permissions? Does it use a service account? Can it run as root? Can it touch only the selected database, directory, branch, workspace, or tenant?

The datasette-agent release explicitly says execute_write_sql writes while taking user permissions into account. That is the right kind of detail to look for. If a product only says the agent can "manage data" or "take action" without naming the permission boundary, the reviewer should treat the write model as unclear.

3. Audit and read-back: how do you know what changed?

A write-capable agent should leave a trail that a human can inspect. At minimum, ask whether the product records the user request, the selected tool, the exact write or diff, the approving actor, the timestamp, and the write result. Then ask whether the product reads back the changed state after the write.

Read-back is not the same as the model saying "done." The useful pattern is concrete evidence: the inserted row, the changed file diff, the updated issue field, the database count, or the command output. If the product does not provide that, build a manual verification step into your workflow before trusting the result.

Do not infer audit or rollback features from the datasette-agent 0.3a0 sources above. The sources verify the approval and unsafe-mode details. They do not establish a complete audit log or rollback feature for that release.

4. Rollback: what happens after a bad write?

Every write review should ask the boring recovery question before the exciting demo. Can the write run inside a transaction? Is there a dry-run mode? Is there a backup, migration history, version control branch, restore point, or undo command? Does the product show enough detail to reverse the write by hand if the automated path fails?

For production data, rollback is not optional process theater. It is the difference between a mistake that becomes a ticket and a mistake that becomes an incident. If the rollback answer is "we would ask the agent to fix it," the system is not ready for high-trust data.

5. Unsafe mode: how explicit is the bypass?

Auto-approval is not automatically bad. It can be useful in a disposable sandbox, a generated test database, or a local throwaway repository. The problem is when the bypass is hidden, ambiguous, or too easy to enable on real data.

The datasette-agent example is notable because the flag name is plain: --unsafe. The release also states what it combines: root mode and automatic yes to ask-user questions. That is the level of clarity reviewers should demand. If a product offers "fast mode," "hands-free mode," or "autonomous mode," ask exactly which approvals it skips and which permissions it changes.

What to ask before letting an agent touch real data

Before using a write-capable agent against real customer, production, financial, health, or source-code data, answer these questions in writing:

1. What exact systems can the agent write to?

2. Are writes disabled by default, or available as soon as the agent connects?

3. Does every write require a human approval, or can approvals be pre-granted?

4. What does the approval prompt show: target, tool, query, diff, fields, command, and expected effect?

5. Does the agent respect the current user's permissions, or does it write through a broader service account?

6. Can the agent elevate to root, admin, owner, or maintainer authority?

7. Is there an auto-approve mode, and is it named loudly enough that operators notice it?

8. Are prompts, tool calls, writes, approvals, denials, and results logged?

9. Does the workflow read back the changed state after the write?

10. What rollback path has been tested before real data is exposed?

If you cannot answer those questions, hold the rollout. Use a sandbox, a copied database, a branch, or a fake tenant until the control surface is visible.

Where Toolhalla should reuse this checklist in reviews

Toolhalla should reuse this checklist anywhere the article is about agents that act, not just agents that answer. It fits coding agents, database agents, MCP-connected tools, browser agents that submit forms, and internal automation agents that update business systems.

For coding-agent coverage, pair it with the methodology discipline in Toolhalla's coding-agent benchmark checklist. A leaderboard score says little about whether the product handles write approval, permission scope, and rollback in your repository.

For runtime and isolation coverage, pair it with Toolhalla's AI agent sandbox guide. A sandbox can limit blast radius, but it does not replace approval UX, audit/read-back, or a rollback plan. The best review treats runtime isolation and write-permission UX as separate rows in the decision table.

Toolhalla should also use this as a source-pack rule. If an article cannot verify the write control surface from primary sources, it should not present the product as ready for real data. Say what is verified, say what is missing, and hold broader claims until the docs, release notes, or code support them.

FAQ

Is user approval enough for a write-capable agent?

No. Approval is only one layer. You still need a clear permission model, a useful approval prompt, logs, read-back, and rollback. A user can approve the wrong thing if the prompt hides the target or effect.

Is --unsafe always a bad feature?

No. An explicit unsafe mode can be useful for disposable local testing or throwaway data. It becomes a production risk when teams enable it against real systems, or when the product does not clearly explain which approvals and permissions it bypasses.

Did datasette-agent 0.3a0 verify audit or rollback features?

Not from the sources used here. The Simon Willison post and GitHub release verify the new write SQL tool, approval support in terminal chat, and --root, --yes, and --unsafe options. They do not establish a complete audit log or rollback feature, so this article treats audit and rollback as reviewer questions.

Can this checklist apply to repository-writing agents?

Yes, but do not copy the database details blindly. For repositories, replace SQL and table checks with branch, file, diff, test, commit, and revert checks. The same structure still applies: approval, permission scope, audit/read-back, rollback, and unsafe-mode behavior.

What should teams do first?

Start with a copied database, a temporary branch, or a test workspace. Enable writes only after the approval prompt, permission boundary, logs, read-back, and rollback path have been inspected and tested.