For the last three years, "AI security" has mostly meant chatbot security — input filtering, output classification, prompt-injection detection at the model boundary. That work is real and necessary, and it solves a meaningful slice of the problem: keeping a model from saying something harmful inside an application's own runtime.
It does not solve the problem agent security is concerned with. Once a model decides to use a tool, the action leaves the model's runtime and shows up on a laptop — as a filesystem write, a registry change, a network connection, a UI event in another application. By the time it reaches that layer, prompt-time guardrails are no longer in the loop.
What agent security has to bound
The right way to think about agent security is by surface, not by technique. The OS-layer surface that a modern agent touches falls into a small number of categories, and a real agent security program has to bound each one:
- Filesystem. Reads, writes, modifications, deletes — across the user's local tree, attached network shares, and any path the agent's tools can resolve.
- Registry. Persistence, autorun keys, security-relevant settings, configuration for other software the agent could tamper with.
- Network. Per-process egress and ingress — what the agent reaches and what reaches the agent. Critical when agents pull in arbitrary connectors and MCP servers.
- Process and IPC. Inter-process orchestration, sub-agent spawning, injection into other processes, UI-driving and computer-use action chains.
- Identity. Whose credentials the agent inherits, whose session it runs as, what tenant it's authenticated against — and whether a remote driver (like a phone running Claude Dispatch) is making decisions on behalf of the seated user.
Why first-generation AI security tools don't cover this
The first generation of AI security tools was designed for a chatbot world — a single application embedding a model behind a clear API boundary. The whole stack reflects that assumption:
- Prompt guardrails intercept text before it reaches the model. They have nothing to say about what the model decides to do with a tool.
- Output classifiers intercept text after the model returns it. They don't see a UI event, a shell command, a file write, or a network call.
- LLM observability and APM measure latency, cost, and prompt/response telemetry inside an application's runtime. Useful for the application team. Invisible to the SOC trying to understand what an agent did on a laptop.
- EDR is the closest existing primitive, but it's optimized for malicious binaries. A signed Anthropic, Microsoft, OpenAI, or Google binary writing files isn't a threat by EDR's lights. The action gets logged and disappears.
None of these are wrong. They're necessary. They're just not sufficient for agents that act outside the application boundary they were designed for.
Agent security is the discipline that picks up where prompt guardrails stop — at the moment the model decides to use a tool, and the action leaves the model's runtime entirely.
What a real agent security program looks like
Operationalizing agent security in 2026 looks like four practices, layered:
- Continuous discovery. A live inventory of every AI agent on every endpoint, including shadow installs the user did themselves. This is what agent observability delivers.
- OS-layer enforcement. Policy decisions made at the kernel — filesystem, registry, network, IPC — so they survive whatever the agent or its tools decide to do. This is what an agent firewall delivers.
- Sandboxing instead of blunt blocking. Copy-on-write isolation that lets the agent operate against a sandboxed copy of sensitive resources, instead of failing the action and getting itself disabled by the user. The difference between governed productivity and shelfware.
- Auditable action chains. Every OS action attributed to the originating agent — including sub-agents and remote-driven sessions — so the compliance team and the SOC can answer the question what did the agent actually do? This is what agent governance rests on.
How Ospiri delivers agent security
Ospiri is built as the runtime layer of an agent security program. The product is a Windows kernel driver and an endpoint agent that deploy alongside the existing EDR stack — not a replacement for any of it. The four kernel-scope isolation layers (filesystem, registry, network, object) plus the signature pipeline give the security team a place to enforce agent policy at the layer where action actually happens.
The architectural bet is copy-on-write at kernel scope. When an agent tries to modify a file, Ospiri clones it into a sandbox. The agent operates against its sandboxed copy and gets the functionality it needs. The original files remain untouched. Policies decide whether to commit, discard, or escalate the sandboxed changes. That's the difference between an agent security program that breaks productivity and one that enables governed productivity.
Why this is the moment to take agent security seriously
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. Every major lab is shipping agents that act on behalf of the user — installing software, opening network connections, modifying files, controlling other applications. The endpoint isn't where the human sits anymore. Without an agent security layer deployed at the OS, the enterprise has no way to enforce what the agent can do, where it can reach, or whether it's authorized to be there.