Agent Passport

An Agent Passport is a portable, verifiable bundle of credentials that represents an agent's identity, reputation, and operational history. Passports enable cross-organizational trust without requiring a shared authority.

$ chio passport create \
    --subject-public-key HEX \
    --output FILE \
    --signing-seed-file SEED \
    --validity-days 30

What Is an Agent Passport

In the chio trust model, capability tokens authorize specific actions and receipts prove what happened. But neither answers the question: who is this agent, and should I trust it?

An Agent Passport fills that gap. It is an unsigned bundle of independently verifiable reputation credentials, each signed by an issuer who has observed the agent's behavior over time. The passport itself is not signed: each credential inside it carries its own cryptographic proof.

The passport structure (schema tag chio.agent-passport.v1):

pub struct AgentPassport {
    pub schema: String,                // "chio.agent-passport.v1"
    pub subject: String,               // did:chio identifier of the agent
    pub credentials: Vec<ReputationCredential>,
    pub merkle_roots: Vec<String>,     // receipt log checkpoint roots
    pub enterprise_identity_provenance: Vec<EnterpriseIdentityProvenance>,
    pub issued_at: String,             // RFC 3339
    pub valid_until: String,           // RFC 3339
}

Why Passports Matter

Passports solve three problems that capability tokens alone cannot:

• Cross-organizational trust. When an agent from Organization A wants to use tools in Organization B, Organization B needs a way to evaluate the agent's trustworthiness without access to Organization A's internal systems. The passport carries that evidence portably.
• Reputation. An agent that has a long history of well-behaved, least-privilege tool use is objectively more trustworthy than a brand-new agent. The passport's reputation credentials encode this history as verifiable metrics.
• Compliance. Enterprise environments need to know that an agent was deployed by a verified organization, operates under specific policies, and has a traceable operational history. Enterprise identity provenance records in the passport provide this chain.

DID Identifiers: did:chio

Every agent and operator in Chio is identified by a did:chio decentralized identifier. The method-specific identifier is the lowercase hex form of an Ed25519 public key:

did:chio:7b0f6f631f6e66207140ead0b6b2e9418916d2c4b3c7448ba5f7ed27f5c8d038

did:chio identifiers are self-certifying: basic resolution requires no registry lookup. The public key is embedded in the identifier itself, so anyone can verify signatures without contacting a resolver.

use chio_did::DidChio;
use chio_core::PublicKey;
use std::str::FromStr;

// Create from a public key
let did = DidChio::from_public_key(public_key);
println!("{}", did.as_str());
// did:chio:7b0f6f63...

// Parse from a string
let did = DidChio::from_str(
    "did:chio:7b0f6f631f6e66207140ead0b6b2e9418916d2c4b3c7448ba5f7ed27f5c8d038"
)?;

// Resolve to a DID Document (self-certifying, no network call)
let doc = did.resolve();

The resolved DID Document includes the verification method (the Ed25519 public key in multibase encoding) and, optionally, service endpoints for receipt log access and passport status resolution.

Reputation Credentials

Each credential in a passport is a signed attestation from an issuer who has observed the agent's behavior. The credential follows the W3C Verifiable Credentials data model, with chio-specific extensions:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://chio.dev/credentials/v1"
  ],
  "type": ["VerifiableCredential", "ChioReputationAttestation"],
  "issuer": "did:chio:a1b2c3d4...",
  "issuanceDate": "2026-04-01T00:00:00Z",
  "expirationDate": "2026-07-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:chio:7b0f6f63...",
    "metrics": {
      "reliability": { ... },
      "least_privilege": { ... },
      "delegation_hygiene": { ... },
      "boundary_pressure": { ... },
      "resource_stewardship": { ... },
      "specialization": { ... },
      "history_depth": { ... },
      "incident_correlation": { ... }
    }
  },
  "evidence": {
    "query": { "since": 1711929600, "until": 1714521600 },
    "receipt_count": 14832,
    "receipt_ids": ["rcpt_a1b2...", "rcpt_c3d4..."],
    "checkpoint_roots": ["sha256:d7e8f9a0..."],
    "lineage_records": 47,
    "uncheckpointed_receipts": 0
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-04-01T12:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:chio:a1b2c3d4...#key-1",
    "proofValue": "z3FXjR..."
  }
}

The metrics field contains a LocalReputationScorecard with up to eight metric categories. Each metric is computed from the agent's receipt history during the attestation window.

Reputation Metrics

The reputation scorecard includes these metric categories, each derived from the agent's auditable receipt history:

Passport Verification

Verifying a passport means checking every credential inside it:

• Each credential's Ed25519 signature is valid against the issuer's public key
• The credential's subject matches the passport's subject
• The credential has not expired
• The passport's valid_until does not extend beyond any contained credential

Verification is pure: it requires no kernel, no storage, and no network access. The verification result is a PassportVerification summary:

pub struct PassportVerification {
    pub passport_id: String,
    pub subject: String,
    pub issuers: Vec<String>,
    pub issuer_count: usize,
    pub credential_count: usize,
    pub merkle_root_count: usize,
    pub enterprise_identity_provenance: Vec<EnterpriseIdentityProvenance>,
    pub passport_lifecycle: Option<PassportLifecycleResolution>,
    pub verified_at: u64,
    pub valid_until: String,
}

Verifier Policies

A verifier can declare minimum thresholds for accepting a passport. The PassportVerifierPolicy specifies requirements that credentials must meet:

pub struct PassportVerifierPolicy {
    pub issuer_allowlist: BTreeSet<String>,       // only accept from these issuers
    pub min_composite_score: Option<f64>,          // 0.0 - 1.0
    pub min_reliability: Option<f64>,              // 0.0 - 1.0
    pub min_least_privilege: Option<f64>,           // 0.0 - 1.0
    pub min_delegation_hygiene: Option<f64>,        // 0.0 - 1.0
    pub max_boundary_pressure: Option<f64>,         // 0.0 - 1.0 (lower is better)
    pub min_receipt_count: Option<usize>,           // minimum receipts in evidence
    pub min_lineage_records: Option<usize>,         // minimum lineage depth
    pub min_history_days: Option<u64>,              // minimum operational history
    pub max_attestation_age_days: Option<u32>,      // reject stale attestations
    pub require_checkpoint_coverage: bool,          // all receipts must be checkpointed
    pub require_receipt_log_urls: bool,             // evidence must include log URLs
    pub require_enterprise_identity_provenance: bool,
    pub require_active_lifecycle: bool,             // passport must be in active state
}

Verifier policies can be signed with the verifier's key and published as SignedPassportVerifierPolicy artifacts, allowing verifiers to declare their trust requirements transparently.

Passport Lifecycle

Passports have a managed lifecycle with five possible states:

Lifecycle records are published with optional distribution metadata including resolve URLs and cache TTLs, enabling decentralized status checking.

Federation: Cross-Org Trust

Federation is how organizations establish mutual trust for agent passports. The enterprise identity provenance chain records how an agent's identity was verified through organizational identity providers:

pub struct EnterpriseIdentityProvenance {
    pub provider_id: String,            // identity provider identifier
    pub provider_kind: String,          // e.g., "azure-ad", "okta"
    pub federation_method: EnterpriseFederationMethod,
    pub principal: String,              // verified principal name
    pub subject_key: String,            // bound agent public key
    pub tenant_id: Option<String>,
    pub organization_id: Option<String>,
    pub groups: Vec<String>,
    pub roles: Vec<String>,
    // ...
}

When Organization A issues a credential for an agent, the credential can include provenance showing that the agent's identity was verified through Organization A's identity provider. Organization B can then evaluate the agent based on the issuer's reputation, the identity provenance chain, and the reputation metrics, without needing direct access to Organization A's systems.

Integration with Capability Tokens

Passports and capability tokens are complementary:

• A capability token authorizes a specific action (invoke tool X on server Y for the next 30 minutes with a $1 budget)
• A passport establishes the agent's identity and trustworthiness (this agent has been operating reliably for 90 days with a 0.95 reliability score)

The binding between them is the subject field: both the capability token and the passport use did:chio identifiers derived from the agent's Ed25519 public key. A verifier can check that the capability token's subject matches the passport's subject, confirming that the authorized agent is the same entity whose reputation is attested.

Capability Token                    Agent Passport
  subject: did:chio:7b0f6f63...        subject: did:chio:7b0f6f63...
  scope: [srv-files/read_file]        credentials: [
  expires_at: 1744537800                { issuer: did:chio:a1b2c3d4...,
  budget: 100 USD                          reliability: 0.95, ... }
                                       ]

Both bound to the same did:chio identity = same agent

Presentation Protocol

When a verifier wants to see an agent's passport, a challenge-response protocol is used:

• Challenge: The verifier sends a signed challenge specifying which issuers it accepts and how many credentials it wants to see
• Response: The agent selects matching credentials from its passport and signs a presentation proving it holds the private key corresponding to the passport's subject DID
• Verification: The verifier checks the presentation signature, validates each credential, and evaluates the result against its verifier policy

This protocol ensures that passports are only shared when requested, the agent proves ownership of its identity, and the verifier can enforce its own trust requirements.

Summary

Next Steps

• CLI Reference · passport commands for creating, verifying, and inspecting passports
• Architecture · how passports fit into the broader trust model
• Capabilities · the authorization mechanism that passports complement
• Receipts · the audit trail that reputation credentials are derived from