Most enterprises have a guess about which AI agents their employees are using. They don't have an answer. The asset inventory shows what IT installed; it doesn't show the four ChatGPT desktops, two Claude installs, and one Cursor instance that an engineering team set up themselves last week. Agent observability is what closes that gap — continuously, without depending on a static allowlist.
It's also the wedge that the rest of the agent firewall sits on top of. You can't sandbox what you can't see. You can't write a policy for an agent class you didn't know was in your environment. Observability comes first; isolation follows.
What agent observability actually has to deliver
A useful agent observability layer has to answer four questions, on demand, for every device under management:
- What's installed? Every AI agent binary on the endpoint — sanctioned, BYO, shadow, or installed by a tutorial five minutes ago. Includes the long tail: coding agents, desktop assistants, browser extensions, MCP-installed sub-agents, custom-GPT helpers.
- What's running? Process-level visibility into which agents are active, who they're authenticated as, and what user is driving them. Includes attribution for remote-driven sessions like Claude Dispatch.
- What's it doing? A live view of OS actions — filesystem reads and writes, registry changes, network connections, IPC handles, child processes spawned. Attributed to the originating agent, not just the binary.
- What's it reaching? Per-process network telemetry. Which destinations the agent talked to, which it tried to talk to, and which were allowed or blocked by policy.
Why first-generation tools don't deliver this
Most of what gets called "AI observability" today is application performance monitoring for LLM calls — latency, token cost, prompt/response telemetry inside an application's own runtime. That's useful, but it answers an entirely different question. It's blind to the agent acting on a laptop, blind to the shadow install, blind to the OS-level action chain.
EDR is the closest existing primitive, but it's optimized for malicious binaries and signature-matched attack patterns. It doesn't classify a benign coding agent writing files as a threat, because by EDR's lights, it isn't one. The agent gets logged as "signed binary, allowed action" and disappears into the noise.
SaaS posture management sees the SaaS side — which Copilot or ChatGPT tenants exist — but not what the local agent does on the local filesystem. CASB sees the network egress at the proxy, but not the process that originated it. Each tool sees a slice. None of them sees the agent.
If your inventory of AI agents is a spreadsheet, you don't have agent observability — you have a snapshot of what people remembered to tell you.
How Ospiri delivers agent observability
Ospiri's observability layer is built on the same Windows kernel driver that powers the agent firewall. The kernel position is non-negotiable: it's the only place where you can see filesystem, registry, network, and process actions in one attribution stream without trusting the agent to self-report.
- Continuous discovery without an allowlist. A separate research system continuously catalogs AI agent binaries — installers, executables, registry footprints, network behaviors. Coverage spans known agents (Claude, Copilot, ChatGPT desktop, Cursor, Perplexity, and more) and emerging tools surfacing on the dark web. New signatures flow to deployed agents in the same shape that endpoint AV signature distribution has worked for decades.
- Unknown agents get restrictive policy by default. When the discovery layer sees a binary it can't classify, it sandboxes it pending admin review. Discovered shadow AI is sandboxed-by-default, not allowed-by-default — which is the opposite of every prior tool's posture.
- Action attribution at the kernel. Every filesystem write, registry change, network socket, and IPC handle is attributed to the originating agent process — including remote-driven sessions and sub-agents spawned by a parent agent.
- Per-process network telemetry. Built on the Windows Filtering Platform. Every destination an agent reaches or attempts to reach, attributed to the agent process — not the device.
Observability is the wedge; isolation is the upsell
The category will mature the same way EDR did. Visibility came first — security teams bought endpoint visibility because they had no map of their environment. Once the map existed, response and isolation followed naturally on top of it. Agent observability is the same shape. Buy visibility because you need to know what's running. Once the map exists, policy and isolation follow on the same agent that's already deployed.
Why this is the moment to deploy 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. Most of those incidents happened on endpoints where nobody in security had a current view of what agents were running. Observability is the precondition for every other thing the security team is going to want to do — and the precondition for every audit the compliance team is going to be asked to produce.