EMILIA Protocol, Inc.

US team@emiliaprotocol.ai

sec AI agents authorization well-known URI receipts fail-closed A growing set of specifications defines evidence objects for machine actions: transparency statements, workload-identity and transaction tokens, permits, action capsules, and authorization, delegation, and inference receipts. What they mostly do not define is the public control plane that says, for a given irreversible action, which evidence is required, at what assurance tier, bound to which real system-of-record fields, under what replay model, and what evidence must exist after the action runs. This document defines the Agent Action Control Manifest: a machine-readable document a service publishes at a well-known location that declares, per consequential action, the enforcement point, the required authorization receipt profile and assurance tier, the execution-binding fields that MUST be observed from the system of record, the replay model, and the evidence that MUST be emitted after the effect boundary. It also carries an OPTIONAL, advisory effects preview (reversibility, data-exposure class, cost class, downstream reach, and whether human consent is required) so a runtime can weigh consequences before it seeks authorization. It is the declaration an agent runtime reads to learn what it must satisfy before an irreversible action, and that an independent scanner audits. The manifest declares policy; it never replaces enforcement, which remains authoritative at the action boundary.

Introduction Layered web conventions tell software what it may do: robots.txt declares crawler policy, CORS declares cross-origin policy, security.txt declares where to report vulnerabilities, and authorization-server metadata declares an issuer's endpoints and capabilities. When an autonomous agent drives a tool or API, no equivalent declaration exists for the properties that matter at machine speed: whether an action is irreversible, what authorization it needs, which observed execution fields the authorization must bind, and what evidence must survive it. The evidence-object ecosystem does not fill this gap. Transparency architecture logs signed statements; workload and transaction-token work identifies the acting principal; permit, capsule, and action-receipt work records decisions and effects. Each defines an artifact; none defines the public contract that binds a specific consequential action to the specific evidence and assurance it requires. Tool-catalog declarations (tool annotations, agent cards) sit closer, but they describe what a tool can do and hint at destructiveness; they do not state what evidence a caller must present, at what assurance, bound to which fields, with what replay semantics. The manifest defined here is also deliberately protocol-agnostic: one declaration covers the same consequential action whether it is reached as a tool call, an HTTP API, or an agent-to-agent message. This document defines that contract as a manifest a service publishes, composing above the receipt primitive and the assurance taxonomy it references.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Consequential action

An operation whose effect is irreversible or materially hard to reverse — a payment, a deletion, a production deploy, a destructive data operation, a permission change.

Control plane

The declarative contract, defined by this manifest, mapping each consequential action to its authorization, execution-binding, replay, and evidence requirements.

Effect boundary

The point at which the action mutates the system of record; the control MUST be enforced before it.

Manifest Location and Versioning A service SHOULD publish its manifest at the well-known URI : /.well-known/agent-action-control.json served with media type application/json over a transport providing server authentication and integrity. The current manifest version identifier is EP-ACTION-CONTROL-MANIFEST-v0.2. An earlier, declaration-only predecessor (EP-ACTION-RISK-MANIFEST-v0.1, served at /.well-known/agent-actions.json, without the control block defined in ) is superseded by this version. A consumer that encounters an unrecognized @version MUST treat the document as discovery-only: it MUST NOT infer weaker requirements from fields it does not understand. Consumers MAY cache the manifest under ordinary HTTP cache semantics; because enforcement is authoritative at the action boundary (), manifest staleness fails safe — an outdated manifest can at worst cause a caller to present insufficient evidence and be refused, never an unauthorized execution.

Manifest Structure The manifest is a JSON object . This section defines the interoperable model; a field-level JSON Schema for the profile is published at the URL named by $schema and pins field types and requiredness for implementations of that profile.

@version, $schema, profile (REQUIRED)

The version identifier, the URL of the JSON Schema, and the profile name (agent-action-control).

service (REQUIRED)

The publishing service (name, issuer origin, manifest URL).

defaults (REQUIRED)

The default disposition, which MUST be fail-closed for consequential actions: missing, invalid, and stale receipts refused; one-time consumption; strict evidence logging.

evidence_profiles (REQUIRED)

The evidence formats the manifest references (authorization receipt, execution attestation, reliance packet, transparency statement).

actions (REQUIRED)

The per-action control declarations ().

Action Control Declarations Each action declaration carries an identifier, a match (how to recognize the action — e.g. protocol + tool, or method + path), the canonical action_type, an advisory risk, receipt_required, the minimum assurance_class, and max_age_sec — the maximum age, in seconds, of the presented authorization receipt at verification time, measured from its issuance timestamp; an older receipt MUST be refused as stale. The match member selects the surface; the action_type is the canonical name the authorization evidence binds to. A publisher MUST NOT publish overlapping match selectors whose declarations conflict; a consumer that finds more than one matching declaration MUST apply the most restrictive one. When receipt_required is true the declaration MUST also carry a control object:

enforcement_point

Where the control runs (pre_execution or pre_effect_commit); enforcement MUST precede the effect boundary. For HTTP surfaces the declaration also names the transport binding: on refusal the service SHOULD return 428 with the declared challenge header, and the caller presents its receipt in the declared proof header.

authorization_receipt

The required receipt profile (an offline-verifiable authorization receipt ).

replay

The replay model; for consequential actions one_time_consumption with a required receipt identifier.

execution_binding

That the authorized action MUST bind material fields observed from the system of record (source: system_of_record), and the non-empty set of required_fields that MUST match. This is what stops "approve $250K to Vendor A" from executing as "$300K to Vendor B".

evidence_output

The evidence that MUST exist after the action: an execution attestation, a reliance packet, and a record of blocked attempts; optionally a transparency registration.

A declaration MAY carry an OPTIONAL effects member: a machine-readable preview of what the action does, so an agent runtime or a human approver can weigh consequences before authorizing. Like risk, effects is ADVISORY — it is not a security control and MUST NOT substitute for the receipt requirement; the fail-closed control is the enforcement point, not a label. Its members:

reversibility

Whether the effect can be undone: irreversible, hard_to_reverse, or reversible. An honest class, not a guarantee.

data_exposure

The most sensitive data class the action exposes or mutates: none, internal, pii, or regulated.

cost_class

An order-of-magnitude impact band (none, low, material, high) — a class, not a figure: the manifest is static, and the actual amount is an execution-binding field observed from the system of record.

downstream

External systems or services the effect propagates to, so a caller can see blast radius beyond the immediate resource.

consent_required

Whether an explicit human-consent interaction is required for this action, distinct from the authorization receipt: the receipt is the durable, offline-verifiable evidence; consent is the interaction that produces it. A true value means the runtime MUST surface the effect to a human before an authorization is sought.

The effects preview and the control requirement answer different questions — "what will this do, and how consequential is it" versus "what authorization evidence is required, and how is it enforced" — and a runtime uses the first to decide whether to seek the second. Neither substitutes for the other: a low-cost_class action can still be irreversible and demand the strongest tier, and the effects preview never lowers a declared control. A declaration MAY additionally carry a conformance member naming the conformance level the enforcement claims to meet and the checks it passes (for example: missing receipt refused, insufficient assurance refused, execution mismatch refused, replay refused, tamper refused). This turns the declared posture into a set of independently re-runnable tests rather than an assertion. A verifier MUST be able to recompute, from the action itself, that the presented authorization is over the same action and meets the declared assurance tier; it MUST NOT rely on a self-asserted assurance value (see the assurance-class taxonomy ).

Semantics: Declaration Is Not Enforcement A service MUST enforce its receipt requirement at the effect boundary regardless of the manifest, and a caller MUST NOT infer that an action is safe because the manifest omits it or marks it not-required. Enforcement is authoritative; the manifest exists so the requirement is discoverable and auditable, not so it can be disabled by editing a file. The declaration (this manifest) and the audit (an independent scan of the live surface) are a pair; a service that both publishes a manifest and passes an independent scan has a verifiable, not merely asserted, posture.

Inline OpenAPI Expression (x-agent-action-control) Deployments that already publish an OpenAPI description MAY express a manifest entry inline, per operation, as an "x-agent-action-control" specification extension carrying the equivalent members of the corresponding manifest entry (action identifier, assurance tier, and the advisory effects preview); the extension's JSON Schema defines the field-level mapping between the two forms, whose member names differ in places for historical reasons. The extension was first deployed under the vendor name "x-emilia-action"; implementations SHOULD accept both names and MUST treat them as aliases of this definition. The two forms are equivalent views of the same declaration: when both are present for an action, they MUST NOT disagree, and a verifier encountering a disagreement MUST treat the stricter declaration as governing. Action identifiers in either form use the "urn:ep:action:<family>.<action>" vocabulary, so that relying-party evidence policies can be keyed to the same names the resource declares. A JSON Schema for the extension and a worked OpenAPI example are published with the reference implementation.

Security Considerations Enforcement is authoritative, not the manifest. A manifest that omits an action, or marks it not-required, does not make that action safe; the enforcement point is the control. Treating the manifest as authoritative would let an attacker who can edit or spoof it disable protection. Integrity and authenticity. The manifest MUST be served over an authenticated, integrity-protected transport and MAY be signed; unsigned manifests fetched over an untrusted path MUST NOT be relied upon beyond discovery. Advisory fields are not scores. The risk field MUST NOT be read as a measurement of safety or as a substitute for the receipt requirement. The security property is the fail-closed control, not a severity label. Information disclosure. A manifest enumerates a service's high-consequence actions; publishers SHOULD assume it is public and SHOULD NOT encode secrets or internal-only endpoints. Downgrade and receipt disclosure. Because enforcement is authoritative, an attacker who spoofs or weakens a manifest cannot disable protection — a caller misled into presenting weaker or no evidence is refused, a denial of service at worst. The sharper risk is disclosure: a spoofed manifest could induce an agent to present an authorization receipt — which may carry an approver identity and action details — to an attacker-controlled endpoint. A consumer SHOULD present a receipt only to the origin from which the manifest was authenticated, and receipt audience binding limits what a misdirected receipt is worth.

IANA Considerations This document requests registration of the following well-known URI in the "Well-Known URIs" registry established by :

URI suffix

agent-action-control.json

Change controller

IETF

Specification document

This document

Status

permanent

Normative References Informative References

Example Manifest (Non-Normative) The following example, abridged from a live deployment, declares one consequential action. A payment-release tool is reachable over a tool-call protocol; executing it requires a device-verified named-human authorization receipt no older than 900 seconds, bound to the material fields as observed from the system of record, consumed exactly once, with post-execution evidence.