How AUMP Works¶

AUMP works by turning user delegation into an enforceable runtime boundary. An agent may still reason with an LLM, call MCP tools, exchange A2A messages, use UCP commerce surfaces, or hand off to AP2 payment flows. The difference is that each material proposed action must be evaluated against the active mandate before it becomes an external effect.

The Runtime Loop¶

flowchart LR
  plan[LLM or planner creates plan] --> action[Normalize proposed action]
  action --> resolve[Resolve mandate by id/hash/url]
  resolve --> validate[Validate schema, status, expiry, revocation]
  validate --> hard[Evaluate hard constraints]
  hard --> disclosure[Evaluate disclosure and compliance]
  disclosure --> escalation[Evaluate escalation rules]
  escalation --> decision{Decision}
  decision -->|allowed| effect[Perform downstream action]
  decision -->|requires_escalation| review[Trusted review]
  decision -->|denied| stop[Block action]
  effect --> evidence[Append evidence]
  review --> evidence
  stop --> evidence

The AUMP specification defines the three action-evaluation results as allowed, requires_escalation, and denied.¹ Conforming runtimes must validate mandates, reject inactive or expired mandates, evaluate hard constraints before soft preferences, enforce disclosure rules, process revocation, and emit evidence for material commitments.²

Data Model¶

classDiagram
  class Mandate {
    aump.version
    id
    status
    issued_at
    expires_at
    principal
    agent
    purpose
    authority
    preferences
    negotiation
    disclosure
    escalation
    evidence
    compliance?
  }
  class ProposedAction {
    type
    attributes
    terms
    decision_factors
    counterparty
  }
  class Evaluation {
    decision
    reason_codes
    paths
  }
  class EvidenceEvent {
    event_type
    mandate_ref
    action_ref
    summary
    privacy
  }
  Mandate --> ProposedAction : constrains
  ProposedAction --> Evaluation : evaluated by runtime
  Evaluation --> EvidenceEvent : recorded when material

The mandate contains authority, preferences, negotiation rules, disclosure rules, escalation policy, evidence policy, and optional compliance profiles. The proposed action is normalized into machine-readable fields so the evaluator can compare it against hard constraints and compliance rules.

Evaluation Order¶

A practical evaluator should order checks from non-negotiable to negotiable:

Validate mandate and action schemas.
Reject inactive, expired, revoked, or out-of-purpose mandates.
Enforce hard constraints and dealbreakers.
Enforce compliance profile prohibitions.
Enforce disclosure policy before outbound content leaves the runtime.
Evaluate escalation triggers.
Allow only the remaining action class.
Append evidence for material decisions.

stateDiagram-v2
  [*] --> Draft
  Draft --> Presented: present summary
  Presented --> Active: principal accepts
  Active --> Suspended: temporary hold
  Suspended --> Active: resume
  Active --> Revoked: revoke
  Active --> Expired: expires_at reached
  Active --> Superseded: replacement mandate
  Draft --> [*]
  Revoked --> [*]
  Expired --> [*]
  Superseded --> [*]

Agents must not act autonomously under a mandate whose status is not active.³

Boundary With Downstream Protocols¶

AUMP should move across protocol boundaries as references, not as the full private mandate. The core specification recommends downstream references such as aump_mandate_id, aump_mandate_hash, aump_mandate_url when appropriate, and aump_version.⁴

flowchart TB
  subgraph Private Runtime
    full[Full private mandate]
    eval[AUMP evaluator]
    full --> eval
  end
  eval --> ref[Mandate id + canonical hash + version]
  ref --> mcp[MCP _meta / structured result]
  ref --> a2a[A2A extension metadata]
  ref --> ucp[UCP meta.aump]
  ref --> ap2[AP2 handoff context]

This boundary is the privacy design. A counterparty can bind a Project Deal-style message or checkout event to the mandate hash without learning the user's reservation price, walk-away terms, private notes, or compliance-sensitive decision factors.⁶

Canonical Hash¶

AUMP uses a canonical unsigned mandate hash:

sha256(<canonical unsigned mandate JSON>)

The serialized value is sha256-<lowercase hexadecimal digest>. The top-level signatures member is excluded so adding or rotating signatures does not change the mandate identity being referenced.⁵

Failure Modes AUMP Is Designed to Catch¶

Failure	Expected decision
Agent tries to act under `draft`, `revoked`, or expired mandate	`denied`
Proposed price exceeds a hard budget constraint	`denied` or `requires_escalation`, depending on mandate policy
Agent tries to reveal a protected reservation value	`denied`
Action uses a prohibited compliance decision factor	`denied`
Commitment action requires trusted review	`requires_escalation`
Action is inside scope and discloses only permitted fields	`allowed`