Authenticated Doesn't Mean Authorized Why AI Agents Need an Execution Boundary

Here is a scenario that should be uncomfortable, because nothing in it is a breach.

A deployment agent is running a routine migration. It holds a database credential your platform team issued on purpose. It connects through an approved path. Every identity check it touches returns green. Then, somewhere in a chain of reasoning that made local sense to it, it decides the cleanest way to resolve a schema conflict is to issue DROP TABLE production_customers.

The credential is valid. The connection is approved. The agent is exactly who it claims to be. And none of that has any bearing on whether it should be permitted to drop your customer table.

The uncomfortable truth about authenticated agents

Most AI agent security discussion still centres on identity: give agents proper non-human identities, rotate their secrets, scope their tokens, stop them sharing service accounts. All of that is correct and worth doing. It is also insufficient in a specific and increasingly expensive way.

Identity controls answer the question who is calling. They do not answer should this call happen. For a deterministic piece of software that only ever does one thing, the distinction is mostly academic - if you know who is calling, you effectively know what they are going to do. For an autonomous agent, the distinction is the entire problem. The agent composes its own action sequences at runtime. The set of things it might request is not enumerable in advance from its identity, which means you cannot pre-authorize it by issuing the right credential.

This is not a fringe position. The Cloud Security Alliance's AI Foundation has adopted Autonomous Action Runtime Management (AARM) - an open system specification published by Herman Errico in February 2026 - as a flagship specification for exactly this layer. Its abstract states the shift plainly:

“As artificial intelligence systems evolve from passive assistants into autonomous agents capable of executing consequential actions, the security boundary shifts from model outputs to tool execution.”

Autonomous Action Runtime Management (AARM), arXiv:2602.09433, 10 February 2026

AARM goes on to define a runtime security system that “intercepts actions before execution, accumulates session context, evaluates against policy and intent alignment, enforces authorization decisions, and records tamper-evident receipts for forensic reconstruction.” In an April 2026 update, CSA describes the same work as “an open specification for securing AI-driven actions at runtime across context, policy, intent, and behavior.”

We think that framing is right, and we would rather point at a vendor-neutral specification that describes the boundary than claim we invented the idea. The category is forming in the open. What matters is whether a given system actually implements the boundary or merely reports on traffic crossing it.

Why traditional IAM isn't enough

It is worth being precise here, because “IAM is not enough” is often said carelessly and lands as “IAM is useless.” It is not. It solves a layer that still has to be solved. The layers stack roughly like this:

• Identity — this agent is a distinct principal with its own non-human identity, not a shared service account.
• Authentication — the presented credential is valid and unexpired, and the caller is who it claims to be.
• Role assignment — the identity holds a coarse-grained set of permissions, usually decided at configuration time.
• Runtime action authorization — this proposed action, against this resource, in this context, under this policy version, right now.
• Execution enforcement — something is actually positioned to stop the action if the answer is no.

IAM covers the first three well. The gap is that role grants are made at configuration time against a set of expected behaviours, while agents act at runtime and generate unexpected ones. A migration role that includes schema modification is a defensible grant. It also, technically, contains DROP TABLE. The role was never wrong; it was simply never a statement about individual actions, because it could not be.

The last two layers are where autonomous systems break the model. And there is a further trap: many teams believe they have the fifth layer when what they actually have is observability. If the destructive call reaches the database and an alert fires afterwards, the enforcement point does not exist. The action has already happened. This is the difference OWASP gestures at with excessive agency — permissions broad enough that a compromised or merely confused agent can subvert the intended workflow while remaining entirely within its granted role.

Authorization before execution

The architecture that closes the gap is not complicated to describe. The proposed action is evaluated before it reaches the protected execution boundary:

Agent intent
    ↓
Proposed action            ← DROP TABLE production_customers
    ↓
CoreGuard                  ← deterministic policy evaluation
    ↓
ALLOW / BLOCK / MODIFY
    ↓
Execution boundary         ← a BLOCK never crosses this line
    ↓
Signed evidence

The ordering is the entire claim. The agent does not act and get audited. It proposes, and the proposal is adjudicated while the action is still hypothetical. A BLOCK is not a rollback, a compensating transaction, or an incident ticket. It is the absence of an execution.

The structural requirement this imposes is that the executor must be unreachable except through the gate. If there is a second code path into the database that does not consult policy, the boundary is decorative. The correct default is to fail closed: absent a valid authorization bound to the exact operation, the executor refuses to run at all. Not "log and continue" — refuse.

Why deterministic enforcement matters

There is an appealing shortcut here: use a second AI model to judge whether the first model's action looks safe. It demos well and it is genuinely useful in some places.

We do not put it on the authoritative decision path, for three practical reasons.

Reproducibility. An examiner asks why a particular action was blocked in March. A deterministic policy engine re-runs the same input and produces the same output, with the same rule identifiers. A probabilistic judge may not, and "the model felt differently that day" is not an answer that survives a regulatory conversation.

Attack surface. A model-based gate is itself steerable by input. Putting a language model in the veto path means the thing being governed and the thing doing the governing share a manipulation surface. Prompt injection then becomes a governance bypass rather than merely a bad answer.

Auditability. A deterministic rule has an identifier, a threshold, and a version. You can hand an auditor the rule that fired and the value that tripped it. That is a different artifact from a confidence score.

None of this means AI has no role in governance. It is well suited to drafting candidate policies, triaging what a human should look at first, summarising an investigation, and explaining a decision in plain language after the fact. AI can assist governance workflows, policy authoring and investigation. The final execution boundary can still be deterministic. Those two statements are compatible, and keeping them separate is a design choice rather than a limitation.

Proof changes the governance model

Blocking the action is half the problem. The other half is being able to demonstrate, later and to someone who does not trust you, what was decided and why.

This is where a log and a decision certificate diverge. Both are records. Only one is independently testable.

In EVE, every governed decision produces an evidence record carrying a content hash over the decision payload and a cryptographic signature over that hash, along with the signing key identifier and the record's position in a hash chain. Alter any covered field and verification fails. That property is what makes the record usable by someone who has no reason to trust the operator — which is the only kind of evidence that is worth anything in an examination.

For EVE's hosted service, decision evidence is signed with ECDSA P-384 using an AWS KMS-resident key, so the private half never leaves the KMS boundary; self-hosted and sidecar deployments use Ed25519. Both are asymmetric, which is the property that matters: verification needs only the public key, so an auditor can check a certificate without asking us for anything and without being online with our infrastructure.

One caveat worth stating plainly, because governance vendors are not usually candid about scope: EVE governs a proposed action that is submitted to it. It is not a SQL proxy and it does not sit on the database wire protocol. The enforcement boundary is a governed call path, and it holds because the executor refuses to run without an authorization — not because we are inspecting packets.

What happens when CoreGuard says BLOCK

Walk the destructive example through the real path. The agent is authenticated. It proposes drop_database against production_customers, a table with roughly 48,000 rows, requesting an administrative capability its credential envelope does not declare.

CoreGuard evaluates it against the autonomous_agent_v1 policy pack and returns BLOCKED, citing named deterministic rules:

• AAG-001 — capability escalation. The agent's declared envelope is read-only; it requested administrative rights.
• AAG-002 — irreversibility gate. drop_database is classified irreversible, and no human confirmation was presented.
• AAG-003 — blast radius. The action affects far more records than the autonomous ceiling permits.
• AAG-HITL-001 — multiple high-severity findings hold the action for human authorization.

Then the part that matters: the protected executor is never entered. The table is still there afterwards. Not restored — never dropped. And a signed decision certificate exists for the denial, which is worth noticing on its own. A blocked action is exactly the kind of event you most want provable evidence of six months later, and it is the kind most systems record least well.

What happens when CoreGuard says ALLOW

Governance that only ever says no is not governance; it is an outage with a policy document attached. The same agent, holding the same credential, proposes SELECT COUNT(*) FROM production_customers. That sits inside its declared read envelope, affects no records, and is reversible.

CoreGuard returns ALLOWED. The query runs, once, and that decision is signed too.

Same agent. Same credentials. Different authorization. That is the distinction identity infrastructure cannot draw on its own, and it is the whole reason the authorization layer has to exist separately from the authentication layer.

You can run both scenarios yourself. The demo drives the same evaluator described here, shows the rules that fired, reports the executor's own invocation counters, and lets you verify the resulting certificate. The database in it is simulated — an in-memory structure with no SQL parser and no SQL executor — because demonstrating an enforcement architecture should not require putting a real table at risk. The governance decision, the policy pack, the rule identifiers, the signing and the verification are the production components.

MCP and autonomous agents raise the stakes

This gets sharper as agents gain standardised reach. The Model Context Protocol and comparable tool-calling interfaces mean an agent can invoke tools, APIs, databases, cloud services, SaaS applications and internal systems through a uniform surface. That is a genuine advance in capability, and it means the space of actions an agent might independently attempt grows faster than any pre-authorization scheme can enumerate.

The AARM specification catalogues the resulting failure modes directly, listing prompt injection, malicious tool outputs, confused deputy, over-privileged credentials, data exfiltration, goal hijacking, intent drift, memory poisoning, cross-agent propagation, side-channel leakage and environmental manipulation among the attack vectors specific to AI-driven actions. Several of those — confused deputy and over-privileged credentials especially — are precisely the case where authentication succeeds and the action is still wrong.

A note on scope, since this is where marketing usually overreaches: knowing which agents and tools exist in your estate is a real and separate problem. EVE governs the systems and actions you declare to it. Automatic discovery of every agent on your network is not something we do, and we are not going to imply otherwise.

The new security boundary

The chain of reasoning is short, and each link fails independently:

• Identity is not authority. Knowing which agent is calling tells you nothing about whether the call should proceed.
• Authentication is not authorization. A valid credential is a statement about the holder, not about the action.
• Authorization is not enforcement unless something is actually positioned to stop the action. A policy nobody can enforce is a document.
• Enforcement without verifiable evidence leaves auditors and operators trusting your word about what happened.

EVE CoreGuard is built for the last two links. It evaluates the proposed action deterministically before execution, returns ALLOW, BLOCK or MODIFY with named rules, fails closed when it cannot evaluate safely, and emits signed evidence that a third party can verify independently.

The agent in the opening scenario was not an attacker. It was doing its job with credentials we gave it, and it reached a conclusion that was locally reasonable and globally unacceptable. That is the ordinary case, not the exotic one. Designing for it means accepting that a valid credential is the beginning of the security question rather than the end of it.

Frequently asked questions

What is the difference between authentication and authorization for AI agents?

Authentication establishes who or what the agent is - it validates a credential, a token, or a workload identity. Authorization determines whether that specific agent may perform this specific action against this specific resource under current policy. An agent can pass authentication perfectly and still be requesting something it must never be permitted to do. Authentication is an identity question; authorization is an action question.

Why isn't IAM enough to govern AI agents?

IAM solves a different layer. It answers who an identity is and what broad roles it holds, usually decided at configuration time. An autonomous agent composes novel action sequences at runtime, and a role grant that is reasonable in aggregate can still contain an individual action that is catastrophic in context - such as a maintenance role that technically includes dropping a table. IAM is necessary and remains necessary; it is a coarse, mostly static layer that was not designed to adjudicate a single proposed action in its full runtime context.

What does authorization before execution actually mean?

It means the proposed action is evaluated against policy before it reaches the protected execution boundary, and a denial stops it there rather than reporting on it afterwards. The practical test is simple: when the decision is BLOCK, does the downstream system ever receive the call? If the answer is that it receives the call and the event is logged, that is monitoring, not enforcement.

Should the enforcement decision be made by an AI model?

AI is genuinely useful for governance workflows - drafting policy, triaging alerts, investigating incidents, explaining a decision. The authoritative execution verdict is a different job. A probabilistic judge introduces variance into the one place where you need the same input to produce the same output every time, and it is difficult to replay for an auditor or a regulator. EVE CoreGuard keeps the ALLOW/BLOCK/MODIFY verdict deterministic; no language model participates in it.

How is a decision certificate different from a log?

A log tells an auditor what a system recorded about itself. A signed decision certificate carries a content hash and a cryptographic signature, so a third party can independently test whether the record is authentic and unmodified rather than trusting the system that wrote it. If any field is altered, verification fails.