KYE™ adds a delegated-authority and evidence layer on top of your existing IAM, OAuth, API gateway, workflow, SIEM, GRC and AI-agent stack. Start in shadow mode: observe AI-agent actions, capture who or what acted, on whose behalf, under what authority, inside what scope, and generate Evidence Packs™ before enforcing runtime controls.
An AI agent calls five services with five different identities. Stop signals don’t cross system boundaries. Auditors can’t reconstruct what happened. Regulators (EU AI Act, DORA, NIS2, PSD3, ISO 42001, NIST AI RMF) want a chain of authority — not an OAuth token.
One URN format. One delegation chain. One decision vocabulary. One cascading bus. One signed proof. The same answer in every system to who acted, on whose behalf, with what authority, under what scope, with what evidence?
Regulatory tailwind · composes with OAuth / SPIFFE / MCP / KYC / KYA · implementable today on Apache 2.0 schemas + reference Gateway + 41-fixture conformance pack.
KYE™ produces the KYE Chain of Authority™ the way digital signatures produce chain-of-custody for documents. Courts already accept signed documents; KYE™ gives them signed delegations.
KYE Protocol™ is the open identity, authority, scope, state and audit layer for every action a human, business, AI agent, service, model, tool or workflow takes — one URN, one delegation chain, one decision vocabulary, one cascading bus, one signed proof.
More: why it exists / what it adds → · technical reference → · whitepaper →
Compliance frameworks, governance architectures, authorisation models and runtime execution control are related but distinct. KYE Protocol™ sits where governance meets execution: the runtime authority and evidence layer that decides and proves whether a delegated action should happen.
Question: What obligations must we meet?
KYE™ role: produces runtime evidence packs and Compliance Map™ mappings that frameworks consume.
Does not: replace the framework, the certifier, or the auditor.
Question: How is accountability organised?
KYE™ role: turns governance intent into runtime authority decisions and replayable evidence.
Does not: replace organisational governance.
Question: Who or what may be allowed?
KYE™ role: extends authorisation into delegated agency, capability scope, six-dimension state, Authority Continuity™, Discoverability, evidence and revocation.
Does not: replace IAM.
Question: Should this specific action happen now?
KYE™ role: decides, records, revokes and proves authority at the point of action.
Does not: process the underlying payment, clinical action or infrastructure command itself.
Identity · Authority · Scope · State (6-dim) · Decision · Audit · Evidence Pack™ · Discoverability · Continuity. Resolves who or what is acting, on behalf of whom, under what authority, in what state — then produces a signed Decision Map™ + Evidence Pack™ any auditor or regulator verifies offline with public keys.
Frameworks tell you what must be governed. KYE™ controls and proves what actually happened at runtime.
IAM answers who logged in. Agentic systems require a deeper runtime question: what was actually acting through the chain?
Who logged in? What permissions were assigned at issuance?
Who or what acted? On behalf of whom? Through which delegation chain? Using which capability? Inside what scope? In what state? With what evidence? Was Authority Continuity™ preserved? Can it be discovered and revoked?
What it is
What it is not
Core records who or what acted, on whose behalf, under what authority, in what state, with what evidence. Seven runtime profiles add the layers around it: an upstream admissibility layer that decides whether a proposed action may even enter the pipeline, continuity from intent to action, discoverability across the authority graph, an ontology-backed semantic layer, an operating-model adoption layer, an assurance-card layer, and a formal-rules layer that turns rights, obligations and governance into runtime authority decisions.
Admit. Decide. Gate. Prove. Revoke. Replay. KYE™ does not only attribute delegated actions after they exist — it checks whether proposed actions are admissible before they enter the authority pipeline, then decides, proves, revokes and replays what happens next.
KYE Protocol™ is a contract layer with a commercial trust layer — not a SaaS product. Path: Learn → Review → Build → Pilot → Conform → Certify. Pick the entry point that fits your role.
Identity tells you the front door — KYE Protocol™ tells you what happened on the other side. We call this Authority Finality™: a replayable proof layer for AI-agent actions. Every action carries a delegation chain back to a human or business, attenuable scope, signed evidence, and standardised reason codes that any auditor can verify with public keys alone.
The v1.0 contract is bank-grade and frozen as of April 2026 (58 v1.0 normative profiles, 193 OpenAPI operations, 142 schemas, 266 control mappings, 126 conformance fixtures all passing). Reference implementations are pilot-grade (correctness-first, not throughput-tuned).
KYE™ composes with all of them. OAuth issues credentials; MCP gives agents tool access; SPIFFE handles workload identity; KYA vendors issue agent passports. KYE™ binds these into one open contract that carries delegation, scope, state, decision, and signed audit across every layer.
Every release of KYE Protocol™ runs scripts/self-govern-kye-on-kye.mjs — eight engines (Identity, Authority, Admissibility, Continuity, Meaning Continuity™, Formal Rules, Obligations, Evidence) evaluate the project as a governed entity and emit eight Ed25519-signed artefacts.
The honest part: the engines correctly classify the project as obligation: breached and admissibility: require_human_review when consistency-drift, missing SOC 2, or stat-mismatches surface. Most "trust" pages claim a green checkmark; KYE™’s signs an honest red one and routes itself to human review.
scripts/verify-self-audit.mjs with zero dependencies. Defaults to offline (against on-disk fixtures); pass --base for live verification.