Try
Try the rail in shadow mode, zero lock-in.
Build against the rail and run it without risk — KYE™ Agent Dev Kit™ ships withKye() so every privileged action auto-emits the evidence family, and shadow mode observes every call before enforcing anything. Start in the sandbox.
The Authority Simulator™: pick a request, watch KYE™ decide
Demo dataYou learn: Why an agent's request is allowed, held for approval or refused, and that the refusal lands before the side effect. You can: Pick a case and run it.
A rule-based execution agent places a small GBP 8,500 hedge adjustment on a permitted instrument — comfortably inside the desk's auto-approval limit. Nothing needs a human.
- Action
- trading.order_place
- Purpose
- place a small hedge adjustment within the desk mandate
- Instrument
- EQ:VOD.L
- Side
- buy
- Amount
- 8,500
Allowed Passed every stage permission_granted
The same rule agent tries to sell a GBP 4.2M block — far above the desk's auto-approval limit. KYE™ holds it: the agent cannot self-authorise an order this size. The money does not move until a human approval is recorded.
- Action
- trading.order_place
- Purpose
- place a GBP 4.2M block order
- Instrument
- EQ:BP.L
- Side
- sell
- Amount
- 4,200,000
Needs approval Stopped at The side effect commits approval_threshold_breach
The desk head records an approval, and the agent re-submits the same GBP 4.2M block. Now the authority is present — KYE™ allows it. The held order is released, with the approval sealed into the evidence.
- Action
- trading.order_place
- Purpose
- place the block order with recorded desk-head approval
- Instrument
- EQ:BP.L
- Side
- sell
- Amount
- 4,200,000
- Approval recorded
- ✓
Allowed Passed every stage permission_granted
Blocked by the limit, the rule agent attempts to grant itself admin authority to raise its own trading mandate. KYE™ refuses outright: an agent can never authorise the expansion of its own authority.
- Action
- authority.self_escalate.grant_admin
- Purpose
- agent attempts to lift its own trading mandate
Denied Stopped at The side effect commits prohibited_action_requested
A rule-based rebalancer sizes each clip from a random draw. On this run the draw produced a GBP 3.1M order — over the desk limit. The agent is non-deterministic, but KYE™'s verdict on the order it actually proposed is the same deterministic…
- Action
- trading.order_place
- Purpose
- randomised position sizing produced an oversized clip
- Instrument
- EQ:VOD.L
- Side
- buy
- Amount
- 3,100,000
Needs approval Stopped at The side effect commits approval_threshold_breach
An LLM-brained copilot, run at temperature 0 for reproducibility, reasons that it should widen its own mandate to finish the task and proposes granting itself admin. A different brain, the same refusal: KYE™ denies the self-escalation…
- Action
- authority.self_escalate.grant_admin
- Purpose
- model reasoned it should widen its own mandate to complete the task
Denied Stopped at The side effect commits prohibited_action_requested
The highest-risk case: an LLM copilot at temperature 0.9 — genuinely unpredictable — proposes a GBP 2.75M block on a volatile name. You cannot know in advance what it will propose; you CAN know how KYE™ will govern whatever it proposes.…
- Action
- trading.order_place
- Purpose
- model proposed a large block on a volatile name
- Instrument
- EQ:GME.L
- Side
- sell
- Amount
- 2,750,000
Needs approval Stopped at The side effect commits approval_threshold_breach
The same 40-tonne copper warehouse receipt is pledged as collateral to two banks in two jurisdictions. A registry records both and discovers the fraud in an audit 41 days later. The KYE™ authority layer refuses the second registration at…
- Action
- custody.pledge_register
- Purpose
- register a pledge over warehouse receipt WR-CU-40T as loan collateral
- Capability
- custody.pledge_register
- Asset ref
- kye:demo:asset:warehouse-receipt-cu-40t
- Encumbrance recorded
- ✓
- Amount
- 165,000
Denied Stopped at The side effect commits binding_already_encumbered
The asset binding the action targets already carries a recorded encumbrance, so a second authority-consuming registration over it is inadmissible (the double-pledge refusal).
The AI payment assistant requests a 320,000 AMD payment to a verified supplier against a matched purchase order. It is inside the delegated threshold, the payee is the verified one, and the execution grant is live. Nothing needs a human.
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-001 to the verified supplier within the delegated threshold
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-001
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-001
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-001
Allowed Passed every stage permission_granted
A 1,800,000 AMD invoice from a verified supplier. The assistant's delegation stops at 500,000 AMD and no approver has recorded consent for this instruction. KYE™ holds it: require_approval, reason payment_threshold_approval_required. The…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-002 above the delegated threshold without a recorded approval
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-002
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-002
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-002
Needs approval Stopped at The side effect commits payment_threshold_approval_required
A payment-class action exceeded the configured threshold for autonomous execution; human approval is required.
A well-formed 420,000 AMD invoice inside the threshold — but the payee account on it is the one a supplier-portal message substituted on 10 September, not the one the SME verified. The rail would settle it. KYE™ denies it…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-003 whose payee bank details changed since the supplier was…
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-003
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-003
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-003
Denied Stopped at The side effect commits supplier_bank_details_changed
The payee bank details on the instruction differ from the last verified record for that supplier. The delegation was granted against the verified payee, not against a payee substituted after verification. Supervisory reading: the instruction is well-formed and would settle; it is the AUTHORITY that is absent, because no one authorised payment to this account.
A 950,000 AMD invoice carries a recorded approval that would clear the threshold — recorded on 11 September, the day BEFORE the supplier's bank details changed and were re-verified. The approver consented to the old payee. KYE™ denies it…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-004 under an approval recorded before the payee changed
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-004
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-004
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-004
Denied Stopped at The side effect commits approval_superseded_by_payee_change
A recorded approval exists but predates the payee change it is being relied on to authorise. The approver consented to the previously verified payee and never saw the new one. Supervisory reading: an approval authorises the instruction that was put in front of the approver, not a later instruction that resembles it — so the threshold control is unmet even though an approval is on file.
A routine 300,000 AMD invoice to a verified supplier, well inside the threshold. The assistant submits it under execution grant B, which expired on 1 September. Absent authority denies regardless of how well-formed the instruction is…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-005 under an execution grant that expired before submission
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-005
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-005
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-005
Denied Stopped at The side effect commits authority_expired
The authority grant was no longer valid at decision time.
The IoDE core scenario. A 2,400,000 AMD instruction: above the threshold, to a payee whose bank details changed since verification, under an approval recorded before that change, submitted on an expired execution grant. The rail would…
- Action
- payment.request
- Purpose
- pay synthetic invoice INV-006 — the four-condition core denial
- Capability
- payment_request
- Instruction ref
- kye:fixture:sme-payment-authority:instruction:PI-006
- Invoice ref
- kye:fixture:sme-payment-authority:invoice:INV-006
- Purchase order ref
- kye:fixture:sme-payment-authority:purchase-order:PO-006
Denied Stopped at The side effect commits authority_expired
The authority grant was no longer valid at decision time.
The agent proposes the action
KYE™ policy decision point
Subject, action, purpose and context, as sent to KYE™.
KYE™ resolves authority and purpose
KYE™ policy decision point
Delegation, scope, thresholds and approvals at decision time.
KYE™ decides and seals
KYE™ policy decision point
Allow, require approval or deny, with a reason code, sealed into the Evidence Pack™.
The side effect commits
KYE™ policy decision point
Only an allowed action reaches the rail; a held or refused one stops here.
How this widget is built
- Demonstrates
- KYE™ runtime decision (kye_decide)
- Components
- Demo scenario registry (kye.demo_scenario.v1)
- Runtime evaluate engine
- Reason Code Dictionary™
- Evidence Pack™
- Flow
- Request → authority and purpose resolved → decision with reason code, sealed → the side effect commits only when allowed. Architecture diagram
- Used on
- /simulator/: The simulator itself: every case is runnable.
- /: The simulator itself: every case is runnable.
- /lab/: The simulator itself: every case is runnable.
Full reference index — every page in the try stage (20) ↓
Derived from the graph
20 pages in the try stage.
This page is a derived view over internal — a secondary projection over the canonical kye-stage enum (the buyer-journey spine). Adding or retagging a page rebuilds this landing on the next CI run — no hand-curated list to maintain.
Operate
Operate — 6 pages
Run KYE Protocol™ in production — deploy, govern, observe, recover.
- KYE™ Audit Pilot™ — 28-day buyer playbook A 28-day, shadow-mode-only KYE™ Audit Pilot™ from kickoff to signed pilot report. Concrete steps, named artefacts, regulatory-citation table, owner column, exit criteria.
- KYE Protocol™ — Playbooks · buyer / vendor / regulator run-throughs Three buyer-facing run-throughs for KYE Protocol™: how a buyer runs the 28-day Audit Pilot, how a vendor self-attests conformance, and how a regulator verifies a KYE™-anchored decision
- KYE Protocol™ — Status · operational targets, SLA tiers, incident severity Honest status spec, implementation, and the service that doesn t exist — Operational targets KYE Protocol™ services run under. SLA tiers (99.9% / 99.95% / 99.99%), RTO/RPO per component, incident seve
- KYE™ Shadow Mode™ — Observe AI-agent actions, suppress side effects A flag, not new code — KYE™ Shadow Mode™ — the runtime flag that suppresses side effects at the Commit Boundary while still running every Authority, Purpose and Decision Engine check
- KYE™ conformance run — vendor playbook A vendor playbook for running the 129-fixture KYE™ conformance pack against your gateway, generating a signed conformance-report.json, and posting the verification record to the public registry.
- KYE™ regulator probe — verifier playbook A regulator / auditor / dispute-panel playbook for verifying a KYE™-anchored decision offline using only the publisher
Build
Build — 14 pages
Build against the rail — SDKs, agents, conformance pack, sandbox.
- Developer Quickstart · KYE Protocol™ Developer Quickstart: send one authority-decision request, read the verdict and its Evidence Pack™ reference, then verify it offline against the JWKS — your first governed decision in under 10 minutes.
- KYE™ Agent Dev Kit™ — build AI agents that prove every action they took KYE™ Agent Dev Kit™ (constitution §32). Opinionated SDK + CLI + templates for building KYE™-aware AI agents. One-line `withKye()` wrapper. Every privileged action auto-evidenced
- KYE™ GovernedUI™ — The human-control interface for AI-agent authority What is KYE™ GovernedUI™? The human-facing visible control surface for AI-agent authority. Approve, reject, edit, escalate, evidence, audit before an AI agent commits a consequential action.
- KYE Protocol™ — Agent Library™ · signed reference agents for every regulated industry KYE™ Agent Library™ — 23 versioned, signed reference agents for 12 categories spanning banking, payments, insurance, healthcare, pharma, logistics, energy, regtech, AI governance
- KYE Protocol™ — Build with KYE™ | Runtime Authority API · SDKs · MCP · Connectors · KYE™ Signal Bus™ Build authority-aware apps with KYE Protocol™. Runtime Authority API, three SDKs (TypeScript / Python / Go), KYE™ MCP Server, Connector Hub™, signed webhooks
- KYE Protocol™ — Developer portal how do you wire AI-agent authorisation, evidence, and replay into your stack with an open SDK in hours instead of weeks?
- KYE Protocol™ — Interactive API Explorer Explore the KYE Protocol™ v3 API interactively. Browse the Core entity hierarchy, State Machine, and State Library endpoints with live schema documentation.
- KYE Protocol™ — KYE™ MCP Server | Authority checks, schemas, evidence packs for MCP agents The KYE™ MCP Server exposes KYE Protocol™ schemas, dictionaries, authority checks, Decision Maps™ and evidence packs to MCP-compatible agents, IDEs and developer tools — through read-only resources
- KYE Protocol™ — Load KYE™ as an agent tool in one file Agents are first-class principals: canonical identity, authority bindings, directory, metering. The KYE™ Agent Tool Pack™ ships every API as a signed.kye-tool.
- KYE Protocol™ — Rules Gateway™ — runtime enforcement Every delegated AI action passes through the Rules Gateway™™. The gateway loads the applicable rule packs + dictionaries + manifests for the tenant
- KYE Protocol™ — Runtime gateway · step 7 of the KYE™ stack KYE™ Reference Gateway™ — the enforcement point that intercepts a candidate action, asks the policy engine for a verdict, and only lets the action commit when the signed Decision Map™ allows
- KYE Protocol™ — Sandbox · build an authorize call in your browser In-browser KYE Protocol™ sandbox. Build an /v1/runtime/authorize request, see the assembled JSON, copy the curl, see a deterministic stub Decision Map™ response. No installation, no signup.
- KYE™ × Weights & Biases — govern agents by model provenance · KYE Protocol™ How does KYE™ work with Weights & Biases? Connect your W&B registry; when an agent
- KYE™ at the inference boundary (NVIDIA NIM · vLLM) — authority before the model runs · KYE Protocol™ How does KYE™ govern AI at the inference boundary? A KYE™ PEP an OpenAI-compatible inference gateway (NVIDIA NIM, Triton, vLLM) consults before running the model — admit, block, escalate or quarantine.
Ready to evaluate KYE Protocol™?
Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.
Canonical KYE™ surfaces referenced on this page: Audit Pilot · Evidence Pack™ · KYE™ Conformance Pack™ · KYE Protocol™.