The AI Governance Stack: Why Policy Belongs in the Kernel, Not the Prompt
The AI Governance Stack: Why Policy Belongs in the Kernel, Not the Prompt
Category: Thought Leadership | Reading time: 7 min
The Governance Illusion
A common pattern in enterprise AI deployments looks like this:
SYSTEM PROMPT:
You are a helpful corporate payment assistant.
IMPORTANT: Never process payments to vendors on the blocked list.
IMPORTANT: Payments over $25,000 require manager approval.
IMPORTANT: Always verify OFAC compliance before processing.
IMPORTANT: Maintain SOX compliance in all decisions.
...
This is the governance-by-prompt pattern. It's pervasive. It's also deeply inadequate.
The problem isn't that the LLM ignores these instructions — usually it doesn't. The problem is that compliance requires enforcement, not instruction. A legal system that relied on people agreeing to follow rules without any mechanism of enforcement would not be a legal system. It would be a suggestion system.
AI governance belongs in the execution kernel, not the prompt. This post explains why — and what a proper governance stack looks like.
Why Prompts Fail as Governance
Prompts are probabilistic. LLMs are probabilistic systems. Even with explicit instructions, there are input conditions under which the model may not follow them — unusual phrasing, adversarial inputs, edge cases not covered by training, or simple model drift after updates. An OFAC compliance rule that works 99.9% of the time fails 1 in 1,000 payments. At scale, that's a compliance incident.
Prompts don't compose. Multi-step agent workflows chain multiple LLM calls. Governance instructions in step 1 are not automatically inherited by step 3. Each LLM call starts with whatever context is explicitly provided — if the governance instructions aren't re-injected at every step, they may not apply.
Prompts aren't auditable. When a regulator asks "how did you ensure no payments went to sanctioned entities?", you cannot point to a system prompt. You need a technical control with an evidence trail. Prompts generate text — not audit records.
Prompts can be injected. Prompt injection attacks embed malicious instructions in content the AI processes — an invoice PDF, a vendor description, an email subject line — that override or modify the governance instructions in the system prompt. A governance rule in the kernel cannot be injected away.
Prompts let the LLM reformulate denials. When governance is in the prompt, a denial becomes an LLM output — natural language that the model may soften, contextualise, or omit key regulatory identifiers from. Taos introduces denial_mode on each step definition: "hard" means the kernel raises a typed exception before the LLM ever sees the denial reason. The verbatim regulatory ground truth — including rule_fired — goes directly to the calling code and audit log, untouched by the model. This distinction between hard denial (terminate, compensate, audit) and soft denial (inform LLM, continue) only exists if governance is in the kernel, not the prompt.
Prompts don't survive policy changes. When your approval threshold changes from $25,000 to $10,000, you need to change the prompt in every agent that uses it, test that the change propagated, and verify that it works. In a kernel-based policy, you change one Rego rule and the enforcement updates everywhere.
The Governance Stack
A proper AI governance stack has four layers, each with a distinct responsibility:
┌──────────────────────────────────────────────────────────┐
│ Layer 4: AI Agent │
│ Responsibility: Natural language understanding, │
│ tool selection, output generation │
│ Technology: LLM (GPT-4, Claude, Gemini, etc.) │
├──────────────────────────────────────────────────────────┤
│ Layer 3: Workflow Orchestration │
│ Responsibility: Step sequencing, state management, │
│ retry logic, parallel execution │
│ Technology: LangGraph, AutoGen, Genkit, ADK, etc. │
├──────────────────────────────────────────────────────────┤
│ Layer 2: Governance Kernel ← Policy belongs here │
│ Responsibility: Policy enforcement, approval routing, │
│ OBO chains, saga compensation, audit logging │
│ Technology: Taos kernel (Regorus + Rust) │
├──────────────────────────────────────────────────────────┤
│ Layer 1: Infrastructure │
│ Responsibility: Authentication, network security, │
│ data encryption, access control │
│ Technology: OPA, IAM, VPC, TLS, etc. │
└──────────────────────────────────────────────────────────┘
Each layer has a clear ownership boundary. The LLM doesn't make governance decisions. The orchestration framework doesn't enforce policy. The kernel doesn't write emails. The infrastructure doesn't understand business rules.
When governance concerns bleed into the LLM layer (system prompts), they become probabilistic, unauditable, and fragile. When they stay in the kernel layer, they become deterministic, auditable, and robust.
What Goes in Each Layer
Layer 1 (Infrastructure) handles:
- Who can authenticate and initiate workflows
- Which services can communicate with which
- Data encryption at rest and in transit
- Network-level access control
Layer 2 (Governance Kernel) handles:
- Whether a specific action is permitted (policy evaluation)
- Which human needs to approve it (routing)
- Who authorised the chain of decisions (OBO chain)
- What happens if something goes wrong (compensation)
- What happened and when (audit log)
Layer 3 (Orchestration) handles:
- The sequence of steps in a workflow
- State management across steps
- Error handling and retry logic
- Parallel execution where applicable
Layer 4 (AI Agent) handles:
- Understanding natural language requests
- Extracting structured information from unstructured input
- Deciding which tool or workflow to invoke
- Generating human-readable output
The system prompt belongs in Layer 4. It should describe the agent's purpose, communication style, and available tools — not governance rules.
The Separation of Concerns in Practice
Consider a payment approval workflow. The governance question is: "Does this payment require VP approval?"
With governance-by-prompt (wrong): The LLM reads the invoice, considers the amount, reasons about your approval policy from the system prompt, and decides whether to flag it for VP approval. The decision is implicit in the LLM's response. It's fast and often correct — and occasionally wrong, unauditable, and vulnerable to injection.
With governance-by-kernel (right):
The LLM extracts the invoice amount and vendor details. The kernel evaluates the Rego policy: amount >= 25000 → required_role = "vp_finance". The routing decision is deterministic, logged, and attributable to the specific policy rule that fired. The LLM never made a governance decision — it did what LLMs are good at, and the kernel did what deterministic systems are good at.
The Kernel Constraint on LLM Freedom
A valid concern: if the kernel controls what the AI can do, doesn't that limit the AI's usefulness?
No — it channels the AI's usefulness appropriately. The AI has full freedom to reason, extract, summarise, and communicate. What it cannot do is take consequential actions outside its policy-defined scope. This is the same constraint that applies to human employees: full freedom of thought, bounded authority to act.
A junior analyst can research any investment opportunity. They cannot execute trades without authorisation. The constraint doesn't make them less useful — it makes their usefulness deployable in a regulated context.
The AI agent without a governance kernel is like an employee with no authority structure: capable, but not deployable in any context where accountability matters.
Building the Stack
Implementing the four-layer governance stack doesn't require building everything from scratch:
| Layer | Taos component | What you build |
|---|---|---|
| Infrastructure | OPA / IAM (existing) | Auth, network, encryption |
| Governance | Taos kernel | Policy bundles (Rego), approval routing config |
| Orchestration | LangGraph / Genkit / ADK | Workflow steps, tool implementations |
| AI Agent | OpenAI / Anthropic / Google | System prompt (purpose, not governance) |
The Taos kernel provides Layer 2 as a managed primitive. You focus on Layer 3 (the workflow) and Layer 4 (the agent) — the parts that encode your business logic.
The Bottom Line
Governance by prompt is the AI equivalent of governance by memo — it documents an intent without enforcing a control. A properly architected AI system puts governance in the kernel: deterministic, auditable, injectable-resistant, and policy-managed.
Your LLM is for intelligence. Your kernel is for governance. Both are necessary. Neither can substitute for the other.
Tags: AI governance stack, policy-as-code, governance kernel, LLM governance, enterprise AI architecture, prompt injection, compliance