I’d design agent access around blast radius, not just permissions. Reading a sales table and executing a bulk update against customer records should never carry the same level of autonomy.

A useful architecture separates the reasoning layer from the execution layer. The model can propose an action, but a policy engine should validate the identity, scope, data sensitivity, and potential impact before execution. Short-lived credentials, row-level access controls, and narrowly scoped APIs help limit what the agent can actually touch.

I’d also make every write operation auditable and, where possible, reversible. High-impact actions should require explicit approval, while low-risk tasks can run autonomously within predefined limits. Tool outputs and retrieved documents must also be treated as untrusted inputs to reduce prompt-injection risks.

One subtle but important point: a human approval step alone isn’t sufficient if the proposed action is difficult to inspect or its consequences aren’t clear.

An AI agent should have enough access to complete its task, but never enough authority to turn one bad decision into a system-wide incident.

I think the right way to approach this is through least-privilege access and risk-based autonomy, rather than treating an AI agent as either fully trusted or completely restricted.

An agent querying a warehouse to analyse churn is very different from one modifying customer records, changing pricing, or triggering payments. These actions need different permission boundaries.

Technically, I’d separate read, write, and execution permissions; enforce access through scoped service identities; and expose business operations through controlled APIs rather than giving agents unrestricted database credentials. Every action should also have policy checks, audit logs, and traceability back to the data and reasoning that triggered it.

For high-impact operations, I’d use a human approval gate. For lower-risk, reversible actions, bounded autonomy makes sense, provided there are transaction limits, validation checks, and rollback mechanisms. Just as importantly, the system needs to defend against prompt injection hidden in documents or retrieved data, because access to trusted infrastructure doesn’t make every input trustworthy.

I’d also avoid relying on the model itself to enforce its own permissions. Authorization should be handled by deterministic controls outside the model, with continuous monitoring and a clear kill switch.

The key principle is that an agent’s permissions should be determined by the potential impact of its actions, not by how capable the model appears to be.