---
title: "Customer Sovereignty — adopt KYE Protocol™ by free will · KYE Protocol™"
description: "KYE Protocol™ is additive and consensual. You keep your existing systems, you control exactly what you share, and KYE™ composes with your stack — it never replaces it. Read-only by default, customer-curated, no rip-and-replace. Your authority stays yours."
url: https://kyeprotocol.com/customer-sovereignty/
lang: en
source: "KYE Protocol"
---

> KYE Protocol™ is additive and consensual. You keep your existing systems, you control exactly what you share, and KYE™ composes with your stack — it never replaces it. Read-only by default, customer-curated, no rip-and-replace. Your authority stays yours.

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

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](https://kyeprotocol.com/integrations/) [What's verifiable](https://kyeprotocol.com/trust/)

## 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™](https://kyeprotocol.com/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](https://kyeprotocol.com/readiness/)

Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/).