Use cases · 10 real-world business applications

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.

payments Financial services (4) local_hospital Healthcare (2) bolt Critical infra (2) grid_view Cross-industry (2)

Financial services

Banking · custody · asset management · agent purchasing.

Banking · payments PSD3 DORA EU AI Act

High-value payment approval via AI agent

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.

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.

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.

Custody · break-glass MiCA FFIEC ISO 27001

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

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.

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.

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.

Asset management · AI research EU AI Act ISO 42001 NIST AI RMF

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

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.

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.

Outcome: the technical-documentation pack the EU AI Act notified body asks for ships from one endpoint — no parallel evidence team, no spreadsheet reconciliation.

Card issuing · agent purchasing PCI DSS 4.0 PSD3 DORA EU AI Act

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

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.

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.

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.

Healthcare & life sciences

Patient data · provider workflows.

Hospital · chart review HIPAA 42 CFR Part 2 NIST CSF

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

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.

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.

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.

Hospital · clinical decision support HIPAA EU AI Act NIST AI RMF

AI-assisted treatment recommendation in an emergency-department triage workflow

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.

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.

Outcome: the authority chain is preserved at the moment of decision, not reconstructed after harm. KYE™ for Clinical AI →

Cybersecurity & critical infrastructure

Energy · telco · public sector.

Critical infra · incident response NIS2 IEC 62443 ISO 27001

NIS2 incident-response agent — 24-hour notification deadline

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.

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.

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.

Public sector · federal RAG FedRAMP NIST 800-207 NIST CSF

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

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.

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.

Outcome: 3PAO assessor walks away with a signed evidence pack instead of an interview transcript; ConMon ships from the same artefact.

Cross-industry

Insurance · B2B SaaS.

Insurance · claims triage GDPR EU AI Act SOC 2

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

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.

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.

Outcome: per-claim explainability is the same artefact regulators, complainants, and the SIU read from. No bespoke explanation pipeline.

B2B SaaS · MCP capability authority SOC 2 GDPR ISO 27001

B2B SaaS agent invoking MCP tools across customer tenants

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.

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.

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.

Where to go from here

Pick the path that fits.

play_circle See it run → apartment Sector profile bundles fact_check Per-framework reference code Developer quickstart forum 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.

rocket_launch Apply for pilot → science Try the sandbox →