Adopt by free will. Keep your stack. Stay in control.

KYE Protocol™ is additive and consensual. You keep your existing systems — your IAM, your SIEM, your GRC, your payment rails, your legal agreements — and KYE™ composes with them. It sits beneath and across your stack to add the runtime-authority layer they cannot reach. It does not replace them, and there is no rip-and-replace.

Customer Sovereignty, point by point

Demo data

You learn: The page's points, one at a time. You can: Step through them.

  1. Step 1 of 4

    KYE Protocol™

    Identity (IAM / OAuth / SPIFFE)

    they prove who ; KYE™ binds what they may do at the moment of action. KYE™ keeps your identity stack.

  2. Step 2 of 4

    KYE Protocol™

    GRC platforms

    they hold your documented controls; KYE™ reads those controls and enforces them at the execution boundary where a GRC platform cannot. You keep your GRC.

  3. Step 3 of 4

    KYE Protocol™

    Observability / SIEM

    they record what happened; KYE™ resolves whether the action was authorised before it commits, and seals a replayable Evidence Pack™ .

  4. Step 4 of 4

    KYE Protocol™

    Legal agreements & AI-policy committees

    KYE™ does not replace them; it hands them a signed artefact they can point to instead of a story.

How this widget is built
Demonstrates
KYE Protocol™
Components
  • The points this page makes
Flow
Each point in order, as the page sets it out. Architecture diagram
Used on

This is KYE Protocol™'s own thesis turned toward you: authority stays with the principal. The customer keeps authority over their own adoption and their own data.

See what KYE™ composes with What's verifiable

What customer sovereignty means here

Three commitments, and they are mechanically enforced in the constitution (§0.26 Adoption by Free Will), not just promised.

You keep your systems

KYE™ composes with your IAM, SIEM, GRC, data-governance, and payment rails. It adds the authority layer above them — your existing platforms stay exactly where they are.

You control what you share

Every input KYE™ reads is customer-curated against an open standard schema. You include only what you choose. Nothing leaves your hands that you did not decide to share.

Read-only by default

Assessment, profiling, and ingest paths observe and read — they do not write back into your systems. Enforcement is opt-in and downstream: shadow first, enforce only when you choose to.

Composes with — does not replace

KYE Protocol™ is not another platform to migrate to. It is the runtime-authority and evidence layer that the systems you already run cannot provide on their own.

  • Identity (IAM / OAuth / SPIFFE) — they prove who; KYE™ binds what they may do at the moment of action. KYE™ keeps your identity stack.
  • GRC platforms — they hold your documented controls; KYE™ reads those controls and enforces them at the execution boundary where a GRC platform cannot. You keep your GRC.
  • Observability / SIEM — they record what happened; KYE™ resolves whether the action was authorised before it commits, and seals a replayable Evidence Pack™.
  • Legal agreements & AI-policy committees — KYE™ does not replace them; it hands them a signed artefact they can point to instead of a story.

Why this is the right way

A protocol earns adoption by lifting pressure, not by demanding a migration. The lower-friction path is also the more honest one.

  • A read-only, customer-curated start is a yes a regulated buyer can actually give.
  • Keeping your systems means no migration risk, no lock-in, and no single throat to choke.
  • Control over what you share is the trust that makes the rest possible — sovereignty first, value second.

Start with a read-only readiness check

Canonical KYE™ surfaces referenced on this page: KYE Protocol™.