Every organisation running AI agents has an access-control problem it has not measured yet. It is not that agents are given too much power. It is that nobody wrote down what power they were given.
Where the gap opens
The pattern is consistent enough to be predictable. A team builds an agent in an AI studio. The studio is approved. The agent's purpose is approved. To do its job the agent needs to reach real systems, so it is connected to them — and behind each of those connections sits an OAuth token, an API key, a service account, or a borrowed human account.
Those identities are created as a step in building the agent, not as a request to security. As Roy Katmor, co-founder and CEO of Orchid, puts it: "The agent is approved, the studio is approved, but the identities behind them sit outside the usual review process."
Then the agent's remit grows. A second integration is added, a permission is widened to unblock a failing run, a scope is copied from another service account because it worked. Katmor's description of the result is the part worth quoting to your own board: "Permissions accumulate, and the account ends up with authority well past the agent's original job."
Why this is worse than an over-permissioned employee
Consider a routine onboarding agent. To do the work it touches HR, the identity provider, ticketing, payroll and internal apps. A human with that combination of access would be a named individual, reviewed at hire, re-attested quarterly, and removed on their last day.
The agent has the same reach with none of that. It has no leaver process. It does not appear in an access review, because access reviews enumerate people. It holds credentials that outlive the project that created them, and it can act on all of them at once, at machine speed, without pausing to wonder whether it should.
The five things you have to be able to state
Katmor's framing is to treat each agent as an application and to hold five facts about it:
1. Owner and purpose — who is accountable, and what it exists to do 2. Tools it can reach — the systems, not the intentions 3. Credentials it uses — every token, key and account behind those connections 4. Effective authority — what those credentials actually permit, which is rarely what was intended 5. Runtime behaviour — what it did, as opposed to what it was approved to do
The fourth is where most inventories fail. Organisations record the permission that was requested. Effective authority is the union of everything the credential can reach, including whatever it inherited from the service account it was cloned from.
The fifth is what turns the list into a control. Once approved intent and observed behaviour are both recorded, they can be compared — and divergence becomes something you can act on with scoped controls, including a targeted kill switch, rather than a blunt shutdown of the whole system.
Why the regulatory pressure is arriving now
None of this is only good practice. Under NIS2, cybersecurity risk management is a management responsibility with personal accountability — and an unreviewed credential holding payroll access is precisely the kind of risk that obligation covers. The EU AI Act's record-keeping requirements assume you can say what a system did; that assumption fails if the identity that acted is undocumented. Access reviews under ISO 27001 and SOC 2 control mappings enumerate accounts, and a service account created inside an AI studio is still an account.
The question moves from "did you have a policy" to "show me the agent, its owner, its credentials, its effective authority, and what it did last Tuesday." An organisation that cannot answer that has not deployed an agent. It has deployed an unmonitored integration with initiative.
What good looks like
An agent should carry an identity that is issued deliberately, scoped narrowly, and revocable immediately — closer to a passport than to a password. Issued by your own authority. Carrying explicit limits on what it may spend and reach. Recorded when used. Revocable in seconds, without redeploying anything, and without taking down the systems it was talking to.
That is a higher bar than most agent deployments meet today. It is also, unlike a policy document, something you can prove.
Related guides
Compliance
The EU AI Act Article 12 readiness guide
What record-keeping and human-oversight obligations actually require operationally from August 2026 — and the evidence an auditor will ask you to produce.
9 min read
Read the guide →Security
When the agents organised themselves: what the Hugging Face swarm means for accountability
Roughly 700 AI agents divided labour, traded favours and compromised production infrastructure across four regions. The uncomfortable part is not that it happened — it is that the account of what happened had to be reconstructed afterwards, by outside parties.
6 min read
Read the analysis →Compliance
AI guardrails in Australia: what the Voluntary AI Safety Standard, Essential Eight and Privacy Act reform mean for enterprise AI
Australia is converging on AI governance from three directions at once — safety guardrails, cyber baselines and privacy reform — and enterprise AI platforms must now prove all three.
6 min read
Read the guide →