Frequently asked questions.

Traditional IAM answers who logged in. KYE Protocol™ answers what happens after — who or what is acting, on behalf of whom, using which capability, under what authority, in what state, and with what audit trail. We call this Authority Finality™: a replayable proof layer for AI-agent actions. KYE™ does not replace legal agreements, signatures, or regulatory obligations — it provides the technical and evidentiary foundation for accountability, compliance, dispute resolution, and legally defensible audit trails in agentic systems.

Agentic systems are reaching production faster than identity, authorization and audit can keep up. Today an AI agent calls five services with five different identities; stop signals don’t cross system boundaries; auditors can’t reconstruct what happened. KYE Protocol™ gives every actor — human, service, agent, model, tool, workflow — a single URN, one delegation chain, one decision vocabulary, one cascade and one append-only audit chain. So “who acted, on whose behalf, with what authority, under what scope, with what evidence” has the same answer in every system.

They solve slices. MCP and A2A are agent communication. OAuth and GNAP are human authorization. SPIFFE is workload identity. SCITT is transparency. None give you one URN format spanning humans + services + AI agents, a first-class delegation chain with attenuable scope, standard decision codes, cascading stop signals and a hash-linked audit chain in a single open contract. KYE Protocol™ is that contract layer; it composes with the others.

KYA frameworks — Visa Trusted Agent, Skyfire, Persona, Sumsub, Trulioo’s Digital Agent Passport — verify an AI agent once, at onboarding, with a vendor-specific passport. KYA answers “is this agent real?” KYE Protocol™ answers the bigger question every minute the agent is alive: who is acting, on whose behalf, with what authority, under what scope, with what evidence? KYE Protocol™ is the open contract that unifies KYC, KYB and KYA — one URN spanning humans, businesses and agents; one delegation chain binding them; one cascading bus revoking the chain when something goes wrong. KYA vendors slot in as credential issuers inside KYE Protocol™; the protocol takes care of everything that happens after issuance.

v1.0 ships:

• 10 canonical profiles + 70 rule packs + 61 sector packs + 501 dictionaries, 591 OpenAPI operations across 87+ runtime endpoints, 1165 JSON Schemas with 1449 validated examples.
• KYE™ Reference Gateway™ (201/201 unit + integration tests), embedded PDP library, PEP middleware, three SDKs (TypeScript / Python / Go).
• 135 conformance fixtures (133/133 pass).
• 289 control mappings across 13 horizontal frameworks: SOC 2, ISO 27001:2022, PCI DSS 4.0, PSD2/PSD3, DORA, NIS2, EU AI Act, ISO 42001, NIST AI RMF, NIST 800-207, NIST CSF, GDPR, FedRAMP — plus sector overlays.

Profile contract is bank-grade today; reference implementation is pilot-grade (correctness-first, not throughput-tuned). Apache 2.0.

KYE Protocol™ is a contract, not a service. Bank stacks deploy:

• A vendor or in-house Gateway behind their existing edge.
• The embedded PDP library where low-latency local decisions are needed.
• The PEP middleware in their service mesh.
• The Signal Bus™ subscribed to by their SIEM.

The reference Gateway is a starter for dev/pilot; production deployments substitute a hardened build behind the same contract. Single-tenant or multi-tenant; on-prem, hybrid, or SaaS.

No. KYE Protocol™ sits over existing identity providers. Your OAuth/OIDC IdP issues credentials that become kye:cred:... records. SPIFFE workload identities become kye:ent:... attestations. Your existing OPA or Cerbos policies plug into the ePDP via published Rego/YAML bundles (we ship kye_authz.rego + kye_authz.yaml at parity). MCP tool servers become kye:capability:... registrations. The protocol composes; it does not replace.

The reference Gateway is correctness-first, not throughput-tuned — expect ≤1k authorize/sec on a single Node.js process. Production deployments substitute a hardened build (Rust, Go, JVM, or the bank’s own runtime) behind the same contract; the Capability + ePDP paths are designed to be horizontally scalable and cache-friendly. There is no per-call licence fee; the protocol is Apache 2.0. Operational cost is your runtime cost, plus your conformance-test cadence.

Run the 129-fixture black-box conformance pack against their Gateway. Fixtures speak only HTTP; no implementation internals required. The reporter emits machine-readable evidence (conformance-report.json) listing every passed and failed scenario. Pin the conformance pack version in your vendor contract; re-run on each release. The same pack tested the reference Gateway, so apples-to-apples is guaranteed.

MCP and function-calling describe how an agent invokes a tool. KYE-Capability describes whether the agent is authorised to invoke this tool, on whose behalf, within what scope, with what obligations.

Capability covers: skills, tools, MCP tools, functions, connectors, prompts, workflows, playbooks, runbooks, model_profiles, payment_actions, api_operations. Each is a first-class entity with its own URN, lifecycle, grant chain, audit trail, and verbs (allow / deny / require-approval / quarantine / supersede / revoke). Plug your existing MCP server in; KYE™ gates each invocation against a capability grant.

10 canonical profiles define the conformance contract (core, connector, manifest, conformance, pdp, epdp, spdp, pep, runtime-authority, evidence-replay) — profiles never shift. 21 rule packs add behaviour (eu-ai-act, financial-services, healthcare, cargo-routing, compliance-evidence, …). 17 sector packs bundle vocabulary + obligations + reality anchors per regulated sector. 12 dictionaries carry every canonical term. 5 manifests define the installable / verifiable / sellable surface (purpose, scope, state, delegation, data-use). KYE™ Rules Gateway™ evaluates the chosen stack deterministically. Layering, not forking.

Payloads — the signed bytes an actor submits to invoke a capability — are first-class evidence artefacts, not authority-bearing entities. Without a payload-artefact contract, the agent / API / tool world tends to treat the signed payload itself as authority (“the payload is signed therefore the action is authorised”), which corrupts the entity model. The KYE™ Payload Trust Profile™ defines a 13-state lifecycle (created → signed → submitted → received → verified → bound_to_decision → executed → archived, plus rejected / expired / replayed / tampered / failed), 10 deny reason codes, and a runtime pipeline that verifies the payload, binds the resulting policy decision back to the artefact, and emits replayable audit evidence. Payloads carry state but never authority.

Authority decisions depend on knowing what kind of entity, capability, resource, data, action, risk, sector, jurisdiction, and evidence is involved. The profile registers 16 canonical V1 taxonomies (entity_type, capability_type, action_type, resource_type, data_class, side_effect_level, risk_state, environment, decision, reason_code, evidence_type, compliance_framework, sector, jurisdiction, plus two state taxonomies) and a normative metadata model with five blocks: labels, classifications, ownership, lineage, compliance. Field values draw from registered taxonomies. The runtime exposes metadata to the policy layer as request.{actor,capability,resource,authority}.metadata, so policies like “require human review for high-risk AI capabilities in production” or “deny special-category data without an authorised healthcare profile” can be expressed declaratively.

File a compromise report. The entity transitions to a compromised recovery state; downstream-derived authorities (delegations, payment authorities, access rights, capability grants, break-glass grants) become unusable within milliseconds. Re-activation requires a recovery flow (request → signed decision → proof) plus, where applicable, a key rotation gated by a break-glass grant. Cascade and recovery algorithms are proprietary. Replaces ad-hoc admin reset.

Admin reset is a black box: an admin clicks a button, you trust the audit log. KYE-Recovery is a contract:

• Request resource (kye:rec:...) records who asked, why, when, and which subject.
• Decision resource records the approver(s), rationale, and time.
• A signed proof artefact ties them together.
• Break-glass grants are time-boxed and emit signals on issue, use, and expiry.

Every step is part of the audit chain. Auditors replay the flow; they don’t take the admin’s word for it.

One signal on the bus — entity.stop, delegation.revoked, credential.revoked — causes every downstream-derived authority to become unusable within milliseconds. Dependent delegations are suspended. Payment authorities are revoked. Resource grants are withdrawn. No orphaned authority. No stale grant. The propagation algorithm is proprietary and is not disclosed in this repository; the simulator above demonstrates the outcome, not the construction.

The Act’s Title III obligations on high-risk AI systems — data governance, technical documentation, record-keeping, transparency, human oversight, accuracy/robustness, post-market monitoring — map to KYE™ artefacts: capability grants for data governance, profile docs for technical docs, audit chain for record-keeping, telemetry for transparency, recovery + break-glass for human oversight, point-in-time replay for post-market investigation. Each Article maps to specific endpoints + conformance fixtures in the 266-row control-mapping table.

KYE™ entity payloads minimise PII; PII is referenced by URN, not embedded. Trust domains are first-class (federation profile) so EU records can stay EU and non-EU records can stay non-EU while remaining cross-verifiable. Right-to-erasure is supported by the lifecycle tombstoned state plus profile-specific obligations (e.g. the Healthcare profile’s redaction.required). The protocol does not, by itself, decide where you host data — it gives you the contract that lets your data-residency policy be auditable.

The vocabulary, URN format, JSON Schemas, OpenAPI specs, conformance pack, reference implementation, SDKs and policy bundles are open under Apache 2.0 in github.com/KYE-Protocol. Profile RFCs are accepted via Discussions. Proprietary algorithms move to a royalty-free open standard at v2.0 (Linux Foundation / OpenWallet Foundation track). Trademark policy: KYE™, KYE Protocol™ and Know Your Entity™ identify the protocol as published; conformant implementations may use them; forks may not.

The vocabulary, URN format, schemas and OpenAPI surface are openly published under Apache 2.0 and are intended to remain royalty-free for conformant implementations. Specific mechanism designs (decision algorithms, hash-chain construction, cascade ordering, attenuation propagation) are proprietary and are not disclosed in the public repositories.

Both, as distinct components. The Decision Engine is the PDP (pdp / epdp libraries); the PEP is the PEP middleware plus the Commit Boundary™, Tool Guard and MCP Guard that sit in the call path and block the privileged action when admissibility is not established. The PEP is not a logger — if it is not satisfied, the action does not commit. Audit/replay is what happens after that gate, not instead of it.

Enforcement is only as complete as the wrapping — an action invoked on a path that never crosses a PEP is, by definition, ungoverned. We treat that as the central integration problem, not a footnote: the Reconciliation Engine runs a declared-vs-deployed bijection over privileged actions to surface unwrapped or out-of-band paths, and a hollow-runtime rule forbids a deployed shell that returns a constant while the real check sits elsewhere. KYE™ makes coverage measurable and auditable; it does not magically intercept a call you never routed through it. Honest answer: bypass resistance is an architecture property you verify with the reconciler, not a marketing claim.

Fail closed. The Edge Governance Safety Floor and Offline Evidence Log are designed so that absence of a positive admissibility decision is a refusal, never a silent allow. Worked example: the shipped GitHub-App worker, lacking its credentials, returns a structured refusal — never a fabricated token or a fake allow. A governed system must be able to prove what it refused to do and why, with a receipt.

The governed guarantee is a budget, measured every CI run — not a hardcoded number that drifts. The published p99 budgets (constitution §16) are Authority Gate < 20 ms, Purpose Admit < 30 ms, Decision Engine < 80 ms, and a benchmark in the open-source repo boots the real PDP decide() path (policy evaluation, obligations and stop-condition checks, evidence-fragment construction, decision-map sealing) over 20,000 iterations and the edge-latency-budget gate fails the build if the measured p99 breaches the budget. In practice the in-process decide() path runs far inside the budget (well under a millisecond on a single Node.js process). Scoped honestly: that is the Decision Engine’s own adjudication overhead — it excludes network-bound authority/purpose resolution, datastore I/O, and the HTTP gateway hop, which are deployment-specific; and the reference Gateway is correctness-first, not throughput-tuned. Decisions are cache-friendly (invalidated on the cascade when authority or policy changes).

The sealed verdict is deterministic: the same inputs, policy version and authority state yield the same decision, replayable byte-for-byte. An LLM may help assemble or cite inputs (e.g. classify a document), but it is never in the seal — the admissibility decision and the evidence it binds are rule-evaluated, so prompt injection cannot flip a verdict. Cited inputs, never an inferred verdict.

The Evidence Pack™ and Replay Proof™ are public JSON Schemas (kye.evidence.pack.v1, kye.replay.proof.v1, Apache-2.0, $id under kyeprotocol.com/schemas): actor, on-behalf-of, authority chain, action, resource, purpose, decision, policy version, payload hash, timestamps and signature. It is verifiable offline from the published public keys alone — no KYE™ service in the loop. That is the deliberate anti-lock-in property: the format and verification are open, so the evidence outlives any vendor relationship.

No — and we are explicit about this. A pack proves what was recorded and decided, under whose authority, at that moment. It does not prove the payload, identity mapping or context was factually correct: an evidence pack can be cryptographically valid and still rest on a wrong input. KYE™ governs whether data may be used for an action (admissibility + provenance), not the ground-truth of the data itself. Treat it as authority-and-provenance proof, not a truth oracle.

No. A control-to-framework mapping is an audit-evidence skeleton, not a compliance guarantee — actual compliance depends on your implementation, retention, processes, legal interpretation and audit acceptance. Our coverage is published as an honest tri-state (enforced at runtime / designed and in build / out of scope) and is never inflated to 100%. We tell you which clauses a real KYE™ artefact satisfies and which it does not.

It is treated as a high-value component: signing is HSM-backed with a multi-signature envelope and documented key-rotation; deployments are tenant-isolated (every tenant-scoped read/query is keyed; no cross-tenant bleed); compromise has a first-class recovery + break-glass flow; and the SDK supply chain ships an SBOM. The Replay-Proof™ derives from public keys, so a compromise of the KYE™ service does not retroactively forge past evidence a third party already verified.

Straight answer: the profile contract is bank-grade; the reference runtime is pilot-grade (correctness-first). Independent SOC 2 Type II and ISO 27001 audits, plus an external penetration test, are declared as pending external work — not claimed as done (we publish a tier-1 readiness register rather than imply certifications we do not hold). Production-ready integrations today include the published reference Gateway, PDP/PEP libraries, three SDKs, and Apache-2.0 connector adapters; per-connector status is tracked openly. We would rather you adopt on verified facts than on a logo wall.

Yes — KYE™ Native Search Engine™ ships as a named sub-engine of the Directory Engine. It returns a signed kye.search_result.v1 envelope that is replayable offline from the per-tenant signing-key registry. CLI: kye search. The search construction is proprietary and is not disclosed in this repository.

Yes — KYE™ Memory Engine™ ships as a named sub-engine of the Decision Engine. Records are signed and append-only; retention is coupled to classification. CLI: kye memory put / recall. The memory construction is proprietary and is not disclosed in this repository.

Yes — KYE™ Reporting Engine™ ships as a named sub-engine of the Evidence Engine. It synthesises per-framework compliance reports and returns a signed kye.report.v1 envelope, replayable offline from the per-tenant signing-key registry. The synthesis construction is proprietary and is not disclosed in this repository.

Yes — via reports@kyeprotocol.com. Per-tenant report_delivery_preferences table accepts opt-in subscriptions per (report_kind, recipient, cadence). Every delivery emits a signed kye.report.delivery.v1 receipt to the WORM report_deliveries table — a regulator can prove the customer received the report on date X. SPF / DKIM / DMARC + ARC.

Yes — KYE™ Data Mapping Agent™ ships as a named sub-engine of the Directory Engine. It returns a signed kye.data_flow_graph.v1 envelope replayable offline from the per-tenant signing-key registry. Powers the Data Mapping Widget on the apex + admin surfaces. The mapping construction is proprietary and is not disclosed in this repository.

Authority is relational: a human owns a business; the business controls an agent; the agent uses a capability; the capability depends on a tool; the tool calls an API; the API uses a credential; and so on. The KYE™ Graph Profile defines canonical node and edge schemas so every entity, delegation, capability, credential, policy, state, decision, audit event, and evidence pack becomes a traversable graph. The Decision Map™ (returned by GET /v1/decisions/{id}/map) is a per-decision graph projection — actor → principal → delegation → capability → authority → scope → state → policy → decision → audit → evidence — that turns “why was this allowed / denied / escalated?” into a visualisable trace. Blast Radius Map™ answers “what breaks if this credential is compromised?”. Compliance Map™ projects KYE™ objects to framework controls. Storage substrate is implementation choice (Postgres, Neo4j, Neptune, Memgraph, TigerGraph, ArangoDB, RDF) — the protocol defines node + edge contracts, never the database.

KYE™ is structured in three tiers. Tier A — Runtime governance (6): authority-first · state-first · decision-first · policy-bound · evidence-first · audit-trail-first. Tier B — Protocol design (8): schema-first · dictionary-first · taxonomy-first · metadata-first · graph-first · profile-first · registry-first · conformance-first. Tier C — Developer adoption (2): API-first · SDK-first.

v1.1: sector overlays for healthcare (clinical / payer / research, 42 CFR Part 2); conformance-report.json + conformance-fixture.json schemas; extended signal-bus durability options. v1.2: certification program + independent test-vector runners + vendor self-attestation portal. v2.0: Federation v2 with multi-hop attenuation; proprietary algorithms move to royalty-free open standard. v1.0 contract surface is stable; v1.1 is purely additive.

The reference implementation, conformance suite and SDKs are public on github.com/KYE-Protocol. Public adopters are listed on the org profile as they go live. Banking, payment, custody and AI lab integrators are encouraged to share their integrations in share their integration with us.

Open a discussion in KYE-Protocol/Discussions — ask a question, propose a profile RFC, share an integration. File issues against the relevant code repo. Watch the org for new profile drops.