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 41 normative profiles, 186 OpenAPI operations (87+ runtime endpoints), 55 JSON Schemas with 58 validated examples payloads, a reference Gateway (67/67 unit tests), an embedded PDP library, a PEP middleware, three SDKs (TypeScript, Python, Go), 37 conformance fixtures (37/37 pass), and 173 control mappings across SOC 2, ISO 27001:2022, PCI DSS 4.0, PSD2/PSD3, DORA, NIS2, EU AI Act, NIST 800-207 and HIPAA. Profile contract is bank-grade today; reference implementation is pilot-grade (correctness-first, not throughput-tuned). Apache 2.0.

Run the 37-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.

KYE Protocol™ is a contract, not a service. Bank stacks deploy: (a) a vendor or in-house Gateway behind their existing edge, (b) the embedded PDP library where low-latency local decisions are needed, (c) the PEP middleware in their service mesh, (d) 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.

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 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.

File a compromise report. The protocol cascades atomically: the entity transitions to compromised recovery_state; all delegations from that entity revoke (recursively through parent_delegation_id); payment authorities revoke; access rights revoke; capability grants revoke; break-glass grants freeze. Every step appends to the audit chain with a shared correlation_id. Re-activation requires a recovery flow (request → signed decision → proof) plus, where applicable, a key rotation gated by a break-glass grant. 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: a request resource (kye:rec:...) records who asked, why, when, and which subject; a 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.

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 173-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. The patent track moves 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.

Core is mandatory. Gateway is mandatory (it’s the API contract). Conformance is mandatory if you claim conformance. Everything else is opt-in by sector: Payments + Treasury + Custody for money flows; Capability + Recovery + Telemetry for agent fleets; Healthcare for HIPAA workloads; Federation for cross-domain; Credentials + Attestation for proof bundles; Signals + Transparency for audit/observability. The Sectors section above lists the typical bundle per industry. Profiles never modify Core; they add vocabulary, schemas, endpoints, fixtures.

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.

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 programme + independent test-vector runners + vendor self-attestation portal. v2.0: Federation v2 with multi-hop attenuation; patent-track algorithms move to royalty-free open standard. v1.0 contract surface is stable; v1.1 is purely additive.

One signal on the bus — entity.stop, delegation.revoked, credential.revoked — propagates through the trust graph in milliseconds. Dependent delegations are suspended. Payment authorities are revoked. Resource grants are withdrawn. Recursive through parent_delegation_id. No orphaned authority. No stale grant. The lifecycle simulator and cascade visualizer above are live demos of the same logic the reference Gateway runs.

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.

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) sit in a separate patent track and are not disclosed in the public repositories.

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.

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.

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. The commercial layer (KYE Cloud™) is SKU-first, metering-first, dashboard-first, evidence-pack-first, enterprise-pack-first, BYOC / on-prem-first — but never bleeds into the open protocol core.