---
title: Open Agent Passport (OAP) Standard
url: https://www.emergentmind.com/topics/open-agent-passport-oap
type: topic
---

# Open Agent Passport (OAP) Standard

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 [2603.20953] [2509.25974] [2605.11487] [2606.03163] [2605.11032] [2606.04193].

## 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 [2603.20953] [2605.11487]. 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 [2603.20953].

## 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 [2605.11487] [2509.25974] [2606.03163].
- **Authorization Payload**: A portable, machine-evaluable set of permissions and constraint rules, encoded independently of the container format [2605.11487].
- **Enforcement Engine**: Deterministic, fail-closed evaluation of requests, policy constraints, and context mapping, with cryptographically verifiable audit output [2603.20953].

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 [2509.25974] [2606.03163].

### 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) [2605.11487]. 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 [2605.11487].

### 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 [2605.11032] [2603.20953]. Integrity of memory and credentials is anchored via BLAKE3 or SHA-256 hashes and layered signature chains [2606.03163] [2605.11032].

## 3. Enforcement, Evaluation, and Performance

At runtime, an OAP-compliant agent performs the following sequence [2603.20953]:

1. A tool call $T$ is attempted (e.g., API payment).
2. OAP "before_tool_call" hook intercepts $T$ before effectuation.
3. The agent presents credential $P$; the enforcer verifies signature, status, and capability match.
4. Policy lookup and constraint evaluation are conducted using the referenced policy pack.
5. If required, escalation or explicit deny occurs; otherwise, ALLOW.
6. 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) [2603.20953].

**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) [2603.20953]

For example:

```json
{
  "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 [2605.11032] [2509.25974] [2606.03163]. Delegation chains are represented as cryptographically signed, chronologically ordered objects, with scope enforcement and attestation binding at each step [2509.25974] [2605.11487].

## 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 [2606.03163]. 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 [2605.11032]. 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 [2606.04193]. 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 [2603.20953] [2605.11032] [2606.03163]. 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 [2605.11487] [2605.11032].

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) [2603.20953]. The evolving ecosystem positions OAP as the infrastructural standard for verifiable, deterministic, and portable authorization in agentic and LLM-driven systems.

Source: https://www.emergentmind.com/topics/open-agent-passport-oap