RFC 0001
The aittps Handshake
§0Abstract
This document proposes the aittps Handshake: a small set of HTTP headers and verification rules that let an AI agent prove, on every request, which agent it is, whom it acts for, what it is permitted to do, and to leave a verifiable record of what it did. It layers on top of HTTPS and existing standards rather than replacing them. The goal is a web where sites can trust agent traffic by verifying it, not by guessing from IP addresses, user-agent strings or CAPTCHAs.
§1Status of this document
This is a first draft, published openly to invite criticism. Nothing here is final. aittps is an open protocol: no company owns it, anyone may implement it free of charge, and changes are made in public. The key words MUST, SHOULD and MAY are used as described in RFC 2119.
§2Problem
The web's trust model assumes a human behind each browser. That assumption is failing in three ways:
- Agents as weapon. AI finds and exploits vulnerabilities faster than humans can patch them. Defenses based on obscurity or rate of human effort no longer hold.
- Agents as target. Agents produce unconstrained output and can be manipulated, for example by prompt injection, into actions their principal never intended, such as leaking keys or personal data.
- Agents as crowd. Automated traffic now rivals or exceeds human traffic. Sites cannot distinguish a person from a script, or a legitimate agent from an abusive one.
Today a site receiving an automated request can only guess. HTTPS tells the client the server is genuine; nothing comparable tells the server who the automated client is, or what it is allowed to do.
§3Design goals
- Verify, don't guess. Trust decisions rest on cryptographic checks, not heuristics.
- Scope, don't trust. A valid identity is not permission. Every request carries the limits of its mandate, so a compromised agent cannot exceed it.
- Eliminate bug classes. Prefer rules that make whole categories of attack impossible over detection that catches them one at a time.
- Privacy by default. A site learns that a verified human or organisation stands behind an agent, not who that human is, unless the principal chooses to disclose more.
- Build on what exists. Reuse HTTPS, HTTP Message Signatures and existing key formats wherever they fit.
- Incremental. A site can start by logging aittps headers, then rate-limit by them, then require them, with no flag day.
§4Overview
The handshake answers four questions, each a layer that builds on the one below:
| LAYER | QUESTION | CARRIED IN |
|---|---|---|
| L1 Identity | Which agent is this? | Agent + signature |
| L2 Delegation | Whom does it act for? | On-Behalf-Of |
| L3 Scope | What may it do, until when? | Agent-Scope |
| L4 Proof | Can both sides verify it later? | Agent-Receipt (response) |
An example request:
POST /checkout HTTP/1.1
Host: shop.example
Agent: https://agents.example/shopper/7f3a
On-Behalf-Of: eyJhbGciOiJFZERTQSJ9... ; delegation credential
Agent-Scope: purchase;max=50USD;uses=1;exp=1792713600
Signature-Input: aittps=("@method" "@target-uri" "agent"
"on-behalf-of" "agent-scope" "content-digest");
created=1792710000;keyid="7f3a-2026";alg="ed25519"
Signature: aittps=:9c1e...b44a:
Content-Digest: sha-256=:X48E9q...:§5Layer 1: Identity
An agent is identified by an Agent URI, an HTTPS URL controlled by the agent's operator. Dereferencing the URI with Accept: application/aittps+json MUST return an agent document containing at least the operator's name, a contact address and a JSON Web Key Set of the agent's current public keys.
Each request MUST be signed using HTTP Message Signatures (RFC 9421) with a key listed in the agent document. The signature MUST cover the method, target URI, the Agent, On-Behalf-Of and Agent-Scope headers, and a content digest when a body is present.
Because the Agent URI is an HTTPS URL, its trust anchors in the existing Web PKI: an agent can be no more anonymous than the domain that hosts its document.
§6Layer 2: Delegation
The On-Behalf-Of header carries a delegation credential: a signed token, issued by a principal or an issuer the principal trusts, stating that the named agent may act for that principal. It MUST include the agent URI, an expiry, and the maximum scope granted.
The principal is described by assurance, not identity. A credential MAY assert, for example, principal=human;assurance=proof-of-person or principal=org;name=Example Ltd. Issuers SHOULD use unlinkable or pairwise identifiers so that sites cannot correlate a person across services.
§7Layer 3: Scope
The Agent-Scope header states what this specific request is permitted to do. It MUST be a subset of the scope granted in the delegation credential. A scope is an action name followed by optional constraints:
Agent-Scope: read:inbox;exp=1792713600
Agent-Scope: purchase;max=50USD;uses=1;exp=1792713600Sites publish which actions their endpoints require at /.well-known/aittps. A site MUST reject a request whose required action is not covered by the presented scope, even when the identity and delegation are valid. This is the rule that contains prompt injection: a hijacked agent holding read:inbox cannot export keys, whatever it has been told to do.
§8Layer 4: Proof & receipts
For any state-changing request, a site SHOULD return an Agent-Receipt header: a signed statement of the action performed, the scope it was performed under and a timestamp, signed with a key the site publishes at its well-known location. The agent forwards receipts to its principal. Both parties then hold the same tamper-evident record, which resolves disputes about what an agent did and on whose authority.
§9Verification and responses
A verifying site or edge proxy proceeds in order, stopping at the first failure:
- Fetch (or use a cached copy of) the agent document; check the signature and its freshness.
- Verify the delegation credential: issuer, expiry and that it names this agent.
- Check that
Agent-Scopeis within the delegated scope and covers the endpoint's required action. - Apply local policy, such as rate limits per agent or per principal.
| RESULT | RESPONSE |
|---|---|
| All checks pass | Normal response, plus Agent-Receipt where applicable |
| No or invalid identity | 401 with WWW-Authenticate: aittps describing what the site accepts |
| Valid identity, out of scope | 403 with the required action named, so the agent can ask its principal |
| Expired credential or scope | 401 with an error="expired" parameter |
§10Security and privacy considerations
- Replay. Signatures include a creation time; verifiers SHOULD reject requests older than a short window and MAY require a nonce for state-changing actions.
- Key compromise. Operators rotate keys by updating the agent document; short credential lifetimes bound the damage of any leaked key.
- Prompt injection. aittps does not stop an agent being manipulated. It limits what a manipulated agent can do to the scope its principal granted.
- Tracking. Delegation credentials can become a cross-site identifier. Issuers SHOULD use pairwise identifiers, and sites MUST NOT require more principal disclosure than the action needs.
- Exclusion. Requiring aittps must not lock out humans using ordinary browsers. The protocol is for automated clients; sites SHOULD keep human paths open.
§11Prior art and related work
aittps builds on, and should stay compatible with, existing work: HTTP Message Signatures (RFC 9421) for request signing; OAuth 2.0 and token exchange (RFC 8693) for delegation; W3C Decentralized Identifiers and Verifiable Credentials; and ongoing IETF and industry efforts on authenticating automated web clients and agent payments. Where those efforts already solve a layer well, aittps should adopt them rather than compete.
§12Open questions
- Which delegation credential format should be normative?
- Who issues proof-of-person assurances, and how do sites choose which issuers to trust without recreating a central gatekeeper?
- Should scope vocabularies be standardised per domain (commerce, email, social) or left to each site?
- How should agent-to-agent calls chain delegation without unbounded token growth?
- What is the minimum a site must implement to claim aittps support?
Comments, objections and alternative designs are welcome as GitHub issues.