The Control Point Is in the Wrong Place
Fifty vendors. One structural flaw. None of them will tell you about it.
I thought I was the only idiot.
It was not one incident. It was a pattern.
I kept watching agents do things nobody had asked them to do. I would carefully scope a prompt, feel good about it, and then watch the model chain actions I had not planned, infer context I had not intended to expose, and produce outputs that were technically allowed but strategically wrong. Every system in place reported that everything worked exactly as designed.
That should not have been possible.
The deeper issue was structural. There was no inspection point before execution. The entire ecosystem assumed: send a prompt, the model responds, maybe log it, maybe filter the output. Nobody had built a place to inspect what was being sent before it reached the model. No policy enforcement on the way in. No way to redact or reshape a prompt carrying too much information, too much access, or too much implicit permission.
You either trusted the prompt or you cleaned up the mess afterward.
I hate cleanup work.
So I built something. I called it PromptTrap, a pre-execution interception layer that sits between the user and the model, enforcing policy on what is sent, redacting sensitive context, and attributing every request. I open-sourced it and gave it away because I could not yet see its value. Something about it felt patentable. I filed the instinct away and kept moving.
Then MCP arrived.
The Model Context Protocol standardized the execution layer. It provided AI agents with a consistent interface for calling tools, accessing data, and taking actions across enterprise systems. It made the boundary between agent and tool a real, addressable protocol layer.
And I realized that PromptTrap was sitting at the wrong boundary.
The prompt layer is where you shape intent. The tool-call layer is where intent becomes action. The prompt matters, but the tool call is what changes the state of the world. We secured the conversation and left the execution path exposed.
The problem is not missing controls. The control point is in the wrong place.
That was the wrong lesson I had been carrying: do not be careless with prompts. The real lesson was this.
Even when you do everything right, the system still behaves in ways you cannot fully predict or control. That is not a prompt problem. That is an architecture problem.
Twelve months later, I have reviewed the architectures of fifty enterprise AI agent security vendors. (I am actually approaching 80 different vendors at this point.)
Every major category is represented, including identity platforms, runtime monitors, MCP gateways, LLM firewalls, endpoint agents, and behavioral analyzers. Some have raised hundreds of millions of dollars, and some have already been acquired.
They are all solving real problems.
None of them sit at the point that actually determines the outcome.
The pattern looked like this.
An agent with authorized access. A well-engineered prompt. A legitimate task.
A chain of actions nobody anticipated, authorized, or could stop in real time.
The agent was not compromised. Not manipulated. Not running malicious code. It was doing exactly what the combination of its instructions and its access permitted.
The outcome was wrong. The execution was technically correct. Every system agreed it was correct.
Every security layer I had in place was irrelevant. Identity controls confirmed the agent was authorized. Credential scoping granted it exactly the access I had configured. Monitoring tools faithfully recorded every action it took.
What was missing was something that could evaluate the chain of actions before they executed. Not the identity. Not the access policy. The actual tool calls, in sequence and with full context, before they ran.
That does not exist in most enterprise deployments today. This will fail in production before it fails in theory.
Twenty years of enterprise security taught me to ask one question.
Who?
Who is authenticated? Who is authorized? Who is being monitored?
We have spent twenty years getting very good at answering the wrong question. We have built entire categories of tooling around it, and we are still optimizing it. I am part of this problem; I contributed to it.
Agentic AI is not a who problem. It is a What problem. What is the agent about to do? What sequence of actions is it assembling? What will the state of the system be after the next tool call executes?
Governing access asks: is this agent allowed to reach this system?
Governing execution asks: should this specific action, with these specific parameters, in this specific context, be permitted to run right now?
Every mature security tool in the market answers the first question. Almost none answer the second. And the gap between those two questions is where the damage happens.
When an agent executes a tool call, who records what happened?
In most architectures, the answer is: the agent, or the systems the agent accessed.
The agent generates its own traces. The agent reports its own actions. The agent is the source of truth about what the agent did.
This is a structural flaw.
If the entity that acts is also the entity that attests to its own behavior, you do not have governance. You have self-reporting.
In a financial audit, we do not let a company audit itself and call it independent verification. In physical security, we do not let an employee badge their own access logs and call it accountability. We separate the actor from the attestor. We require that the record of what happened be produced by a system that is not the system being governed. I keep using this example because it works and everyone understands it. There are entire movies about this (Accountant/Accountant 2)
We have not applied this principle to AI agents.
I will call it the Attestation Separation Principle.
The entity that acts cannot attest to its own behavior.
If your current system relies on the agent to describe what it did, you have already violated this principle.
Looking at what most of the market is building starts to highlight this issue pretty quickly.
An SDK hook that runs inside the agent process is not an independent attestation. The hook and the agent share a trust boundary.
A behavioral monitoring layer that reads the agent’s own telemetry is not independent attestation. The signals come from the system being governed.
A gateway that logs which MCP servers the agent connected to is not an independent attestation. It records the connection. What happened inside the connection is recorded downstream.
A JIT credential provider that logs which credentials it issued is not an independent attestation. It records the authorization. What the agent did with that authorization is recorded elsewhere.
Most of the market is optimizing visibility inside the same trust boundary.
None of this means these tools are useless. They serve real purposes. But none of them satisfy the Attestation Separation Principle. None of them can answer the question that a regulator, a board, or an incident response team will eventually ask.
Most of what is being deployed today can observe failure. It cannot prevent it.
The test is simple: prove what the agent did from a record it could not alter.
The architectural requirement is specific.
The governance layer must sit in the execution path. Not adjacent to it. Not downstream of it. In it. The tool call cannot complete without passing through a system that is not the agent.
That system must make a deterministic decision before execution. Allow. Deny. Intercept. Not log. Not detect. Not guide. Decide.
And that system must produce its own record. Independent of the agent’s runtime. Cryptographically verifiable. Tamper-evident. Produced by the entity that governed, not the entity that acted.
This is not a feature set. It is an architectural position.
You cannot observe your way to the chain of custody.
The mistake I made a year ago was not being careful with prompts.
The mistake was believing that because the agent was authorized, what it did was governed.
Authorization and governance are not the same thing.
Every enterprise deploying AI agents at scale is making that mistake right now. Not because they are careless. Because the market has not given them the tools to make the distinction.
Are you willing to swallow the risk? Where does the liability fall? At what point does “we have monitoring” become legally indistinguishable from “we knew the risk and chose not to prevent it”?
Appendix: The Technical Architecture of the Problem
For practitioners who want to go deeper.
If the Attestation Separation Principle is correct, the architecture becomes unavoidable.
Why inline position is the only position that satisfies the principle
The Model Context Protocol defines a client-server architecture. An AI agent (the MCP client) sends tool-call requests to MCP servers: tools, APIs, and databases. The MCP server executes the tool and returns the result.
A governance layer that satisfies the Attestation Separation Principle must sit between the client and the server. Every tool call request passes through it before reaching the MCP server. The governance layer evaluates the request against policy, makes an enforcement decision, and forwards it if permitted. The MCP server never receives an ungoverned request.
Everything else people are deploying today sits outside the execution path.
A sidecar monitor reads the agent’s outbound traffic without intercepting it. The tool call executes regardless of what the sidecar observes.
An SDK hook runs in the agent process. The hook and the agent share a process boundary. The hook’s record is generated within the governed system.
An endpoint agent intercepts at the OS or network layer. Closer to inline, but the interception point is on the same machine as the governed agent.
An MCP gateway controls which MCP servers the agent can reach. It governs the connection boundary, not the execution of tool calls within an authorized connection.
The policy evaluation model
An inline governance layer evaluates tool calls against structured policy using a declarative engine. Open Policy Agent with Rego is a mature option for this class of problem. Policy rules inspect the tool call method, parameters, the agent’s task context, the delegating user, the data classification of the resources being accessed, and the cumulative sequence of prior tool calls in the session.
The enforcement decision is deterministic. Given the same policy and tool call, the decision is always the same. This is structurally distinct from LLM-based guardrails, which are probabilistic. Probabilistic safety applied to deterministic execution is not governance. It is a confidence interval.
The audit trail model
Each tool call evaluation produces a Decision Record. The record contains: timestamp, agent identity, tool called, parameters, policy evaluated, decision rendered, and a cryptographic hash linking it to the prior Decision Record in the session chain.
The hash chain ensures that any tampering with a record, whether deletion, modification, or reordering, breaks the chain and is detectable. The chain is produced by the governance layer, not by the agent. The agent cannot produce, modify, or access the Decision Record.
This satisfies the Attestation Separation Principle. The actor and the attestor are different systems.
The practical implication for enterprise deployment
An enterprise that can produce a complete, tamper-evident Decision Trace for every agent session can answer the regulatory question. Every tool call is evaluated. Every policy decision is made. Every enforcement action taken. From a system that the agent cannot modify.
What did the agent do, and how do you know?
An enterprise that relies on the agent’s own logs, platform telemetry, or behavioral monitoring cannot answer that question. It can describe what it observed. It cannot prove what happened.
That distinction will matter more than most people expect and sooner.