SPHR Enterprise Agentic Multi-Purpose Harnesses — Governance at Runtime — Part 3

Part 3 of 5 · SPHR Enterprise Agentic Multi-Purpose Harnesses

You cannot make an autonomous agent safe by asking it nicely. The moment an agent takes real actions — calling tools, moving data, delegating to other agents — governance has to be something the system enforces, not something the prompt requests. This is Part 3 of our series on the SPHR Enterprise Agentic Multi-Purpose Harnesses; earlier parts covered the control plane you own and agent identity and zero trust. Here we get to the mechanism that makes those controls bite at runtime: a deterministic policy kernel that intercepts every action before it executes, a tamper-evident audit trail that falls out of that enforcement for free, and human-in-the-loop gates for the actions that warrant a person's judgment.

Prompts are requests; runtime policy is a control

Prompt-level safety is probabilistic. "Never run destructive commands" is a wish the model may or may not honor, and a self-improving agent can rewrite the very instruction you are counting on — the drift problem we unpacked in the self-improving agent's audit problem. A harness treats governance as a first-class runtime layer instead. Every meaningful thing an agent does is a discrete action — a tool call, a message to another agent, a delegation, a model call — and each one is intercepted and evaluated against policy before it reaches the wire. A denied action does not "usually not happen"; it does not happen. That is the difference between discouraging behavior and controlling it.

The policy kernel: enforcement point to decision point

The mechanism is a policy kernel that separates enforcement from decision. A policy enforcement point (PEP) sits in the action path and intercepts each call; it asks a policy decision point (PDP) whether the action is allowed; and only an allow proceeds. In a harness this is AGT — a stateless, fail-closed kernel, so if policy is missing or the check cannot complete, the action is denied rather than waved through. Crucially, no separate policy product is bolted on: AGT natively supports YAML rules, OPA Rego, and Cedar as policy languages, so common rules are written as simple YAML and complex conditional logic drops to Rego. The mental model is the one we use across the platform:

Agent action  →  Intercept (PEP)  →  Decide (PDP)  →  Allow / Deny  →  Record

Intercept every tool call, message, and delegation

The kernel does not sample; it sits on every action. A subagent invoking a tool, one agent messaging another, the orchestrator delegating a subtask — each passes through the same enforcement point carrying the agent's scoped identity and the human principal behind it (from Part 2). Because interception is universal and happens in deterministic application code rather than in the model's reasoning, the outcome does not depend on how the agent was prompted or on which model sits behind its reasoning tier. That is what "deterministic" buys you: the same action under the same policy always resolves the same way, with no path an agent can take to slip an action past the check by changing its own behavior.

Audit as a byproduct of enforcement

Here is the payoff most teams miss. Because the audit record is written by the same step that allows or denies each action, you do not run a separate logging effort and you do not trust the agent to report on itself. Each entry captures the acting identity, the policy decision, and the inputs behind the action — the reconstructible evidence Microsoft frames as a "Decision Bill of Materials." Recorded in a tamper-evident log, an entry cannot be altered or deleted after the fact without detection. The result is that "govern and audit an autonomous agent" stops being two projects: enforcement produces the audit trail as a byproduct, so the answer to "what did this agent do, under whose authority, and why?" is always on hand — reproducibly, not from memory.

Human-in-the-loop for the actions that warrant it

Determinism does not mean removing people; it means spending human judgment where it matters. A harness routes irreversible or high-blast-radius actions — for example a production infrastructure change such as a terraform apply against prod — to a human-in-the-loop gate. The kernel pauses the action, surfaces the evidence behind it, and requires a person to approve before it proceeds, recording who approved what. Routine, low-risk actions pass automatically. This is the operational form of the "human oversight" regulators increasingly expect, and it maps onto the same interception point that does policy and audit — one layer, three jobs. For how those obligations are arriving on a calendar, see the enterprise agent control plane.

A runtime-governance readiness checklist

Before you let agents act autonomously in production, confirm the governance is at runtime, not in the prompt:

• Deterministic enforcement. Is policy evaluated in application code before each action, so a denied action cannot execute — rather than being discouraged in a prompt?
• Universal interception. Does the enforcement point sit on every tool call, message, and delegation — not a sample?
• Fail-closed. If policy is missing or a check cannot complete, is the default deny?
• Audit as byproduct. Is a tamper-evident record — identity, decision, inputs — written by the enforcement step itself, not self-reported by the agent?
• Human gates. Are irreversible or consequential actions routed to a meaningful human approval, with the approver recorded?

Continue the series

This is Part 3 of a five-part series on the SPHR Enterprise Agentic Multi-Purpose Harnesses:

• Part 1 — The control plane you own
• Part 2 — Agent identity and zero trust
• Part 3 — Governance at runtime (you are here)
• Part 4 — The OWASP Agentic Top 10, controlled: ASI01–ASI10 answered with concrete controls
• Part 5 — Multi-tenant knowledge, memory, and cost: isolation and FinOps at the action layer

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We make governance a runtime layer in your harness: a deterministic, fail-closed policy kernel on every action, a tamper-evident audit trail produced as a byproduct of enforcement, and human-in-the-loop gates on the actions that carry real consequence. As an Anthropic partner working model-agnostic and multi-cloud, we build the governance layer to hold whether the reasoning behind an action came from one model or another. If your agent "guardrails" live only in a prompt today, let's move them to runtime.

Frequently asked questions

Why can't you govern AI agents with prompt instructions?

Prompt instructions are probabilistic requests, not controls — the model may comply or not, and a self-improving agent can rewrite the very instruction you are relying on. Durable governance moves the decision out of the prompt and into a runtime layer that intercepts each action and evaluates policy deterministically before it executes. A denied action then does not happen, rather than being merely discouraged.

What is a policy kernel (PEP/PDP) for AI agents?

A policy kernel splits enforcement from decision: a policy enforcement point (PEP) sits in the action path and intercepts each tool call, message, or delegation, then asks a policy decision point (PDP) whether it is allowed. In a harness this is AGT — a stateless, fail-closed kernel that natively supports YAML, OPA Rego, and Cedar as policy languages, so common rules are simple YAML and complex conditions drop to Rego, with no separate policy product added.

What does deterministic runtime governance mean?

Deterministic means the same action under the same policy always produces the same decision and the same audit record — no gaps the agent can open by changing its own behavior, and no action that runs without a record. Because the check happens in application code before execution rather than in the model's reasoning, the outcome does not depend on how the agent was prompted. AGT reports p99 policy-evaluation latency under 0.1 ms, so this runs on every action without noticeable overhead.

How does an agent audit trail become tamper-evident?

Because the audit record is a byproduct of the same enforcement step that allows or denies each action, it is written in the governance layer, not self-reported by the agent. Each entry captures the acting identity, the policy decision, and the inputs behind the action — reconstructible on demand. Recording it in a tamper-evident log means an entry cannot be altered or deleted after the fact without detection, which is what an auditor or regulator actually asks for.

When should an AI agent action require human approval?

Whenever an action is irreversible, high-blast-radius, or consequential — for example a production infrastructure change. A harness routes those to a human-in-the-loop gate: the policy kernel pauses the action, surfaces the evidence behind it, and requires a person to approve before it proceeds, then records who approved what. Routine, low-risk actions pass through automatically, so oversight is spent where it matters rather than rubber-stamped everywhere.

This series describes the pattern-level architecture of the SPHR Enterprise Agentic Multi-Purpose Harnesses, built on public frameworks — Microsoft's Agent Framework (MAF) and Agent Governance Toolkit (AGT), plus OPA Rego and Cedar as policy languages. Implementation details are generalized.