| Internet-Draft | \nAgent Identity Protocol: Agentic Authent | \nMarch 2026 | \n
| Cao & Arango Gutierrez | \nExpires 17 September 2026 | \n[Page] | \n
\n This document defines the Agent Identity Protocol (AIP), an open\n standard for verifiable identity and policy enforcement for\n artificial intelligence (AI) agents.¶
\n\n Agent Identity Protocol (AIP) addresses the problem of AI agents operating with unbounded\n permissions -- running as users, inheriting full API key access, and\n executing tool calls with no verifiable identity boundary between\n human and non-human actors.¶
\n\n The protocol is structured as two cooperating layers. Layer 1\n (Identity) gives every agent a unique identifier and a key\n pair registered with an AIP Registry; the agent signs every outbound\n action with that key. Layer 2 (Enforcement) interposes a proxy\n between the AI client and every tool server that verifies the\n signature, evaluates a declarative policy, and produces an allow,\n deny, or hold decision before any tool is reached.¶
\n\n This Internet-Draft is submitted in full conformance with the\n provisions of BCP 78 and BCP 79.¶
\n\n Internet-Drafts are working documents of the Internet Engineering Task\n Force (IETF). Note that other groups may also distribute working\n documents as Internet-Drafts. The list of current Internet-Drafts is\n at https://datatracker.ietf.org/drafts/current/.¶
\n\n Internet-Drafts are draft documents valid for a maximum of six months\n and may be updated, replaced, or obsoleted by other documents at any\n time. It is inappropriate to use Internet-Drafts as reference\n material or to cite them other than as \"work in progress.\"¶
\n\n This Internet-Draft will expire on 17 September 2026.¶
\n\n Copyright (c) 2026 IETF Trust and the persons identified as the\n document authors. All rights reserved.¶
\n\n This document is subject to BCP 78 and the IETF Trust's Legal\n Provisions Relating to IETF Documents\n (https://trustee.ietf.org/license-info) in effect on the date of\n publication of this document. Please review these documents\n carefully, as they describe your rights and restrictions with\n respect to this document. Code Components extracted from this\n document must include Revised BSD License text as described in\n Section 4.e of the Trust Legal Provisions and are provided without\n warranty as described in the Revised BSD License.¶
\n\n AI agents are being deployed at scale with the same credentials as\n the humans who operate them. When an agent calls a tool -- writing\n a file, querying a database, sending a request to an external API --\n there is nothing in the request that distinguishes it from a direct\n human action. The downstream service has no way to know it is\n talking to an agent, which agent, who authorized it, or what it is\n permitted to do.¶
\n\n This creates compounding problems as agents become more capable and\n more numerous. An agent that is compromised, misbehaves, or is\n manipulated into acting outside its intended scope has no technical\n boundary stopping it from using every credential it has been given.\n Audit logs attribute actions to human accounts rather than to agents,\n making incident investigation difficult. Multi-agent systems can\n accumulate permissions across delegation steps without any explicit\n record of what was authorized.¶
\n\n AIP closes this gap with two layers:¶
\n\n Layer 1 -- Agent Identity. At provisioning time, the agent is\n registered with an AIP Registry. The registry assigns the agent a\n unique identifier (the Agent ID) and records the agent's\n public key alongside the identity of the accountable principal.\n From that point forward, the agent signs every outbound tool call\n with its private key. Any party that can reach the registry can\n verify who the agent is.¶
\n\n Layer 2 -- Enforcement Proxy. An AIP Proxy sits between the AI\n client and every tool server. It intercepts every tool call,\n verifies the agent's signature against the registry, evaluates the\n call against a simple declarative policy (the AgentPolicy), and\n either forwards the call, blocks it, or holds it for human approval.\n The tool server is never reached until all checks pass. Every\n decision is written to an append-only audit log.¶
\n\n The two layers are independent. Layer 1 can be used without Layer 2\n to provide signed, attributable agent actions in existing systems.\n Layer 2 requires Layer 1 for identity verification but adds no new\n requirements on tool servers.¶
\n\n AIP targets the Model Context Protocol (MCP) [MCP] as its primary\n tool-call interface but is designed to be applicable to any\n structured tool invocation mechanism.¶
\n\n AIP does NOT:¶
\n\n\n The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\n \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\",\n and \"OPTIONAL\" in this document are to be interpreted as described in\n BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all\n capitals, as shown here.¶
\n\n When an AI agent calls a tool, it presents credentials that belong\n to a human account. The tool server cannot tell whether the actor\n is a human or an agent, which agent it is, or what limits apply to\n it. This creates four concrete problems:¶
\n\n Security -- A compromised or manipulated agent can invoke any¶
\n\n tool the human account can reach. There is no agent-specific\n authorization boundary.¶
\n\n Auditability -- Logs record actions against a human account.¶
\n\n After an incident, investigators cannot determine which actions\n were taken by a human versus an agent.¶
\n\n Compliance -- Regulations increasingly require traceability of¶
\n\n automated decision-making. Without agent-level identity,\n organizations cannot satisfy these requirements.¶
\n\n Accountability -- Billing, rate limits, and quotas are scoped¶
\n\n to human accounts. Agent usage cannot be isolated or\n attributed.¶
\n\n Even where agent behavior policies exist, they are expressed as\n text in model system prompts. System prompts are not tamper-evident\n and can be bypassed by adversarial inputs to the model. There is no\n infrastructure-layer enforcement point that acts independently of\n the model.¶
\n\n AIP closes both gaps. Layer 1 gives every agent a distinct,\n verifiable identity independent of the human principal's credentials.\n Layer 2 enforces agent-specific policy at the tool-call boundary,\n outside the model's trust domain, in a way that cannot be overridden\n by model outputs.¶
\n\n AIP introduces two components into the agent-to-tool-server path:\n an AIP Registry (Layer 1) and an AIP Proxy (Layer 2).¶
\n\n +-----------------------------------------+\n | AI Client (Agent) |\n +-----------------+-----------------------+\n | tools/call + AIP Token\n v\n +-----------------------------------------+\n | AIP Proxy (Layer 2) |\n | +-----------+ +--------------------+ |\n | | Verify | | Policy Engine | |\n | | Token | | (AgentPolicy) | |\n | +-----+-----+ +---------+----------+ |\n | | | |\n | +-----v------------------v----------+ |\n | | Audit Logger | |\n | +-----------------------------------+ |\n +-----+-------------------+---------------+\n | |\n ALLOW | DENY | HOLD\n v v\n +-----------+ +------------------+\n | Tool | | Error / HITL |\n | Server | | Queue |\n +-----------+ +------------------+\n\n ^\n | key lookup\n |\n +---------+\n | AIP |\n | Registry|\n | (Lay. 1)|\n +---------+\n\n
\n The lifecycle of a single tool call under AIP is as follows:¶
\nRegistration (once, at deploy time). The principal registers\n the agent with an AIP Registry. The registry assigns an Agent\n ID and stores the agent's public key. The agent stores\n its private key securely.¶
\nToken construction (per call). Before each tool call the agent\n constructs an AIP Token (Section 5.6): a small JSON object\n containing the Agent ID, tool name, argument hash, nonce,\n timestamp, and a key signature over the token.¶
\nProxy intercept. The AIP Proxy receives the tool call request\n before it reaches the tool server.¶
\nToken verification (Layer 1). The proxy retrieves the agent's\n public key from the registry (or local cache) and verifies the\n signature. It also checks the nonce for replay and the timestamp\n for freshness.¶
\nPolicy evaluation (Layer 2). The proxy checks the call against\n the AgentPolicy: is the tool on the allowlist? Do the arguments\n pass validation? Does the call trigger a HITL hold? Does the\n response contain sensitive data that must be redacted?¶
\nDecision. The proxy produces one of three outcomes:\n ALLOW -- forward the call to the tool server;\n DENY -- return an error to the agent, tool server not reached;\n HOLD -- queue the call for human approval.¶
\nAudit. Every decision is written to the audit log regardless\n of outcome.¶
\nOAuth 2.0 [RFC6749] / OIDC [OIDC]: AIP does not replace service-\n level authentication. The agent still presents its OAuth token or\n API key to the tool server. AIP provides a separate agent\n identity layer that the proxy can verify independently.¶
\nSPIFFE/SVID [SPIFFE]: In Kubernetes deployments, the AIP Proxy\n MAY use a SPIFFE SVID to authenticate to tool servers over mTLS,\n layering workload identity on top of AIP agent identity.¶
\nJSON-RPC 2.0 [JSON-RPC]: Tool call and error messages use the\n JSON-RPC 2.0 wire format, compatible with MCP and similar\n protocols.¶
\n\n An agent is provisioned by its principal submitting a registration\n request to an AIP Registry. The request MUST include:¶
\n\n The agent's public key, base64url-encoded [RFC4648];¶
\n\n (b) The principal identifier -- a string that uniquely identifies\n the accountable human or organization (e.g., an email address,\n an organization slug, or an OAuth subject claim); (TO BE WORKED ON FURTHER)¶
\n\n A human-readable agent name (RECOMMENDED);¶
\n\n (d) An optional free-text description.¶
\n\n The registration request MUST be authenticated. Authentication MAY\n be via OAuth 2.0 bearer token, mTLS client certificate, or a pre-\n shared registration secret, at the registry operator's discretion.¶
\n\n On successful registration, the registry:¶
\n\n Assigns a UUID v4 [RFC4122] as the agent's local identifier;¶
\n\n (b) Constructs the Agent ID as \"<registry-host>/<uuid>\";\n (c) Stores the Agent Record (Section 5.2);\n (d) Returns the Agent ID to the principal.¶
\n\n The principal MUST store the Agent ID and configure the agent with\n both the Agent ID and its private key before deployment.¶
\n\n The Agent Record is the data structure the AIP Registry stores for\n each registered agent. It MUST contain:¶
\n\n Example Agent Record (JSON):¶
\n\n{\n \"agentId\": \"reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01\",\n \"publicKey\": \"MCowBQYDK2VwAyEAz8vG...\",\n \"principalId\": \"acme-corp\",\n \"name\": \"ResearchAssistant-v1\",\n \"description\": \"Internal document retrieval agent\",\n \"createdAt\": \"2026-01-15T09:00:00Z\",\n \"keyHistory\": [\n {\n \"publicKey\": \"MCowBQYDK2VwAyEAz8vG...\",\n \"activeFrom\": \"2026-01-15T09:00:00Z\",\n \"revokedAt\": null\n }\n ],\n \"status\": \"active\"\n}\n¶\n\n The AIP Registry MUST expose the following HTTP endpoints over\n TLS 1.3 (Section 9.4):¶
\n\nPOST /v1/agents Register a new agent\nGET /v1/agents/{agentId} Retrieve an Agent Record\nPUT /v1/agents/{agentId}/key Rotate the agent's public key\nDELETE /v1/agents/{agentId} Revoke an agent\nGET /v1/revocations/stream SSE stream for revocation events\n¶\n\n The GET /v1/agents/{agentId} endpoint is the only endpoint that\n MUST be reachable by AIP Proxies at call-verification time. All\n other endpoints are used during provisioning and key management.¶
\n\n Responses from GET /v1/agents/{agentId} MUST include the full\n Agent Record. Proxies SHOULD cache this response for at least\n 30 seconds. The cache MUST be invalidated on receipt of a\n revocation event from the SSE stream.¶
\n\n A principal rotates an agent's key by submitting a PUT request to\n /v1/agents/{agentId}/key, authenticated with the current private\n key. The request body MUST contain the new public key.¶
\n\n Append a new keyHistory entry with the new public key;¶
\n\n (c) Update the \"publicKey\" field on the Agent Record;\n (d) Emit a rotation event on the revocations SSE stream so that\n proxies can invalidate their cached Agent Records immediately.¶
\n\n The Agent ID does NOT change on key rotation.¶
\n\n A principal revokes an agent by sending a DELETE request to\n /v1/agents/{agentId}. The registry MUST set the agent's status\n to \"revoked\" and emit a revocation event on the SSE stream.¶
\n\n Proxies MUST reject AIP Tokens from revoked agents with error\n AIP-E012. Revoked Agent Records MUST be retained in the registry\n for audit log verification but MUST NOT be returned as \"active\".¶
\n\n The AIP Token is a compact signed JSON object that the agent\n constructs and attaches to every outbound tool call. It is the\n mechanism by which the agent asserts its identity to the proxy.¶
\n\n To produce the bytes that are signed:¶
\n\n Construct a JSON object containing all token fields except¶
\n\n \"signature\";¶
\n\n Serialize with no insignificant whitespace;¶
\n\n (c) Sort object keys lexicographically;\n (d) Encode as UTF-8.¶
\n\n The signature field is then set to the base64url encoding of the signature over these bytes.¶
\n\n{\n \"aipVersion\": \"1\",\n \"agentId\": \"reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01\",\n \"tool\": \"read_file\",\n \"argumentsHash\": \"e3b0c44298fc1c149afb4c8996fb924...\",\n \"nonce\": \"a3f8b2c1d4e5f607a8b9c0d1e2f3a4b5\",\n \"timestamp\": \"2026-02-24T14:30:00Z\",\n \"signature\": \"TUlJQ0lqQU5CZ2txaGtpRzl3MEJB...\"\n}\n¶\n\n The AIP Proxy MUST perform the following checks in order. A\n failure at any step MUST produce a DENY decision with the\n corresponding error code (Section 7.2) and an audit log entry.¶
\n\n If all five steps pass, the token is verified and the call proceeds\n to policy evaluation (Section 6.3).¶
\n\n The AIP Proxy is a forward proxy interposed between the AI client\n and one or more tool servers. It is transparent: it presents itself\n to the AI client as the tool server endpoint, and to the tool server\n as an authorized caller.¶
\n\n The proxy operates in one of two modes, set per agent in the\n AgentPolicy:¶
\n\n Policy violations result in DENY responses. The tool¶
\n\n server is never reached for blocked calls. This is the\n default and RECOMMENDED mode.¶
\n\n Policy violations are logged but calls are forwarded¶
\n\n regardless. Used for baselining and policy development\n before switching to enforce mode.¶
\n\n The proxy MUST maintain locally:¶
\n\no The AgentPolicy for each agent it serves;\no A bounded nonce cache (TTL >= 600 seconds, LRU eviction);\no A revocation cache (refresh interval <= 60 seconds);\no An append-only audit log.\n¶\n
\n The AgentPolicy is a YAML file that declares the enforcement rules\n for a specific agent. One AgentPolicy file corresponds to one\n Agent ID. A AgentPolicy file can apply to multiple Agent IDs.¶
\n<CODE BEGINS>\n agentId: <Agent ID>\n mode: <enforce | monitor>\n\n tools:\n allowed:\n - <tool-name>\n rules:\n - tool: <tool-name>\n action: <allow | ask | block>\n args:\n <arg-name>:\n pattern: <PCRE regex>\n maxLength: <integer>\n\n dlp:\n - name: <pattern name>\n regex: <PCRE regex>\n action: <redact | block>\n scope: <request | response | both>\n\n hitl:\n approvers:\n - <email or identifier of approver>\n timeout_seconds: <integer, default 300> # seconds to wait for approval\n on_timeout: <deny | allow> # action if no response received\n\n<CODE ENDS>¶\n
\n The tools.allowed list defines every tool the agent is permitted\n to call. Any call to a tool not on this list MUST be denied with\n AIP-E001 when the proxy is in enforce mode.¶
\n\n Each entry in tools.rules applies additional handling to a named\n tool:¶
\n\n The tool is on the allowlist and is forwarded after¶
\n\n argument validation. This is the default when no rule\n is specified.¶
\n\n The call is held for HITL approval before forwarding,¶
\n\n regardless of any other policy check.¶
\n\n The call is unconditionally denied. This overrides the¶
\n\n allowlist and cannot be circumvented. Use this for tools\n that must never be reachable by the agent under any\n circumstances.¶
\n\n Argument rules (args) apply PCRE regex pattern matching and a\n maximum length check to named arguments before the call is\n forwarded. A violation produces AIP-E002.¶
\n\n Each DLP rule specifies a regex pattern, an action, and a scope:¶
\n\n Matching content in arguments is replaced with¶
\n\n \"[REDACTED:<name>]\" and the call proceeds.¶
\n\n Matching content in the tool response is¶
\n\n replaced with \"[REDACTED:<name>]\" before the\n response is returned to the agent.¶
\n\n If a match is found anywhere in the request¶
\n\n or response, the call or response is rejected\n with AIP-E008.¶
\n\n The hitl block identifies who may approve held calls, how long the\n proxy waits, and what to do on timeout. The default on_timeout is\n \"deny\". Setting on_timeout to \"allow\" SHOULD only be used for\n non-sensitive, low-impact tools.¶
\n\n The following is the normative sequence for every tool call received\n by the proxy.¶
\n\n1. Receive the tool call from the AI client.\n\n2. Run token verification (Section 5.7).\n Any failure -> DENY with the corresponding AIP-Exxx code.\n\n3. Check tools.allowed.\n Tool not present and mode == enforce -> DENY AIP-E001.\n\n4. Check tools.rules for this tool.\n action == block -> DENY AIP-E003.\n action == ask -> go to step 7 (HITL).\n\n5. Validate arguments against any matching tools.rules.args.\n Violation -> DENY AIP-E002.\n\n6. Run DLP scan on request arguments.\n block match -> DENY AIP-E008.\n redact match -> replace content, continue.\n\n7. If action == ask: submit to HITL queue (Section 6.5).\n Approved -> continue to step 8.\n Denied -> DENY AIP-E015.\n Timed out -> resolve per on_timeout.\n\n8. ALLOW: forward the call to the tool server.\n\n9. Receive the tool server response.\n\n10. Run DLP scan on the response.\n block match -> return AIP-E008 to agent, suppress response.\n redact match -> replace content, continue.\n¶\n
\n 11. Return the (possibly redacted) response to the agent.¶
\n\n 12. Write audit log record (Section 6.7).¶
\n\n The call passed all checks and was forwarded. The tool¶
\n\n server response was returned to the agent.¶
\n\n The call was rejected before reaching the tool server.¶
\n\n The proxy returns a JSON-RPC 2.0 error (Section 7.2).\n The tool server receives nothing.¶
\n\n The call is queued. The proxy returns a pending response¶
\n\n to the agent. The call is resolved when a human approver\n responds or the HITL timeout is reached.¶
\n\n When a call is held, the proxy MUST notify all addresses listed in\n hitl.approvers. The notification MUST include:¶
\nThe Agent ID and agent name;¶
\nThe tool name and (post-redaction) arguments;¶
\nThe policy rule that triggered the hold;¶
\nA unique hold_id.¶
\n\n Notification delivery (email, webhook, Slack, web UI) is out of\n scope for this specification.¶
\n\n Approvers submit a decision to the proxy using the HITL API.\n Approval and denial endpoints are:¶
\n\n POST /v1/hitl/{hold_id}/approve\n POST /v1/hitl/{hold_id}/deny\n¶\n\n These endpoints MUST be authenticated. If no response is received\n within hitl.timeout_seconds, the proxy resolves the hold according\n to hitl.on_timeout and writes the outcome to the audit log.¶
\n\n The DLP scanner applies the dlp rules from the AgentPolicy to both\n the inbound tool call arguments and the outbound tool server\n response. Rules are evaluated in the order they are listed. The\n first matching rule wins.¶
\n\n Implementations SHOULD provide a standard rule library covering\n common sensitive data types:¶
\n\n\n The proxy MUST write one log record per tool call outcome. Records\n MUST be appended to an append-only log and MUST NOT be modified after\n writing.¶
\n\n Log records SHOULD be hash-chained: each record includes the SHA-256\n hash of the previous record, enabling tamper detection.¶
\n\n See Section 7.3 for the normative record format.¶
\n\n Log records MUST be retained for a minimum of 90 days.¶
\n\n For HTTP-based tool transports, the AIP Token is conveyed in the\n request header:¶
\n\n base64url encoding is defined in [RFC4648] Section 5 (no padding).¶
\n\n For MCP stdio transports, the AIP Token is conveyed as a \"_aip\"\n field at the top level of the JSON-RPC request object:¶
\n\n{\n \"jsonrpc\": \"2.0\",\n \"method\": \"tools/call\",\n \"id\": 1,\n \"params\": {\n \"name\": \"read_file\",\n \"arguments\": { \"path\": \"/data/report.txt\" }\n },\n \"_aip\": {\n \"aipVersion\": \"1\",\n \"agentId\": \"reg.agentidentityprotocol.io/01933f4a...\",\n \"tool\": \"read_file\",\n \"argumentsHash\": \"e3b0c44298...\",\n \"nonce\": \"a3f8b2c1d4e5f607...\",\n \"timestamp\": \"2026-02-24T14:30:00Z\",\n \"signature\": \"TUlJQ0lq...\"\n }\n}\n¶\n\n Error responses MUST conform to JSON-RPC 2.0 [JSON-RPC].\n AIP error codes are in the range -32001 to -32099:¶
\n\nCode ID Meaning\n------ -------- -----------------------------------------------\n-32001 AIP-E001 Tool not in allowlist\n-32002 AIP-E002 Argument validation failed\n-32003 AIP-E003 Tool unconditionally blocked\n-32004 AIP-E004 Nonce replay detected\n-32005 AIP-E005 Timestamp out of range\n-32008 AIP-E008 DLP violation\n-32010 AIP-E010 AIP Token missing\n-32011 AIP-E011 Agent ID not found in registry\n-32012 AIP-E012 Agent revoked\n-32013 AIP-E013 Signature verification failed\n-32015 AIP-E015 HITL approval denied\n-32016 AIP-E016 HITL timed out\n-32099 AIP-E099 Internal proxy error\n\nExample error response:\n\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"error\": {\n \"code\": -32001,\n \"message\": \"AIP-E001: tool not in allowlist\",\n \"data\": {\n \"aipCode\": \"AIP-E001\",\n \"agentId\": \"reg.agentidentityprotocol.io/01933f4a...\",\n \"tool\": \"exec_command\"\n }\n }\n}\n¶\n\n Each record is a single JSON object on one line (JSONL [JSONL]):¶
\n\n{\n \"v\": 1,\n \"ts\": \"<ISO 8601 UTC>\",\n \"eventId\": \"<UUID v4>\",\n \"prevHash\": \"<SHA-256 hex of previous record, or null>\",\n \"decision\": \"<ALLOW | DENY | HOLD>\",\n \"errorCode\": \"<AIP-Exxx or null>\",\n \"agentId\": \"<Agent ID>\",\n \"principalId\": \"<principal identifier>\",\n \"tool\": \"<tool name>\",\n \"argumentsHash\": \"<SHA-256 hex>\",\n \"policyName\": \"<AgentPolicy agentId value>\",\n \"verificationStep\": \"<1-5 or null if passed>\",\n \"dlp\": [\n { \"rule\": \"<rule name>\", \"scope\": \"<request|response>\",\n \"action\": \"<redacted|blocked>\" }\n ],\n \"holdId\": \"<UUID or null>\",\n \"proxyVersion\": \"<semver>\"\n}\n¶\n\n The localhost proxy is the simplest deployment: a single binary\n running on the developer's machine alongside the AI client. It\n binds to 127.0.0.1:8787 (configurable), supports HTTP and MCP\n stdio interception, and uses a local SQLite database for the nonce\n cache, revocation cache, and audit log. Policy is loaded from a\n YAML file at ~/.aip/policy.yaml.¶
\n\n This mode is suitable for individual developers and is the\n recommended starting point for adopting AIP. A Go proxy\n implementation is available at the working group's GitHub\n repository.¶
\n\n For production deployments, the AIP Proxy runs as a sidecar\n container in the same pod as the agent container. Outbound\n tool-server traffic is redirected through the proxy on port 15001\n via iptables REDIRECT rules. Policy is loaded from a Kubernetes\n ConfigMap or Secret. Storage uses Redis for the distributed nonce\n cache and a PersistentVolumeClaim for the audit log. A Prometheus\n metrics endpoint is exposed at /metrics.¶
\n\n Exported metrics include: aip_calls_total, aip_denials_total,\n aip_holds_total, and aip_verification_latency_seconds.¶
\n\n In enterprise environments the AIP Proxy integrates with existing\n identity infrastructure:¶
\nOIDC mapping: The registry maintains a table mapping Agent IDs\n to OIDC subject claims. When a tool server requires an OIDC\n token, the proxy can present one on the agent's behalf after AIP\n verification passes, without the agent holding OIDC credentials\n directly.¶
\nSPIFFE/mTLS: The proxy is issued a SPIFFE SVID and uses it to\n establish mTLS connections to tool servers, providing transport-\n layer mutual authentication in addition to AIP application-layer\n identity.¶
\nCentral policy management: AgentPolicy files are managed via\n a policy API with versioning, rollback, and change auditing,\n rather than local YAML files.¶
\n\n AIP is built with the idea of using Ed25519 [RFC8032] for all signatures. Ed25519 was chosen\n because it is fast (sign and verify in under 1ms), produces short\n keys and signatures (32 and 64 bytes respectively), is deterministic\n (no per-signature randomness required), and has broad library support\n across all major languages and platforms. However other cryptographic algorithms should be supported.¶
\n\nAll Ed25519 operations MUST use a constant-time\nimplementation to prevent timing side-channels (Section 9.3).\n¶\n
\n The principal threat model for AIP at Layer 2 is the prompt\n injection attack: malicious content in the agent's context causes\n it to attempt tool calls outside its intended scope.¶
\n\n The allowlist in the AgentPolicy prevents the agent from reaching\n tools it was not provisioned for, regardless of what the model\n produces. The \"block\" action provides an unconditional deny for\n specified tools that cannot be overridden by any model output,\n injected prompt, or delegation claim. The proxy operates entirely\n outside the model's trust boundary; the model cannot influence the\n proxy's decisions.¶
\n\nAIP does not protect against:\no A compromised agent runtime that routes calls around the proxy;\no Tool servers that accept calls from sources other than the proxy.\n¶\n
\n All communication between AIP Proxies and the AIP Registry MUST use\n TLS 1.3 [RFC8446]. Server certificates MUST be validated against\n the system trust store. Certificate pinning is RECOMMENDED for\n registry connections in production deployments.¶
\n\n Proxy-to-tool-server connections MUST use TLS 1.2 [RFC5246] or\n later. TLS 1.3 is RECOMMENDED.¶
\n\n Agent private keys MUST be stored in a secure key store. In order\n of preference:¶
\n\n 1. Hardware Security Module (HSM) or Trusted Platform Module (TPM);\n 2. OS keychain (macOS Keychain, Windows DPAPI, Linux Secret Service);\n 3. Encrypted file with passphrase derived using Argon2id [RFC9106].¶
\n\n Private keys MUST NOT be stored in environment variables, plaintext\n configuration files, or source code repositories.¶
\n\n A proxy MUST be configured with an explicit list of trusted registry\n hostnames and the TLS certificate fingerprint (or CA) for each.\n Agent Records from registries not on this list MUST be rejected.¶
\n\n The nonce cache must be large enough to hold all unique nonces\n generated within the TTL window (600 seconds). Implementations\n MUST use a bounded cache with LRU eviction and MUST NOT silently\n drop old nonces without ensuring they are outside the TTL window.¶
\n\n The proxy's revocation cache has a maximum refresh interval of\n 60 seconds (Section 6.1). In the worst case, a revoked agent can\n continue making calls for up to 60 seconds after revocation.\n Deployments with stricter requirements SHOULD subscribe to the\n registry's SSE revocation stream (Section 5.3) and invalidate the\n cache on receipt of a revocation event.¶
\n\n The proxy adds a small amount of latency to every tool call (one\n cache lookup and one key verification). To prevent the proxy\n from becoming an availability bottleneck:¶
\n\n\n Agent Records are visible to any party that can query the registry.\n Principals SHOULD use non-identifying agent names for agents that\n handle sensitive workloads.¶
\n\n Audit logs contain Agent IDs, tool names, and argument hashes.\n While argument values are not logged in plaintext, the combination\n of Agent ID and tool name may itself be sensitive in some contexts.\n Audit logs MUST be access-controlled appropriately.¶
\n\n When DLP redaction is applied to a response, the proxy modifies the\n data the agent receives. Operators MUST ensure that redaction does\n not cause the agent to produce incorrect or harmful downstream\n actions due to missing context.¶
\n\n Registry operators MUST publish a data retention policy. Agent\n Records for revoked agents SHOULD be pseudonymized after the\n minimum retention period required for audit log verification.¶
\n\n This document defines the \"AIP-Token\" HTTP header field. Registration\n is requested in the \"Permanent Message Header Field Names\" registry\n per [RFC3864]. The header field name is \"AIP-Token\", applicable\n protocol is \"http\", status is \"standard\", the author/change\n controller is the IETF, and the specification document is this\n document (Section 7.1).¶
\n\n The media type \"application/aip+json\" is requested for AIP Tokens\n serialized as standalone JSON documents. The type name is\n \"application\", the subtype name is \"aip+json\", the required\n parameter is \"version\" (value \"1\"), encoding considerations are\n UTF-8, and security considerations are described in Section 9.¶
\n\n A complete AgentPolicy for a research assistant agent.¶
\n<CODE BEGINS>\n\n agentId: reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01\n mode: enforce\n\n tools:\n - allowed:\n - read_file\n - list_directory\n - web_search\n - git_status\n - write_file\n - create_issue\n - rules:\n - tool: write_file\n action: ask\n - tool: exec_command\n action: block\n - tool: delete_file\n action: block\n - tool: create_issue\n action: ask\n\n dlp:\n - name: aws-access-key\n regex: \"AKIA[A-Z0-9]{16}\"\n action: block\n scope: both\n - name: private-key-pem\n regex: \"-----BEGIN [A-Z ]* PRIVATE KEY-----\"\n action: block\n scope: both\n - name: generic-token\n regex: \"[a-zA-Z0-9_\\\\-]{40,}\"\n action: redact\n scope: response\n\n hitl:\n - approvers:\n - ops@acme.example\n - timeout_seconds: 300 # wait 5 minutes\n - on_timeout: deny\n\n\n<CODE ENDS>¶\n\n An AIP Token for a read_file call, shown before base64url encoding\n for transport in the AIP-Token header.¶
\n\n{\n \"aipVersion\": \"1\",\n \"agentId\": \"reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01\",\n \"tool\": \"read_file\",\n \"argumentsHash\": \"e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855\",\n \"nonce\": \"a3f8b2c1d4e5f607a8b9c0d1e2f3a4b5\",\n \"timestamp\": \"2026-02-24T14:30:00Z\",\n \"signature\": \"TUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFOQ0E...\"\n}\n¶\n\n Tool not in allowlist¶
\n\n The requested tool is not listed in tools.allowed and\n the proxy is in enforce mode.¶
\n\n Argument validation failed¶
\n\n A tool argument failed a pattern or maxLength check\n defined in tools.rules.args.¶
\n\n Tool unconditionally blocked¶
\n\n The tool has action: block in tools.rules.¶
\n\n Nonce replay¶
\n\n The nonce in the AIP Token was already seen within the\n 600-second cache window.¶
\n\n Timestamp out of range¶
\n\n The token timestamp is more than 300 seconds old or more\n than 30 seconds in the future.¶
\n\n DLP violation¶
\n\n A DLP rule with action: block matched content in the\n request or response.¶
\n\n AIP Token missing¶
\n\n The tool call arrived with no AIP-Token header or _aip\n field.¶
\n\n Agent ID not found¶
\n\n The agentId in the token could not be resolved at the\n registry.¶
\n\n Agent revoked¶
\n\n The Agent Record for this agentId has status: revoked.¶
\n\n Signature verification failed¶
\n\n The key signature did not verify against the public\n key in the Agent Record.¶
\n\n HITL approval denied¶
\n\n A human approver explicitly denied the held call.¶
\n\n HITL timed out¶
\n\n The HITL hold expired and on_timeout is set to deny.¶
\n\n Internal proxy error¶
\n\n An unexpected error occurred in the proxy. See proxy\n logs for details.¶
\n\n \n draft-aip-agent-identity-protocol-00\n \n
\n \n\n\n\n\n\n\n\n Active Internet-Draft\n (individual)\n \n\n
| Document | \nDocument type | \n\n | \n \n\n\n\n\n\n\n\n Active Internet-Draft\n (individual)\n \n\n \n \n \n \n\n\n\n\n \n This document is an Internet-Draft (I-D).\n Anyone may submit an I-D to the IETF.\n This I-D is not endorsed by the IETF and has no formal standing in the\n IETF standards process.\n \n\n\n \n | \n
|---|---|---|---|
| \n | Select version | \n\n | \n \n\n\n\n
| \n
| \n | Authors | \n\n \n | \n\n \n \n James Cao \n ,\n \n Carlos Eduardo Arango Gutierrez \n \n \n \n \n Email authors\n \n | \n
| \n | \n RFC stream\n | \n\n \n | \n\n \n (None)\n \n | \n
| \n | \n Intended RFC status\n | \n\n \n | \n\n \n \n (None)\n \n \n | \n
| \n | \n Other formats\n | \n\n | \n\n \n \n \n\n \n | \n