Ask an organization what its AI agent can do and the answer arrives as a document. That document was written before the system was built, it describes what was intended, and it was last revised at the point the project needed a sign-off. It is therefore a statement of intent, recording a decision taken at one moment, and it is not an inventory of a system that has changed since.
The authoritative answer lives in the service identity, because that is the object the target system evaluates when it decides whether to carry out a request. Every tool call is made by software authenticating as something, whether a machine account in a directory, a workload identity, an API key, or a role assumed at run time. Whatever that identity is permitted to do, the agent can do, because the agent is the thing using it. The design document constrains what the developers intended the agent to do. The service identity constrains what it is able to do. Where the two differ the identity is what the target system will act on, because the target system authorizes the request in front of it and has no access to the document, and the difference between the two is the finding.
It would be convenient to treat the gap as a hygiene problem, meaning a team that cut corners, but the way these systems are built produces it without anyone cutting a corner. An engineer integrating an agent with a core banking platform requests a service identity. Provisioning it is a ticket, the ticket is slow, and the tool set is expected to grow, so the request is raised once, early, with a scope wide enough that it will not have to be raised four more times. The tools are then built against that identity, one at a time, as the product develops.
Six months later the agent holds five tools and the identity holds permissions for twenty operations, of which the agent invokes five in the code path that exists today. That is not a latent risk in the ordinary sense, where a condition has to change before exposure arises. It is a live authority, and the only thing keeping the agent from the other fifteen operations is the current shape of the application code. That code changes weekly, at the hands of people who have not read the design document and who have no reason to ask whether a new capability was approved, because from where they sit the permission is already there.
The evidence required is an export of the effective permissions of every identity in the agent’s call path. Effective rather than assigned, because inherited group memberships and role chains grant authority that no individual assignment records, and an assigned-permissions report will not show them. The request has to be made in those words, because asking what permissions the agent has returns the application’s documented permissions, which is the design document already in hand.
Three follow-through questions turn the export into findings, and each one addresses a different way authority extends beyond the use case.
The finding is not that the design document is out of date, because a documentation observation is closed by updating a document and the condition returns with the next configuration change. The finding is that the organization cannot state the authority of its agent, because that authority is set by a service identity no process reviews and the artifact that is reviewed does not describe it.
The recommendation follows from that framing, and it has to produce something that is maintained rather than something that is issued. An authority register, derived from the service identity rather than from the design, reconciled at every change, with a named approver for each capability, is a control, because it has to be maintained and somebody has to own maintaining it. A refreshed architecture diagram is a description, and it will be out of date on the same schedule as the one it replaced.
This brief is one of ten behind Module 1, The tool surface, a free guided walkthrough of an AI agent assessment at a credit union. The same engagement can be run unassisted, with the check questions above put to you against evidence rather than against a description.
NexNith advises boards and audit committees on exactly this work. How we work