Knowing what an agent is allowed to do is not the same as enforcing it or proving what it actually did. That second layer has to live somewhere nothing can reach around, and that is the work I have been focused on.
There is a genuinely good wave of work happening right now to give agents verifiable identity. Cryptographic credentials, attestation grades, delegation chains that prove one agent’s authority came from another. I have contributed to some of it, most directly through AgentMesh, the identity and trust layer I built for the parts of this that the A2A and MCP protocols leave out, and I am glad it is happening, because you cannot govern an agent you cannot name. Identity is the foundation, and the ecosystem is building it well.
I want to talk about the layer underneath it, because it is the one people skip, and it is the harder one.
Two questions that look like one
An agent’s identity credential answers a specific question: who is this agent, and what is it permitted to do. That is real and it is verifiable. A relying party can check the credential without trusting whoever operates the agent, and that is a meaningful thing to be able to do.
But it answers what an agent may do. It does not answer what the agent did do. At the moment the agent actually acts, two harder questions open up. Was the permission on that credential actually enforced? And afterward, can you prove what happened, to someone who was not there and does not trust you?
A credential is a promise about behavior. It is not the behavior. An agent can carry a flawless, fully verified credential that says it may only read a single record, and still reach further, if nothing at the point of action is holding it to that promise. The credential is a claim. Enforcement is what turns the claim into a fact.
Claiming trust and enforcing it are different layers
This is the distinction I think the whole field is about to reorganize around.
Identity is the claim. It says who an agent is and what authority it holds. Enforcement is what happens at the exact moment the agent tries to act, the thing that either lets the action through or does not, according to that authority. Evidence is the proof, afterward, that the action happened the way the credential said it would.
The ecosystem is racing on the first, and it should. But the second and third do not come for free with a good credential, and this is the part worth sitting with: whether a permission was truly enforced depends entirely on where the enforcement runs. If the check that holds an agent to its credential runs inside software that a privileged operator or a compromised dependency can reach, then the guarantee is only as strong as that environment. The credential can be perfect, and the enforcement can still be quietly bypassed, and no one downstream would be able to tell.
That is not a knock-on identity work. It is simply the next layer down, and it is the layer I have spent my time on.
Where enforcement has to live
If enforcement is going to mean something, it has to run somewhere the thing it governs cannot reach around. Not beside the agent. Not in the same operating system as the operator. Underneath all of it, in hardware.
That is the shape of the layer I have been building in the open, as Confidential MCP for the enforcement and TRACE for the evidence. The policy that holds an agent to its authority is evaluated inside a Trusted Execution Environment. The policy is measured into the hardware attestation report before any code runs, so the rules in force are provable, not asserted. The signing key never leaves the enclave, so the record of what happened cannot be forged after the fact, even by someone with root on the host. The agent presents its credential, and the enforcement layer holds it to exactly that credential, in a place neither the agent, nor the operator, nor a dependency can quietly change the answer.
The output of all that is the part auditors and regulators actually need: a signed record proving which authority was enforced and what the agent did under it. Not a promise on letterhead. Proof rooted in silicon.
This composes. It does not compete.
Here is the thing I want to be clear about, because it matters.
The identity layer and the enforcement layer are not rivals. They stack. Identity answers who an agent is and what it is allowed to do. Enforcement and evidence answer whether that was actually honored and can be proven. The strongest agent systems will have both: a verifiable identity on top, and hardware-rooted enforcement and evidence underneath. A credential gives an agent something to present at the border. This layer is what makes the border’s decision mean something once the agent is through and starts to act.
I would rather see the identity work I have contributed to succeed and have this layer sit beneath it than have either one try to be the whole stack. Neither is.
Why this is the question that is about to matter
As agents get identities and start acting across boundaries they do not control, the question a relying party asks is going to shift. Today it is “can I verify who you are.” Very soon it becomes “was what you were allowed to do actually enforced, and can you prove what you did.” The first question is being answered well by a lot of good people. The second is the one I am building for, because it is the one that decides whether you can hand an agent real authority and sleep at night.
Identity is the promise. Enforcement is the proof. I have been building the proof layer, in the open, and I would rather build it with the people who are going to depend on it.
Top comments (0)