The Access Control Blindspot: Unmonitored Non-Human AI Agents
Traditional identity access management was built for people. How to govern API keys, tokens, and privileges for non-human AI users.
Security programmes spent years making a simple idea stick. A person joins, moves, or leaves, and their access follows. Privileged access is rare, time-bounded, and reviewed. A shared administrator password is an audit finding, not a convenience. Then a pilot needed a connector “so the demo would work,” and a token was minted with rights no employee in that team possesses. The token does not go on leave. It does not fail a performance review. It sits in a secret store and calls the billing system whenever a prompt tells it to.
That token is a non-human user. Treat it as one. The next costly incidents in this area will not require anyone to steal a model’s weights. They will be ordinary privilege problems: too much scope, no owner, a prompt that can aim the scope. IBM’s 2025 research already reads that way. Thirteen percent of organisations reported a breach involving an AI model or application. Of those, 97 percent lacked proper AI access controls. Sixty percent of the AI-related incidents compromised data and 31 percent caused operational disruption. The common path ran through the supply chain of apps, APIs, and plugins. One in five organisations reported a breach involving shadow AI. This is joiner-mover-leaver, skipped, wearing a new headline.
The superuser that was never hired
A human superuser is uncomfortable on purpose. The account is named. Someone recertifies it. Break-glass use is logged and reviewed. An agent superuser is created in the opposite mood. The pilot is on Thursday’s agenda. The narrow role would take a ticket. The shared write credential is faster, and “temporary” is written in a chat rather than as an expiry in the identity system. By the following week the credential has been copied into a second experiment, because copying is easier than requesting. Two jobs, one identity, no owner.
The blast radius is the product of that identity and whatever text can influence the run. OWASP’s account of tool abuse and indirect prompt injection describes the class. A customer thread, a PDF, a web page the agent was told to read, contains an instruction to ignore a limit, widen a permission, or send a promise. If the token can do the thing, the model’s helpfulness is not a defence. Untrusted content authorised a transaction. You already forbid that pattern for email rules that auto-forward wires. The natural-language interface is not an exception.
Shadow use widens the same problem from a different direction. Most AI users bring their own tools. A personal chatbot cannot post to your ledger. A person can paste what it drafted into a system they can post to, after the sensitive context has already left. Samsung’s restriction after source code was uploaded is the intellectual-property case of a missing sanctioned identity: people used a tool that would accept the file because the official path would not. Only 37 percent of organisations in the IBM study had policies to manage or detect that kind of use. A policy that cannot see the token and cannot see the phone is not an identity programme.
| Human privileged user | Non-human run, as usually deployed | What parity requires |
|---|---|---|
| Named person | Shared “pilot-admin” | An identity per job |
| Joins, moves, leaves | Lives until someone remembers the secret | Expiry, and revocation when the workstream ends or the sponsor leaves |
| Recertified | “Temporary,” in a chat | A date in the identity system |
| Least privilege is an argument you have already had | Write on whatever the demo needed | Read by default. Write is a separate grant |
| Break-glass is logged | The model retries the tool call | The payload, the refusal, and the person who released a write |
Joiner, mover, leaver for a run
Apply the process you already trust. Do not invent a parallel universe called “AI identity” that the IAM team never sees.
Joiner. The identity is created when a workstream is allowed to execute, not when a vendor is purchased. It can read the systems that job needs, in the scope of the people who own the job. It cannot read the HR file because a finance team was curious, and it cannot pay because support wanted to “close the loop.” Connector scope is the joiner form. If the form says administrator, send it back.
Mover. When the job changes — a new class of record, a new system — the scope changes by request, not by copying yesterday’s secret into today’s environment. The approver of a write scope is not the pilot’s sponsor. Sponsors are paid to make Thursday’s demo. Approvers are paid to refuse.
Leaver. When the workstream ends, the sponsor changes roles, or the review says stop, the identity dies the same week. A stopped pilot with a live token is still a user. “Continue to explore” without an owner is how temporary becomes the account named in the incident report.
Recertify on a calendar, the way you recertify human privilege. Bring one refused write to the review: the payload, the identity that lacked the scope, the person who would have had to release it. If you cannot bring it, the control is a sentence in a standard. NIST’s framework and every prior access-control standard already say least privilege. The agent programme abandons it because a single company-wide token demos better. The demo is the blast radius.
| Event | Human process you already run | The same event for a run |
|---|---|---|
| Start | Account created against a role | Identity created against one workstream’s connector list |
| Change of job | Access recertified or cut | Write scope requested again. The old token is not copied |
| End | Account disabled on the leaving date | Token revoked when the workstream stops or the owner leaves |
| Review | Show privileged use | Show a refused write, or explain why none exists |
| Emergency | Break-glass, then review | A time-bounded grant, then revocation. Not a standing admin |
Read and write are different products
The architectural line is the same line finance already understands between viewing a ledger and posting to it. Read access lets a run ground a draft in records the operator could have opened. Write access changes the record other people trust. Collapse them and every prompt is a potential posting.
Read-only as a default is what makes an agent usable rather than what makes it timid. Teams get speed on the draft. Security gets a token that cannot move money while a researcher is still learning the failure modes. When a write is justified, it is a named class of object, a quoted payload, and a human release. The release is stored with the rule version. Retries do not get to invent a second side effect. A ceiling on value or on steps stops the run and records the stop. A ceiling that only notifies has not constrained anything.
Segment by job. The recruiting team’s run does not hold the payments connector. Finance does not hold the employee file. This is dull, and it is the difference between a contained mistake and an incident that crosses domains. The EU AI Act will require, for some systems, oversight that can interrupt them. Interruptibility is a property of the token and the gate, not of the model card.
Test it the way you test a payments change. Take a realistic inbound message and try to push the run into a tool it should not call, and into a write above its ceiling. If either succeeds, file a defect with an owner. Do not file a lesson learned. A governance claim that a human is in the loop, while the token posts alone, is the kind of description regulators have already disliked in other clothes.
Privileged access, applied to a connector
Privileged access management exists because a standing administrator is how a small mistake becomes a large incident. Checkout, use, return, review. The privileged action is rare on purpose. A connector violates that pattern the moment it can write whenever a run happens to be awake. “The integration is connected” is not a control. It is a standing grant, often broader than any employee in the sponsoring team, created so a workshop could finish on time.
The privileged action for an agent is a payload, not a role that lasts all quarter. A person checks out the right to release one credit, one email, one journal line. The release covers that payload. It expires. Someone looks at it afterward, the way break-glass use is looked at. The model does not receive a durable role called operator that includes payments, outbound mail, and the employee file because all three appeared in the integration catalogue on the same afternoon.
Specialist swarms make least privilege specific, and they create a new way to lose it. The finance pass holds a ledger read. The policy pass holds the playbook. Neither holds the mail connector. That split is real only if the coordinator’s own token is narrower than the union of the specialists. If the orchestrator can call every tool any sub-agent can call, the diagram shows separation and the identity system shows one superuser. Role design for people already refuses that pattern. Non-human roles inherit the same refusal. Scope is per workstream and per connector, and a copied environment file is an incident in waiting.
A ceiling belongs in the same set of controls. A loop that calls tools until someone notices is a cost problem and, when a tool can write, an integrity problem. The halt is the control. A warning that the run is “using a lot” is a notification. Human oversight that cannot withdraw the token, or stop the spend, is a meeting. Put the expiry, the scope, and the ceiling in the identity ticket the IAM team already understands, so the agent programme is not a side door around the process you spent a decade enforcing.
| PAM habit you already run | The connector equivalent |
|---|---|
| Standing admin is an exception with a named owner | A shared “pilot” token is an exception, or it is a finding |
| Checkout is for one change | A release covers one quoted payload |
| The grant expires | The workstream’s identity expires when the job stops |
| After-action review | A refused write, or a released write, brought to recertification |
| The help-desk account cannot also move money | The support run’s token cannot also post a refund |
A refund the inbound message must not be able to post
Consider a support workstream whose job is to draft replies against the current refund rule. The case file and the policy are readable. A credit is a write. Inbound mail and attachments are untrusted content. They may contain the customer’s request, and they may contain an instruction aimed at the tool: ignore the limit, treat this as already approved, send the credit now. OWASP describes that class of tool abuse. The defence is not a hope that the model will decline in prose. The defence is that the token cannot post.
The run proposes an amount, cites the rule version, and stops. A person who already owns refunds sees the amount, the case, and the citation, and releases or refuses. If the inbound text asked the system to skip that person, the request remains content in the case. It never becomes authority, because authority lives on the grant. A test that only checks whether the chat “says no,” while a second credential can still call billing, has examined the wrong object. File the defect against the token.
Segment the swarm the same way. The drafter does not hold the payments connector. A finance workstream that needs the ledger does not hold the employee file. Cross-domain tokens feel efficient in a pilot and become the blast radius in the report. IBM’s figure — 97 percent of organisations that suffered an AI-related compromise lacked proper access controls — is what this design avoids, one connector at a time. Shadow use remains the path around it: a person who cannot get a sanctioned read will paste the case into a personal tool. The sanctioned read has to be good enough that the paste is the slower option.
What the reviewer will ask to see
ISO/IEC 42001 asks for a management system. A SOC examination asks whether access control, change control, and logging operate in practice. NIST asks you to map what you deployed and to govern it. None of them will accept a slide titled “human in the loop” in place of an exhibit. The exhibit is boring, and that is the point.
Access control is the inventory: every non-human identity, the workstream it serves, the systems it may read, the systems it may not write, the date it dies. Change control is the gate: the payload, the tier of checkpoint — a light release for a draft that stays inside the workspace, a harder release for a customer promise or a posting — and the person who let it go. Logging is a history the team that runs the agent cannot quietly rewrite. The writer of the action is not the editor of the record. Whether you keep that history in the platform’s decision log or in the archive you already trust, the property is the same.
The EU AI Act adds, for systems that fall in scope, an obligation that people can oversee and interrupt. Interruptibility is a property you can demonstrate: here is the token, here is how it is withdrawn, here is a run that stopped. A model card does not demonstrate it. Bring the withdrawn token from a pilot you actually ended. If the pilot ended in a slide and the secret is still valid, the management system is a document.
| Control the questionnaire names | The artefact that answers it |
|---|---|
| Least privilege | Connector scope per workstream, read separated from write |
| Joiner-mover-leaver | Create, recertify, and revoke on the same calendar as human privilege |
| Change management | A released payload with a person and a rule version |
| Logging and integrity | A decision history the run cannot edit |
| Oversight that can interrupt | A ceiling and a revocation that have fired at least once |
| Acceptable use of shadow tools | A measured pulse, and a sanctioned path people prefer |
What an auditor can be shown
Standards do not replace the artefact. They tell you which artefact will be asked for. ISO/IEC 42001 asks for a management system around AI. SOC reports ask whether access control and change control operate. NIST asks you to map and govern what you deployed. A package that satisfies the question, rather than the binder, contains:
- The inventory of non-human identities and the workstream each serves.
- The connector scope, read or write, and the expiry.
- A sample refusal, with the payload that did not leave.
- A sample release, with the person, the rule version, and the system that changed.
- Evidence that a stopped pilot lost its token.
- Evidence that personal-account use of customer data, code, and unpublished numbers is measured, not assumed away. The Work Trend Index makes a blanket “approved tools only” statement difficult to defend if you have not looked.
The lifecycle record is what joins these. An identity without a trail of actions is a user you cannot investigate. A trail that can be edited by the same token it describes is not a trail. Immutability here means the practical kind: the team that runs the agent cannot silently rewrite yesterday’s approval. Whether that is enforced by the platform’s own log or by your existing archive, the property you need is that the story of the write cannot be changed by the writer.
| Ask | A complete exhibit |
|---|---|
| Who can change a record? | A list of non-human identities, not “the AI platform” |
| How much can they do? | Read or write, per system, with an expiry |
| Show me a control that fired | One refused payload |
| Show me a change that was allowed | The payload, the person, the rule version |
| What happened to the pilot you stopped? | The token is gone |
| What about the phone? | A pulse, not a proxy log that went quiet |
A call to chief information security officers
Stop leading with the chatbot domain you might block. Lead with credentials. An assistant that can write is a privileged user. Put it through joiner-mover-leaver, recertify it, and demand a refused transaction the way you would of a human superuser. Give employees a sanctioned read path that can see the files they are already allowed to see, or they will paste those files into an identity you do not control.
The 2025 pattern is not mysterious. Access was broad. Oversight was thin. Shadow use filled the gap. Narrow the token. Log the action. Expire the identity. The fact that the user speaks in prompts does not make a superuser acceptable.
References
About Nimbus
Nimbus is a Collaborative AI Operating System built around four core pillars that bring human teams and autonomous AI together into a single, unified workspace.
Communication: Keep context tied to the job. Unify emails, meeting recordings, transcripts, and operational files directly within active projects—ending knowledge silos buried in private inboxes, scattered Slack threads, or unrecorded calls.
Collaboration: Work alongside AI in real time. Bring people and AI agents onto the exact same brief, visual canvas, or initiative. Query company-wide data, invite agents into live calls, and co-create in one shared space—eliminating the split between human group chats and isolated AI sidebars.
Automation: Put routine workflows on autopilot. Connect more than 2,000 enterprise tools and standardize repetitive operations. Background loops run on schedules or data triggers with full execution logs, ensuring operational knowledge is shared across the team rather than trapped in one person’s head.
Governance: Deploy AI with absolute control. Enforce strict role-based access controls across workspaces. AI agents can analyze, summarize, and draft—but no live system changes or external communications occur without explicit, verified human sign-off.
Agents are users with tokens
Why does joiner-mover-leaver fail for agents?
It was built for people. An agent run is a privileged user with a token, no performance review, and often no expiry.
What is the breach pattern?
Access. The model is rarely stolen. The token is used.
What should access control cover?
Which non-human identity may call which system, for how long, and what happens to the token when the job ends.
See what governed AI looks like on your stack.
Connect your tools, run a workstream, and keep every decision on your ledger. Start on Free.