Skip to content
Get started
OpenAgent · Security

Security
by construction

Six layers of defense. Every layer of the identity stack is built on reviewed, standards-track cryptography with properties a verifier can check offline — not assurances that depend on a network path.

Layers
6
Model
Defense in depth
Verify
Offline-first
Report
security@openagent.id
Threat modelReport a vulnerability
A closer lookTrust deserves a closer look.
OPENAGENTID / FIELD NOTES04IDENTITY + PROOFCHECK BEFORE ACCEPTING

Inspect the identity, follow the proof, and check the boundary before accepting an action.

  1. 01Present the identity
  2. 02Inspect the proof
  3. 03Check the scope
  4. 04Read the result
§ 01
Defense in depth

Six layers.
No single point of trust.

Security is not a perimeter around the protocol — it is the protocol. Each layer below is independently meaningful; together they make forgery, escalation, and silent failure expensive.

Signature verification

Deterministic canonicalization

Content hashing

Offline validation

Cryptographic Identity

Standards-based signatures and deterministic serialization so verifiers can validate identities offline without trusting a network path.

Least privilege

Scoped grants

Audience binding

Auditability

Capability-Based Access

Least-privilege authorization built on scoped grants. Capabilities are designed to be narrow, auditable, and easy to validate.

Threshold signing

Multi-party control

Separation of duties

Governance transitions

Threshold Governance

Shared-control identities where critical signatures require multiple participants, reducing single-operator compromise risk.

Spending policies

Temporal windows

Lineage constraints

Delegation narrowing

Policy Enforcement

Multi-dimensional policy engine with spending limits, temporal windows, lineage constraints, and contract policies.

Resolution

Schema validation

Signature checks

Policy + conformance

Trust Verification

Verification is treated as a pipeline: resolve, validate, verify signatures, and apply the conformance and policy rules a verifier requires.

Careful key handling

Defensive parsing

Dependency scrutiny

Safe defaults

Memory Safety

Reference implementations are designed to be secure by default: careful key handling, conservative dependencies, and defensive verification paths.

§ 02
Verification pipeline

Trust is a
routine, not a service.

A verifier walks a fixed sequence: resolve the document, validate structure, check signatures, walk lineage, then apply policy. Failures are explicit reasons — not silent accepts.

01
Resolve
Fetch or load the identity document
02
Validate
Schema + kind checks
03
Verify
Ed25519 signatures
04
Lineage
HKDF proof chain
05
Policy
Conformance + grants
§ 03
Guarantees

What we hold ourselves to

Reference implementations favor memory-safe languages, constant-time comparisons on secret material, and wipe-on-drop key handling. Claims without linked evidence do not appear as guarantees.

forbid
unsafe_code (Rust)
pre
Third-party audit status
CT
Comparisons
wipe
Key material on drop
AuditsPre-audit — see /security/audits
Disclosuresecurity@openagent.id
PrimitivesStandards-track only
Threat modelMitigation-mapped vectors
§ 04
Continue

Dive into the security family

Threat modeling, primitive choices, audit status, and how to report issues privately.

Threat modelCategories from key compromise to availability, each mapped to mitigations.Cryptographic primitivesEd25519, HKDF-SHA256, BLAKE3, FROST, JCS — why each exists.AuditsWhat is published today and which checks this site enforces in CI.Responsible disclosurePrivate reporting channel, response targets, and good-faith research rules.
Next

Found something that looks wrong?

Report it privately so a fix can ship before public discussion.

Email security@openagent.idDisclosure process