Skip to content
Get started

Identity & authority

Every agent.
A verifiable
origin.

Identify the agent. Verify its lineage.
Limit what it can do.

Use open SDKs for signed identity documents, scoped credentials, and policy checks. Choose the components and language your application needs.

Give your agent an identity Read the specification

Open standard · Apache-2.0 OR MIT

A closer lookAn identity, made legible.
OPENAGENTID / FIELD NOTES01PORTABLE IDENTITYdid:oas:…ROOTDesignated authoritySCOPEExplicit permissionPROOFTraceable lineage

A portable document connects an agent to its root and the authority it has been given.

  1. 01Start with a root
  2. 02Assemble the identity
  3. 03Read its authority
  4. 04Carry it forward
The agent identity control planeFollow the identity

A traceable beginning

Trust has a path.
Follow every link.

Different roots. An explicit chain of relationships.
Explore where an agent’s lineage begins.

Conceptual lineage. No identity is issued.

01 — Document

Identity and entity kind.

did:oas — a DID method for autonomous agents, designed against W3C DID Core.

did-document.json
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:oas:l1fe:agent:z6MkhaX...doK",
"kind": "agent",
"created": "2026-04-09T00:00:00Z",
"verificationMethod": [{
"id": "#key-1",
"type": "Ed25519VerificationKey2020",
"publicKeyMultibase": "z6Mkha...doK"
}],
"authentication": ["#key-1"],
"service": [{
"id": "#agent-api",
"type": "OASEntityService",
"serviceEndpoint": "https://agent.example"
}],
"lineage": {
"humanRootDid": "did:oas:l1fe:hmr:alice",
"creatorDid": "did:oas:l1fe:hmr:alice",
"generation": 1,
"derivationProof": { "type": "AgentLineageProof2025", ... }
}
}
Ln 0, Col 1
0/23 linesbuilding

02 — Lineage

The human root.

Every lineage chain terminates at a human-root keyholder (HMR/MHR). Cryptographic ancestry — not a personhood or Sybil attestation.

Human Root
Derived Roots
Agents
Entities

03 — Verification

7-step verification pipeline.

Every identity passes through the same rigorous process.

Ready
aegis-verify v0.1
01RESOLVE
02SCHEMA
03SIGNATURE
04REVOCATION
05LINEAGE
06LIVENESS
07CONFORMANCE
did:oas:l1fe:agent:z6MkhaX...doK0/7 steps
04 — How it works

Three steps.
A clearer trust boundary.

Inspect a signed document. Follow the derivation chain. Apply your verification policy before granting access. Each step gives your application a concrete input to check and a result it can explain.

format · did:oas URI + identity document

signature · Ed25519, self-signed

registry · none required

An identity you can inspect.

Every agent gets a did:oas identifier and an identity document listing its public keys and entity kind. The document is signed by a key it lists, so anyone holding it can check its integrity directly — there is no central registry to query and no account to provision. That is the OAS specification: an open DID-based standard designed against W3C DID Core — not a W3C endorsement, and not a vendor login.

derivation · HKDF-SHA256

proof · AgentLineageProof2025

root · human-root keyholder (HMR / MHR)

Trace every derivation.

Agent keys are derived from their parent's keys with HKDF-SHA256, and every derivation carries a signed lineage proof. Follow the chain upward and you land on a human-root keyholder (HMR / MHR). That proves cryptographic ancestry under the verifier's trust policy — not legal personhood or Sybil resistance, which stay out of band. Authorizing verification uses typed lineage APIs; structural shape checks never grant privilege.

pipeline · 7 checks, in order

signature · constant-time Ed25519

network · no external calls required

Verify before granting access.

The seven checks you watched — resolve, schema, signature, revocation, lineage, liveness, conformance — run wherever your code runs. The signature check is constant-time Ed25519, and the pipeline is designed to complete without external network calls. Fewer moving parts and fewer round trips: that is where the speed and the security actually come from.

05 — The integration

This is
all it takes.

Not pseudocode — the complete calls. Create OAS identities, authenticate requests, broker Arsenal credentials, require anchored lineage authority, and gate skills from the six-language SDK: TypeScript, Rust, Python, Go, Swift, Kotlin.

The verification pipeline you scrolled through is the .verify() call below. One import gives you the whole stack; every failure returns a named reason instead of a silent pass.

IdentityOAS + anchored lineage
VerificationAEGIS + revocation
CredentialsArsenal ACTs
Governanceskills policy + audit
typescript · complete example@openagentid/sdk · oas-sdk
import { act } from '@openagentid/sdk';

const claims = await act.verify(tokenBytes)
.issuer('arsenal:broker:prod-1')
.forAudience('my-service')
.requireScope('tools:calendar:invoke')
.trustedKeys([brokerPublicKey])
.run();

// verified claims, or a thrown reason:
// forged, expired, wrong-audience, under-scoped
$npm install @openagentid/sdk
06 — The control plane

Build the agent.
Define its boundaries.

Connect OAS identity, Arsenal capabilities, AEGIS verification, wallet derivation, and skills governance through one application interface. Explore each contract and its integration requirements below.

01FacadeOpenAgent SDKOne import for creating agents, authenticating requests, brokering credentials, checking skills policy, and reaching the lower layers when needed.Language-specific installation and availabilityOpenAgent.createAgent / OpenAgent.authenticateRuntime escape hatches for OAS, Arsenal, and AEGIS02IdentityOASThe did:oas identity layer: entity kinds, DID documents, local signatures, lineage proofs, and policy-controlled anchored authority.Portable DID and document verificationHuman, collective, org, agent, tool, skill, model, dataset, and service identitiesSigil by default; explicit trust policy for other anchor backends03VerificationAEGISThe request-time decision layer for signature validity, lineage, revocation, liveness, trust tiers, delegated authority, and policy.Anonymous, identified, and sovereign launch tiersFresh revocation checks even when verification is cachedPolicy for rate, time, spend, approval, and trust requirements04CapabilitiesArsenalThe ACT and credential broker layer. Agents receive scoped capability, while raw provider secrets stay inside the broker.Scope grammar: service:resource:actionSession-scoped and request-scoped ACTsCredential proxy with audit instead of plaintext API keys in agent memory05InteropAuth ProtocolThe SDK-free HTTP challenge-response binding that lets any external agent prove key possession with canonical OpenAgent headers.401 challenge with WWW-Authenticate: OpenAgentJCS challenge signing with Ed25519Session headers with DID, trust tier, token, and expiry06Identity WalletsWallet DerivationDID-rooted wallet derivation for Sigil, Solana, and EVM chains so identity and wallet authority stay connected.DID is the wallet root materialHKDF domain separation for EVM keysRotation and revocation change wallet authority paths07Runtime PolicySkills GovernancePolicy for SKILLS.md surfaces: allow, deny, rate limits, argument schemas, time windows, consent, and audit receipts.Deny unknown skills by defaultHuman approval for sensitive skillsBLAKE3 hash-chain audit receipts08CompatibilityConformanceJSON vectors and runners for challenge, signatures, nonces, trust tiers, sessions, errors, headers, and raw interop.Rust and TypeScript runnersSDK-free Ed25519 and HTTP compatibilityLaunch-required vs future-capable fixtures
07 — The layers underneath

The lower layers
stay independent.

OpenAgent ID is the facade. OAS, AEGIS, Arsenal, OATS, visual identity, and acoustic transport remain composable libraries for teams that need to reach below the facade.

OASDID-based identity framework for autonomous agents, designed against W3C DID Core (not a W3C endorsement). Portable DIDs and lineage claims give privileged actions an accountable authority path under verifier policy.AEGISModular framework for verification, authentication, delegation, and policy enforcement. Plugin-based architecture with FROST threshold signatures.ArsenalShort-lived, scoped Agent Capability Tokens (ACTs) with proof-of-possession binding. Minimizes blast radius with cryptographically-linked audit trails.OAS FingerprintParticle-based visual encoding of DID identities. Makes DIDs camera-readable with Reed-Solomon error correction and animated particle clouds.OAS GlyphConverts did:oas addresses into scannable 12x12 block-grid avatars with embedded identity data. BLAKE3-derived color palettes unique to each DID.OAS VoiceTransforms identity credentials into modulated audio signals. FSK modulation over audio with encrypted channels and replay protection.OATSAudit and trust-signal primitives for agent lifecycle evidence. Complements OAS lineage; does not sell or publish a universal paid trust score.
08 — The foundation

Open by design.
Inspectable by you.

Build against documented contracts: protocol specifications, SDK interfaces, conformance vectors, and independent libraries you can inspect.

01

Open standard

OAS identity, OpenAgent auth, Arsenal ACTs, AEGIS results, and conformance vectors are documented as contracts.

02

Layered by design

Use the OpenAgent facade for app code, then drop into OAS, Arsenal, or AEGIS when you are building infrastructure.

03

Fail-closed authority

Privileged actions require the authority checks selected by your verifier policy. Sigil is the default anchor; additional backends require explicit trust and a matching adapter. Missing required authority fails closed.

Start here

Ready to give your
agents identity?

Choose your language and check its installation requirements. Then connect identity, credentials, policy, wallets, and skills to your application.

Get StartedStar on GitHub

First call

OpenAgent.createAgent()

License

Apache-2.0 OR MIT