A contract between agents
ARSIA defines how an agent identifies itself, requests an action, carries the compliance requirements that apply to it, and communicates a human oversight decision. Because every implementation uses the same structures, messages can be inspected, tested and audited the same way everywhere.
The specification defines the contract. The SDK helps you construct and check messages. Your application and infrastructure enforce the workflow: they pause for approval, store the audit record and decide what runs.
What the envelope carries
An envelope is a JSON object. In wire version 1.0, six fields are required on every message, and the rest depend on the intent and on the requirements that apply.
| Field | What it holds |
|---|---|
v | The wire version, "1.0" in Draft-01.1. Required. |
id, ts | A unique message identifier and a UTC timestamp. Required. |
from, to | Agent identifiers of sender and receiver, such as agent:acme.advisor. Required. |
intent | One of request, response, event, error, pending_approval, approval_decision. Required. |
capabilities | The capabilities a request needs from the receiver. |
compliance | Profile, retention, data residency, human oversight, audit, PII and legal basis. |
payload | The application’s own content: a type and exactly one of args, result or data. |
security | Algorithm, key identifier and signature, plus encryption metadata when the payload is encrypted. |
correlation_id, expires_at, idempotency, context | Linking replies to requests, bounding validity, safe retries and extra context. |
Identity is more than a signature
Verifying a signature tells you that a message matches a particular public key. Trusting the sender takes more: resolving that key through discovery (JWKS), checking who issued the agent’s certificate, confirming the capability was granted, and honouring revocation.
ARSIA-Identity defines three certificate trust levels: L1 self-signed, L2 signed by a certificate authority, and L3 eIDAS qualified. Which level you accept is a policy decision for the receiver.
A structurally valid message is not automatically authorized, and a valid signature is not a guarantee that an action should execute. The receiver decides.
The message lifecycle
- Construct. Set the sender, receiver, capabilities and the application payload.
- Apply requirements. Name a compliance profile and resolve its defaults before signing.
- Sign. Bind the completed envelope to the sender’s key. Any later change needs a new signature.
- Receive and evaluate. Verify the signature, validate structure (L1) and semantics (L2), then enforce authorization and policy.
- Act and record. Ask for approval if the profile requires it, execute or refuse, and keep the audit evidence for as long as the profile says.
Human oversight
The human_oversight field says when a person must be involved. When approval is needed before execution, the agent sends pending_approval and waits; the reviewer answers with approval_decision, approved or denied, with a justification.
| Mode | Meaning | Used by |
|---|---|---|
required_before_execution | Nothing runs until a reviewer approves. | EU-AI-ACT-HIGH-RISK, MIFID-II |
required_post_execution | The action runs; a person reviews it afterwards. | PAC-AGRICULTURE |
required_within_24h | A person reviews the action within 24 hours. | DSA-VLOP, DORA |
not_required | No review is required by the profile. | GDPR-STANDARD, EU-AI-ACT-LIMITED-RISK |
The protocol defines the messages and the requirement. Pausing execution and authenticating the reviewer is the job of your runtime.
Alongside MCP and A2A
An integration can carry an MCP tool call or an A2A task inside an ARSIA envelope. The receiver evaluates the envelope first, then hands the inner message to its adapter or runtime.
MCP and A2A are separate integration paths, and neither is required. The SDK includes runnable examples for both: MCP tool calls with compliance, and A2A tasks with EU AI Act oversight (opens in a new tab).