Evaluating AI Observability Tools for Security Operations

96% of enterprises are running AI agents in production. Only 37% have a formal AI governance policy of any kind. That gap, near-universal deployment paired with minority-level oversight, is the actual subject of this piece: how to judge AI observability tools built for security operations, not the dashboards built for data science teams asking a completely different set of questions.

Those two groups don't want the same answers. A data scientist wants to know if the model is accurate, if latency is acceptable, if drift is creeping into the outputs. A security analyst wants to know who issued the prompt, what data the agent actually touched, whether that access was authorized, and whether an injection or exfiltration attempt is sitting in the logs waiting to get noticed. A tool built for the first question set can be blind to the second. It'll report a fine F1 score while a prompt injection, a credential leak, and an unauthorized tool call all happen in the same session, undetected, because nobody built it to look for them. Most teams buying observability tools right now are buying the wrong kind. Model-performance dashboards are not security tools, and treating the two as interchangeable is how the majority without formal governance ended up there.

Fortune 500 companies are projected to run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. That's not linear growth. That's the monitoring surface expanding by orders of magnitude while most organizations are still arguing over who owns the problem.

The threat surface AI observability must actually cover

Start with shadow AI, since it's the baseline condition everything else sits on top of. Gartner surveyed 302 cybersecurity leaders between March and May of 2025 and found 69% suspect, or have direct evidence, that employees use prohibited public generative AI tools at work. Separately, 98% of organizations report some form of unsanctioned AI use. IBM's 2025 Cost of a Data Breach Report put a number on what that costs: shadow AI involvement added $670,000 to the average breach. A tool that can't see ungoverned AI use is measuring risk with one eye closed, and no amount of dashboard polish fixes a blind eye.

Prompt injection is a different animal from the input validation failures security teams have handled for two decades. Attacker-controlled content, embedded in a retrieval result, a tool output, or a message the agent processes, hijacks the agent's behavior from the inside. This turns dangerous fast once the agent has write access to internal APIs or SaaS systems, because the injection is now corrupting an action. It's issuing instructions. Catching it means inspecting prompt and completion content in real time. Log review after the fact tells you what happened. It doesn't stop it from happening, and by the time someone reads that log, the damage is filed and closed.

And plain leakage occurs too. A study surveying 48,340 workers across 47 countries found 48% had uploaded company information to public AI platforms, and 57% said they hide their AI use from employers. Self-reported signals are worthless when more than half the workforce is actively concealing the behavior you're trying to measure. Technical detection is mandatory here. It's the only option left standing. The same logic applies to secrets and API keys that show up embedded in a prompt or surfaced in a completion, which need to get pattern-matched in real time, the way a system catches a leaked social security number.

Unauthorized tool invocation deserves its own line. Agentic workflows call external tools, MCP servers, APIs, SaaS connectors, on a user's behalf, and each of those calls is an access control decision made by software instead of a person. Without per-tool logging, there's a record of what the user asked for but no record of what the agent actually did. Treating those two records as the same thing is how audits fall apart under questioning.

Regulation is closing in, even with the timeline slipping. The EU AI Act's high-risk obligations under Annex III were pushed to December 2, 2027, following the AI Omnibus that took effect July 27, 2026, with penalties reaching €35 million or 7% of global annual revenue. Many organizations still lack a systematic inventory of the AI systems running in production. That's an observability failure sitting upstream of every other control, since nothing downstream matters if you haven't counted what's running.

Criterion 1: Real-time threat detection, not post-hoc log review

A tool that logs prompt content for later review and a tool that blocks a malicious payload before the agent acts on it are not variations on a theme. They're different categories of product, full stop, and vendors blur the line constantly because the second one is harder to build.

Real-time detection means inline inspection: prompts and completions checked before they reach the model or get returned to a user, matched against PII categories, secrets formats, and known injection signatures, all inside a latency budget tight enough not to wreck an interactive workflow. That budget matters more than it sounds like it should. Ask any vendor for detection latency at their 99th-percentile query volume, not their average, because averages hide the exact sessions where the security layer becomes the reason the product feels slow.

Indirect injection is the harder case, and the one worth pressing on. Content arriving through retrieval, through a tool's output, through a page the agent browsed, is just as dangerous as a direct prompt and far easier to miss. Ask whether detection fires before the model generates a response or after. Before is the only answer with any security value. After is a postmortem with a nicer font.

A few questions separate the tools worth buying from the ones that aren't. Does the platform block, quarantine, or merely alert on a detected violation? Can rules get tuned per use case, so an HR workflow carries stricter PII enforcement than an internal developer tool? If a vendor's entire security pitch is a dashboard showing what already went wrong, with no enforcement path attached, it doesn't qualify as a security product. It's an expensive obituary.

Criterion 2: Audit completeness, what the log must actually contain

Logging that a session occurred and logging what happened inside it are two different disciplines, and most tools are only built for the first one.

A security-grade audit record has to answer a specific set of questions on demand: who started the session, what permissions were active at the time, what was in the prompt (redacted for PII before it ever touches storage), which tools the agent called and with what parameters, what the model returned, and which policy rules fired and what they did about it. Timestamps need to cover each event in that chain, not just session open and close. Skip one of those fields and the log becomes a record of activity without being a record of accountability, a distinction regulators care about even when engineering teams don't.

Agentic systems make this harder, because a single session using MCP servers can invoke dozens of tools, and a log capturing only session-level metadata can't answer the question that actually matters during an investigation: did the agent read that file? Tool-call granularity is essential. It's the whole point.

Two more things worth checking before signing anything. Are logs write-once, or can an administrator quietly edit them later? What's the retention policy, and does it match the organization's actual regulatory obligations, which vary by sector and are easy to get wrong. Underneath all of it sits the inventory problem again: many organizations don't have a systematic list of the AI systems running in their environment, and a platform can't log what it doesn't know exists. Check whether the tool discovers ungoverned AI endpoints on its own, or just logs the ones someone already told it about.

Criterion 3: Identity-aware logging tied to the organization's existing identity layer

When an incident happens, the question is never abstract. It's which employee, in which role, accessing which system, caused this. A session token that can't trace back to a directory identity can't answer that, no matter how detailed the rest of the log looks.

This mechanism is exactly what makes shadow AI dangerous in the first place: tools operating outside the identity layer are invisible to security by definition, not by oversight. Identity-aware logging closes that gap by tying into the organization's identity provider, Okta, Microsoft Entra ID, or any SAML/OIDC-compliant system, and carrying the authenticated user's identity into every log record, not just at session start but for each tool call inside it. Group and role membership at the time of the request matters too, because it lets an auditor check the access decision against the policy that was actually in effect that day, not the policy in effect now.

Identity-aware logging without role-based access control is just watching. You can see who did what, sure, but you couldn't have stopped it, which turns the audit into a eulogy instead of a control. Fine-grained, per-tool, per-resource permissions are the only thing that scales at enterprise size. A single blanket "AI users" group can't tell the difference between a developer who needs code search and an HR analyst who should never see compensation data.

Agent identity is its own category and gets overlooked constantly. An agent running an overnight scheduled task shouldn't inherit the full permission set of the engineer who configured it, any more than a company car inherits the CEO's parking spot just because the CEO signed the lease. Ask whether the platform issues distinct machine identities for agents, with scoped permissions and audit trails kept separate from human logs. Here's a fair test: try to answer "which user, in which role, invoked tool X on date Y" using nothing but the vendor's audit interface. If that requires exporting raw logs and joining them against an external directory by hand, the integration remains unfinished. It's a demo.

Criterion 4: Integration with existing security infrastructure, not a parallel stack

A tool can produce a flawless, identity-linked audit log and still fail the organization completely if that log only feeds a proprietary dashboard nobody on the SOC team ever opens. A new silo with better branding isn't a governance solution. Security operations already run on SIEM, SOAR, and ticketing workflows, and a tool that can't emit into those systems is a dead end for security purposes, a specialty dashboard wearing a security-shaped label.

Check the export path first. Does the tool emit structured events, CEF, LEEF, or JSON, to Splunk, Microsoft Sentinel, or Google SecOps, in real time rather than overnight batches? Can a detected injection or PII violation trigger a SOAR playbook automatically, or does someone have to spot it first? Is there webhook, PagerDuty, or email alerting, or only an in-app notification that requires someone to have the tab open? Is there a queryable API, so existing detection logic can pull event data on its own terms instead of waiting on a vendor's UI?

Cost and usage telemetry deserves more attention than finance teams usually give it, because a spike in token consumption by a single user or agent can be an early signal of data exfiltration, or a runaway agent loop burning through API calls in the background. That's a security signal wearing a billing report's clothes. Check whether the tool's cost data is granular enough to catch a per-user anomaly, not just a monthly total that only tells the story after the invoice lands.

MCP coverage is no longer optional. As of late 2025, 97 million monthly SDK downloads confirm MCP has gone fully mainstream, and Cisco announced dedicated MCP security tooling at RSA Conference 2026 in response. A tool built before agentic workflows existed may have zero visibility into what MCP servers an agent calls, a blind spot dressed up as a legacy feature set. A gateway sitting between agents and MCP servers, a governed layer everything routes through, tends to produce the richest per-tool telemetry available. Check whether the observability platform can consume those gateway logs directly or whether it demands agents get instrumented one by one. Don't skip deployment model early in the process, either: cloud-only tools get ruled out fast in regulated industries with data residency requirements, so confirm on-premises or hybrid support before falling for a feature set.

Criterion 5: Policy enforcement that can be defined, versioned, and audited

A tool that flags a PII violation and then lets the completion go out to the user anyway has detected a risk and done nothing useful with it. In a regulated environment, that's a paper trail explaining exactly how the breach happened, not a control. Real enforcement means block, redact, and alert exist as distinct, selectable responses per rule, not one alert-only setting dressed up as a feature.

Policies also need to live somewhere other than a vendor's UI. Governance frameworks, including the Databricks AI Governance Framework published in July 2025 and the Liminal enterprise AI governance guide, increasingly treat automated policy enforcement as table stakes for scaling an AI program past a handful of pilot use cases. That means policies written in a declarative, version-controllable format, YAML, OPA/Rego, Cedar, rather than a set of toggles a compliance officer clicked once and forgot about. Version-controlled policy moves through the same change management process as everything else in the security stack: reviewed, approved, rolled back if needed. Point-and-click configuration can't get audited the same way, because there's no diff to look at.

Scope matters as much as format. Rules should be assignable to specific roles or groups, specific tools or MCP servers, specific data classifications, and specific operational windows, tighter rules during active incident response than during a routine Tuesday. Every policy evaluation needs to leave behind its own record: which rule fired, what action it took, what the request context looked like at that exact moment. That record is a mandatory piece of evidence. It's the specific document a regulator is going to ask for, and "we have logs somewhere" won't be an acceptable answer when they do.