Controlling what an AI agent can access and change requires three things: an explicit inventory of the systems and data the agent needs, a declared scope stating what it is authorized to modify, and enforcement of that scope at the point where changes execute. Access controls alone are not sufficient, because they govern the actor rather than the action.
Start with what the agent actually needs
Most agents are over-provisioned at deployment, usually because the fastest path to a working prototype is to give it broad credentials and narrow them later. Later rarely arrives.
Write down, for each agent in production: which systems it reads from, which it writes to, which tools it can invoke, and which data classifications it touches. This is tedious and it is the step people skip. Every control below depends on it.
Separate reading from changing
The two carry different risk and should be scoped separately. An agent that reads production data and writes only to a staging system is a fundamentally different exposure from one that writes to production, even if both hold the same credential.
Where the agent framework supports it, issue separate credentials for read and write paths. Where it does not, treat write scope as the thing that needs enforcement and read scope as the thing that needs monitoring.
Declare scope before the agent runs, not after
A scope declared in advance is enforceable. A scope inferred from logs afterward is a report. The distinction matters most when an agent behaves unexpectedly, because that is precisely when there is no time to work out what it should have been doing.
A workable declaration covers: the systems the agent may modify, the file paths, services or configuration objects within them, the tools it may invoke, and what should happen when it attempts something outside that list.
Decide what happens at the boundary
Three options, and the choice is a real one.
- Log it. Lowest friction, no protection. Appropriate for a monitoring phase while you learn what the agent actually does.
- Alert on it. Useful in a staffed environment. Not useful at machine speed, because the agent completes the action well before anyone reads the alert.
- Block it. The only option that holds when nobody is watching. It requires the scope declaration to be accurate, which is why the inventory step matters.
Test the boundary before you trust it
Have the agent attempt something outside its declared scope in a non-production environment and confirm the result matches what you expect. Organizations routinely discover at this point that the boundary was documented rather than enforced.
Where enforcement happens
Access control at the identity layer decides whether the agent may connect. Application-layer controls decide what the agent may request. Neither evaluates the change itself at the point it executes, which is why an agent with a valid credential using an approved tool can make an unauthorized change that looks legitimate at every layer above the operating system.
Mimic’s AI Shield enforces declared scope at the kernel, so an action outside scope does not execute regardless of credential validity or which tool initiated it. That is one way to close the gap. The important part is that the gap exists in most deployments and that documenting a boundary is not the same as enforcing one. For the discipline these controls sit inside, see agentic AI security.
Agent access control, answered.
How do I decide what an AI agent should be allowed to change?
+Start from the task rather than the credential. List what the agent must modify to complete its work, then scope to that and nothing more. If the scope is hard to write down, the agent’s job is probably too broadly defined, which is itself worth fixing before deployment.
Is least privilege enough for AI agents?
+Least privilege limits what an agent can reach. It does not evaluate what the agent does with what it can reach. An agent scoped to a production database still has the ability to drop a table within that scope, so privilege limits and action limits are different controls.
What if the agent needs broad access to be useful?
+Broad read access with narrow write scope is often the right answer, and it covers most legitimate use cases. If an agent genuinely needs broad write access to production, that is a decision worth escalating rather than configuring.
How often should agent scope be reviewed?
+Whenever the agent’s task changes, and on a fixed interval regardless. Agent scope drifts the same way human entitlements do, except faster, because agents are deployed and modified without the ceremony that surrounds a role change.
