Move agents from read-only to write access without losing control
Read-only agents are useful. The business value usually starts when agents can act. That is where authorization, approval, and proof have to move into the request path.
Search, summarization, and retrieval are lower-consequence because they mostly inspect. Write access changes the risk profile. An agent that can update a customer record, open a production ticket, trigger a workflow, call an MCP tool, export a file, or approve a payment needs a decision before the action runs.
The access ladder
| Agent capability | Common default | Keel policy posture |
|---|---|---|
| Read | Retrieve, search, summarize, inspect records | Allow with budget, rate, provider, and data-scope limits. |
| Routine write | Create tickets, update low-risk workflow state, draft records | Allow only for scoped tools, known agents, expected tenants, and reversible operations. |
| Sensitive write | Modify production, export data, update financial or regulated records | Challenge for approval or require stricter policy conditions before dispatch. |
| Irreversible action | Send payment, delete data, disable access, merge risky changes | Deny by default or require explicit break-glass approval with evidence. |
How to model it
Keel does not need to become your IAM system to enforce this boundary. The governed request carries structured metadata into policy evaluation:
- action name - for example `crm.ticket.update`, `repo.pr.merge`, or `mcp.tool.call`
- resource attributes - provider, model, operation, environment, tenant, or target system
- context - caller identity, agent identity, risk class, operation class, amount, target, or data category
- MCP tool metadata - server, tool name, requested action, and normalized argument hash
Policy can then allow, deny, throttle, constrain, or challenge the request before execution. The important part is that the classification exists before the action, not after a dashboard tries to explain what happened.
What the proof needs to show
When security asks why a write-capable agent acted, the answer should not depend on screenshots or a reconstructed incident timeline. A permit-backed record should show the requested action, actor, policy version, decision, approval requirement if any, and later evidence tied to the same execution path.
Frequently asked questions
What does read-only to write access mean for AI agents?
Read-only agents retrieve, summarize, and inspect. Write-capable agents mutate systems: they update records, create tickets, call tools with side effects, move data, trigger payments, or change production state.
Does Keel decide read versus write automatically?
No. Keel enforces the policy boundary. The application or MCP layer should provide action, tool, resource, and context metadata so policy can classify the requested action before execution.
Can risky write actions require approval?
Yes. Challenged permits can require formal approval and attach actor identity, authorization basis, rationale, policy snapshot, and request metadata to the same permit evidence.