The technical layer behind KYE Protocol™ — schemas, rails, and engines.

Graph-first · explainable by default

Every decision comes with a Decision Map™.

KYE™ is graph-first because authority is relational. Every entity, delegation, capability, credential, policy, state, decision, and evidence object is a node; every authority relationship is a typed edge. The runtime traverses, projects, and explains — so an auditor, regulator, dispute panel, or developer can answer why without rebuilding the chain by hand.

Entities vs. evidence

KYE™ governs entities and the evidence they produce — never confuses one for the other.

KYE™ governs acting entities, principal entities, capability entities, and evidence artefacts. Payloads are evidence artefacts that bind signed requests to authority decisions and audit trails — they carry state but never authority.

KYE™ Payload Trust Profile™ — payloads are signed, hashed, replay-resistant artefacts. The runtime verifies them, binds the resulting decision back to the artefact, and emits replayable audit evidence. See profile inventory →

KYE™ binds signed payloads to entity authority, capability state, policy decisions, and replayable audit evidence.

How it works

Three steps, every time. Identify. Authorize. Prove.

A KYE™-governed action is the same shape whether the actor is a human pressing a button, a service account hitting an API, or an AI agent running a tool. That uniformity is the whole point.

Decision Map™™ · the chain that produced the verdict

Every decision comes with a map.

The runtime emits a signed Decision Map™™ with every /v1/runtime/authorize response. The map shows which inputs led to the verdict — the principal, the delegation, the actor, the capability, the scope, the state, and the policy — bound to the audit-chain entry and the evidence pack. Verifiable offline with public keys alone.

Try the live version on the agent-backed purchasing simulator — change any input and watch the chain recompute.

KYE™ Signal Bus™ · runtime, not registry

Every authority change, delivered as a signed event.

A registry is passive. KYE Protocol™ is a runtime authority layer — when authority changes, downstream systems must know before the next request lands. The KYE™ Signal Bus™ emits signed, replayable events for every grant, revocation, state transition, decision, approval, recovery action and evidence-pack lifecycle. Subscribers verify with public keys alone, deduplicate by event id, and bind every signal back to the audit chain.

24 event families · 79 well-known types (nine highlighted below)

Canonical envelope · one shape across every event

Schema: https://kyeprotocol.com/schemas/signal.json. Signing covers the full envelope; subscribers verify with the publisher's published JWKS.

{
  "schema_version":  "kye.webhook.v1",
  "event_id":        "kye:event:01HX...",
  "event_type":      "kye.authority.revoked",
  "event_version":   "1.0",
  "occurred_at":     "2026-05-06T21:30:00Z",
  "tenant_id":       "tenant_acme",
  "correlation_id":  "kye:corr:agent_purchase_001",
  "causation_id":    "kye:event:01HX-prev...",
  "actor_entity_id":     "kye:entity:agent:shopping_agent_456",
  "principal_entity_id": "kye:entity:person:customer_123",
  "subject_ref":     "kye:authority:grant:purchase_001",
  "reason_code":     "principal_revoked_authority",
  "data": { "previous_state": "active", "new_state": "revoked",
            "affected_capabilities": ["kye:capability:payment_action:card_purchase"] },
  "audit_ref":     "kye:audit:event_001",
  "evidence_refs": ["kye:evidence-pack:authority_revocation_001"],
  "delivery":  { "idempotency_key": "kye:event:01HX...", "replayable": true },
  "signature": { "algorithm": "ed25519", "key_id": "kye:key:webhook_signing_001",
                 "signature": "..." }
}

Endpoints · subscribe, manage, replay

• POST /v1/webhook-endpoints · GET · PATCH · DELETE — manage subscriber endpoints + filter expressions
• POST /v1/webhook-endpoints/{id}:test · :rotate-secret — synthetic-event smoke test, signing-key rotation
• GET /v1/webhook-deliveries · POST .../{id}:replay — delivery log + per-delivery replay
• GET /v1/events · GET .../{id} · POST .../{id}:replay · GET /v1/event-types
• POST /v1/signals · POST /v1/signals/subscribe · GET /v1/signals/replay · GET /v1/signals/{id} — KYE™ Signal Bus™ publisher side

Delivery guarantees

• Signed — over the canonical envelope, with JWKS-based verification and no shared secrets. Conformance test vectors verified in CI; the signing construction itself is proprietary.
• Idempotent — subscribers dedup by event_id; replays carry the same id.
• Retried — exponential backoff under a publisher-configured budget; per-subscriber retry policy.
• Dead-lettered — exhausted retries land in DLQ for operator-initiated replay.
• Replayable — ≥ 24-hour replay window via /v1/signals/replay; subscribers refetch missed events without involving the publisher.
• Audit-bound — every publish, delivery, and retry is recorded as an audit event linked via audit_ref + evidence_refs.
• Three transports — HTTPS webhook (REQUIRED), SSE / WebSocket (OPTIONAL), Kafka-compatible topic (OPTIONAL).
• SSF / CAEP boundary adapter — KYE™ event types translate to OpenID Shared Signals Framework + CAEP at trust-domain boundaries; lossless for the in-scope families.

What ships today

Envelope schema, every event-family schema, error / reason codes, delivery-receipt format, verifier SDK (TypeScript / Python / Go), reference Gateway webhook handler + retry loop + DLQ + replay endpoint, conformance test vectors. All Apache 2.0.

Worked example · agent-purchase revocation

A customer revokes their shopping-agent's payment authority. One signed kye.authority.revoked event fans out to five subscribers: bank freezes the agent card token; merchant platform blocks future agent purchases; agent runtime removes the payment_action.card_purchase capability; SIEM opens an alert linked to the audit-chain ref; audit pipeline emits kye.evidence_pack.generated for the regulator-facing pack. All five verify with the same public-key set; the regulator can replay the entire flow offline.

KYE™-on-KYE™ · the engine governs itself

The KYE™ Reference Gateway™ uses its own primitives to govern itself.

Eat-your-own-dog-food is the credibility test for any authority infrastructure. The KYE™ Reference Gateway™ boots itself as a KYE™ tenant: registers a self-entity (kye:gateway:<trust-domain>:reference:01), the canonical operator-action capability catalogue (kye.gateway.key.rotate, profile.activate, capability.register, rate.set, audit.checkpoint, conformance.run, self_audit.run, cascade.replay, tenant.create, tenant.suspend), and a bootstrap-operator root grant. Every operator action against the running Gateway routes through POST /v1/runtime/authorize on the same engine, hits the same audit chain, and emits the same Decision Map™ + Evidence Pack™ any external decision produces.

Why this matters for procurement: a regulator can replay an external decision against the Gateway and replay the Gateway’s own key rotations using the same JWKS, the same evidence-pack format, the same audit-chain primitives. Misbehaving operators are bounded by the same scope + state-vector + cascade primitives that bound external agents.

Public proof of mechanism — three signed fixture artefacts (run record, engine health, audit-chain integrity) live at /trust-self-audit with a published JWKS and a 90-line verifier anyone can run in Node 18+.

State model · six dimensions

An entity isn’t one state. It’s a six-dimension state vector, all auditable.

Most systems collapse identity, authority and risk into one boolean. KYE Protocol™ keeps them separate so a single failure mode — expired credential, suspicious behaviour, lost key — changes the right dimension without nuking the rest.

Quick map: the state vector has 6 dimensions below (each transitions independently). The entity_state dimension — the lifecycle of the actor itself — takes 15 well-defined values (see the simulator below). The other five dimensions have smaller value sets shown on each card.

entity_state

Lifecycle of the actor itself.

• provisional
• active
• suspended
• quarantined
• stopped
• tombstoned

emits: entity.activated · entity.suspended · entity.stopped

authority_state

Whether this actor has any active authority right now.

• none
• scoped
• elevated
• break_glass
• frozen

emits: authority.elevated · authority.frozen

delegation_state

Whether the chain of delegations behind this actor is intact.

• active
• parent_revoked
• self_revoked
• expired
• scope_violated

emits: delegation.revoked (recursive)

credential_state

Verifiable credentials held by this actor.

• none
• valid
• expired
• revoked
• signature_invalid

emits: credential.revoked · credential.expired

recovery_state

Whether this actor is mid-recovery, post-compromise, or healthy.

• healthy
• recovery_requested
• recovery_decided
• compromised
• rotated

emits: recovery.decided · break_glass.granted

risk_state

Telemetry-derived risk posture — informs sPDP without changing identity.

• nominal
• elevated
• watch
• denylisted

emits: risk.elevated · risk.cleared

Each dimension cascades independently. Stop the entity? Authority freezes, delegations & capabilities revoke, credentials stay valid (so post-mortem keeps working), risk locks at last-known. The vocabulary is open and pinned in the conformance pack.

Lifecycle simulator

The entity_state dimension takes 15 well-defined values — and only legal transitions.

Click through them. Try an illegal move (the protocol blocks it). Stop, quarantine or revoke an entity and watch the cascade roll down to its delegations, payment authorities and resource grants.

Current state

status: —

Cascaded effects

Signal log

Profiles for every sector

Banking, healthcare, custody — no rewrites required.

10 canonical profiles + 70 rule packs + 61 sector packs + 501 dictionaries + 5 manifests, structured by responsibility. The 10 profiles define conformance modes (core, connector, manifest, conformance, pdp, epdp, spdp, pep, runtime-authority, evidence-replay) and never shift. Rule packs · sector packs · dictionaries layer on top deterministically through KYE™ Rules Gateway™.

Tier-1 evaluation path: read the var(--radius-lg) canonical profiles end-to-end before deciding to pilot — core · connector · manifest · conformance · pdp · epdp · spdp · pep · runtime-authority · evidence-replay. Then layer the rule packs your sector needs from 70 rule packs (eu-ai-act, financial-services, cargo-routing, compliance-evidence, …) and the sector pack overlays for your jurisdiction. The 12 canonical dictionaries and 5 manifests compose on top. KYE™ Rules Gateway™ evaluates the chosen stack deterministically.

Run the var(--radius-pill) conformance pack: github.com/KYE-Protocol/examples — clone & run npm test →

Coverage

One protocol. Every actor, every action, every state.

KYE Protocol™ is deliberately scoped to the identity, authority, scope, state, and audit layer — not custody, not settlement, not a policy engine. That makes it horizontal across vendors and vertical across regulators.

Implementable protocol · not a whitepaper

From authority to audit — backed by schemas, taxonomies, metadata, and a traversable graph.

KYE Protocol™ has three layers. Runtime Governance — authority, state, decisions, policy, evidence, audit. Protocol Design — schemas, dictionaries, taxonomies, metadata, graph, profiles, registries, conformance. Developer Adoption — APIs and SDKs. The separation matters: what the protocol decides is independent from how it ships, which is independent from how you use it.

Tier A · Runtime governance — what KYE™ decides

Tier B · Protocol design — how KYE™ classifies and ships

Tier C · Developer adoption — how KYE™ reaches developers

Where it sits in your stack

MCP and OAuth solve parts. KYE™ solves the whole identity-authority-audit problem.

MCP and A2A handle agent communication. OAuth and GNAP do human authorization. SPIFFE does workload identity. SCITT does transparency. KYE Protocol™ is the contract layer that composes them — one URN, one delegation chain, one decision vocabulary, one cascade, one audit chain.

↔ scroll horizontally to see all columns

Ready to see your AI agents flagged?

Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

Canonical KYE™ surfaces referenced on this page: Authority Graph™ · Evidence Pack™ · KYE™ Conformance Pack™ · KYE Protocol™.