# What an agent may do

Proving an agent cannot exceed the authority it was given.

Source: https://intransic.com/questions/authorisation-scope

## How do I prove an AI agent can't exceed the permissions it was given?

Prove it at your boundary, not inside the agent. Your agent is a caller like any other. Whatever decides that a caller may read this record and not that one is what your evidence points at. Make it code your agent cannot reach. Then show three things. The check exists. It runs on every path in. It refuses a request that should be refused. That third one gets skipped, and it is the only one separating a control that works from one merely present. Prompt instructions are not this. An instruction is a request to your model, and a model that ignores yours has broken nothing.

## What can a code review actually tell you about an agent's runtime authorisation?

It tells you intent, not behaviour. A review shows the check somebody wrote. It cannot tell you whether that check ran on the request that mattered. It cannot tell you whether a second path reaches the same resource without passing it. It cannot tell you whether the value compared was the one assumed. Those are properties of a run. None of this argues against code review, which catches what nothing else catches. It argues against letting review stand alone as authorisation evidence. Ask one more thing of every control you read: what would show this having worked?

## How do I scope an agent so it can only reach the caller's own resources?

Derive your scope from the verified caller on every request. Never from anything your agent supplies. This failure has a recognisable shape. Your identity check happens at the door. Then some later query filters by a tenant or user value that arrived in the request body. An agent able to influence that value reaches across your boundary while every authentication check passes. So resolve your caller once, from the credential. Let every read and write downstream take its scope from that resolved value alone. If a parameter can widen what your request sees, it is not a filter. It is your authorisation decision in disguise.

## My agent needs to write, not just read. What changes?

Everything gets sharper, because a mistake now persists. Reads fail quietly. Writes do not. Three things are worth having before you turn writing on. Scope the write narrower than the read, since an agent that reads a table seldom needs to write all of it. Make it reversible, or make it need approval, and decide that per operation rather than globally. And record the before state. An audit of a write you cannot reconstruct is an audit of your logging. If reversibility is impossible, that is your human confirmation step.

## Should an agent be able to change its own permissions?

No, and be absolute about it. An agent that can widen its own scope has no scope. Whatever grants permission has to sit outside what your agent can call, exactly as the check does. This sounds obvious and convenience breaks it. A tool that edits configuration. An admin endpoint sitting in the same allow-list as everything else. A credential with rights over its own policy. Go and read your tool list, and ask which entries could change your tool list. That audit is shorter than it sounds and it finds things.

## What does least privilege mean for an agent?

Scoped to the task. Not to the person, and not to your product. The instinct is to grant your agent whatever its user has. That is convenient and it is the wrong boundary, because the agent does one job and your user does everything. Grant what that job needs, on the resources it touches, for as long as it runs. Then test the shape of it. If your agent were fully compromised right now, what could it reach? If the answer is everything your user can reach, you gave a person's authority to a process.