Identity & clearance for the agentic internet.

Overview

AI agents now browse, buy, and act on the open web on behalf of people and organizations. AIdenID is the site-owned decision layer for that traffic: it decides who gets through, per request, and proves the decision. It is vendor-neutral across edges — one-line middleware for Node / Fastify / Next, with Cloudflare and Fastly edge adapters (Vercel Edge on the roadmap).

• Per-request decisions — six outcomes: allow, throttle, queue, sandbox, deny, price_required.
• Cryptographic hard path — HTTP Message Signatures (RFC 9421), DPoP (RFC 9449), Token Exchange (RFC 8693), audience-bound session tokens.
• Signed decision receipts — Ed25519, self-verifiable, with Merkle-backed audit artifacts for key rotations, policy versions, revocations, and evidence roots.
• Instant revocation — kill any chain, session, or delegation with a single call; epoch-checked on every request.

Identity + Clearance — one platform

AIdenID is two halves of a single lifecycle, not two products:

• Identity (issuance) — scoped, ephemeral agent identities with intent-bound delegation, TTL, and lineage. Includes verification interception (OTP, magic-link, and email-confirmation extraction) so an agent can complete real identity flows.
• Clearance (enforcement) — a per-request decision over that identity: the four-layer cascade, six outcomes, and a signed receipt. The AIdenID SDK enforces clearance at your edge in one line.

How it runs — two planes

The decision that gates a request is deliberately separated from the machinery that manages identities, so the hot path stays fast and keeps working even when our control plane doesn't.

Quickstart

Install the enforcement SDK and gate a route in one line:

// 1. install
npm i @aidenid/sdk

// 2. verify, then enforce — at your existing gate
import { verifyAgent, enforce } from '@aidenid/sdk'

const decision = await verifyAgent(req, { route: '/blog/:slug', action: 'read', resourceId: slug })
return enforce(decision)  // allow→full · priced→402 · else→teaser only

The six outcomes

Every request resolves to exactly one terminal outcome, with a canonical HTTP behavior:

Payments — the 402 is real money

When a surface is worth money, price_required answers 402 Payment Required with a signed price quote instead of hard-blocking. That response is compatible with x402 — the open HTTP-402 standard for agent payments — and Google's AP2. The agent's wallet settles the micro-payment and retries the request.

The four-layer cascade

Evaluated in order; every layer writes an honest 0..1 score and a passed flag into the receipt.

Delegation & revocation

An agent acts under a delegation — a scoped grant from a human principal, bound to an action and optionally a single resource, with an issue and expiry time:

{
  "principalId": "user_42",
  "agentId":     "chatgpt-agent-7f3a",
  "scope":       ["read"],
  "resourceId":  "aidenid-demo",
  "issuedAt":    "2026-06-16T00:00:00Z",
  "expiresAt":   "2026-06-16T01:00:00Z"
}

Revocation is instant. A single call kills a chain, session, or delegation; an epoch is checked on every request, and the next request from that agent returns a deny revocation receipt (revoked: true, revocationOf: <receiptId>).

Signed receipts & verification

Every decision returns a Decision receipt signed with Ed25519 over a deterministic canonical encoding. The receipt carries its own verify key, so it is self-verifiable — clients re-check the signature in-browser with zero server round-trips.

// the verifier checks the exact same canonical bytes the signer signed
const ok = ed25519.verify(
  d.signerPublicKey,
  d.signature,
  canonicalString(signingPayload(d)),  // keys sorted, no whitespace, undefined dropped
)

Crypto fields (signature, signerKeyId, signerPublicKey, alg) are excluded from the signed payload. Scores are rounded to 4 decimals before signing so the bytes are stable across engines.

API reference

Same-origin (or via a proxy) — no CORS holes. Decision endpoints:

Live control-plane endpoints (traffic stream, plain-language rules → signed policy versions, bounded agent planning sessions): /api/aidenid/traffic, /classify, /rules, /simulate, /policies, /agent.

Confidence labels (the soft path)

AIdenID never claims human-vs-bot certainty. Alongside the cryptographic hard path, requests carry a confidence label:

• verified_agent — cryptographically proven operator + delegation.
• signed_agent — valid operator signature, delegation unproven.
• likely_human — interactive signals, no agent identity.
• suspicious_automation — automation signals without identity.
• unknown — insufficient signal; default-deny on sensitive surfaces.

Protocol & proofs

The identity and verification surface is built on open standards and is tested — so a reviewer can check the work rather than take our word:

• RFC 9421 HTTP Message Signatures and RFC 9449 DPoP for agent identity; Ed25519 / P-256 signatures end to end.
• RFC 6962-style Merkle transparency log — key rotations, policy versions, and revocations commit to an append-only tree, so any past decision is provable, not just asserted.
• SSRF-hardened key fetching — issuer key (JWKS) pulls are DNS-pinned and block private, link-local, and cloud-metadata ranges, so a hostile issuer URL can't pivot into your network.
• Deterministic decision ladder under a continuous crypto + policy test suite.