Agentic Governance™ with Authority Finality™
Before your AI agent acts,
one API call proves it was allowed.
Was the action allowed? Can you prove what happened? Did it close cleanly? The KYE™ Authority API answers all three on every consequential action (allow, deny or require approval) and returns a signed receipt your auditor can verify offline, years later. Know Your Entity™ at t=0: identity asks who; KYE™ proves whether it was allowed, the instant the action forms.
Decision centre: chain of authority, admissibility, finality
ComputedYou learn: Who decided what, along which chain, why a request was held or denied, and that the record is final and verifiable. You can: Watch decisions arrive; approve as the delegate (the initiator cannot), verify a seal, revoke a delegation.
-
Procurement agent orders above its approval threshold
approval_threshold_breach
Chain of authority
- Orrin Logistics (demo) Principal
- Dara Quinn, head of procurement kye:authority:orrin.example:procurement-head-2026
- Procurement agent kye:authority:orrin.example:proc-04-2026q4
-
Drafting agent prepares a disclosure letter, with redaction
permission_granted
Decision record sealed
- Decision allow_with_constraints
- Obligations kye:obligation:redaction
ff8305bc6290ca7ef2d60b6290c4c2712c62b1280faf28be46d896685fdea90e -
Credit agent acts outside its jurisdiction
jurisdiction_unsupported
Decision
- not_revoked grant in force
- within_time_window 2026-10-14T09:09:20Z before 2027-01-12T00:00:00Z
- action_in_scope credit.line.approve in [credit.line.approve]
- purpose_matches lending.adjudicate = lending.adjudicate
- within_jurisdiction US in [GB, IE]
- within_constraints GBP 4,200.00 ≤ GBP 25,000.00
-
Accounts-payable agent pays a supplier invoice
permission_granted
Chain of authority
- Brightmoor Retail (demo) Principal
- Ana Ruiz, finance lead kye:authority:brightmoor.example:finance-lead-2026
- Accounts-payable agent kye:authority:brightmoor.example:ap-11-2026q4
-
Clinical summarisation agent asks to read records for marketing
permission_missing
Decision
- not_revoked grant in force
- within_time_window 2026-10-14T09:05:31Z before 2027-01-01T00:00:00Z
- action_in_scope record.read in [record.read, record.summarise]
- purpose_matches marketing.outreach ≠ clinical.summarise
- data_class_in_scope [health.record] in [health.record]
- within_jurisdiction GB in [GB]
-
HR operations agent acts on a revoked delegation
delegation_revoked
Signal
- Regional treasurer, EU Revoked
- Treasury agent (fx-router) Revoked by cascade
How this widget is built
- Demonstrates
- Decision feed and approvals
- Components
- Policy decision point (evaluate, kye_decide)
- Chain of authority
- Admissibility checks
- Decision records and evidence packs
- Revocation cascade
- Flow
- Each decision lands on the device of whoever must know or act: approvals on the approver's phone, denials on the CISO dashboard, allows in the team channel. Tapping one opens its chain, checks, seal or cascade. Architecture diagram
- Used on
- /examples/: On the examples page; it plays when scrolled into view (Play/Pause).
- /: The home page, right after its opening.
- /terminal/: The terminal: the decision centre on its devices.
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.
Authority Finality™KYE Protocol™ enforces authority while the action is forming: it refuses out-of-scope AI-agent action before the side effect commits, and every refusal and approval is signed, replayable and verifiable offline.
Start where you are
Eight ways in. Every page, at most three clicks away.
Each section lists its groups and their pages; every page also links its neighbours and the pages that share its audience, industry, regulation or stage.
The platform
What KYE Protocol™ is and how authority is decided, enforced and proven.
- Overview (The platform) · 9
- How authority works · 15
- Operating model (The platform) · 7
- Concepts and model · 10
- Maps of KYE™ · 10
- The category and its governance · 12
Products
GovernedUI™, add-ons, authority packs, governed agents and the marketplace.
- Platform and runtime · 14
- Add-ons · 30
- Authority packs and consoles · 17
- Governed Agents · 46
- Marketplace and apps · 6
By sector
KYE™ by sector: sector packs, sector solutions and the foundry's packs.
- Sector pages · 7
- Sector solutions · 12
- Sector Pack Foundry™ · 38
Compliance, conformance & certification
249 frameworks mapped, requirement by requirement, to the KYE™ artefact that enforces them.
- Coverage · 5
- Framework library · 11
- Islamic finance standards · 21
- Health and life sciences · 23
- AI governance frameworks · 37
- Privacy and data protection · 26
- Security and resilience · 23
- Audit, tax and accounting · 12
- Financial services and AML · 27
- Other frameworks · 69
- Evidence and reports · 19
Solutions
Start from your role, your use case or your region.
- KYE Protocol™ for your role · 15
- Use cases (Solutions) · 17
- Sovereign AI (UK · EU · Gulf · Public sector) · 9
- Journeys · 8
Developer portal
Build with KYE™: the API, SDKs, schemas, connectors and open source.
- Build · 12
- API reference · 22
- Interfaces and connectors · 3
- Libraries and ecosystem · 2
- KYE™ Open Source · 12
- Tools · 9
Engage
Partner, pilot, certify, build and invest with KYE™.
- Partner programs · 6
- KYE™ Sector Pack Foundry™ · 1
- Pilots and proofs of concept · 5
- Certification and training · 7
- Marketplace and community · 6
- Startups and ventures · 3
Resources
Learn, read, check our trust record, and find the legal terms.
- KYE™ Learn™ · 10
- Glossary · 191
- Blog · 9
- KYE™ Research Library™ · 14
- Analyst Briefing · 7
- KYE Protocol™ Trust Center · 8
- Assess and operate · 3
- Roadmap and updates · 6
- Press and brand · 6
- Legal · 9
- More pages · 1
Browse by
Audience, industry, product, capability, regulation, stage.
Security and identity teams · Compliance and risk · Legal counsel · Privacy and data protection officers
9 valuesIndustryFinancial services · Insurance · Islamic finance · Healthcare and life sciences
12 valuesProduct (Browse)GovernedUI™ · Governed Agents™ · Evidence Pack™ · KYE™ MCP Server
10 valuesCapability (Browse)Delegation and chains of authority · Admissibility and decisions · Evidence and replay · Human oversight and approval
10 valuesRegulation and frameworkEU AI Act · GDPR and national data protection acts · DORA · NIS2
17 valuesStageUnderstand · Evaluate · Try · Adopt
5 valuesContent typeFramework mapping · Governed agent · Sector pack · Role guide
17 valuesFAQ
Questions we are often asked
What is KYE Protocol™ in one sentence?
The open contract that answers, for every action a human, service, AI agent, model, tool or workflow takes: who acted, on whose behalf, with what authority, under what scope, with what evidence?
Does KYE™ replace legal agreements or signatures?
No. KYE™ does not replace legal agreements, signatures, or regulatory obligations; it provides the technical control and evidence layer needed to support authority finality, accountability and legally defensible audit trails for agentic systems.
What does one call return?
A decision (allow, require_approval or deny) with a reason code from KYE™'s vocabulary, a replay-stable decision id, a receipt you can verify, and a sealed Evidence Pack™ that can be verified offline from published keys.
How is it different from IAM?
Traditional IAM answers who logged in. KYE™ answers everything that comes after: who or what acted, who they acted for, what authority they had, what capability they used, what state they were in, and what evidence proves it.
Can I try it without signing up?
What licence is the protocol under?
Apache License 2.0. KYE™, KYE Protocol™ and Know Your Entity™ are trademarks of the KYE Protocol™ project; see the trademarks page.
How is the information I enter in forms used?
Only to answer that request. Read the details in the and the full privacy policy.