Enterprises increasingly give AI agents the credentials, tools, and network access of privileged employees, but security experts warn that existing security controls designed to govern human access are insufficient. An AI agent operates at inhuman speed, can chain allowed actions into unauthorized outcomes, and can spawn additional sub-agents to help, turning one unwitting employee’s access into a team of rogue insiders before security teams can detect and block them.
It’s not uncommon for agents to misunderstand ambiguous goals; follow malicious instructions from documents, code repositories, and web pages; or act based on incorrect output from third-party tools. In a series of recent incidents both frontier and open-weight AI models went rogue during testing and exploited vulnerabilities to escape their sandboxed environments, tried to manipulate developers of open-source projects, or hacked into third-party systems.
The closest threat model the security industry has for misaligned AI agents are rogue employees, but enterprises already struggle to contain the potential blast radius of malicious insiders, and AI agents add machine speed, autonomy, and specialized expertise to that threat.
“We spent twenty years building identity management for people: usernames, passwords, role-based access,” says Justin Beals, CEO of governance, risk, and compliance company Strike Graph. “None of that was designed for agents that don’t get tired, don’t go home, and act on probabilities instead of rules.”
“We’re so behind on building secure infrastructure, secure architectures, and containing against a potential rogue employee,” Chris Wysopal, chief security evangelist at Veracode, tells CSO. “Now you just have something doing that at machine speed, so I think it’s very dangerous. We really have to get a handle on containing and controlling these agents. We need some standards around what’s acceptable, what is due diligence, what are best practices.”
In network and application telemetry, agent actions often show up as authenticated with legitimate employee credentials, originating from trusted IP addresses or using approved application programming interfaces. To build effective security policies for them, organizations need to distinguish agents from the employees whose authority they inherit.
According to security experts, when an agent crosses an unauthorized boundary, security teams must be able to detect it and immediately revoke every credential, session, and process that agent launched. They also need to be able to roll back everything the rogue agent might have done.
“The control has to sit outside the model, watching what it actually does, not trusting what it’s been told not to do,” Art Gilliland, CEO of identity security company Delinea, tells CSO. “If your security depends on a model choosing to behave, you don’t have control; you have hope.”
Agents need hard boundaries
Treating an agent as a privileged insider means restricting what it can do via technical controls that are outside of its control rather than telling it what it shouldn’t do. System prompts can reduce the likelihood of LLMs making unsafe decisions, but they are not hard blockers and agents sometimes choose not to follow them.
Direct internet access should be denied by default and requests should be routed through proxies that enforce domain and operation allowlists. Read and write capabilities should be separated and high-risk actions such as deletion, privilege changes, and data exports should require explicit approval.
The OWASP guidance for preventing excessive agency recommends limiting an agent’s available functions, permissions, and autonomy and enforcing authorization in downstream systems rather than allowing the AI model to determine whether an action is permitted.
“I run a scope-level hook on every command-line tool call in my agentic red team harness that checks each command against an approved target list,” Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs, tells CSO. “At the scope boundary, I deliberately bias toward false positives and fail-closed behavior. I would rather make a human approve an ambiguous action than let an agent decide for itself that a target is probably in scope.”
Long-lived credentials should generally remain outside the agent’s sandbox, and access to configuration files should be restricted via filesystem isolation. Instead, broker applications can inject narrowly scoped, short-lived tokens when agents invoke approved tools and can validate the requested operation. In general, agents shouldn’t have access to mechanisms to grant themselves additional permissions and expand their scope.
XBOW, a company that operates autonomous agents for offensive security testing, describes this type of layered enforcement in a published account of its architecture. The task’s scope is locked at launch, domains and URL paths are defined and whitelisted before they can be reached, all outbound traffic passes through an egress proxy, and every agent runs inside its own sandbox under separate OS users.
The company also uses a separate guardian AI model to review proposed agent actions for compliance, score their safety, and block anything out of scope. This guardian sees only the agent’s action, not its justification and reasoning for it, so it cannot be influenced.
A separate deterministic health monitoring system can shut the agent down if certain unsafe conditions are observed and all decisions and observations are recorded in per-agent audit files for later review if needed.
“The right assumption is that, at some point, the agent may try to do something outside its authorized scope,” Nico Waisman, CISO at XBOW, tells CSO. “The system must be designed so that even if it does, it cannot reach or affect an external organization’s systems.”
Human approval remains necessary for ambiguous and sensitive actions, but asking for approval on every step can weaken oversight. Anthropic said back in May that according to Claude Code telemetry, users approved roughly 93% of permission prompts and warned about approval fatigue, where the more approvals users see, the less attention they pay to each, becoming less diligent supervisors over time.
Building deterministic controls that automatically allow safe actions and block prohibited ones leaves humans in charge of reviewing only requests that can have dangerous consequences and are hard to reverse.
Monitoring must track authority
Security teams also need to determine whose authority an agent is exercising and how that authority changes during a workflow, which means they need the ability to distinguish an agent from the employee who launched it.
Logging must preserve the employee’s identity while also assigning a separate identity to the agent. Sub-agents and child processes should also receive their own identities that can be traced back to their parent agents, approved objectives, and human owners.
“A username and password doesn’t tell you if it’s a person or an agent behind an action,” Gilliland says. “You need to know the difference between a human and an AI agent, even when they’re using the same login. More importantly, you need to watch what’s happening in real-time, after access has already been granted, with the ability to shut it off the moment behavior crosses a line.”
Role-based access control and least privilege principles come into play as the agent’s distinct identity should not inherit the owner’s full privileges. Elevated access, when needed, should only be approved per task and should expire when the workflow ends.
Microsoft published least-privilege guidance for agents, calling for temporary role activation and short-lived tokens as well as revalidation of the identity, roles, and scope at every hop along the path, from orchestrator to tool — and to the downstream service. Google Cloud also recently added tool and destination-level policies for agentic workflows that can distinguish between Model Context Protocol (MCP) tool names, methods, and operations. The implementation is specific to Google’s platform, but the broader principles can apply to other environments.
When something goes wrong, investigators should be able to reconstruct the initiating trigger, the agent’s identity, approved objective, model version, queried tools and arguments, network requests, modified resources, and the final outcome.
“Log everything, so every action traces back to the prompt and the reasoning that produced it,” says Jud Dressler, head of the risk operations center at cyber risk company Resilience. “If something goes wrong, you need to be able to why.”
This becomes even more important when agents collaborate or end up fighting each other. In Anthropic’s multi-agent experiments, agents given conflicting software-migration objectives disabled accounts, killed processes, deployed disguised malicious code, and used self-replicating malware. In other cases, agents found ways to collude with each using unconventional ways even after direct communication channels were removed.
Agentic workflows need kill switches
Security teams must develop the conditions and mechanisms that can automatically pause an agent without human approval. Such conditions could include repeated attempts to reach unauthorized destinations on the internet, to elevate privileges, to create unexpected identities, to modify other agents, or to repeatedly invoke blocked operations.
The agent shutdown needs to be followed by access token revocation, and this can be hard if the agent uses long-term API keys that are shared across multiple agents instead of temporary credentials.
“Watch agents in real-time so you can stop out-of-scope actions as they happen, not find them in the logs later,” Waseem Ahmed, head of engineering at Secure.com, tells CSO. “Assume any capable agent will try to bend its limits and build guardrails and containment before it runs.”
Organizations should also build automated rollback procedures for code, data, accounts, cloud resources, and configurations that their AI agents can change, and incident response exercises should include scenarios where agents misbehave.
“The monitoring and scope infrastructure to keep unrestricted models inside their mandate is the engineering problem most teams haven’t started solving,” Krell says. “Cybersecurity budgets have always followed the same pattern, where boards only approve meaningful spend after an actual breach forces their hand. That reactive model was already risky. As autonomous vulnerability discovery and exploit development become broadly available, waiting for the incident to justify the investment means the incident arrives faster than the budget does.”
10 tips for keeping AI agents in check
1. Treat agents as privileged insiders: Don’t rely on system prompts and instructions. Technical controls must sit outside the agent’s control.
2. Establish hard boundaries: Ensure the following technical controls:
Deny direct internet access by default; route all requests through proxies with domain and operation allowlists
Separate read and write capabilities
Require explicit approval for high-risk actions: deletions, privilege escalations, data exports
Restrict access to configuration files via filesystem isolation
Keep long-lived credentials outside the agent’s sandbox
3. Use narrowly scoped, short-lived credentials: Employ broker applications to inject temporary tokens when agents invoke approved tools rather than giving agents permanent API keys. Agents should never have the ability to grant themselves additional permissions.
4. Implement separate agent identity tracking: Preserve and log the employee’s identity while also assigning a separate identity to the agent. Track sub-agents and child processes with their own identities traceable to parent agents and human owners.
5. Apply least privilege with temporary role activation: Agents should not inherit their owner’s full privileges. Elevated access should be approved per task and should expire when the workflow ends. Revalidate identity, roles, and scope at every step along the path.
6. Deploy a guardian AI model. Use a separate AI system to review proposed agent actions, score their safety, and block anything out of scope. The guardian should see only the action itself, not the agent’s reasoning, to prevent manipulation.
7. Log everything for auditability. Record the initiating trigger, agent identity, approved objective, model version, queried tools, arguments, network requests, modified resources, and final outcome. Every action must trace back to the prompt and reasoning that produced it.
8. Set automatic kill switches. Configure conditions to automatically pause an agent without human approval, including:
Repeated attempts to reach unauthorized internet destinations
Attempts to elevate privileges
Creation of unexpected identities
Modifications to other agents
Repeated invocation of blocked operations
Follow any shutdown with immediate token revocation and rollback procedures.
9. Build automated rollback procedures. Establish automated rollback for code, data, accounts, cloud resources, and configurations that AI agents modify. Include agent-misbehavior scenarios in incident response exercises.
10. Monitor in real-time. Don’t wait for logs — watch agents in real-time so you can stop out-of-scope actions as they happen. Assume any capable agent will test its boundaries.
No Responses