TL;DR
Security teams used to ask one question about a new AI tool: how accurate is it? Now there is a harder one. What is it allowed to do on its own, and can you take that back?
In our interviews with security leaders for The Security Practitioner’s Guide to AI Hype, oversight and control of AI came up on its own in 8 of 14 conversations, before we ever asked about it. The pattern was clear. Teams want AI to do more of the work. They will not hand it authority they cannot see, approve, or reverse.
That gap has a name: AI agent governance.
The Promise and the Operational Reality
When organizations talk about deploying AI agents, they typically focus on two things: what the agent can do, and how accurate it is. These are reasonable concerns in a proof-of-concept setting. They are insufficient in production.
The operational questions that actually matter (who authorized this capability, which version of this skill ran, what data did this hook touch, who can revoke this plugin, how do I roll back this behavior without redeploying the whole system) have no satisfying answers in any major agent framework today. Not because the frameworks are bad. Because no one has yet built the layer those answers require.
That layer does not exist. This essay argues that it must exist, that we can describe its architecture with reasonable precision, and that the history of software infrastructure gives us a clear map of how it will emerge if we build it deliberately.
What is AI agent governance in cybersecurity?
AI agent governance in cybersecurity is the set of controls that decide what an AI agent can do, what it must be approved for before doing, and how it records every action it takes. In practice, it covers five things: the agent’s scope, its permissions, the policies it follows, the approval gates for risky actions, and the audit trail it leaves behind.
The point is simple. It lets an AI agent do real security work without giving it authority no one can see or revoke. A copilot only advises, so your team keeps control. An ungoverned agent can act, but no one can prove what it did or stop it in time. Governed execution sits in between: the agent does the work, and your team keeps the decision rights.
Seven controls turn an AI agent into a governed one.
Governance is not a trust badge. It is a stack of controls around what the agent can do. Set all seven and an AI agent can do real security work inside limits your team owns.
Miss one layer and governed is just a label. Set all seven and it becomes something you can prove to an auditor or a board.
The Gap
System prompts live in database rows or environment variables. Tool definitions are Python class methods decorated with metadata. Hooks are registered imperatively in initialization code. Skills are documented in README files, if at all.
The result is that there is no unit (no package, no artifact, no manifest) that represents “this capability as deployed.” There is nothing to version. There is nothing to sign. There is nothing to revoke. You can’t audit at the capability level, only at the log-line level. This has three compounding consequences.
- Lifecycle Management Is Impossible in Any Coherent Sense
- Governance Has No Surface to Attach To
- Accountability Chains Break at Inference Time
What the Architecture Needs to Look Like
The solution is not a new framework. Frameworks have proliferated; the problem has not diminished. The solution is a standard, a set of specifications that any framework can implement and any enterprise can require. That standard needs five components.
- Capability Manifest
- Registry With Cryptographic Provenance
- Capability Runtime With Manifest Enforcement
- Structured Audit Bus
- Policy Sidecar
Why This Matters Now
The argument for deferring this problem is always the same: it is early, the ecosystem is moving fast, standards imposed too soon calcify the wrong abstractions. This argument was correct in 2013 for containers. It is less obviously correct today for agent capabilities, for two reasons.
- First, agents’ risk profile is qualitatively different from that of earlier infrastructure primitives. A misconfigured container crashes a service. A misconfigured agent capability (a hook that fails to apply a content filter, a tool that operates outside its intended scope, a skill that exposes data to an LLM context it was never meant to reach) can produce consequential real-world actions before anyone notices.
- Second, enterprise adoption is happening now, not in three years. Organizations are deploying agents into workflows that touch customer data, financial records, and internal communications. They are doing this without a capability governance layer because none exists. The absence of a standard doesn’t delay enterprise adoption; it means adoption happens without the accountability infrastructure it should have.
How Secure.com puts AI security governance into practice
Governance only works when it lives in the product, not in a policy document. Secure.com runs AI security teammates that do real work inside the scope, permissions, and approval gates your team sets.
- Scope and permissions: each teammate owns one function and gets only the access that function needs, so there is no open-ended reach.
- Approval gates: consequential actions pause for a human; lower-risk work keeps moving within policy.
- Full evidence trail: log every recommendation, approval, and action so you can show an auditor or board exactly who decided what.
- Above your stack: teammates work with the tools you already own, with no rip-and-replace.
- Start with one: land a single teammate, prove the model in days, and add more only once you trust it.
Bottom Line
- What are the governance requirements your organization is currently trying to solve without the right tools?
- What should a capability manifest actually contain?
- Where does this architectural sketch need revision? This conversation needs more voices.
