The safety case says the control exists. Can the runtime enforce it?

Agentic AI governance has a gap. A safety case is a written argument that a system is acceptably safe; the runtime is what actually happens when an agent acts. When an AI agent closes an alert, moves money, or grants access, KYE Protocol™ proves who authorised it and that the claimed control fired — cutting exam-prep from days to minutes. If a control is part of your safety argument, KYE™ makes the runtime answer for it.

Start a governed pilotSee the authority stack

The Handoff Problem, stage by stage

Demo data

You learn: How it works, one stage at a time. You can: Run it end to end.

  1. Evaluation evidence

    KYE Protocol™

    the agent passed pre-deployment tests against a defined risk set (think NIST AI RMF Measure functions). What did we observe before launch?

  2. Safety case claim

    KYE Protocol™

    you assert the agent is acceptably safe because specific controls hold (the argument the EU AI Act™ Article 9 risk-management duty expects). What are we promising?

  3. Deployment scope

    KYE Protocol™

    the agent ships into a real environment with real reach. Where, and over what, can it act?

  4. Runtime permissions

    KYE Protocol™

    the live grants that decide each action — the step where a paper claim either becomes a control or evaporates. What may it do right now?

  5. Action logging

    KYE Protocol™

    each consequential action is recorded with its basis (the EU AI Act™ Article 12 logging duty binds here). What did it actually do?

  6. Monitoring triggers

    KYE Protocol™

    drift, anomalies, and threshold breaches raise signals. What changed?

  7. Escalation / rollback

    KYE Protocol™

    a human or a kill-switch can stop or reverse the agent mid-flight. Can we stop it, and prove we did?

  8. Reopened decision

    KYE Protocol™

    the incident feeds back and the safety case is revised. What do we change next?

How this widget is built
Demonstrates
KYE™ runtime
Components
  • The stages this page describes
Flow
Each stage in order, as the page sets it out. Architecture diagram
Used on

Where the handoff breaks

The same eight steps form the spine of any agentic safety case — and the break is usually between step 2 and step 4. Read them under one question: if a control is part of the safety argument, can the runtime actually enforce it?

  1. Evaluation evidence — the agent passed pre-deployment tests against a defined risk set (think NIST AI RMF Measure functions). What did we observe before launch?
  2. Safety case claim — you assert the agent is acceptably safe because specific controls hold (the argument the EU AI Act™ Article 9 risk-management duty expects). What are we promising?
  3. Deployment scope — the agent ships into a real environment with real reach. Where, and over what, can it act?
  4. Runtime permissions — the live grants that decide each action — the step where a paper claim either becomes a control or evaporates. What may it do right now?
  5. Action logging — each consequential action is recorded with its basis (the EU AI Act™ Article 12 logging duty binds here). What did it actually do?
  6. Monitoring triggers — drift, anomalies, and threshold breaches raise signals. What changed?
  7. Escalation / rollback — a human or a kill-switch can stop or reverse the agent mid-flight. Can we stop it, and prove we did?
  8. Reopened decision — the incident feeds back and the safety case is revised. What do we change next?

The hollow handoff: a safety case can claim every one of these and still fail, because the claim lives in a document while enforcement lives in a runtime nobody can replay. A reviewer who cannot independently check step 4 against step 1 is trusting a promise, not a control.

How KYE Protocol™ closes it

For a CISO, the answer cannot be another report — it has to be a control your auditor can verify without trusting you. KYE™ binds each safety-case control to an enforced, replay-provable runtime check at the action boundary, so the claim and the enforcement are the same fact.

Safety-case stepThe enforced KYE™ check at the action boundary
Runtime permissionsAuthority Gateway™ — every consequential action is intercepted before it commits, not reviewed after.
Safety case claim → scopePurpose Permission™ binds authority to a purpose and scope, so yesterday's grant cannot authorise today's different act.
Action loggingDecision Map™ records why each action was admitted, blocked, escalated, or quarantined, with its cited basis.
Evaluation ↔ runtimeEvidence Pack™ seals the decision into a tamper-evident record any auditor verifies offline from public keys alone.
Escalation / rollbackAuthority Finality™ states — authority can be admitted, suspended, or revoked mid-flight, and the change is itself evidenced.

The chain is fixed: Authority Gateway™ → Purpose Permission™ → Decision Map™ → Evidence Pack™ → finality states. Each link is one runtime check, and each check answers one line of the safety argument — so the gap between the claim and the enforcement disappears.

Why a check, not a checkbox

A reviewer should never have to trust the vendor's log — including ours. KYE™ puts the proof where it cannot be argued with.

  • Every claimed control maps to a runtime check that fires per action, not to an annual attestation refreshed every 90 days too late.
  • The same sealed evidence serves the incident responder today and the auditor next quarter — verifiable against the EU AI Act™, NIST AI RMF, and ISO/IEC 42001 clause 9 duties you must answer to.
  • A handoff that spans jurisdictions stays governed: the cross-jurisdiction handoff keeps the safety argument intact when the action crosses a border.

Start a governed pilot See the authority stack

Canonical KYE™ surfaces referenced on this page: KYE Protocol™ · Purpose Permission.