Closing the agent governance gap

The emerging challenge with AI agents isn’t simply preventing attacks from external rogue AI agents; it’s accounting for what your own agents are doing on the inside. AI agents are already rewiring how organizations operate, and we’re only in the first inning. Recent incidents, however, have exposed the risk for individuals and enterprises alike. This is happening because organizations are moving fast and pushing themselves to move even faster. 

In this environment, AI agents have created edge cases that reveal real risks when deployed without sufficient security controls. And further, no one can predict the impact of advances coming over the next six months. All of this reinforces the need to get security fundamentals right. If you’re building with AI agents right now, you know the real challenge isn’t just getting them to run. It’s knowing what happens when they act on their own. That starts with three questions. What agents do I have in my environment? What are they doing? And what are they capable of doing?  

The proliferation problem  

Agentic governance is problematic because enterprises must track a sprawling agent landscape AND ensure each agent is built and deployed securely. Also, agentic adoption is frictionless. Creating an agent is only one API call away from a model provider. Vibe coding means any curious employee can build an agent. This triple proliferation of vendor agents, platform native agents and homegrown agents compounds the problem. 

Visibility is the starting line  

There is the famous security adage that you can’t protect what you can’t see. Right now, most organizations lack basic visibility into what agents are in their environments. According to Anthropic, 82 percent of organizations have discovered unregistered agents in their network, and 57 percent already deploy agents for multi-stage workflows.  

In addition to basic visibility, enterprises also need to understand other related attributes, such as who onboarded the agents, what access privileges they have and how they are behaving as designed. For example, an over-provisioned agent, like an email agent with 50 tools attached, would be suspect and worth investigating.  

Security teams also need one view of their agents across every platform they run on, because each platform has its own permissions and its own telemetry. When each agent has a single record, security teams can connect what it can do on one platform with what it can do on another, and compare both with what the agent was built to do. That’s how seemingly routine activities add up to an attack chain. An agent might read customer records in one cloud, hold a credential for a payments API in another and be able to send messages from a SaaS application. No single platform sees a problem, but together they form a path to move sensitive data out of the company that the agent’s intended scope never required. Similarly, an agent that gains permissions across several platforms over time might never trigger an alert in any one of them, yet the combined record shows how its reach has far exceeded its purpose.   

Governance must extend from build-time to runtime  

Shift-left security helps find model or tool vulnerabilities before deployment, to find risks before an agent goes into production. That’s a necessary first step, but insufficient. Agents create tightly coupled runtime behavior-to-vulnerability. Unlike traditional software, AI agents exhibit behaviors at runtime that can’t necessarily be predicted by inspecting the code in the development phase. Code analysis can’t uncover prompt hijacking, poisoned context or goal drift. 

The model has evolved from “secure the code, then ship it” to continuous behavioral oversight at execution time, layered on top of build-time governance. Pre-deployment security analysis is still required because spec-driven development enforces checkpoints before code is generated. But runtime monitoring is also necessary to detect exposures in the production environment and enforce what agents do versus what they’re scoped to do. 

In practice, this means applying two layers of control to every agent. The first layer is runtime behavioral boundaries. These define what an agent can do. They determine what the agent can reach, what it can return and where it must stop and ask for human approval. This is the enforcement mechanism that operationalizes runtime governance. The second layer is identity controls. These define what an agent is allowed to touch.  

Think of every agent like a scoped, temporary employee with an expiration date. You enforce this by applying familiar IAM principles to agents. Least privilege. Short-lived credentials. Multi-factor authentication for long-lived credentials. Just like an individual contributor engineer shouldn’t get access to the broader team’s payroll, a code generation agent shouldn’t be provisioned to push directly to production environments. An agent designed to answer customer queries shouldn’t get read/write access to the customer database. An IT helpdesk agent doesn’t need domain admin privileges to alter security policies. 

Prioritize by exploitability, not severity  

AI-fueled exploits are breaking down CVE-based severity scoring. The status quo is security teams patching the most critical vulnerabilities first. But attackers don’t always work that way. They can now use agents to chain low-severity vulnerabilities together in ways that render individual scores meaningless while building attack paths that combine for a devastating impact.  

For example, an agent might combine an information disclosure flaw, a misconfigured service account and an unpatched privilege escalation into a single attack path that reaches sensitive data, even though none of those vulnerabilities would individually trigger an urgent patch cycle. If that path leads to customer PII or financial records, organizations face regulatory action under frameworks like GDPR, HIPAA or PCI DSS. If it exposes API keys, service credentials or internal network configurations, the attacker gains a foothold for lateral movement across the environment. 

Context is critical. A vulnerability in network-isolated code is much less dangerous than the same vulnerability in an internet-facing service. Rather than treating every vulnerability in isolation, the better approach is to prioritize based on exploitability within the actual runtime environment. Factor in what’s reachable, what damage an attacker could do and the business impact.  

The new security fundamentals for agents 

The emerging challenge with AI agents is accounting for what your own agents are doing inside your enterprise. In this environment, enterprises need visibility, runtime governance and exploitability-based prioritization. To that end, the security fundamentals you already know still matter. You should already be applying least privilege, short-lived credentials, MFA for the necessary long-lived credentials, automated pipelines and proper testing to secure your corporate environment. These controls limit what an agent can access and what damage it can do if compromised. You will also want to add the agent-specific fundamentals mentioned earlier: visibility, continuous behavioral oversight, identity controls and exploitability-based prioritization. These capabilities tell you what your agents are doing, whether they should be taking those actions and how to intervene when they drift. Together, pre-agentic security fundamentals and agent-specific best practices provide the baseline governance guardrails to secure AI agents. 

Organizations that get this right can accelerate agentic deployments at scale, unlocking innovation while minimizing unintended consequences.