By Mary Beth Chalk, Co-Founder & Chief Commercial Officer, BeeKeeperAI
Policy defines the boundary. Architecture enforces it. Neither reaches an agent already in motion — the gap that matters most for security, data, and AI leaders.
Earlier this week we published an argument that sits at the center of how we govern AI:
Policy can prohibit an action, but it cannot make one impossible.
As AI matures from models to agents, the protections that matter most must move out of contracts and policies and into the infrastructure where computation happens.
The response added valuable input to the LinkedIn article.
Within forty-eight hours, the discussion drew over 60 comments — from cybersecurity GRC practitioners, enterprise architects, AI governance researchers, founders building authorization and attestation protocols, and a co-author of the Imperial College London survey the piece was built on. Several threads ran four and five replies deep and there was useful disagreement.
What emerged was sharper than what we started with. It’s worth putting on the record, because it further clarifies what we think lies ahead.
The short version: protecting data and intellectual property during computation is largely a solved problem. Knowing whether an agent stayed within the rules while it ran and being able to pull its permission back, during compute, before it does something irreversible, is not. That second problem is where AI governance is moving.
Four protections typically confounded under a single word
One of the most clarifying things to come out of the discussion is that our industry uses the word “control” to mean at least four different protection guarantees. Treating them as one is how governance programs end up with gaps nobody planned.
- Confidentiality. Can anyone — a cloud operator, an infrastructure administrator, a vendor, a model host — see the data or the agent while it runs?
- Authorization. What actions are the agent permitted to take, when, and what under conditions?
- Enforcement. If the action isn’t permitted, what stops it — a rule someone could break, or an architecture that gives them no way to break it?
- Detection and revocation. During compute, can we tell that the agent has moved outside what was approved — and can we withdraw its permission before the damage is done?
Throughout this piece, revocation means exactly that: taking back an agent’s authority after it was granted.
Confidential computing answers the first, confidentiality, decisively. Sensitive computation runs inside a hardware-isolated trusted execution environment, or TEE, and hardware attestation verifies that the environment is genuine and unmodified before any data or model is released into it. The guarantee doesn’t rest on trusting the people who operate the infrastructure, because they are removed from the trust boundary entirely.
The second, authorization, is a different problem. It provides the boundaries (i.e., policy) around which the agent may behave. Confidentiality and authorization are separate disciplines that share a vocabulary, and it is easy to build one and assume you have covered the other.
The third, enforcement, is where the discussion was precise about what that means: a boundary that is a property of the computing environment rather than a rule the agent is asked to follow. Several participants arrived at the same design from different directions — authority checked at the moment an action is attempted, defaults that fail closed when that check can’t be completed, and permissions scoped tightly enough that no single step can carry an agent past them.
The distinction mattered because of an objection raised more than once in the thread: model guardrails can be defeated, so governance is theater. What that argument indicts is governance that depends on the model’s cooperation. Persuading a model to attempt something is not the same as creating a path the environment never opened.
Detection and revocation is an emerging area of development. Several participants are building toward it from different directions: permissions that expire quickly rather than persist, authority re-checked at the moment each action is attempted and failing closed when that check can’t be completed, and verification that the outcome of an action actually matched what was authorized rather than assuming that permission implies success.
What none of it does yet is guarantee interception.
Once an action has left the protected environment — an API call dispatched, a payment submitted, a record written — cancellation belongs to whatever system received it. As one builder in the thread put it plainly, these designs bound the exposure to a single declared action rather than eliminating it: long-running work gets divided into phases, with authority rechecked before each new commitment. That shrinks the window. It does not close it, and nobody in the discussion claimed otherwise.
Why stopping an agent in motion is hard
Start with the baseline protection that TEEs already provide. Every run begins with fresh attestation — hardware proof that the environment is genuine and unmodified — and fresh key release, meaning the keys that unlock data and models are issued only into an environment that has just passed that check. Nothing carries a standing permission. Authority is established at the start of each run rather than inherited from the last one.
That baseline is strong when the work stays in one place.
A single agent operating inside a single attested environment has one boundary to hold: what it can reach, what it can do, and what is allowed to leave are all governed by an environment that was verified before the work began, and the record of what happened comes from that same environment.
The picture changes when an agent hands work to another agent running somewhere else — a different environment, often operated by a different party, sometimes calling outside tools and services along the way.
There is no longer one boundary to hold. There is a chain of them, each requiring its own verification, and the terms of what was originally authorized have to travel intact from one to the next.
Now the problem. An agent is authorized to do a scope of work. Attestation passes, keys are released, and the work begins. Then something changes that is inconsistent with the policy-based boundary before the work is finished: consent is withdrawn, a monitoring signal fires inside the TEE, or a human decides the run should stop.
Fresh attestation and fresh key release reduce that risk considerably, because a change in policy takes effect before the next run begins. What they cannot do is reach inside a run that is already underway. Security engineers know this pattern well: the check happens at one moment, the action happens at another, and the gap between them is where things go wrong.
Across handoffs, it gets harder still.
Four things have to survive every pass from one agent to the next:
- whether the authorization is still current,
- whether it has been revoked,
- exactly what was delegated, and
- whether the whole chain can be verified rather than just the last step.
Lose any one of them at any handoff, and that handoff becomes the place where a stale “yes” survives long enough to cause something irreversible. The survey treats these four as a single compound problem rather than four separate features, and the discussion made clear why that framing is right.
The practical consequence is one most governance programs haven’t absorbed: being able to block an agent’s next action is not the same as being able to stop the action it is taking right now across a multiple agents. The first is solved and shipping. The second isn’t.
What the discussion agreed on
Four points held across very different vantage points — an IT operations leader who has spent a career on configuration drift, a virtual CISO who thinks in terms of regulated filings, engineers building agent authorization tools:
- Policy can’t keep pace with machine speed.
- Authorizing an action at the start isn’t the same as watching it and catching the moment it moves outside what was approved.
- Humans decide where the boundary sits; architecture is what makes it hold while the agent runs.
- A log written after the run is an autopsy, not a control.
That last one deserves emphasis. If the only signal that something went wrong appears in a record someone reads later, that isn’t governance during execution. It’s forensics. Both are necessary. They are not substitutes.
The agent’s ceiling is established by a human
Every agent operates within an outer limit of the discretion (e.g., ceiling) it has been granted. Where that ceiling sits depends on two things: how much damage the action could do if it went wrong, and how much of that exposure the organization is prepared to absorb. Both are human judgments about consequence. Neither is a technical property of the agent.
Which leads to a principle worth stating plainly: an agent’s own track record should never be the basis for raising its ceiling.
A clean history can reduce friction inside a boundary a human already set — fewer checks, faster approvals. But the moment good behavior earns expanded authority automatically, you have built a system that grants the most latitude exactly where scrutiny has relaxed, and you have removed the person who was accountable for accepting that risk.
Evidence should be trusted to tighten, not to loosen. Being wrong in the tightening direction is recoverable. Being wrong in the other direction may not be.
A boundary isn’t the whole story either. An agent can operate entirely within an approved scope and still behave badly — a hundred individually permitted actions that add up to something nobody would have approved. Enforcement stops an agent from leaving the room. It doesn’t notice what happens inside it.
The limit we’ll state plainly
The sharpest challenge in the entire discussion came from a cybersecurity governance leader, and it deserves to be conceded rather than argued around: attestation is evidence, not prevention.
It proves the environment was intact and that the operator couldn’t look inside. It does not prove the agent stayed within its mandate, because the mandate lives outside the TEE. And for anything that ends up in a regulated filing, the question that follows is who can verify that attestation independently — because assurance that your own risk and audit teams cannot reproduce themselves is still someone else’s word for it, cryptographic rather than contractual.
We think that’s correct, and it sets a standard worth designing toward. Evidence earns its weight when the party relying on it can reproduce the verification, not merely receive a signed statement from the party being verified.
Three questions worth asking on Monday
For security, data, and AI leaders trying to turn this into something actionable, the discussion converged on a useful shift: stop auditing whether controls exist and start testing whether they arrive in time.
- Trigger a revocation while something is running. Not “do we have one” — fire it mid-task and watch whether it actually interrupts the work before the consequence lands, or simply writes a log entry.
- Test what happens across handoffs. When one agent passes work to another, confirm that the authorization and the limits of what was delegated all survive the pass. Find the handoff that drops one.
- Ask who re-performs the verification. If your assurance rests on attestation, determine whether your own risk or audit function can independently reproduce that check, or is accepting it on faith.
Where BeeKeeperAI stands
EscrowAI® was built for the first three guarantees. Sensitive computation runs inside a TEE with hardware attestation. Every run is gated on fresh attestation and fresh key release rather than a standing permission. The data custodian never surrenders custody of the data, and the model owner never exposes proprietary IP. Output is checked against policy before it is released, and if data memorization or other prohibited behavior is detected during compute, the run is terminated. An immutable record shows what actually executed.
That is confidentiality, enforcement, and evidence — confidence for the AI team, control for the data team, compliance for the security team.
On the fourth, we are not going to claim more than we can prove. Revoking an agent’s authority mid-run, in the moment an action would take effect, and across a chain of agents handing work to one another — that is the work ahead, for us and for the industry.
It is also the experiment this discussion asked all of us to run: can a revoked or changed authorization reach an agent mid-task, inside a TEE, before an irreversible action completes — and does that guarantee hold across handoffs, where it is hardest to preserve?
A credible answer must be bounded rather than best-effort, tested in the moment the action takes effect rather than well upstream of it, and verifiable by someone other than us.
If you are working on any part of this, we would like to compare notes. And if you would like the synopsis of the LinkedIn discussion — the themes, the points of consensus, and the questions still open — you can download it here.
Every contributor to the discussion is credited in the synopsis. Contributors participated in a public conversation on LinkedIn; their inclusion does not imply endorsement of BeeKeeperAI or EscrowAI.
Comments