--- title: "Telecom customer-consent authority for AI agents — KYE Protocol™" description: "A tangible walk-through for telecom teams: an AI retention agent about to move a customer onto a worse tariff without their consent — refused at the action boundary and sealed as a receipt you can replay. Built for operators running agentic customer and billing flows." url: https://kyeprotocol.com/solutions/telecom-consent-authority/ lang: en source: "KYE Protocol" --- > A tangible walk-through for telecom teams: an AI retention agent about to move a customer onto a worse tariff without their consent — refused at the action boundary and sealed as a receipt you can replay. Built for operators running agentic customer and billing flows. For telecom teams # An AI agent tried to auto-renew a customer onto a worse tariff without their consent. KYE™ blocked it. Built for an operator like yours. Your customer, retention and billing flows now carry AI agents that change tariffs, renew contracts and apply charges at machine speed. KYE Protocol™ checks the customer’s consent and the agent’s mandate at the moment of the change — and refuses any detrimental modification the customer never agreed to. Each refusal is sealed as a receipt your complaints and compliance teams can replay, turning a disputed-change case from days into minutes. [Book a 20-minute walk-through](https://kyeprotocol.com/book-a-demo/) [Try the runnable demo](https://kyeprotocol.com/sandbox/demos/telecom-consent-authority/) [Authority Finality™](https://kyeprotocol.com/authority-finality/) **AI retention agent** apply tariff change · no consent **KYE™** customer consent check ### Refused consent required · signed ### Admitted consent on file · signed **Stopped before the change lands.** The tariff change is refused because the customer never consented to a detrimental modification — and the refusal is signed and verifiable, so you can prove to the customer and the regulator that consent was required and enforced. That refusal, sealed REFUSED · CONSENT\_REQUIRED `kye:evidence:9f2a…` [Replay & verify →](https://kyeprotocol.com/evidence-pack-demo/) 1 · What KYE™ ™ governs in your stack ## You keep your platform. KYE™ governs the customer-consent boundary. Your systems already run provisioning, billing and retention across millions of customers. KYE Protocol™ adds the one check an AI agent makes it urgent to enforce: at the moment of a consequential change, did this customer actually consent, and is the agent acting inside its mandate? - **Contract & tariff changes** — a renewal, upgrade or price change is admitted only with valid customer consent and a mandate that covers it; a detrimental change without consent is refused, not silently applied. - **Billing & refunds** — charges, credits and refunds are admitted only within the agent’s authorised limits; an out-of-scope adjustment is refused and escalated to a human. - **Every act sealed** — admit or refuse, the decision packs an [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) and a Replay-Proof™ verifiable from public keys alone — your fair-treatment evidence, built as it happens. 2 · The honest boundary ## KYE™ proves the basis — it does not run your network or bill the customer. This is a governance layer, not a BSS/OSS or charging system. KYE Protocol™ does not provision services, rate calls, or stand in for your billing stack. It checks consent and mandate at the action boundary, admits or refuses, and seals the proof. A change outside the agent’s scope or without consent is refused and routed to a human step-up — the refusal is itself evidence. See how the delegation chain is drawn on the [authority diagram](https://kyeprotocol.com/authority-diagram/), then walk a sealed decision on the [Evidence Pack™ demo](https://kyeprotocol.com/evidence-pack-demo/). 3 · See it on your own flow ## Seeing is believing. Bring one real flow. In a 20-minute walk-through we take one of your live flows — a tariff change, a contract renewal, a billing adjustment — and show the AI action refused or admitted against the customer’s consent and the agent’s mandate, then hand you the sealed receipt to replay yourself. No credentials to share: the proof verifies against a public key set, the same runtime enforcement KYE Protocol™ uses to govern itself. [Book a 20-minute walk-through](https://kyeprotocol.com/book-a-demo/) [Replay a sealed decision](https://kyeprotocol.com/evidence-pack-demo/) Related ## Go deeper on telecom customer authority. - [**Authority Finality™**](https://kyeprotocol.com/authority-finality/) — why a consequential change must reach signed closure under the consent and authority that existed then. - [**Authority diagram**](https://kyeprotocol.com/authority-diagram/) — how the consent and delegation chain are drawn and checked. - [**Evidence Pack™ demo**](https://kyeprotocol.com/evidence-pack-demo/) — replay a sealed decision and verify it from public keys alone. This page is an illustrative sector walk-through for telecom teams; it shows how KYE Protocol™ would govern such a stack and does not describe or imply an existing deployment or commercial relationship with any named platform or vendor. Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/).