Proposed standard · Draft VIAA-1

Don't trust the agent.
Verify every action.

VIAA-1 stops authenticating an agent once and trusting its session. Instead, every consequential action carries a cryptographic proof of who, what, and under whose attenuated authority — and the resource returns a signed receipt of what it did.

Holder-bound mandatesSigned action envelopesTamper-evident receipts
A resource can establish7 / 7
  1. 1Which agent instance requested this?
  2. 2Who operates or sponsors that agent?
  3. 3Whose authority is it exercising?
  4. 4What exact action was authorized?
  5. 5What constraints and approvals apply?
  6. 6Was the authority still valid when used?
  7. 7What actually happened?
The core rule

Natural-language instructions never grant authority

They may be recorded as audit commitments — but only structured, machine-enforceable mandates confer permission. The model that plans an action is treated as an untrusted proposer, never as a source of rights.

A resource can cryptographically establish which agent instance requested an exact action, under whose explicitly attenuated authority, subject to which constraints — and can later prove what it did with that request.

— VIAA-1, the narrow and enforceable guarantee

Five distinctions the protocol keeps separate

Each primitive proves exactly one thing. Conflating them is how confused-deputy and over-trust failures happen.

Identity
Proves: Control of a key and claims made by trusted issuers
Does not prove: Permission to act
Authority
Proves: A principal granted a narrowly defined capability
Does not prove: That the agent is competent or aligned
Attestation
Proves: Claims about the executing workload or environment
Does not prove: Future behavior
Intent
Proves: Someone approved a specific structured action or mandate
Does not prove: That an LLM understood their wishes
Receipt
Proves: A service accepted or performed a cryptographically linked action
Does not prove: That every statement made by the service is true
§2 Architecture

An authority module the model can't talk its way past

Private keys and bearer credentials live in an Agent Authority Module — a sidecar or trusted runtime — not in the planner. A compromised agent must never be the only barrier: the resource independently repeats every authorization check at the point of execution.

Human or organization
issues a root mandate
root mandate
Agent A — Authority Module
signs the exact action · attenuates to Agent B
proof bundle
Resource enforcement point
verify → reserve → execute
signed action receipt
Tamper-evident receipt
two-sided, hash-chained evidence

The Agent Authority Module

  • Converts model proposals into structured actions
  • Checks local constraints before signing
  • Obtains necessary human or org approvals
  • Signs only actions covered by a valid mandate
  • Never exposes reusable user credentials to the model

No global identity authority is required. Each resource defines which issuers and trust domains it accepts. A model name or weight hash is not identity — two deployments of the same model are distinct agents.

§4 Core signed objects

Six objects, each independently verifiable

Every object is deterministic CBOR signed with COSE_Sign1. Together the agent-signed action and the resource-signed receipt form two-sided, tamper-evident evidence — without the agent ever having to countersign after the fact.

§4.1

Agent Registration

Binds a stable agent URI to its sponsor, operator policy, and root key.

signed by Authority issuerLong-lived
  • Stable agent URI
  • Sponsor + operator
  • Root public key
  • Manifest digests
  • Revocation epoch
§4.2

Instance Binding

Connects a registration to the key of one running instance.

signed by Root keyShort-lived
  • Registration digest
  • Instance key thumbprint
  • Workload identity
  • Attestation result
  • Expiry
§4.3

Resource Descriptor

Resources identify themselves so agents can't be tricked by impostors.

signed by Resource domain keyVersioned
  • Resource identity + origins
  • Service public keys
  • Supported operations
  • Schema digests
  • Endpoints
§4.4

Mandate

A holder-bound, attenuable capability — useless without key possession.

signed by Issuer / parent holderTime-boxed
  • Grantor + holder key
  • Audiences
  • Typed constraints
  • Quotas + delegation rules
  • Obligations
§4.5

Action Envelope

Signed for every side-effecting call. Change anything and it breaks.

signed by Instance keyPer action
  • Operation + schema digest
  • Canonical parameters
  • Mandate-chain digests
  • Resource challenge
  • Idempotency key
§4.6

Execution Receipt

The resource's signed, linked record of what it actually did.

signed by Resource service keyHash-chained
  • Action digest
  • Authorization result
  • Effect identifier
  • Metered quantity
  • Previous receipt digest
§5 Authority algebra

A child mandate may narrow authority — never widen it

Mandate constraints use a limited, monotonic language so delegation-chain containment stays decidable and deterministic. No negation, no regex, no disjunction beyond explicit sets, no external policy calls.

Valid attenuation

  • Allowed operationsA subset
  • Allowed valuesA smaller set
  • Numeric rangeA contained range
  • URI / string prefixA longer, narrower prefix
  • Resource hierarchyA descendant resource
  • Time intervalA shorter interval
  • Usage or budgetA smaller amount
  • Delegation depthA lower number
  • ObligationsAdditional obligations

R′⊆R · A′⊆A · P′⇒P · T′⊆T · Q′≤Q · D′<D · O′⊇O

No implicit union — an agent can't combine two insufficient mandates into a sufficient one. Every action must be authorized by a single valid delegation chain.

mandate.json — JSON view (signed as deterministic CBOR)
{
  "type": "viaa.mandate",
  "issuer": "https://authority.acme.example",
  "grantor": "https://identity.acme.example/users/42",
  "holder_key": "sha256:INSTANCE_KEY_THUMBPRINT",
  "audience": ["https://orders.vendor.example"],
  "grant": [{
    "operation": "urn:vendor:orders:create:v3",
    "schema": "sha256:OPERATION_SCHEMA_DIGEST",
    "constraints": [
      ["currency",          "eq",     "USD"],
      ["amount_minor",      "range",  [0, 50000]],
      ["vendor_id",         "one_of", ["V42"]],
      ["shipping_country",  "one_of", ["US"]]
    ]
  }],
  "quota": { "uses": 3, "total_amount_minor": 100000 },
  "delegation": { "allowed": true, "remaining_depth": 1 },
  "obligations": ["produce_execution_receipt"]
}
The child may

Cut the cap to $200, permit one use, expire in ten minutes, forbid further delegation.

It may not

Add vendors, countries, operations, or time. Unknown operators are rejected outright.

§7 Protocol flow

Five phases, ending at the point of execution

A preflight authorization response is never sufficient. The final, binding check happens at the resource enforcement point — closing the time-of-check / time-of-use gap.

The VIAA Proof Bundle

01Agent Registration
02Instance Binding
03Mandate chain
04Fresh status assertions
05Approval evidence
06Quota reservation
07Signed Action Envelope

Presented together, the bundle lets a resource verify identity, authority, freshness, and the exact action — with no shared secret and no callback to the issuer required.

§8 Verification rule

Ten conjuncts. Every one must hold.

A perfectly signed request from an untrusted issuer, or one outside the mandate, is still rejected. A signature failure is not the only denial condition — authorization is a conjunction, evaluated independently and reported per check.

ALLOW =
ValidSignaturesTrustedIdentityPathHolderProofFreshStatusNonEscalatingDelegationActionMatchApprovalsMetObligationsMetLocalPolicyAtomicStateCommit

The check is atomic and runs at execution time: the resource consumes the action nonce, reserves quota, executes the canonical action, then commits or releases the reservation.

§9 + §10 Stateful guarantees

Budgets and revocation that static tokens can't enforce

Two resources can't both accept the same remaining budget, and a revoked agent can't keep acting on yesterday's credential. VIAA treats both as stateful, freshness-bound problems.

Quota Coordinator

A stateful service issues a short-lived reservation bound to the mandate, action, resource, holder key, and a maximum quantity. The resource commits the actual metered amount — or releases the hold on failure.

total budgetsuse countsrate limitsone-time permitschild allocations

Revocation & freshness

Bumping an agent's revocation epoch invalidates every older mandate at once; direct status entries revoke individual mandates. Agents staple a short-lived signed status assertion — and policy decides how fresh it must be.

Low-risk accessshort credential lifetimes
Medium-risk actionsa recent stapled assertion
High-risk actionsa live status check before execution
§13 Threat model

Designed against the attacks that break agent authorization

Each row is a concrete attack and the protocol mechanism that defends it. The reference implementation ships a conformance test for every one.

Stolen mandate
Holder-key binding · short lifetime · instance proof
Prompt injection
Model can't mint authority · external authority module
Confused deputy
Explicit grantor, audience, resource, operation, action
Tool impersonation
Signed Resource Descriptor + operation schema
Delegation laundering
Parent hashes + deterministic non-amplification
Request modification
Action signature covers canonical params + schema
Replay
Resource nonce · action id · expiry · consume-once state
Duplicate effect on retry
Idempotency key + signed effect receipt
Budget double-spend
Atomic quota reservation
Agent clone
Instance key · short binding · optional attestation
Semantic API drift
Mandates bind to immutable schema digests
Log fabrication
Agent-signed action + resource-signed receipt
Revoked agent active
Revocation epochs + freshness requirements
Authz / execution race
Final check + execution at the enforcement point
§11 Assurance

Assurance is a vector, not a score

VIAA defines no universal 'trusted agent' number. Resources evaluate independent claims and require exactly the level each one needs — and attestation is evaluated separately from authorization. It can inform a trust decision; it never grants access by itself.

Principal identity
self-assertedorganization-verifiedregulated
Agent registration
unregisteredsponsor-issuedindependently-certified
Key protection
softwareOS-backedhardware-backed
Runtime evidence
noneworkload-identitymeasured-attested
Approval
standingfresh human presencemulti-party
Status freshness
offlinestapledlive

A high-risk resource can require

  • organization-verified principal
  • sponsor-issued agent registration
  • hardware-backed instance key
  • fresh runtime attestation
  • per-action human approval
  • live revocation status
Privacy by default: pairwise identifiers per resource, selective disclosure of principal attributes, and salted commitments instead of raw prompts or payloads in logs.
§14–16 Wire profile & interop

A deterministic cryptographic core that rides existing rails

VIAA need not replace your identity stack. It defines the downstream action proof and receipts, and slots in beneath the protocols you already run.

Cryptographic profile

  • Deterministic CBOR for all signed data
  • COSE_Sign1 signature structures
  • SHA-256 object digests + key thumbprints
  • Ed25519 suite (P-256 ECDSA profile when required)
  • TLS transport · signed store-and-forward envelopes
  • Strict schema validation, duplicate-key rejection
  • Integer monetary quantities — never floating point
application/viaa+cborapplication/viaa-bundle+cborapplication/viaa-receipt+cbor

Compatible with existing standards

  • W3C Verifiable Credentials 2.0
    principal, sponsor, certification & registration claims
  • GNAP
    negotiate and issue root mandates
  • DPoP
    the holder-binding pattern, generalized to exact actions
  • SPIFFE · EAT · RATS
    workload identity and runtime attestation
  • WebAuthn
    fresh human approval / user-presence evidence
  • MCP · A2A · HTTP · gRPC
    transport adapters beneath the application semantics
§17 Reference implementation

A working MVP, not just a paper

The recommended first implementation exists: one trust domain, registration + short-lived instance binding, single-hop attenuated mandates, the monotonic constraint language, signed action envelopes and receipts, a quota coordinator, status epochs — and conformance tests for attenuation, replay, schema substitution, and quota races.

demo — the ten-conjunct ALLOW rule in action
$ node examples/demo.ts

Phase E — Verification & execution at the resource
  ✓ TrustedIdentityPath
  ✓ ValidSignatures
  ✓ HolderProof
  ✓ NonEscalatingDelegation
  ✓ FreshStatus        — stapled assertions fresh
  ✓ AtomicStateCommit
  ✓ ActionMatch
  ✓ ApprovalsMet       — none required
  ✓ ObligationsMet     — produce_execution_receipt
  ✓ LocalPolicy
Authorization: ALLOW
Receipt: executed | effect: order_V42_25000 | metered: 25000

Attack — over-budget action ($600 > $500 cap)
  ✗ ActionMatch  — amount_minor=60000 violates range [0,50000]
Authorization: DENY | receipt: rejected
38
conformance tests
0
runtime dependencies
6
signed object types
10
ALLOW conjuncts

Stack

TypeScriptNode ≥ 23.6Ed25519COSE_Sign1Deterministic CBORzero deps
§18 Non-goals

Narrow on purpose

VIAA does not make broad permissions safe, and it proves none of the things people wish identity could prove. It provides something smaller and enforceable instead.

VIAA does not prove…

  • that an agent is intelligent
  • that it is safe or aligned
  • that it is truthful
  • that it is legally liable
  • that it acts in your best interests
  • that an LLM understood your intent