Refused
out of runbook · signed
For security operations
An AI SOC agent tried to disable a privileged account outside its runbook. KYE™ held the action.
Built for a team like yours. Your detection and response stack now runs AI agents that isolate hosts, disable accounts and block traffic at machine speed — the same speed at which a wrong action becomes an outage. KYE Protocol™ checks the agent’s authorised runbook at the moment of the response — and refuses any action outside its approved scope, holding it for a human. Each refusal is sealed as a receipt your incident review can replay, turning a "why did the bot do that" post-mortem from days into minutes.
AI SOC agent
disable priv account · off-runbook
KYE™runbook scope check
Admitted
within runbook · signed
Held before the response lands. The action is refused because disabling a privileged account sits outside the agent’s approved runbook — and the refusal is signed and verifiable, so you can prove to leadership and audit that a human held authority over the high-blast-radius step.
That refusal, sealed REFUSED · OUT_OF_RUNBOOK_SCOPE kye:evidence:d5b1… Replay & verify →
1 · What KYE™ ™ governs in your stack
You keep your platform. KYE™ governs the response boundary.
Your platform already detects, correlates and orchestrates response across the estate. KYE Protocol™ adds the one check an autonomous responder makes it urgent to enforce: at the moment of a consequential action, is this inside the runbook the agent was actually authorised to run — or a step that must wait for a human?
- Automated response — isolating a host, disabling an account or blocking a range is admitted only when the agent’s runbook and blast-radius limits cover it; a higher-impact action is refused and held for approval.
- Privileged & destructive actions — account disablement, credential revocation and data actions on production are gated by delegated authority — an out-of-scope action is refused, not executed and explained later.
- Every act sealed — admit or refuse, the decision packs an Evidence Pack™ and a Replay-Proof™ verifiable from public keys alone — your incident-review evidence, built as it happens.
2 · The honest boundary
KYE™ proves the basis — it does not detect the threat or run the response.
This is a governance layer, not a SIEM, SOAR or EDR. KYE Protocol™ does not collect your logs, write your detections, or execute your playbooks.
It checks the responder’s authorised runbook at the action boundary, admits or refuses, and seals the proof. An action outside the agent’s runbook is refused and routed to a human step-up — the refusal is itself evidence. See how the delegation chain is drawn on the authority diagram, then walk a sealed decision on the Evidence Pack™ demo.
3 · See it on your own flow
Seeing is believing. Bring one real flow.
In a 20-minute walk-through we take one of your live flows — a host isolation, an account disablement, a bulk block — and show the AI action refused or admitted against the agent’s authorised runbook, then hand you the sealed receipt to replay yourself. No credentials to share: the proof verifies against a public key set, the same runtime enforcement KYE Protocol™ uses to govern itself.
Canonical KYE™ surfaces referenced on this page: KYE Protocol™.