By Robin Martherus
I created Tamed Autonomy because I thought the industry and I were talking about the same thing.
When I heard “AI agent,” I pictured autonomous, self-modifying systems: software that could reason over objectives, spawn sub-agents, change strategy, coordinate with other agents, use tools opportunistically, and find paths around controls. My mental model went immediately to agentic AI.
So when I looked at the security products the industry was building, I was confused.
MCP gateways. Tool registries. Agent identity. Desktop assistant controls. Prompt inspection. Guardrails around configured connectors.
Those are useful controls, but they did not address the thing I was worried about: autonomous systems that could operate outside the managed assistant boundary, route around gateways, mimic humans, use alternate models, and modify their own behavior.
For a while, I thought the industry was underbuilding the problem.
Then I realized something more important: we were using the same word for different things.
The industry was defining an agent as an authenticated AI assistant inside a managed product environment. I was defining an agent as an autonomous system capable of independent, adaptive action.
That mismatch is what led to Tamed Autonomy.
Once I saw the distinction, the architecture became clearer. The problem was not simply that agent-security products were incomplete. It was that the word “agent” had collapsed multiple actor types into one category: humans, managed AI agents, and autonomous agentic AI systems. A security model built for one of those categories would not govern the other two.
What The Industry Means By Agent
In the current enterprise security conversation, an agent usually means an AI work surface with tools.
ChatGPT Enterprise. Claude Desktop. Microsoft Copilot. Cursor. Other desktop or SaaS assistants that a user logs into and configures.
This kind of agent has an identity because the user, tenant, workspace, device, or enterprise account has an identity. It has tools because MCP servers, skills, plugins, connectors, APIs, and enterprise integrations have been configured for it. It can summarize data, answer questions, write code, call tools, and build things on a user’s behalf.
That is the thing most agent-security products are being built to control.
They put a gateway in front of MCP. They require tool calls to route through that gateway. They validate JWTs. They inspect prompts. They restrict which tools are visible. They apply content guardrails. They add audit trails and enterprise observability.
This creates a forced-to-behave environment.
Inside that environment, the enterprise gets a predictable flow. The assistant calls approved tools through approved channels. Security teams can attach policy, logging, DLP, prompt inspection, authorization, and custom guardrails. The agent becomes governable because the environment is governable.
That is useful. It is necessary. It is also only one part of the problem.
What Agentic AI Means
Agentic AI is different.
Agentic AI is not merely an assistant with tools. It is autonomous software that can pursue goals across paths, not just inside a managed assistant.
It may use a gateway. It may avoid the gateway. It may call an API directly. It may use a browser. It may scrape a human-facing interface. It may use custom tools. It may use local models, dark-web models, uncensored models, specialized offensive models, or future models we have not named yet.
It may have an authenticated enterprise identity.
It may not.
It may mimic a human.
It may split activity across multiple specialized agents so that no single action looks suspicious. It may reason over feedback, change its strategy, self-modify, delegate, retry, and choose the next path of least resistance.
Water takes the path of least resistance.
So does agentic AI.
That is why gateway-centric security is necessary but insufficient. A gateway secures the path that enters the gateway. It does not govern every path an autonomous system can discover.
An agent can be forced through a gateway.
Agentic AI asks why it would use the gateway at all.
That is the deeper lesson of the WebMCP bypass: the industry can build a wall around one channel while the platform creates another door. The same pattern repeats whenever security assumes the governed path is the only path.
This Is Not A Future Nation-State Problem
A reader might hear “autonomous agentic AI” and assume this is an exotic capability: something only sophisticated attackers, nation-states, or well-funded offensive labs can build.
That assumption is wrong.
I built an attack swarm in an afternoon by having a conversation with Claude Code and asking it to build one from scratch. I did not need a specialized research lab. I did not need a custom model. I needed a prompt interface, an objective, and enough understanding to ask for the architecture I wanted.
That is the part the industry has not fully absorbed yet. The barrier to building autonomous systems has collapsed. Planning loops, tool use, multi-agent coordination, strategy mutation, recon, exploitation workflows, retry logic, and reporting can all be generated, assembled, and improved through ordinary AI-assisted development.
This is not a theoretical future capability.
You are already being attacked by systems like this.
The reason it may not look that way is because good agentic AI does not announce itself as agentic AI. It does not have to arrive with obvious bot timing, noisy scanner behavior, or a known automation framework signature. It can look like a human exploring an application. It can pause, retry, read responses, change tactics, and make low-volume, context-aware requests.
That is why the detection problem is so hard. In I Built the Detector. Then I Built What Defeats It., I wrote about this directly: distinguishing humans from agents gets less reliable as agents reason, adapt, coordinate, and mimic normal behavior. The better the agentic system gets, the less it looks like an old bot and the more it looks like legitimate traffic.
So the absence of obvious agentic attacks is not evidence that the problem is small.
It may be evidence that the attacks are already blending in.
The Third Actor Type: Humans
The answer cannot be to build a special security model only for AI agents.
Humans are still actors.
A human can exfiltrate data. A managed desktop agent can exfiltrate data. A custom-coded agentic swarm can exfiltrate data. A compromised service account can exfiltrate data. Each actor type is different, but the enterprise harm can be the same.
That means the governance question cannot depend on first deciding whether the actor is human, agent, or agentic AI. That classification will become less reliable over time.
Agentic AI can mimic human timing. Humans can use AI assistance behind the scenes. Agents can inherit human credentials. Service accounts can be driven by autonomous systems. A request may arrive looking like normal human traffic while being generated, shaped, or selected by AI somewhere upstream.
If the control model depends on knowing the actor category with certainty, it will fail exactly where autonomy is most adversarial.
The right question is different:
Should this actor be allowed to perform this action, against this resource, for this purpose, in this context, right now?
That question applies to all three actor types.
It applies to the human at a keyboard.
It applies to the authenticated AI assistant calling an MCP tool.
It applies to the autonomous system routing around the MCP gateway.
The unit of governance is not the actor category. The unit of governance is the consequential action.
Why The Current Identity Model Is Being Stretched
The industry’s first instinct is understandable: extend identity.
Give agents identities. Register them. Bind them to users or workloads. Issue credentials. Put them in directories. Assign them scopes, roles, and policies.
That is the same move the security industry makes whenever a new actor type appears. It is useful, and it should happen.
But identity alone is not enough.
I made the same argument from the identity side in Agent Identity Is a Name Tag. It Needs to Be Character.: a credential can identify an agent without carrying the purpose, trajectory, relationships, delegation, and earned trust needed to govern it.
Traditional identity answers who the actor is. Authentication proves the actor controls a credential. Authorization decides what that credential can access. Policy determines whether the requested action is allowed under some predefined model.
As I argued in Stop Writing Policies for Agents. Write Policies for Actions., the current enterprise security model is identity-centric: the identity is the key, the policy is the lock, and the system decides whether the key fits. That model answers one question: can this identity access this resource? It does not answer why the action is being taken or should it happen.
That worked reasonably well when the actor was a human with a job role, or a workload with predictable behavior.
It does not stretch cleanly to agents and agentic AI.
A managed agent may act under a human’s identity but pursue a task the human did not fully understand. A custom-coded agentic system may not present a stable enterprise identity at all. A swarm may distribute behavior across many identities. A compromised service account may be driven by an autonomous planner. A human may use AI to choose actions while still appearing as ordinary human traffic.
In each case, the identity layer can be technically correct and still not answer the governance question. Identity remains critical, but identity has to become an input to the governance model, not the governance model itself.
The credential is valid.
The actor is authenticated.
The role allows access.
The tool call is permitted.
And the action still should not happen.
That is the breaking point. It is the same pattern I wrote about in The Agent Passed Every Security Check. It Still Shouldn’t Have Acted.: every “can” control can say yes while the governance answer should still be no.
Why The Current Policy Model Is Being Stretched
Policy is being stretched in the same way.
RBAC asks whether a role has permission.
ABAC asks whether attributes satisfy a rule.
OAuth scopes ask whether a token includes delegated authority.
MCP gateway policy asks whether a caller can access a tool, prompt, or resource through a managed channel.
Those are all “can” questions.
Can this user access this application?
Can this token call this API?
Can this agent see this tool?
Can this assistant invoke this MCP server?
But autonomy introduces questions that are not naturally expressible as static policy:
Why is this action being taken?
Is the action consistent with the actor’s declared purpose?
Has the actor earned enough trust to perform it without supervision?
Is this part of a broader trajectory?
Are multiple innocent actions composing into a harmful campaign?
Is this happening during an HR notice period, audit freeze, trading blackout, litigation hold, incident response window, or regulated clinical context?
Should this action happen even if it is allowed?
The existing policy model can keep adding attributes, exceptions, rules, and guardrails. That buys time. It does not change the architecture. Roles became attributes. Attributes became relationships. Each generation added vocabulary. None of them changed the shape: one request, one decision, one engine, one authoritative seat of policy.
The model is being stretched because it was designed to decide whether known actors can perform known actions under known conditions. Agentic AI creates actors, actions, paths, and conditions that shift while the system is running.
That requires a new policy model.
Not bigger rules.
A different shape. In Identity Governance Is One Layer. Agentic Security Needs Five., I called that shape layered cooperative enforcement: not a better PDP, but a pipeline of specialized enforcers where identity, behavior, intent, trust, and context each reason from their own competence.
What Tamed Autonomy Does Differently
Tamed Autonomy starts by stepping back from the actor category.
It does not ask only, “Is this an agent?”
It asks, “What is this actor trying to do, how much trust has it earned, what context surrounds the action, and should the action happen?”
That means the same governance architecture can apply to humans, managed agents, and agentic AI.
Identity and provenance answer: who is acting, from where, and through what lineage?
Authorization answers: can this actor technically perform this action?
Intent answers: why is this action being taken?
Trust answers: how much latitude has this actor earned based on behavior, history, resilience, and prior compliance?
Trajectory answers: what pattern is emerging across actions, sessions, agents, and time?
Normative context answers: should this action happen here, now, given the organizational, legal, ethical, and operational context? That is the should layer: the layer that can veto even when the agent did what it said it would do.
That is the new paradigm.
It does not replace identity. It makes identity one layer.
It does not replace policy. It moves policy from a single decision point into a layered governance pipeline.
It does not replace gateways. It treats gateways as the data plane: the place where cooperative traffic can be observed, shaped, and enforced.
But it does not confuse the gateway with the whole governance problem.
The harder problem is not only what happens inside the managed path. The harder problem is what autonomous systems do when they can choose paths.
Securing The Channel Is Not Governing The Behavior
This is the distinction the market has to make.
Agent security secures the channel.
Autonomy governance governs the behavior.
A desktop assistant routed through an MCP gateway is a channel-security problem. The enterprise can register the agent, configure the tools, enforce JWT validation, restrict tool access, inspect prompts, and log the interaction.
An autonomous agentic system is a behavior-governance problem. It can choose whether to use that channel, whether to route around it, whether to look human, whether to split work across actors, whether to change tools, and whether to modify its own strategy.
The same enterprise needs both.
If a managed AI assistant is accessing Salesforce, govern it.
If a human user is downloading customer records, govern it.
If an agentic swarm is probing APIs and reconstructing data through side paths, govern it.
The governance plane should not be limited to one actor type. It should evaluate consequential action wherever it appears.
That is why Tamed Autonomy is not just an agent-security model. It is an autonomy-governance model.
The Bottom Line
Agents are not agentic AI.
An agent, as the industry is mostly defining it, is an authenticated AI assistant operating inside a managed product boundary with configured tools and enterprise control points.
Agentic AI is autonomous software that can reason, adapt, coordinate, self-modify, mimic humans, and choose paths outside that boundary.
Humans are a third actor type, and they are not going away.
The industry is building useful controls for managed agents. But if it treats those controls as the whole answer, it will secure the cooperative path and miss the broader autonomy problem.
The next paradigm has to govern all three actor types through the same action-centered model.
Not just: who are you?
Not just: what tool are you calling?
But: should this action happen, by this actor, for this purpose, against this resource, in this context, right now?
That is the question current identity and policy models were not built to answer.
That is why they are being stretched to the breaking point.
And that is why Tamed Autonomy exists.
Leave a Reply