Somebody in your environment authorized an agent to act on its own and cannot tell you what they authorized.
The model sits in the middle of a lot of wiring. Data flows in from sources somebody connected. Tool calls flow out to systems somebody authorized. Almost nobody has drawn that wiring, and the interesting risk lives inside it.
No one asks. They just do.
Part of why: the wiring got built by different people at different times. A platform engineer connected the data source. An application owner switched on the tool integrations because the demo required them, a vendor shipped a default nobody changed, and not one of those three people thought they were making a security decision. No single person holds the whole picture, and the architecture diagram, if one exists at all, shows boxes rather than authority.
Three questions collapse that ambiguity fast.
Which identity does the agent use. What data can it read. What can it do with no human in the loop. Insist on written answers, because a conversation lets people gloss the parts they are still guessing.
The second one surprises people. Agents get pointed at a data source through a connector that authenticates once, broadly, and then serves every query the agent makes after that. The scope of the connector is the scope of the agent. Go look at the app registration behind your copilot and count the permissions sitting on it, and notice that Files.Read.All got granted during a proof of concept by somebody optimizing for a working demo.
Model evaluation is the least useful AI security work most teams are doing right now. It gets the attention because it looks like AI, it has benchmarks, and there are vendors selling tooling for it. The authority question reads like plumbing by comparison, which is exactly why it goes unanswered quarter after quarter.
Think about what an incident review actually requires. Nobody asks for the model card. Somebody has to reconstruct what the agent could reach and what it was permitted to do, and when that reconstruction starts during the incident, day one goes to archaeology instead of containment.
Here is where writing it down stops being paperwork. Those three answers are the scope. Take them to whoever issues credentials in your environment and ask for one that fits them: an identifier belonging to that agent and nothing else, a named human who answers for it, permissions granted deliberately rather than inherited, and a date or a condition that retires it.
Expect the shared credential to fight you. The one your agent borrowed is usually holding up two other things nobody documented either, so revoking it to scope one agent breaks the other two on a Tuesday afternoon. That is not a reason to skip the step. That is the finding.
Identity programs spent fifteen years building lifecycle for people. Joiner, mover, leaver, quarterly attestation, a manager whose signature carries weight. Every piece of that machinery assumes a human being with a start date, and none of it engages with something a Terraform module provisioned at four on a Thursday afternoon.
So, here's the MondayMove
Pick the agent in your environment with the most access. Write down which identity it uses, what data it can read, and what it can do with no human approval, then give it a credential of its own that matches those three answers and nothing more.
One agent done properly teaches you the pattern for the thousand (literally) behind it.
Discussion