Most enterprise AI policies today are written at the document layer. There's a usage standard, an approved-tools list, a training module, maybe a tenant-level connector configuration. None of those artifacts touch the action. When a coding agent writes a file, when a desktop assistant reaches a forbidden destination, when a Dispatch session approves an action on behalf of a remote user — the policy document is not in the loop.
Agent governance is what closes that gap. It connects written policy to enforced policy, and it produces the audit trail that proves the connection held in practice. For regulated industries, that's not optional; it's the precondition for deploying agents at all.
What agent governance has to deliver
A real agent governance program has to deliver four things, in order:
- Inventory. A continuously-updated map of which agents are running where, who installed them, and what they're authenticated as. Without this, every other governance artifact is a guess.
- Policy. Machine-enforceable rules — by agent class, by user, by environment, by data scope — that decide what an agent is allowed to read, write, reach, and orchestrate. Templates by vendor (Claude, Copilot, Gemini, OpenAI) so the security team isn't writing rules from scratch.
- Enforcement. Policy applied at the layer where the action happens — the OS kernel — not just at the model boundary or the tenant control plane. An action that violates policy has to be blocked, sandboxed, or escalated before it lands.
- Audit. An attribution-grade record of every agent action, sufficient for an internal review or an external regulator. Includes sub-agents, remote-driven sessions, and the chain of decisions that led to a given outcome.
Why first-generation governance frameworks don't cover runtime agents
Most existing AI governance frameworks were written for a model-procurement world. They handle vendor risk review, data classification, model evaluation, fairness testing, and acceptable-use policy. All necessary. None of it tells you what to do when a Claude desktop instance, driven by Claude Dispatch from a phone the security team has never seen, decides to copy a directory it found in a poisoned document.
The reasons the first-generation frameworks miss runtime agents are structural:
- They assume model-as-a-service. Policy attaches to the procurement contract, not to the binary running on the laptop.
- They assume human-in-the-loop. Sandboxed agent runs, sub-agents, and remote-driving capabilities like Claude Dispatch and Operator break that assumption.
- They assume the action is observable from the application layer. It isn't. Once an agent decides to use a tool, the action leaves the application's runtime and shows up on the OS — where the application's logs can't see it.
- They don't produce kernel-grade attribution. An auditor asking "what did the agent do on this device, in this session?" needs an answer at the OS layer, not a model trace.
If your AI policy lives in a Confluence page and your enforcement lives in a tenant admin console, you have governance theater. Real governance is the policy enforced where the action happens — and the audit trail that proves it held.
Where agent governance matters most
The verticals that feel this most acutely are the ones where the regulator is already asking the question:
- Financial services. Hedge funds, private credit, mortgage servicing, and broker-dealers are deploying agents into workflows where regulators expect documented control over decisions affecting customer funds, model risk, and consumer outcomes.
- Healthcare. Agent decisions touching PHI need attribution-grade audit trails. The HIPAA framework was not written with autonomous agents in mind, and the answer to "who took this action" has to remain answerable.
- Regulated SaaS and critical infrastructure. SOC 2, ISO 27001, and sector-specific frameworks expect demonstrated control over what runs on production-adjacent endpoints. "We trusted the vendor's settings" is not a control.
- International and sovereign. Cross-border data residency obligations get harder, not easier, when an agent on an employee laptop can ground against datasets in multiple jurisdictions.
How Ospiri delivers agent governance
Ospiri is built as the runtime enforcement and audit layer of an agent governance program. It deploys alongside the existing EDR stack and applies policy at the OS kernel — the layer where the action actually happens.
- Inventory comes from the observability layer. Continuous discovery without an allowlist; unknown agents get restrictive policy by default.
- Policy templates by vendor. Out-of-the-box policy classes for Claude, Copilot, Gemini, OpenAI, and the long tail of coding and desktop agents — calibrated to each vendor's tool inventory and risk profile.
- Enforcement at four kernel scopes. Filesystem, registry, network, and object isolation, with copy-on-write semantics so the agent keeps working while sensitive resources stay untouched. WSL and VM-resident coverage is in active development.
- Attribution-grade audit. Every OS action attributed to the originating agent process — including sub-agents and remote-driven sessions — so the answer to "what did the agent actually do" is produceable on demand.
Why this is the moment to formalize it
88% of organizations reported an AI agent security incident in the last 12 months. Shadow AI breaches run roughly $670K above the cyber breach baseline. The frameworks regulators will use to evaluate agent governance over the next 24 months are being drafted now. Organizations that can produce attribution-grade evidence of runtime control will be in a different conversation than the ones still pointing at policy documents.