SPECIFICATION / HUMAN AUTHORITY

Agent Approval Interchange Specification

AAIS makes approval a durable, portable protocol instead of a terminal prompt: the harness stays authoritative while a CLI, web UI, desktop app, or policy service presents and returns the decision.

Project

What it is

AAIS 1.0 is an open, transport-neutral contract for one critical handoff: an agent runtime needs permission to perform an action, and a person must be able to decide from the interface they are actually using. It covers chats, bot sessions, subagents, background jobs, and graph nodes without defining any of those runtimes.

The first support release is 0.1.0. Python, TypeScript, Go, Rust, and Java libraries share one conformance corpus and implement validation, RFC 8785 action digests, request and decision creation, replay-safe pending state, and durable snapshots.

The authority boundary

The harness remains the authority. A web or desktop client presents the exact requested action and returns a selected decision; it does not grant itself new capability. Before acting, the harness revalidates the decision against the current request, action digest, expiry, offered choices, and current policy.

That separation lets several applications sit on top of one runtime without moving enforcement into each interface. A terminal, browser, native client, or policy service can all speak the same contract while the runtime keeps one source of truth.

Safety properties

  • Exact-action binding. The decision carries a digest of the canonical action the user reviewed.
  • Bounded choices. A client may select only a scope the harness offered: once, session, or a constrained persistent rule.
  • Fail-closed lifecycle. Expired, stale, conflicting, malformed, or replayed decisions are rejected.
  • Clear provenance and risk. Requests identify their harness, session, run, action, and concise reasons for the risk level.
  • Receipts and idempotency. Retried delivery cannot silently execute the approved action twice.

Approvals survive reconnects

A pending approval is durable application state, not a process blocked on standard input. Ordered events and restorable snapshots let a client close, reconnect, and recover outstanding decisions. This is what allows a web UI to handle an approval raised by a long-running graph after the user has navigated elsewhere.

How AAIS composes

AGS describes the work and where a graph may require a human gate. OAP describes the agent and the ceiling on its authority. AAIS carries the live request and decision when a specific action reaches that boundary. MCP, AG-UI, HTTP/SSE, WebSocket, and stdio can transport or adapt the messages; none replaces the authority contract.

Five support libraries

The 0.1.0 packages are published on PyPI, npm, pkg.go.dev, crates.io, and Maven Central. The libraries deliberately share behavior and fixtures so an approval emitted in one language can be verified in another instead of merely having a similar-looking JSON shape.

What it is not

AAIS does not define chat, model reasoning, tools, profiles, workflow graphs, authentication, or a network transport. It also does not expose private chain-of-thought. It carries concise activity, provenance, risk, choices, decisions, and receipts—the information a person and a runtime need to authorize safely.

Where to learn more

Primary sources first. Repositories and specifications move faster than any summary, so treat the links below as the authority and this page as orientation.