The Shadow Agent Problem
We've spent years securing who can access our systems.
The next challenge is governing what autonomous AI is allowed to do once it has access.
Imagine this:
A developer creates an AI agent using a personal API key, connects it to internal tools, and gives it permission to read customer data, call internal APIs, deploy code, or trigger business workflows.
No procurement process.
No centralized registration.
No security review.
The agent authenticates successfully and starts taking actions.
This is what I think of as the Shadow Agent Problem.
It's similar to the Shadow IT and Shadow SaaS challenges enterprises faced years ago—but with one critical difference:
AI agents don't just access information. They act on it.
They can initiate payments, modify infrastructure, interact with production systems, and automate decisions at machine speed.
That's why traditional controls aren't always enough.
Identity, procurement, and access management remain essential, but they primarily answer:
"Who is allowed to connect?"
They don't necessarily answer:
"Should this specific action be allowed to happen right now?"
I believe governance needs to exist at the execution layer.
Instead of evaluating only the identity of the agent, evaluate the action itself before it reaches the real world.
For example:
Should this payment be approved?
Should this deployment proceed?
Should this API call be allowed?
Should this database query execute?
Should this infrastructure change be blocked?
Every high-impact action becomes a policy decision.
Not after execution.
Before execution.
A possible architecture could include:
A policy engine that evaluates every high-impact action against organizational rules.
Approval workflows for sensitive operations.
A complete audit trail explaining what was attempted, why it was approved or rejected, and under which policy.
Real-time interception before external systems are affected.
One advantage of this model is that it doesn't require security teams to know about every AI agent in advance.
Instead of trying to catalog every possible agent, you govern the actions they perform.
As autonomous AI becomes more common inside enterprises, I think this architectural pattern will become increasingly important.
I'm curious how others are approaching this problem.
Are you enforcing governance at the tool/function-call layer?
Using policy engines like OPA?
Building middleware around agent frameworks?
Or taking a completely different approach?
I'd love to hear how you're thinking about execution governance for AI agents.
Top comments (4)
The execution-layer governance angle is the strongest part here. I’d push it one step further: the policy engine shouldn’t only evaluate the action, but the context in which it was generated agent identity, tool, target resource, requested scope, data provenance, and current system state. That makes policies like “allow this API call in staging, but require approval in production” possible without relying on the agent to make that distinction correctly.
For production agent systems, I think this separation between intent → policy decision → execution is becoming as important as authentication itself. It also gives security teams a much cleaner place to enforce controls without needing to understand every agent implementation.
Thanks—this is a great point. I completely agree that context is just as important as the action itself. The same operation can have very different risk depending on who initiated it, which resource is being accessed, the environment (staging vs. production), and the current state of the system.
I really like the way you framed it as intent → policy decision → execution. That's very close to how I'm thinking about Ex. The goal isn't simply to authorize an API call, but to evaluate whether the proposed action should happen in its full operational context before it reaches the real world.
I also like your observation that this gives security teams a single governance layer, rather than requiring them to understand every individual agent implementation. That's one of the long-term ideas I'm exploring with Ex. Thanks for sharing your perspective.
The Shadow Agent framing lands. The payment example especially - most teams treat agent payment ability as a gateway auth check, but that answers "is this key valid?" not "should this 00 charge happen at 3 AM?"
Execution-layer governance is the right layer to solve it. The key is separating the agent's ability to propose an action from its ability to complete it. An agent can commit to a payment cryptographically but still needs a human cosign before the money moves. That puts the policy decision right where it belongs: between the proposal and the execution, not before the session starts.
Been working on something in this space. The design constraint that drove most of our choices was keeping the agent's signing key on a separate channel from the user's approval - the agent never holds the key to finish what it started. That maps pretty directly to what you're describing about evaluating the action rather than the identity.
Good framing. Curious what runtime you're targeting first.
Thanks—I really like the distinction you made between an agent proposing an action versus completing it. That captures the direction I'm thinking about with Ex. My goal isn't to stop AI from acting; it's to ensure that high-impact actions are evaluated before they reach the real world.
For the first runtime, I'm thinking about environments where AI agents already interact with enterprise systems through APIs and tools—coding agents, workflow automation, and enterprise integrations seem like practical starting points. The long-term vision is broader: a governance layer that can sit between autonomous AI and any high-impact execution environment, regardless of the underlying agent framework.
I'm still exploring the architecture and really appreciate hearing how others are approaching this problem.