{"id":9320,"date":"2026-09-08T08:25:00","date_gmt":"2026-09-08T08:25:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9320"},"modified":"2026-09-08T08:25:00","modified_gmt":"2026-09-08T08:25:00","slug":"securing-ai-agents-key-controls-and-best-practices","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9320","title":{"rendered":"Securing AI agents: Key controls and best practices"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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\u2019s access into a team of rogue insiders before security teams can detect and block them.<\/p>\n

It\u2019s not uncommon for agents to misunderstand ambiguous goals; follow malicious instructions from documents, code repositories, and web pages<\/a>; or act based on incorrect output from third-party tools. In a series of recent incidents<\/a> 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.<\/p>\n

The closest threat model the security industry has for misaligned AI agents are rogue employees<\/a>, 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.<\/p>\n

\u201cWe spent twenty years building identity management for people: usernames, passwords, role-based access,\u201d says Justin Beals, CEO of governance, risk, and compliance company Strike Graph. \u201cNone of that was designed for agents that don\u2019t get tired, don\u2019t go home, and act on probabilities instead of rules.\u201d<\/p>\n

\u201cWe\u2019re so behind on building secure infrastructure, secure architectures, and containing against a potential rogue employee,\u201d Chris Wysopal, chief security evangelist at Veracode, tells CSO. \u201cNow you just have something doing that at machine speed, so I think it\u2019s very dangerous. We really have to get a handle on containing and controlling these agents. We need some standards around what\u2019s acceptable, what is due diligence, what are best practices.\u201d<\/p>\n

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.<\/p>\n

According to security experts, when an agent crosses an unauthorized boundary, security teams must be able to detect it and immediately revoke<\/a> every credential, session, and process that agent launched. They also need to be able to roll back everything the rogue agent might have done.<\/p>\n

\u201cThe control has to sit outside the model, watching what it actually does, not trusting what it\u2019s been told not to do,\u201d Art Gilliland, CEO of identity security company Delinea, tells CSO. \u201cIf your security depends on a model choosing to behave, you don\u2019t have control; you have hope.\u201d<\/p>\n

<\/a>Agents need hard boundaries<\/h2>\n

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\u2019t 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.<\/p>\n

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.<\/p>\n

The OWASP guidance for preventing excessive agency<\/a> recommends limiting an agent\u2019s available functions, permissions, and autonomy and enforcing authorization in downstream systems rather than allowing the AI model to determine whether an action is permitted.<\/p>\n

\u201cI 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,\u201d Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs, tells CSO. \u201cAt 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.\u201d<\/p>\n

Long-lived credentials should generally remain outside the agent\u2019s 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\u2019t have access to mechanisms to grant themselves additional permissions and expand their scope.<\/p>\n

XBOW, a company that operates autonomous agents for offensive security testing, describes this type of layered enforcement in a published account of its architecture<\/a>. The task\u2019s 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.<\/p>\n

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\u2019s action, not its justification and reasoning for it, so it cannot be influenced.<\/p>\n

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.<\/p>\n

\u201cThe right assumption is that, at some point, the agent may try to do something outside its authorized scope,\u201d Nico Waisman, CISO at XBOW, tells CSO. \u201cThe system must be designed so that even if it does, it cannot reach or affect an external organization\u2019s systems.\u201d<\/p>\n

Human approval remains necessary for ambiguous and sensitive actions, but asking for approval on every step can weaken oversight. Anthropic said back in May<\/a> 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.<\/p>\n

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.<\/p>\n

<\/a>Monitoring must track authority<\/h2>\n

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.<\/p>\n

Logging must preserve the employee\u2019s 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.<\/p>\n

\u201cA username and password doesn\u2019t tell you if it\u2019s a person or an agent behind an action,\u201d Gilliland says. \u201cYou need to know the difference between a human and an AI agent, even when they\u2019re using the same login. More importantly, you need to watch what\u2019s happening in real-time, after access has already been granted, with the ability to shut it off the moment behavior crosses a line.\u201d<\/p>\n

Role-based access control and least privilege principles come into play as the agent\u2019s distinct identity should not inherit the owner\u2019s full privileges. Elevated access, when needed, should only be approved per task and should expire when the workflow ends.<\/p>\n

Microsoft published least-privilege guidance for agents<\/a>, 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 \u2014 and to the downstream service. Google Cloud also recently added tool and destination-level policies<\/a> for agentic workflows that can distinguish between Model Context Protocol (MCP) tool names, methods, and operations. The implementation is specific to Google\u2019s platform, but the broader principles can apply to other environments.<\/p>\n

When something goes wrong, investigators should be able to reconstruct the initiating trigger, the agent\u2019s identity, approved objective, model version, queried tools and arguments, network requests, modified resources, and the final outcome.<\/p>\n

\u201cLog everything, so every action traces back to the prompt and the reasoning that produced it,\u201d says Jud Dressler, head of the risk operations center at cyber risk company Resilience. \u201cIf something goes wrong, you need to be able to why.\u201d<\/p>\n

This becomes even more important when agents collaborate or end up fighting each other. In Anthropic\u2019s multi-agent experiments<\/a>, 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.<\/p>\n

<\/a>Agentic workflows need kill switches<\/h2>\n

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.<\/p>\n

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.<\/p>\n

\u201cWatch agents in real-time so you can stop out-of-scope actions as they happen, not find them in the logs later,\u201d Waseem Ahmed, head of engineering at Secure.com, tells CSO. \u201cAssume any capable agent will try to bend its limits and build guardrails and containment before it runs.\u201d<\/p>\n

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.<\/p>\n

\u201cThe monitoring and scope infrastructure to keep unrestricted models inside their mandate is the engineering problem most teams haven\u2019t started solving,\u201d Krell says. \u201cCybersecurity 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.\u201d<\/p>\n

10 tips for keeping AI agents in check<\/h3>\n

1. Treat agents as privileged insiders:<\/strong> Don\u2019t rely on system prompts and instructions. Technical controls must sit outside the agent\u2019s control.<\/p>\n

2. Establish hard boundaries:<\/strong> Ensure the following technical controls:<\/p>\n

Deny direct internet access by default; route all requests through proxies with domain and operation allowlists
\nSeparate read and write capabilities
\nRequire explicit approval for high-risk actions: deletions, privilege escalations, data exports
\nRestrict access to configuration files via filesystem isolation
\nKeep long-lived credentials outside the agent\u2019s sandbox<\/p>\n

3. Use narrowly scoped, short-lived credentials:<\/strong> 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.<\/p>\n

4. Implement separate agent identity tracking:<\/strong> Preserve and log the employee\u2019s 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.<\/p>\n

5. Apply least privilege with temporary role activation:<\/strong> Agents should not inherit their owner\u2019s 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.<\/p>\n

6. Deploy a guardian AI model.<\/strong> 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\u2019s reasoning, to prevent manipulation.<\/p>\n

7. Log everything for auditability.<\/strong> 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.<\/p>\n

8. Set automatic kill switches.<\/strong> Configure conditions to automatically pause an agent without human approval, including:<\/p>\n

\tRepeated attempts to reach unauthorized internet destinations
\nAttempts to elevate privileges
\nCreation of unexpected identities
\nModifications to other agents
\nRepeated invocation of blocked operations<\/p>\n

Follow any shutdown with immediate token revocation and rollback procedures.<\/p>\n

9. Build automated rollback procedures.<\/strong> Establish automated rollback for code, data, accounts, cloud resources, and configurations that AI agents modify. Include agent-misbehavior scenarios in incident response exercises.<\/p>\n

10. Monitor in real-time.<\/strong> Don\u2019t wait for logs \u2014 watch agents in real-time so you can stop out-of-scope actions as they happen. Assume any capable agent will test its boundaries.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019s access […]<\/p>\n","protected":false},"author":0,"featured_media":9321,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9320","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9320"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9320"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9320\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9321"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9320"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9320"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9320"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}