---
title: "The Handoff Problem — can your runtime enforce the safety case it claims? · KYE Protocol™"
description: "In agentic AI governance there is a gap between a safety-case claim on paper and whether the runtime can actually enforce it. KYE Protocol™ closes the handoff: each safety-case control is bound to an enforced, replay-provable runtime check at the action boundary."
url: https://kyeprotocol.com/handoff-problem/
lang: en
source: "KYE Protocol"
---

> In agentic AI governance there is a gap between a safety-case claim on paper and whether the runtime can actually enforce it. KYE Protocol™ closes the handoff: each safety-case control is bound to an enforced, replay-provable runtime check at the action boundary.

# 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 pilot](https://kyeprotocol.com/poc/) [See the authority stack](https://kyeprotocol.com/agent-authority-stack/)

## 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 step | The enforced KYE™ check at the action boundary |
| --- | --- |
| Runtime permissions | Authority Gateway™ — every consequential action is intercepted before it commits, not reviewed after. |
| Safety case claim → scope | Purpose Permission™ binds authority to a purpose and scope, so yesterday's grant cannot authorise today's different act. |
| Action logging | Decision Map™ records why each action was admitted, blocked, escalated, or quarantined, with its cited basis. |
| Evaluation ↔ runtime | [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) seals the decision into a tamper-evident record any auditor verifies offline from public keys alone. |
| Escalation / rollback | Authority 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™](https://kyeprotocol.com/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](https://kyeprotocol.com/cross-jurisdiction-handoff/) keeps the safety argument intact when the action crosses a border.

[Start a governed pilot](https://kyeprotocol.com/poc/) [See the authority stack](https://kyeprotocol.com/agent-authority-stack/)

Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/) · [Purpose Permission](https://kyeprotocol.com/glossary/).