PaperlayerView exact revision on arXiv

Source-linked AI summary

AID-Guard: Stateful Authorization for Delegated Agent Effects

Yingzhe Tong, Leyu Dai, Songhui Guo

arXiv:2608.21159v1cs.CRcs.AI

TL;DR

Delegated agent authorization can become stale or produce duplicate effects when requests, provider state, delivery, and recovery change after admission. AID-Guard binds approval to effect closure through commit-time revalidation and conservative reservation lineage, with evaluations supporting the property within declared inventories, contracts, and schedules.

  • Problem

    Delegated authorization must remain bound after admission because requests, provider state, delivery, retry, and recovery can evolve before the provider outcome is resolved.

  • Method

    AID-Guard forms durable single-use authority, revalidates the exact request and provider state at commit, and permits release or one successor only after terminal or certified no-effect evidence.

  • Results

    Across the evaluated effect-path inventory, provider contracts, and failure schedules, the protocol preserved one-effect-or-certified-no-effect semantics.

  • Takeaways & Limitations

    The results support binding authorization to provider effects through a durable post-admission boundary rather than treating retry and recovery as transport details.

  • Takeaways & Limitations

    The evaluation used a declared loopback domain, bounded provider schedules, and a prototype that does not discover omitted effect routes.

Abstract

from arXiv · show

Tool-using AI agents turn delegated tasks into provider effects, yet authorization often ends at admission while provider state, delivery, retry, and recovery evolve. A request may change before commit, or response loss may cause a replacement to create a second effect from one approval. We present AID-Guard, a stateful authorization-to-effect closure protocol. It revalidates the approved request and provider state at commit, retains one reservation under ambiguity, and permits release or one successor only after a terminal result or certified no effect with a delivery fence. For supported provider contracts, one reservation yields at most one effect across retry and recovery. To our knowledge, it is the first evaluated agent-authorization protocol to unify these controls in one lifecycle. We implement a Python/SQLite prototype. In a declared loopback MCP domain, 13 live mutations caused no unauthorized provider effects, three concurrent histories were linearizable, and evidence bundles supported public verification and replay. All 210 Stripe provider-contract trials matched predeclared outcomes. Across Stripe and Resend, 40 terminalize-successor schedules, 30 overlapping races, and 10 crash-recovery schedules completed without duplicate effects. Under complete proposer compromise, AID-Guard blocked 44/44 attacks and admitted 44/44 matched legitimate proposals. Its strict exact-manifest profile reduced benign utility by 35.4 to 43.8 percentage points; a typed frontier recovered 9-10 completions without observed unsafe effects. A composition study blocked 20/20 post-admission lifecycle attacks and preserved 8/8 valid or exact-retry executions. The results support authorization-to-effect binding under the evaluated effect-path inventory, provider contracts, and failure schedules.

I. Introduction

AID-Guard frames delegated execution as an authorization-to-effect closure problem: admission alone cannot bind an approved action through mutable requests, provider state, delivery uncertainty, and recovery. It addresses this gap with durable checkpoints, commit-time revalidation, conservative recovery, and evaluation across declared effect paths.

  • Protocol: AID-Guard revalidates the exact approved request and current provider state at commit, while retaining one reservation when delivery is ambiguous.A terminal result closes the normal path; certified no-effect evidence enables release or one successor on the same lineage.
  • Protocol: Under supported provider contracts, each reservation yields at most one effect across its predecessor and accepted successor.The evaluated contracts include atomic and controlled-idempotent provider paths.
  • Evaluation: 13 live mutations caused no unauthorized provider effects in the declared loopback MCP domain.The evaluation used an enumerated effect-path inventory and separate evidence planes.
  • Contributions: The protocol models the authorization-effect gap as a stateful one-effect-or-certified-no-effect property over one reservation lineage.Its design combines H1–H3 authority formation, commit-time binding, no-effect recovery, and role-separated outcome evidence.
  • Scope: The deployment closure obligation requires every effect-capable path in the protected domain to pass through a registered adapter or tool-native verifier.The prototype verifies conformance to the registered inventory but does not discover omitted routes.

B. Adversary

The threat model gives the adversary broad control over proposal generation, metadata, protocol objects, races, crashes, and response loss, while the security goals require authorized, unique, and auditable effects within a declared domain. The claims remain conditional on trusted enforcement components, supported provider contracts, and complete effect-path coverage.

  • Threat model: The adversary may control the planner, agent, and subagents, inject arbitrary content, fabricate metadata, replay objects, race requests, and induce crashes or response loss.The objective includes unauthorized effects, duplicate effects from one reservation, authority recovery after possible effect, and inconsistent histories.
  • Security goals: P1 requires every accepted protected effect to descend from one active user-approved root through H1 binding, H2 issuance, H3 claim, and exact D2 dispatch.The protected domain must be D0-complete.
  • Security goals: P2 permits at most one provider-atomic effect per reserved use, with release or one successor requiring a valid one-use no-effect certificate and delivery fence.The successor remains on the same reservation lineage.
  • Security goals: P3 requires role-separated evidence over one authorization and effect lineage, supporting public integrity checking and privileged deterministic replay.Missing evidence is reported as incomplete rather than treated as proof of no effect.
  • Scope: The containment claim excludes compromised trusted hosts or enforcement components, undeclared bypass paths, non-atomic batches, and unsupported provider contracts.User-intent inference, policy quality, multi-region linearizability, automatic path discovery, and production hardening remain separate problems.

B. From User Approval to an Eligible Observation

AID-Guard turns user approval into an eligible observation and then durable authority through separated H1–H3 checkpoints, exact request binding, provider preconditions, and contract-specific effect paths. Conservative recovery preserves uncertainty unless provider evidence establishes no effect and supports a fenced release or successor.

  • Authority formation: H1 resolves an opaque evaluation handle and binds the server-side observation to the current actor session in one authority-store transaction.An evaluation can enter at most one authority transaction and remains non-authoritative.
  • Authority formation: H2 atomically consumes required confirmation, reserves one quota unit, registers one holder-bound capability, and commits the issuance snapshot.An exact committed retry returns the original issuance without creating another reservation or capability.
  • Authority formation: H3 revalidates claim-time state and atomically changes the capability from issued to claimed and the reservation from reserved to in flight.The authoritative claim is a server-side compare-and-swap over registered state.
  • Commit-time binding: D2 reloads the bound request and provider contract state, discards caller-owned mutable state, and enforces the approved provider precondition.The effect path receives exactly the request body whose digest is bound into the claim.
  • Provider contracts: Atomic providers combine claim, mutation, capability consumption, quota commit, and outcome recording in one transaction, while controlled-idempotent providers persist a submitted attempt and immutable outbox.The controlled-idempotent provider binds its idempotency key to the exact operation scope and request body.
  • Conservative recovery: Providers without atomic commit or durable exact-result idempotency remain uncertain and charged after ambiguous delivery, so automatic retry and replacement are disallowed.Certified recovery requires provider-enforced delivery identity and terminalization facts before release or successor transfer.

F. Evidence as a Separate Plane

AID-Guard treats evidence as a separate, durable plane that records protocol lineage and supports verification, replay, and conditional property analysis. Its guarantees depend on explicit assumptions about state, ordering, authority, and bounded proof exploration.

  • The online path emits immutable decision, claim, dispatch, outcome, and closure objects that form a complete lineage evidence graph.
  • Role-separated signatures and store commitments bind object types, transactions, effects, requests, ordering, and state.Public verification checks canonical forms, signatures, commitments, and graph completeness without sensitive artifacts; privileged replay resolves protected artifacts and reproduces deterministic projections.
  • The paper states three conditional properties and exercises their proof sketches under malformed inputs, crashes, concurrency, and bounded state exploration.Appendix Table XIII reports the finite counterexample search used to exercise failure classes.
  • The conceptual joint state comprises authorization transaction, capability, reservation, dispatch attempt, and durable provider/outcome state.The ordering relation records durable transitive references and supports atomic claim/effect transitions with their provider outcomes.

B. P1: Delegated execution authorization

P1 binds accepted provider effects to a unique successful claim of an approved, context-matching capability and the exact immutable request. Its enforcement and recovery arguments rely on commit-time checks, serialized provider contracts, and explicit scope boundaries.

  • B. P1: Delegated execution authorization: Every accepted protected effect follows a unique successful claim of an unexpired, context-matching, holder-bound capability derived from an approved root and exact immutable request.The property is conditional on assumptions A1–A5 and requires the capability and request lineage to remain bound through dispatch.
  • B. P1: Delegated execution authorization: At H3, compare-and-swap permits one claim while checking root, session, contract, dependency, boundary, request, and reservation identities together.D2 reloads the bound request, discards caller-owned mutable state, and enforces the approved provider precondition.
  • B. P1: Delegated execution authorization: The durable submitted attempt is the authorization linearization point on the controlled-idempotent path.Mutations ordered before it invalidate submission, while later mutations cannot mint replacement authority or detach the in-flight request from its lineage.
  • C. P2: Conditional effect uniqueness: For supported contracts, each reservation yields at most one provider-atomic effect across predecessor and accepted successor ownership.Atomic and controlled-idempotent contracts define the relevant retry and recovery behavior.
  • C. P2: Conditional effect uniqueness: Accepted recovery requires a no-effect certificate, installs a durable delivery fence, and atomically selects release or one successor.The transferred successor retains the same reservation identity and charge, preventing a direct predecessor effect from coexisting with accepted recovery.
  • C. P2: Conditional effect uniqueness: P2 excludes non-atomic batches and providers outside supported contracts or their retry and evidence-retention windows.For those cases, ambiguity remains charged and uncertain; absence of a provider result does not itself create recovery authority.
  • D. P3: Auditable accountability: Evidence verification detects modified, missing, mislinked, duplicated, or wrong-role objects under uncompromised evidence roles.Privileged replay additionally requires protected history and a resolved authority anchor.

E. Failure Confinement

AID-Guard confines proposer compromise through role separation, trusted reconstruction, durable state, crash-aware recovery, and an isolated effect boundary. The evaluation asks whether these controls preserve safety, recovery semantics, evidence, utility, and composition coverage across declared scenarios.

  • F. Failure Confinement: Planner compromise is constrained by accepted root, exact effect, quota, step-up, holder-proof, and boundary checks.Compromising the root signer, gateway, authority store, or exclusive effect adapter invalidates the corresponding core property because these are TCB assumptions.
  • F. Failure Confinement: The prototype uses strict typed schemas, canonical signed encodings, explicit role keys, and a pinned official MCP Python SDK.It is implemented in Python 3.11 with RFC 8785 JSON canonicalization, SHA-256 digests, and Ed25519 signatures.
  • F. Failure Confinement: A crash before commit leaves no successor state, while restart reloads durable joint state and recovery uses terminal lookup or exact replay without treating response absence as no effect.Controlled-idempotent delivery persists the outbox and attempt before network dispatch.
  • F. Failure Confinement: The effect boundary keeps credentials outside planner inputs and reloads the current authority lineage, immutable request, credential boundary, and provider contract before dispatch.Atomic delivery commits authority and provider mutation together; controlled-idempotent delivery binds idempotency to operation scope and request body.
  • F. Failure Confinement: Public verification and privileged replay operate on projected evidence and are not executable, while the live loopback deployment separates authority, provider, server, and untrusted-client processes.The bridge accepts opaque references and proofs.
  • F. Failure Confinement: The evaluation measures declared-inventory coverage, unauthorized effects, one-effect recovery semantics, evidence and recovery cost, proposer-control safety and utility, and composition with upstream defenses.

A. Experimental Scope and Method

The evaluation covers declared effect paths, lifecycle recovery, concurrency, external provider contracts, evidence verification, and performance in a frozen prototype. Across these planes, the reported executions preserved authorization-to-effect behavior under the tested mutations, histories, retries, and recovery schedules.

  • Declared scope: The frozen epoch-0 inventory completely evaluated all 39 registered items, with 20 IN_SCOPE_PASS and 19 NOT_APPLICABLE_VALIDATED dispositions.This is conformance evidence for the declared inventory, not discovery of omitted effect-capable routes.
  • Mutation evaluation: All 13 official-MCP mutations were rejected by responsible protocol checks or returned invalid verification results, adding no unauthorized provider effects.Enforcement spanned request schema, authorization binding, principal and deployment checks, and evidence verification.
  • Recovery contract: Four end-to-end traces covered commit, response loss, certified no-effect release, and transfer to one successor while preserving one-effect-or-certified-no-effect behavior.Release or transfer required a delivery fence, and successors continued the same reservation lineage rather than receiving a second budget.
  • Concurrency: Three overlapping runtime histories were linearizable, retaining one effect, blocking predecessor delivery after recovery, and rejecting a changed body under the same idempotency key.The histories exercised replay, recovery, and conflict linearization points.
  • Provider contracts: All 210 frozen Stripe trials matched predeclared outcomes, while 30 Stripe recovery lineages, 10 crash-recovery schedules, and 10 Resend lineages completed without duplicate effects.Stripe’s finite schedules do not establish arbitrary provider linearizability, and the Resend schedule was sequential.
  • Performance: The unoptimized protected median was 3930.8 ms above ambient (2.35×), with the measured increment dominated by repeated authority passes and synchronous durability.A separate SQLite benchmark sustained 1,694 operations/s with one writer and 1,373 operations/s with eight writers, while P99 rose to 104.748 ms under writer serialization.

E. RQ4: Post-Effect Evidence and Recovery Cost

The evaluation measures evidence and recovery costs in a local prototype, then tests model-in-the-loop safety, utility, proposer compromise, and containment under controlled profiles.

  • Post-Effect Evidence and Recovery Cost: 1.3 s was the average for off-path bundle generation and privileged replay in the local prototype.Receipt projection and public verification took tens of milliseconds; exceptional response-loss and certified no-effect recovery averaged 10.0 s and 14.5 s.
  • Model-in-the-Loop Admission: AID-Guard produced zero unsafe effects in protected DeepSeek and Qwen arms, versus seven for Qwen and one for DeepSeek without protection.The exact-manifest profile reduced benign utility by 43.8 percentage points for DeepSeek and 35.4 points for Qwen relative to unprotected execution.
  • Authority-Form Frontier: All 864 attack episodes remained free of unsafe effects across exact, typed single-use, and typed three-call authority forms.The typed frontier increased observed utility from 12/48 to 22/48 for DeepSeek and from 17/48 to 26/48 for Qwen, without establishing a causal effect size.
  • Containment under Proposer Compromise: AID-Guard contained all 44 Qwen positive-control cases, while Progent, Spotlighting, CaMeL, and the unprotected condition contained 30, 15, 6, and 2 cases.The adjacent methods were evaluated under a common positive-control profile.
  • Containment under Proposer Compromise: 98 oracle-confirmed unsafe effects occurred under forced pressure without protection, compared with none under AID-Guard.The positive-control profile exercised 44 closed executable attack sequences.
  • Containment under Proposer Compromise: 44/44 direct attacks were blocked under full proposer compromise while 44/44 matched legitimate proposals were admitted and executed.This separates boundary enforcement from model refusal or indiscriminate rejection.

G. RQ6: Shared-Extension Composition

The shared-extension study tests lifecycle attacks after upstream admission controls, combining controlled-provider scenarios with retry, recovery, and evidence cases.

  • Study Design: Five shared scenarios per source exercised request or actor substitution, cross-session replay, commit-time drift, and same-key body conflict.Matched-valid and AID-Guard-only cases additionally covered retry, recovery, and evidence.
  • Shared-Extension Outcomes: 20/20 shared attacks were blocked by AID-Guard, while both evaluated arms preserved all 8 matched-valid cases.Upstream-only arms produced 12 unsafe effects, four duplicate effects, and four provider-native rejections.
  • Provider Contracts: Provider support determines which recovery transitions may be enabled rather than acting as a binary integration flag.Without terminalization and retention, the adapter can disable no-effect release and successor transfer while leaving ambiguity charged and unresolved.
  • Authority-Form Frontier: The typed three-call frontier raised observed utility from 12/48 to 22/48 for DeepSeek and from 17/48 to 26/48 for Qwen, with all 864 attack episodes remaining safe.The independent no-seed calls do not establish a causal effect size or optimal policy.

B. Limitations and Future Work

The paper’s claims are bounded by its declared effect-path inventory, synthetic and controlled evaluation setting, finite provider schedules, and conservative authority forms.

  • Scope Boundaries: The prototype uses synthetic credentials on a trusted host, one enumerable loopback domain, one controlled provider, and bounded Stripe and Resend schedules.These finite test-mode observations do not establish every network interleaving or a formal provider guarantee.
  • Future Work: Practical deployment requires improved contract synthesis, policy tuning, implementation optimization, additional contracts, witnessed transparency, user studies, and isolated keys and effect boundaries.The process-separated prototype is described as high-latency, and the P1–P2 models do not cover unbounded provider and concurrency combinations.
  • Contribution Boundary: AID-Guard’s contribution is provider-state validation, ambiguity-safe successor recovery, and outcome closure rather than a new possession proof, idempotency primitive, or log.The paper positions these mechanisms as complementary to existing defenses and execution-boundary systems.

Appendix A Detailed Official-MCP Evidence

The official-MCP evidence package combines category-level conformance checks, runtime histories, contention measurements, and authority-form controls within a declared frozen profile.

  • Evidence Organization: Table VII organizes security outcomes by primary evaluation cluster, with positive-trace counts overlapping across clusters.The table is a cross-cluster organization rather than a disjoint total.
  • Runtime and Effect Histories: The independent recorder produced effect counts of 1, 1, 1, 1, 0, 0, and 0 across valid commit, exact retry, conflict, response loss, release, successor fencing, and pathcatalog mismatch probes.Every hash chain verified in the separately recorded histories.
  • D0 Inventory: Table VIII reports mechanically validated inventory dispositions, where P denotes IN_SCOPE_PASS and N/A denotes absence in the frozen epoch.These dispositions provide conformance evidence for the declared set, not automatic route discovery.
  • Authority-Store Contention: No retained authority-store operation produced a busy error or incorrect durable counter in the contention measurements.The measurement isolates the authority-store critical section rather than end-to-end protocol latency.
  • Authority-Form Controls: The exact compiler binds every argument to task ground truth, while typed profiles permit only explicit placeholders, bounded splits, or reductions within approved limits.Exact single use has quota one; bounded reuse has quota three, with fresh H1–H3 identities and single-use capability per accepted call.

Appendix D Detailed Proposer-Pressure Results

The appendix evaluates proposer-pressure discrimination, composition cases, control removals, bounded transition models, and evidence verification. Results are interpreted within fixed case sets, retained provider-native controls, and finite model bounds.

  • Proposer-pressure results: 44 predeclared Qwen-extension cases and a fixed six-case proposer-pressure set measure unsafe effects, not natural or population ASR.The table explicitly distinguishes these sets from natural or population attack-success-rate estimates.
  • Control-removal analysis: Every control-removal profile preserved its matched normal execution while retaining provider-native controls.The residual-control analysis therefore evaluates removals without bypassing provider-native protections.
  • Control-removal analysis: The two zero-delta rows do not show that single-use authority or the durable recovery fence is unnecessary.Retained provider-native idempotency and terminal controls mask those removals in this profile; other rows expose failures without such residual controls.
  • Bounded transition evidence: Depth 6 and 8 bound single-lineage executable projections rather than arbitrary numbers of principals, providers, or concurrent requests.The models validate finite projections, while concurrent schedules and combinations of authority, provider, recovery, and evidence state drive state-space growth.
  • Evidence verification: 26 verifier observations comprised 2 valid positive paths and 24 negative paths, with 7 omissions classified Incomplete and 17 mutations classified Invalid.The campaign covered authority, witness, consumption, attestation, closure, and bundle-linkage evidence, but excluded malicious-store rollback and split-view attacks requiring transparency mechanisms.
Loading 2608.21159v1…