🤖 AI

From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI

This paper proposes a layered translation method that bridges high-level AI governance standards with implementable runtime guardrails by categorizing controls into four distinct layers—governance objectives, design-time constraints, runtime mediation, and assurance feedback—to ensure that only observable, determinate, and time-sensitive risks are enforced during Agentic AI execution.

Original authors: Christopher Koch

Published 2026-04-08

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Christopher Koch

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you've hired a super-smart, hyper-efficient personal assistant (an Agentic AI) to handle your company's shopping and contracts. This assistant doesn't just answer questions; it can browse the web, sign documents, transfer money, and negotiate deals on its own.

The problem? This assistant is so eager to help that it might accidentally buy 10,000 units of a product it doesn't need, or sign a contract with a shady vendor, just because it was following a complex chain of logic.

This paper is about how to build a safety system for this assistant. It argues that we can't just take a thick rulebook (like ISO standards or government guidelines) and expect a computer to read it and instantly know what to do. Instead, we need a translation method to turn those big, vague rules into specific, enforceable actions.

Here is the breakdown using a simple analogy: The "Corporate Travel Manager."

1. The Problem: The Rulebook vs. The Reality

Imagine your company has a rulebook that says: "Employees must act responsibly and ensure we get the best value for money."

If you hand this rulebook to a robot travel agent, it gets confused.

The Rule: "Be responsible."
The Robot's Dilemma: Does "responsible" mean booking the cheapest flight? Or the fastest one? What if the cheapest flight has a layover in a dangerous city?
The Risk: The robot might book a $50 flight that saves money but gets the employee stuck in a bad neighborhood. The rule was followed technically, but the spirit of the rule was violated.

The paper says: You cannot turn a "spirit of the law" directly into a "computer code" for every situation. Some things need human judgment; others need hard computer blocks.

2. The Solution: The "Layered Translation" Method

The author proposes a 4-Layer Safety System to translate those big rules into actual controls. Think of it like a security checkpoint at an airport, but for your AI's actions.

Layer 1: The Design (The Blueprint)

The Concept: Before the AI even starts working, you limit what it can touch.
The Analogy: You give the travel agent a credit card with a $500 limit and a list of approved airlines only. You don't wait for them to try to buy a private jet and then stop them; you simply don't give them the keys to the private jet hangar.
In the Paper: This is "Design-time constraints." You restrict the tools and data the AI can access.

Layer 2: The Runtime Guardrails (The Bouncer)

The Concept: These are the rules the AI checks while it is working, in real-time.
The Analogy: The agent tries to book a flight for $600. The system (the bouncer) immediately says, "STOP! That's over your $500 limit. I am blocking this ticket."
The Catch: This only works for things that are clear and measurable.
- Good for Guardrails: "Is the price over $500?" (Yes/No, easy to check).
- Bad for Guardrails: "Is this flight 'fair' or 'ethical'?" (Too vague for a computer to decide instantly).

Layer 3: The Human Escalation (The Manager)

The Concept: When the rule is too fuzzy for a computer, or the risk is too high, you pause and ask a human.
The Analogy: The agent finds a flight that is $450 but requires a 14-hour layover in a country with travel warnings. The computer can't decide if this is "safe" or "fair." So, it hits the "PAUSE" button and emails your boss: "Hey, this flight is cheap but risky. Do you want to approve it?"
In the Paper: This is for things requiring "contextual judgment" or "societal impact."

Layer 4: The Assurance (The Audit Trail)

The Concept: After the trip is over, you check the receipts to make sure everything went right.
The Analogy: At the end of the month, you get a report showing every flight booked, every dollar spent, and who approved the exceptions. If the agent bought something weird, you can see exactly what happened and fix it.
In the Paper: This is "Assurance evidence" (logs, audits, traces).

3. The "Enforceability Rubric" (The Decision Tool)

The paper gives you a checklist to decide which layer a rule belongs in. Ask these questions:

Can we see the danger before it happens? (If yes -> Runtime Guardrail. If no -> Human or Audit).
Is the rule a simple "Yes/No"? (If yes -> Guardrail. If it requires "maybe" or "it depends" -> Human).
If we make a mistake, can we undo it? (If the damage is permanent, like deleting a database, you need a stronger guardrail before it happens).

4. The Real-World Example: The Procurement Agent

The paper uses a "Shopping Agent" as an example:

Rule: "Only buy from approved vendors."
- Translation: Design Layer. The agent literally cannot see any other vendors in its database.
Rule: "Don't spend over €5,000 without a boss."
- Translation: Runtime Layer. The computer checks the price. If >€5,000, it stops and asks a human.
Rule: "Be fair and explainable."
- Translation: Human + Audit Layer. You can't code "fairness" easily. Instead, you design the system to be fair, and then a human reviews the decisions later to make sure they were fair.

The Big Takeaway

The main point of this paper is: Don't try to force a computer to be a philosopher.

Standards (ISO/NIST) are the "Constitution" (the big ideas).
Runtime Guardrails are the "Traffic Lights" (stopping clear violations instantly).
Humans are the "Judges" (deciding the gray areas).
Audits are the "Police Reports" (checking what happened later).

To keep Agentic AI safe, you need to put the right rule in the right layer. If you try to make a computer judge "fairness" in real-time, it will fail. If you try to have a human check every single email the AI writes, you will go crazy. The solution is a layered approach where computers do the math, humans do the judgment, and the system keeps a perfect record of everything.

1. Problem Statement

The rapid emergence of Agentic AI systems—capable of planning, tool use, state maintenance, and multi-step execution—has created a governance gap that existing frameworks cannot directly address.

The Shift in Risk: Unlike single-turn generative AI, where risks are often assessed at the prompt/output level, agentic AI risks emerge dynamically during execution trajectories. An agent may appear safe at individual steps but produce unacceptable outcomes when actions are composed over time.
The Standards Gap: Major governance frameworks (ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF, etc.) provide high-level management systems, risk processes, and accountability baselines. However, they are technology-agnostic and do not define executable policy languages or action schemas.
The Core Challenge: Organizations struggle to translate these high-level governance objectives into implementable runtime guardrails. There is a lack of a disciplined method to decide which requirements should be enforced at runtime, which should remain design-time constraints, which require human escalation, and which are best handled via post-hoc assurance.

2. Methodology: The Layered Translation Method

The paper proposes a design-oriented interpretive framework to bridge the gap between governance intent and technical implementation. The method consists of five distinct steps:

A. Artifact Differentiation

The method first separates four conflated concepts into distinct artifacts with specific roles:

Governance Objective: Normative goals (e.g., accountability, risk reduction) sourced from standards.
Technical Control: Mechanisms to operationalize objectives (e.g., scoped credentials, logging).
Runtime Guardrail: A subset of controls that intervene during execution (allow, deny, delay, escalate, or reshape actions).
Assurance Evidence: Artifacts proving control existence and execution (logs, attestations, audit traces).

B. Step 1: Extract Normative Objective

Identify the specific requirement from a standard or internal policy (e.g., "ensure access is authorized").

C. Step 2: Normalize into a Control Tuple

Rewrite the objective into a structured tuple $\kappa = \langle a, x, r, \phi, \delta, \epsilon, o \rangle$ :

$a$ : Acting principal (agent/human).
$x$ : Action class.
$r$ : Protected resource/effect.
$\phi$ : Precondition/context.
$\delta$ : Control decision (allow, deny, escalate, etc.).
$\epsilon$ : Evidence artifact to be produced.
$o$ : Accountable owner.

D. Step 3: Score Runtime Enforceability

Using a Runtime-Enforceability Rubric (Table I), assess if a control is suitable for runtime enforcement. High-enforceability controls must meet criteria such as:

Timing: Harm must be preventable before execution.
Observability: Required state/context is machine-observable.
Determinacy: The rule is crisp, not requiring open-ended ethical balancing.
Reversibility: Mistakes are hard to undo, necessitating urgent intervention.
Evidence: Outcomes can be cleanly logged and attributed.

E. Step 4: Assign Control Layers

Based on the score, assign the control to the appropriate layer:

Governance Objective Layer: Intent and ownership.
Design-Time Layer: Architecture, least-privilege scoping, sandbox design.
Runtime Layer: Action validation, policy checks, dynamic authorization.
Assurance Layer: Telemetry, audits, drift monitoring.
Note: Human escalation is the default for ambiguous or high-impact decisions.

F. Step 5: Specify Evidence and Ownership

Ensure every translated control defines the specific evidence artifact and the accountable owner to ensure auditability.

3. Key Contributions

Conceptual Distinction: Clearly separates governance objectives, technical controls, runtime guardrails, and assurance evidence, preventing the conflation of management intent with execution logic.
Translation Framework: Introduces a systematic method (the Control Tuple and Enforceability Rubric) to map standards-derived requirements to specific architectural layers.
Case Study Validation: Demonstrates the method using an Enterprise Procurement Agent, showing how requirements like "approved vendors only" translate to runtime allowlists, while "fair ranking" translates to design-time constraints and post-hoc audits.
Evaluation Agenda: Proposes five dimensions for evaluating agentic governance: Policy Fidelity, Intervention Quality, Trajectory Coverage, Safety–Utility Trade-off, and Evidence Completeness.

4. Results and Findings (via Case Study)

The procurement agent case study yielded specific insights:

High Runtime Enforceability: Requirements with crisp rules and observable pre-execution states (e.g., "Only approved vendors," "Purchases > €5k require approval") are successfully mapped to runtime guardrails (allowlists, approval gates).
Low Runtime Enforceability: Requirements involving open-ended judgment (e.g., "Supplier ranking must be fair and contestable") are poor candidates for runtime enforcement. Attempting to encode these as deterministic rules risks safety failures or over-blocking. These are better handled via design-time constraints and assurance audits.
Architectural Dependency: Runtime guardrails are most effective when design-time scoping (e.g., least-privilege credentials) has already constrained the agent's action space.
Layered Defense: A single layer is insufficient. Effective governance requires a combination of design-time constraints, runtime checks, human escalation, and post-hoc assurance.

5. Significance and Implications

Pragmatic Governance: The paper argues against the naive compilation of standards directly into code. Instead, it advocates for a layered approach where runtime guardrails are reserved only for controls that are observable, determinate, and time-sensitive.
Risk Mitigation: By correctly placing controls (e.g., moving "fairness" checks to assurance rather than runtime), organizations can avoid the pitfalls of brittle automation and false positives that degrade agent utility.
Auditability: The emphasis on "Control Tuples" and explicit "Evidence Artifacts" ensures that AI systems remain auditable and accountable, addressing the "black box" nature of agentic decision-making.
Future Direction: The framework provides a blueprint for future research to empirically validate control placement and measure the fidelity of translated policies in real-world deployments.

In summary, the paper provides a critical bridge between high-level AI governance standards and the practical engineering of safe, compliant agentic systems, emphasizing that runtime guardrails are a specific tool, not the entirety of governance.