CORE GUIDE
Runtime enforcement
Runtime enforcement turns policy from advice into executable constraints by controlling which actions, data and side effects can actually pass through the system, even when the model proposes something unsafe.
Mental model
Prompting influences model behavior; runtime enforcement constrains system behavior. Gates, scoped credentials, validators, schemas, approval checks and deny rules are outside-model mechanisms that can make prohibited actions impossible or observable.
Why it matters
Models are probabilistic and context-sensitive, so a strong prompt can reduce but not eliminate unsafe proposals. For permissions, money, privacy and irreversible actions, relying on persuasion creates a single fragile layer. Runtime enforcement gives the application deterministic leverage and produces evidence that a policy was actually applied.
01
Place hard constraints where side effects cross the runtime
Identify consequential capability boundaries and enforce them before execution: validate structured inputs, check user/task authorization, scope credentials, require approvals and reject disallowed combinations. Keep model recommendations visible for diagnosis, but make the runtime independently decide whether the proposed action can execute.
02
Example: prompt says 'never export customer data'
An agent is prompted never to export full customer records, yet an injected document persuades it to call an export tool. If the runtime exposes broad credentials, the prompt failure becomes a breach. With scoped capabilities and a deny rule for external exports, the proposed call is blocked and recorded regardless of the model's text.
Common failure modes
- Using prompt refusal language as the only protection for sensitive tools.
- Putting runtime gates after a side effect has already occurred.
- Creating enforcement rules without observable reason codes or audit evidence.
Engineering heuristics
- Enforce consequential policy before side effects execute.
- Scope credentials and capabilities to the current task.
- Return structured block reasons so failures remain diagnosable.
Takeaways
- 01Runtime enforcement constrains actions, not just model intentions.
- 02Hard guarantees require controls outside the model.
- 03Blocked actions should produce evidence, not disappear silently.
Reading evidence
This records actions you actually took; it does not claim mastery, proficiency, or certification.
Used in
This Concept is reused across these canonical learning paths.
Related concepts from the Knowledge Graph
These relationships come from the canonical graph, not a separate Guide taxonomy.