---
title: "KYE Protocol™ — Use cases | Real-world business applications across banking, healthcare, custody, insurance, SaaS, telco, public sector"
description: "Nine real-world KYE Protocol™ use cases — high-value payments, custody break-glass, EU AI Act docs, HIPAA chart review, NIS2 incident response, FedRAMP…"
url: https://kyeprotocol.com/usecases/
lang: en
source: "KYE Protocol"
---

> Nine real-world KYE Protocol™ use cases — high-value payments, custody break-glass, EU AI Act docs, HIPAA chart review, NIS2 incident response, FedRAMP…

Use cases

# Ten flows, one six-step trace.

Banking, healthcare, custody, insurance, SaaS, telco, public sector. Every scenario follows the same trace: **entity → delegation → capability → decision → audit → recovery**. Each one ends at the same artefact — a signed evidence pack a regulator or auditor can replay using public keys alone. _Each scenario is a shape, not a fixture; pilots typically pick one capability and prove the audit chain end-to-end._

Financial services

## Banking · custody · asset management · agent purchasing.

### High-value payment approval via AI agent

Banking · payments PSD3 DORA EU AI Act A multinational corporate treasurer’s AI agent prepares a $2.4M cross-border FX payment overnight. The bank’s PSD3 rail must prove that the action was authorised, scope-bound, signed, and recoverable — with no human re-keying and full audit reconstructibility. **Outcome:** a single signed evidence pack proves SCA, attenuated authority, payment intent ↔ rail confirmation, and a Decision Map™ the bank’s PSD3 supervisor can replay from public keys alone.

- 1. Entity Treasury agent registered as `kye:agent:acme.eu:treasury:fx-router` with model + capability inventory.
- 2. Delegation Signed chain: _Group CFO_ → _Regional treasurer_ → _Agent_; PSD3 SCA satisfied at the human edge once, attenuated through the chain.
- 3. Capability `pep` profile scopes the agent to USD ≤ $5M, EU/US corridors only, no first-time beneficiaries without approval.
- 4. Decision KYE™ ePDP returns `allow_with_constraints`; constraints carry the obligation to record an SCA proof artefact.
- 5. Audit Append-only chain links the payment intent, decision, payment authority, payment attestation, and bank-side rail confirmation.
- 6. Recovery If reconciliation fails, the payment authority is revoked; cascade kills any downstream wallet grants in < 1 second.

### Break-glass recovery when an agent signing key is suspected compromised

Custody · break-glass MiCA FFIEC ISO 27001 02:14 UTC: a digital-asset custody desk’s anomaly detector flags an unusual signing pattern from the trading agent. Whether the key is actually compromised is not yet clear — but the custodian must act before the next settlement cycle, and prove every step. **Outcome:** 380 ms from quarantine signal to dead delegation chain. The MiCA Art. 70 / FFIEC Cybersecurity Resilience evidence pack produces itself — no spreadsheet reconstruction the morning after.

- 1. Entity The trading agent `kye:agent:acme-cust.eu:desk-a:signer` sits inside a delegation chain rooted at the Head of Custody.
- 2. Signal SOC issues a `quarantine` signal on the agent’s authority token; cascade fans out to every dependent capability.
- 3. Capability Time-boxed break-glass grant issued to the on-call lead under the `evidence-replay` profile; signs every action with a recovery key.
- 4. Decision KYE™ ePDP enforces the recovery scope: read evidence, freeze positions, re-key, but _cannot_ initiate new trades.
- 5. Audit Recovery-request resource, decision resource, and signed proof artefact linked into the audit chain; break-glass auto-expires in 4 hours.
- 6. Closure Once forensics clears the agent, signal bus emits `restore`; cascade re-issues attenuated grants under fresh keys.

### Investment-research agent — EU AI Act high-risk technical-documentation pack

Asset management · AI research EU AI Act ISO 42001 NIST AI RMF A €18B AUM asset manager runs an AI research agent that drafts investment memos for the IC. Under EU AI Act Title III the agent is high-risk: technical documentation, data governance, human oversight, post-market monitoring — due continuously, on demand. **Outcome:** the technical-documentation pack the EU AI Act notified body asks for ships from one endpoint — no parallel evidence team, no spreadsheet reconciliation.

- 1. Entity Research agent + every model variant inventoried; per-version `model_card` attestation.
- 2. Delegation Chain rooted at Head of Research, attenuated to the agent for memo drafting only — never trade execution.
- 3. Capability `kye-euaiact-1.0` binds AI system registry, capability classification (high-risk), human-oversight gate at memo finalisation.
- 4. Decision Every research-tool invocation is an `authorize` call — data sources, retrieval scope, and licence terms enforced at the runtime layer.
- 5. Audit Evidence chain produces the Title III §11 technical-documentation pack: data governance log, accuracy/robustness telemetry, human-oversight events.
- 6. Monitoring Post-market signals continuously fed back into the audit chain; corrective-action trail is immutable.

### Bank-backed AI shopping agent on a tokenised card — _before the bank authorises the payment, KYE™ authorises the agent_

Card issuing · agent purchasing PCI DSS 4.0 PSD3 DORA EU AI Act A retail bank ships an AI purchasing agent to its customers. The customer delegates limited buying authority — capped amount, allowed merchant categories, jurisdiction, time window, approval threshold — bound to a virtual card token (never the raw PAN). On every purchase intent, KYE™ answers _was the agent allowed to use this card, on this customer’s behalf, for this merchant, this amount, this category, in this state?_ before the bank’s issuer authorisation pipeline runs. **Outcome:** the bank’s issuer authorisation pipeline still answers _“is this card transaction financially authorised?”_. KYE™ answers the prior question — _“is this agent authorised to request this purchase, on this customer’s behalf, under this delegation?”_. KYE™ Authority Finality™ + bank issuer authorisation = agent-backed card purchase with proof a regulator, court, or chargeback panel can replay offline.

- 1. Entity Customer (`kye:human:bank-z.eu:psu:alice-meier`), shopping agent (`kye:agent:bank-z.eu:retail:shopping-bot`), virtual-card token (`kye:credential:card-token:tok_abc123`) registered as KYE™ entities. Agent never holds the raw PAN.
- 2. Delegation Customer → agent grant: ≤ £100 / purchase, ≤ £300 / day, GB only, allowed MCCs (`groceries`, `travel`, `office_supplies`); blocked MCCs (gambling, crypto, adult, weapons); approval required > £50.
- 3. Capability `pep` + `pep` bind sub-capabilities: `purchase.search` · `purchase.compare` · `purchase.prepare` · `purchase.request_approval` · `purchase.execute` · `purchase.refund_request` · `purchase.dispute_prepare`. The agent may prepare without being allowed to execute.
- 4. Decision Per purchase, the agent calls `POST /v1/runtime/authorize`. KYE™ checks: customer + agent + card token active · delegation valid · merchant allowed · amount within scope · approval threshold · risk state · payload signed and fresh. Returns `allow_with_constraints` · `require_approval` (push to bank-app) · `deny` with reason (e.g. `merchant_category_blocked`, `amount_above_agent_threshold`).
- 5. Audit Per-purchase Decision Map™ + signed evidence pack: customer → agent → capability → card-token → merchant → amount → approval → decision → receipt. Used for chargebacks, disputes, fraud investigations, regulatory review.
- 6. Recovery If the agent or its session key is suspected compromised — `quarantine` signal, cascade revokes the delegation + the card-token grant in < 1 second. Stale-consent purchases become impossible before the next clearing cycle.

Healthcare & life sciences

## Patient data · provider workflows.

### Clinical chart-review agent reading PHI for a population-health program

Hospital · chart review HIPAA 42 CFR Part 2 NIST CSF A regional hospital network runs an AI chart-review agent that summarises 12,000 patient charts a week to identify rising-risk cohorts for outreach. PHI is the most sensitive data the system handles; HIPAA Privacy Rule and 42 CFR Part 2 substance-use redaction obligations apply on every read. **Outcome:** the OCR-ready accounting-of-disclosures comes from the audit chain; 42 CFR Part 2 redaction is enforced at the capability layer, not in app code.

- 1. Entity Chart-review agent `kye:agent:northstar-health:populations:chart-summariser`; model + capability + dataset versioning recorded.
- 2. Delegation Chain rooted at the chief medical information officer; care-team membership → agent, attenuated to read-only PHI within the consent-defined cohort.
- 3. Capability `pep` binds capability to redaction profile (substance-use, mental-health, HIV) _before_ bytes leave the EHR boundary.
- 4. Decision KYE™ ePDP enforces minimum-necessary; attempts to access non-cohort records emit `deny` with reason `scope_violation`.
- 5. Audit Every read becomes a HIPAA accounting-of-disclosures event; signed chain meets Privacy Rule §164.528.
- 6. Recovery If consent is withdrawn, the cohort grant is revoked; cascade kills any downstream summary the agent had cached.

[AI-assisted treatment recommendation in an emergency-department triage workflow Hospital · clinical decision support HIPAA EU AI Act NIST AI RMF An AI clinical-decision-support tool recommends a triage priority and a treatment pathway; an emergency clinician relies on it under time pressure. If the patient is later harmed, the first question is not what the AI recommended — it is who or what acted, under whose authority, within which clinical scope, and whether that chain can be proven from a record that existed before litigation was contemplated. **Outcome:** the authority chain is preserved at the moment of decision, not reconstructed after harm. KYE™ for Clinical AI → - 1. Entity CDS agent `kye:agent:metro-health:ed:triage-advisor`; model + tool capability + version recorded. - 2. Delegation Chain rooted at the chief medical officer; the sanctioned clinical use case → agent, attenuated to recommendation-only — the agent never decides. - 3. Capability `pep` binds the agent to the authorised scope of use; Purpose Permission™ blocks any recommendation outside the consented clinical context. - 4. Decision Each recommendation seals the authority context — entity, delegation, scope, active policy constraints, approval state — at the moment it is produced. - 5. Audit A signed Evidence Pack™ + Replay-Proof™ chain captures the basis the clinician could independently review; replayable from public keys alone. - 6. Recovery If a model version or use case is withdrawn, the delegation is revoked; cascade prevents any further recommendation under the retired authority.](https://kyeprotocol.com/clinical-ai/)

Cybersecurity & critical infrastructure

## Energy · telco · public sector.

### NIS2 incident-response agent — 24-hour notification deadline

Critical infra · incident response NIS2 IEC 62443 ISO 27001 An energy-distribution operator (NIS2 essential entity) sees an OT-network anomaly at 23:48. The 24-hour early-warning notification clock is running. An AI agent triages alerts, escalates to the CISO, and drafts the regulator filing — every action must be reconstructible by the national CSIRT. **Outcome:** the NIS2 24-hour early warning, 72-hour incident notification, and 1-month final report all draw from the same audit chain. No spreadsheet, no “who acknowledged what when” debate.

- 1. Entity SOC agent + every detector + the CISO+CSIRT contact entities all carry KYE™ URNs.
- 2. Delegation Out-of-hours playbook delegates a time-boxed escalation grant to the SOC agent; expires when CISO acknowledges or 4 hours pass.
- 3. Capability `kye-nis2-1.0` binds the “notify regulator” capability to the CISO’s human-oversight gate.
- 4. Decision Each escalation, draft, and external-comms call is an authorize event; deny on any path that would leak operational data outside the in-scope CSIRT.
- 5. Audit Signed timeline of detection → triage → escalation → CISO acknowledgement → regulator filing.
- 6. Closure Post-incident review attaches root-cause + corrective action to the same chain — one artefact for the regulator, internal audit, and insurer.

### FedRAMP-bound RAG agent over CUI corpus for a federal civilian agency

Public sector · federal RAG FedRAMP NIST 800-207 NIST CSF A federal civilian agency runs a Retrieval-Augmented Generation agent over a 4M-document CUI (controlled unclassified information) corpus, exposing it to authorised analysts. NIST 800-53 access-control + audit + AC-6 least-privilege + AC-21 information-sharing constraints apply on every retrieval. **Outcome:** 3PAO assessor walks away with a signed evidence pack instead of an interview transcript; ConMon ships from the same artefact.

- 1. Entity RAG agent, retrieval index, embedding model and analyst principals all registered as KYE™ entities under the agency trust domain.
- 2. Delegation Analyst → agent grant attenuates to the analyst’s clearance categories; per-document classification labels enforced.
- 3. Capability `kye-fedramp-1.0` binds capability to data classification + need-to-know + dissemination control.
- 4. Decision Every retrieval is an authorize call: `allow` for in-scope, `deny` with redacted excerpt for cross-classification.
- 5. Audit Signed audit trail meets NIST 800-53 AU-2/AU-3 + AC-21 dissemination logs; regulator can replay from public keys.
- 6. Continuous monitoring Telemetry feeds the FedRAMP ConMon evidence pack continuously, not as a quarterly scramble.

Cross-industry

## Insurance · B2B SaaS.

### Claims-triage agent processing 40,000 auto claims a day

Insurance · claims triage GDPR EU AI Act SOC 2 A national auto insurer triages 40K claims a day with an AI agent. State DOI, GDPR Art. 22 (right against solely automated decisions), and the EU AI Act Annex III treatment of insurance pricing all apply. The insurer must explain every individual decision — and revoke the agent’s authority instantly when fraud is detected. **Outcome:** per-claim explainability is the same artefact regulators, complainants, and the SIU read from. No separate explanation pipeline.

- 1. Entity Triage agent + model + ruleset + claims-handler principals registered; per-claim audit-bundle URN.
- 2. Delegation Claims-team lead → agent, attenuated to: monetary cap per claim, no payouts, no SIU referrals without human review.
- 3. Capability `kye-insurance-1.0` binds capability to the GDPR Art. 22 human-review gate at the deny path.
- 4. Decision Decision Map™ for every individual claim shows model + features + fact-pattern + matched rules — the explanation a complainant’s lawyer asks for.
- 5. Audit Signed evidence chain doubles as the SOC 2 access-review and the regulator’s decision-explainability pack.
- 6. Recovery Anomaly detector spots adversarial inputs → `quarantine`; cascade revokes downstream payment authorities in < 1 second.

### B2B SaaS agent invoking MCP tools across customer tenants

B2B SaaS · MCP capability authority SOC 2 GDPR ISO 27001 A multi-tenant SaaS vendor ships an in-product AI agent that invokes Anthropic-MCP tools (CRM, calendar, file store) on behalf of customer admins. SOC 2 access reviews, GDPR data-subject-deletion obligations, and tenant-isolation invariants must hold on every call. **Outcome:** tenant isolation is a protocol invariant, not a unit-test promise. SOC 2 access reviews, GDPR Art. 17, and incident-response evidence all draw from the same audit chain.

- 1. Entity Each tenant → agent → MCP-tool relationship encoded as a delegation edge in the Authority Graph™.
- 2. Delegation Tenant admin → agent, scoped to that tenant’s namespace only; no cross-tenant traversal possible by construction.
- 3. Capability Every MCP tool registered as a first-class capability with parameter-level scopes; per-tenant capability-grant TTLs.
- 4. Decision Every MCP invocation is an authorize call; deny with reason `cross_tenant` on any leak path.
- 5. Audit Signed access-review evidence ships per tenant; the SOC 2 control-test produces itself.
- 6. Recovery Tenant offboarding emits a single signal → cascade revokes every grant + deletes derived data per GDPR Art. 17.

Where to go from here

## Pick the path that fits.

[See it run →](https://kyeprotocol.com/demos/) [Sector profile bundles](https://kyeprotocol.com/sectors/) [Per-framework reference](https://kyeprotocol.com/frameworks/) [Developer quickstart](https://kyeprotocol.com/developers/) Talk to us

Each scenario above is a _shape_, not a fixture. Pilots typically pick one capability (e.g. payment authority, chart-review, claims explainability), prove the audit chain, then expand to the next. Want a custom walkthrough for your sector? We’ll trace your flow live.

## Ready to see your AI agents flagged?

Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

[Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/)

Canonical KYE™ surfaces referenced on this page: [Authority Graph™](https://kyeprotocol.com/authority-lifecycle/) · [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/) · [Purpose Permission](https://kyeprotocol.com/glossary/).
