Open Agent Passport (OAP) Standard

Updated 3 July 2026

Open Agent Passport (OAP) is a standardized, cryptographically verifiable protocol that encodes agent identity, capabilities, and authorization policies.
It integrates embedded constraints, delegation chains, and audit mechanisms into a portable and deterministic security package.
OAP facilitates secure, cross-system agent interactions with measurable enforcement latency and robust anti-injection defenses.

The Open Agent Passport (OAP) is an open, cryptographically verifiable artifact and protocol suite that standardizes identity, capability, and authorization semantics for autonomous software agents operating across heterogeneous organizational, technical, and trust boundaries. OAP serves as both a machine-consumable credential and a cross-framework enforcement regime—binding agent identity, embedded capabilities, explicit policy constraints, delegation chains, provenance assertions, and audit/recovery mechanisms into a portable, deterministic, and auditable package. It is a response to the structural gaps left by probabilistic model alignment, post-hoc evaluation, vendor-specific identity formats, and weak cross-system observability in agent-based and LLM-driven automation (Uchibeke, 21 Mar 2026, Nagabhushanaradhya, 30 Sep 2025, Madhira, 12 May 2026, Xu, 2 Jun 2026, Ravindran, 10 May 2026, Figuera, 2 Jun 2026).

1. Motivations and Scope

Autonomous agents now routinely initiate privileged actions—monetary transfers, API invocations, sub-agent delegation—across loosely federated enterprise environments. Traditional guardrails, such as RLHF or post-hoc logs, provide only probabilistic or retrospective mitigation, while identity primitives lack transportable, enforceable, and policy-rich semantics (Uchibeke, 21 Mar 2026, Madhira, 12 May 2026). The pre-action authorization gap arises because agent "passwords" authenticate identity but do not encode or enforce what an agent is allowed to do, under what policy constraints, or how evidence of proper enforcement is preserved. OAP was developed to provide deterministic, per-call authorization, prevent prompt injection bypass, and generate signed, tamper-evident audit trails—serving as the missing "permission slip" for agents (Uchibeke, 21 Mar 2026).

2. OAP Core Architecture and Model

2.1 Conceptual Structure

OAP is structured as a multi-layered, open specification:

Credential Container: A cryptographic envelope (JWT, JWS, or W3C Verifiable Credential) binding agent subject, issuer, and proof-of-possession keys (Madhira, 12 May 2026, Nagabhushanaradhya, 30 Sep 2025, Xu, 2 Jun 2026).
Authorization Payload: A portable, machine-evaluable set of permissions and constraint rules, encoded independently of the container format (Madhira, 12 May 2026).
Enforcement Engine: Deterministic, fail-closed evaluation of requests, policy constraints, and context mapping, with cryptographically verifiable audit output (Uchibeke, 21 Mar 2026).

OAP instances may also embed delegation chains, agent attestation evidence, agent-specific claims, status indicators (Active, Suspended, Revoked), and provenance metadata. Agent capabilities are declared explicitly and enforced per call or invocation (Nagabhushanaradhya, 30 Sep 2025, Xu, 2 Jun 2026).

2.2 Formal Model

The OAP authorization core can be formalized:

$P = \left(\mathrm{agentId},\,\mathrm{issuerId},\,\mathrm{Perm},\,\mathcal{C}\right)$

where $\mathrm{Perm}$ is a finite set of action identifiers, and constraints $\mathcal{C}$ are deterministic, typed predicates (e.g., numeric limits, temporal windows, enumerated allow/deny sets, string patterns) (Madhira, 12 May 2026). The enforcement decision is computed by:

$\delta(P, R, L) = \begin{cases} \mathrm{ALLOW} & \mathrm{if}\ R.\mathrm{action} \in \mathrm{Perm} \land \forall c \in \mathcal{C}: c(\mathrm{R}) \ \mathrm{DENY} & \text{otherwise} \end{cases}$

Delegated credentials are attenuated such that child permissions are a subset of parent permissions, and constraints become strictly more restrictive (Madhira, 12 May 2026).

2.3 Attestation and Provenance

OAP supports provable attestation by embedding remotely verifiable evidence (e.g., EAT/JWT), Merkle-DAG provenance of agent state, and audit trails generated with Ed25519 signatures at all principal transitions (Ravindran, 10 May 2026, Uchibeke, 21 Mar 2026). Integrity of memory and credentials is anchored via BLAKE3 or SHA-256 hashes and layered signature chains (Xu, 2 Jun 2026, Ravindran, 10 May 2026).

3. Enforcement, Evaluation, and Performance

At runtime, an OAP-compliant agent performs the following sequence (Uchibeke, 21 Mar 2026):

A tool call $T$ is attempted (e.g., API payment).
OAP "before_tool_call" hook intercepts $T$ before effectuation.
The agent presents credential $P$ ; the enforcer verifies signature, status, and capability match.
Policy lookup and constraint evaluation are conducted using the referenced policy pack.
If required, escalation or explicit deny occurs; otherwise, ALLOW.
For every decision, a signed audit record is produced.

Empirical benchmarks reveal median cloud API enforcement latency of 53 ms and local enforcement (Python subprocess) around 174–358 ms depending on percentile. In controlled red-team scenarios, social engineering attacks succeeded 74.6% of the time against permissive alignment-only architectures but were reduced to 0% under a restrictive OAP policy (across 879 attempts) (Uchibeke, 21 Mar 2026).

Performance Table

Layer	Median (ms)	99th %ile (ms)	Steps Included
Cloud API	53	77	Passport lookup, policy eval, sign
Local (subprocess)	174	358	Full local verification pipeline

4. Policy Language, Capability Encoding, and Delegation Semantics

4.1 Policy Language

OAP policies are declarative JSON documents specifying:

Unique identifier (policy_id)
Required parameter schemas (JSON-Schema)
Minimum required agent assurance level (e.g., external verification)
Constraint rules as finite, loop-free conditions (O(n) evaluation for $n$ rules) (Uchibeke, 21 Mar 2026)

For example:

{
  "policy_id": "finance.payment.refund.v1",
  "required_context": {"properties": {"amount": {"type": "number"}, ...}},
  "min_assurance": "L2",
  "rules": [
    {"condition": "amount > limits.max_per_tx", "deny_code": "oap.limit_exceeded"},
    {"condition": "currency NOT IN limits.supported", "deny_code": "oap.currency_unsupported"}
  ]
}

4.2 Capabilities and Delegation

Capabilities are encoded either as claim arrays (e.g., "email:read"), capability tokens with fine-grained permissions, or as composite objects in Merkle-DAG form for portable agent memory (Ravindran, 10 May 2026, Nagabhushanaradhya, 30 Sep 2025, Xu, 2 Jun 2026). Delegation chains are represented as cryptographically signed, chronologically ordered objects, with scope enforcement and attestation binding at each step (Nagabhushanaradhya, 30 Sep 2025, Madhira, 12 May 2026).

5. OAP in Trust Ecosystems and Discovery Protocols

5.1 Role in Trust Layers

In multi-agent protocols such as OpenAgenet/OAN, OAP acts as the canonical, versioned, Root-signed artifact linking an agent's DID document, status, canonical capabilities, and supporting cryptographic evidence (Xu, 2 Jun 2026). OAP enables protocol-agnostic agent discovery, trusted invocation, and lifecycle governance—including registration, revocation, and versioning. Agents present OAP objects for acceptance before protocol-specific message exchange.

5.2 Discovery and Invocation

Discovery nodes synchronize and index OAPs published by domain Roots, validating hash, signature, and status. Searchable fields include capabilities, service endpoints, and custom tags. Trusted invocation envelopes bind principals, API targets, nonces, and proof-of-discovery objects, ensuring replay resistance and non-repudiation.

Key Schema Fields (OAN v1 OAP)

Field	Purpose
`passportVersion`	Version identifier
`agentDid`	Agent subject identifier
`status`	[Pending, Active, Suspended, Revoked]
`metadata`	Capabilities, custom discovery tags
`hash`	Canonical package hash (SHA-256)
`rootSignature`	Root domain Ed25519 signature

6. Memory Transfer, Portability, and Security

OAP extends to signed state transfer with the Portable Agent Memory protocol, decomposing agent knowledge into five components (episodic, semantic, procedural, working, identity memory), each content-addressable and chained by a Merkle-DAG for tamper evidence (Ravindran, 10 May 2026). Capability tokens permit selective disclosure and rehydration while an injection-resistant pipeline ensures safe adaptation to new agents, mitigating prompt-injection by structural, lexical, and contextual filtering. Performance benchmarks demonstrate serialization and verification in 1–4 ms on commodity hardware; injection attacks had 0/200 success under the full protocol suite.

7. Observability, Audit, and Notarized Receipts

Standard OAP audit logs are agent-produced, but the Sello protocol extends OAP by shifting signing to the receiver. Every privileged action triggers the receiving service to generate, sign (Ed25519), and HPKE-encrypt a receipt to the agent owner's key, which is then published to a witness-cosigned public Merkle log (Figuera, 2 Jun 2026). Owners discover and verify receipts via token-derived references, achieving strong non-repudiation and tamper-evidence. Sello exhibits four key properties: receiver-side signing, HPKE-bound receipts, public log with witness cosigning, and owner-side discovery. Comparison to prior agent receipt systems shows Sello offers full support for these security properties.

Comparative Table: Observability Protocols

System	Receiver-sign	Owner-HPKE	Public log	Owner discovery
Sello (OAP/Sello)	✓	✓	✓	✓
Agent Receipt (prior)	✗	✗	✗	✗

8. Applications, Limitations, and Future Directions

OAP is deployed in live agent authorization gateways, cross-model memory transfer, GDPR-compliant data portability, multi-party workflow control, and transparency-audited automation (Uchibeke, 21 Mar 2026, Ravindran, 10 May 2026, Xu, 2 Jun 2026). Documented limitations include restricted expressivity of default policy languages, varying agent-side working memory fidelity, and dependency on external trust registries for inter-domain recognition. Future plans entail expanded stateful constraint enforcement, LLM-enabled summarization/compression, privacy-preserving selective disclosure (ZKPs), extended multi-profile bindings (JWT, VC, OAuth), and a managed ecosystem for portable memory and audit artifact exchange (Madhira, 12 May 2026, Ravindran, 10 May 2026).

OAP artifacts, specifications, and reference implementations are open source under Apache 2.0, with provenance and conformance test packs published to Zenodo (DOI: 10.5281/zenodo.18901596) (Uchibeke, 21 Mar 2026). The evolving ecosystem positions OAP as the infrastructural standard for verifiable, deterministic, and portable authorization in agentic and LLM-driven systems.