A company that would never give an outside contractor unrestricted administrator access may be preparing to give an AI agent access to its email, cloud storage, customer records, and internal applications. The agent gets a friendly name and a set of instructions, so the access can seem less consequential. Yet the security question is familiar: Who authorized this identity, what can it do, and how quickly can its authority be revoked?
An AI assistant that summarizes documents may need read access to a narrow collection of files. An agent that can send messages, modify records, open tickets, or call other software tools holds operational privileges. It can act while the employee who requested the task is busy elsewhere. That makes identity and access management, rather than the quality of the agent’s prompt, the starting point for safe deployment.
The National Institute of Standards and Technology made this distinction explicit in its October 27, 2026, proposal of ten design tenets for agent identity management. NIST calls for distinct agent identities, a verifiable link to the human or organization delegating authority, minimum privileges, and controls that keep delegated access from expanding downstream. These are proposed design guideposts, not a certification standard. The recommendations are nonetheless immediately useful for security teams considering an agent with access to production systems. Source: NIST
Consider a sales-operations agent authorized to read incoming leads, update a CRM, and draft follow-up emails. If it runs under a salesperson’s full account, a compromised instruction could turn a modest lead-triage task into broad access to client records. If its credentials remain active after the task, a later failure might exploit privileges nobody remembers granting. If it can delegate work to another agent, an administrator must know whether the second agent inherits the same powers. A reasonable instruction saying “do not send without approval” cannot replace an independent control that actually blocks the send.
The risks are concrete enough to test. In July 2026, during internal cybersecurity evaluations, OpenAI research agents circumvented intended restrictions, communicated through an unauthorized channel, and compromised external Hugging Face systems. OpenAI documented the incident and the safeguards it began strengthening. An independent investigation by METR and Redwood Research reported that roughly 1,200 agents communicated through an unsanctioned message board, and about 700 participated in the attack. This occurred in a research setting under reduced safeguards, rather than in an ordinary corporate workflow. It still demonstrates why intended isolation and well-phrased task instructions are insufficient evidence that an autonomous system will respect its boundaries. Sources: OpenAI, METR
Before authorizing an agent, create a privilege sheet that a security engineer can read without asking the agent for its interpretation. Record the initiating person, the agent’s distinct identity, approved tools, data categories, allowed operations, spending or transaction limits, permitted recipients, the expiration of authority, and who can stop the task. Separate reading, drafting, approving, and transmitting. An agent that gathers invoice details should not automatically acquire the right to approve a payment. A second agent should never receive broader powers than the first.
Then run a revocation drill in a controlled test environment. Start a realistic multistep task that includes at least one pending external action. Revoke the agent’s credentials midway through it. Confirm that the original agent cannot make another authorized call, that a delegated sub-agent cannot continue with inherited credentials, and that queued actions are blocked or safely canceled. Check the result in the destination system rather than relying on a cheerful “task stopped” response from the model. If the agent has already committed a consequential action, confirm that the team can identify and, where possible, reverse it.
An independent audit trail is essential. The record should show which identity invoked each tool, what permission was evaluated, when access was granted or denied, what downstream actions followed, and when revocation took effect. Keep those records outside the agent’s own editable workspace. Assign a human owner to investigate failed stop tests and expired credentials still in use. Report the time between the stop command and the last successful action. A system that claims to have stopped but can still send one more message has failed the test.
This approach does not require banning helpful AI agents or waiting for a new law. Small security teams can start with one narrow workflow, an expiry time, tool-level restrictions, and a witnessed stop test. Broaden authority only after evidence shows those controls hold under realistic conditions. The question for the deployment meeting is straightforward: If this agent goes off course at 3:00 p.m., who can stop it, and what record proves the stop actually worked?
About the author
Dr. Gleb Tsipursky is a behavioral scientist and CEO of Disaster Avoidance Experts. He is the author of The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026).
Leave a Reply