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.

Where the handoff breaks

Whether you are a CISO, a regulator, or a builder, 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.

Start a governed pilot See the authority stack