In a previous post, “You Cannot Secure the AI Agents You Don’t Know About,” I made a narrow and obvious claim: organizations cannot secure and govern agents they do not know exist. Discovery answers whether an agent is there. It does not answer what that agent can reach, what it did, or whether an organization can reconstruct any of that for an auditor after the fact. As Alejandro Leal put it in KuppingerCole’s Agent Visibility and Observability Platforms Leadership Brief, visibility shows that an agent exists; observability explains what happened, why it happened, and how it can be addressed. Closing that gap requires seven more capabilities.
This post extends the discussion from visibility to observability while also sitting inside a larger AI security framework. Jonathan Care’s Advisory Note, “Navigating the Agentic AI Security Landscape,” introduces a six-category framework for agentic AI security and governance. What follows is not a competing model. It is a continued discussion of the visibility and observability slice of that landscape, expanded into the seven controls that an organization or a vendor must have in place to deliver effective observability after agent discovery.
The seven controls of AI agent observability
1. Inventory, Ownership, and Identity Context
A list of agents is not an inventory. A useful agent inventory requires context: an owner, a purpose, a lifecycle state, and a mechanism for flagging an agent as orphaned the moment its owner leaves the organization. Without these and other contexts, agents will accumulate the way stale service accounts have, except faster
2. Runtime Telemetry and Trace Capture
Knowing an agent exists and its key context is not the same as knowing what it did. Prompts, tool calls, and Model Context Protocol (MCP) activities all need to be captured, not merely the fact that the agent ran and produced some result.
3. Interaction and Delegation Mapping
Agents call other agents, and agents can also receive delegated rights directly from people. A system that maps only the first hop of that chain will miss the multi-hop delegation paths where accountability gets lost.
4. Permission, Credential, and Tool Access Analysis
Most agents do not hold their own permissions today. In practice, they inherit access transitively through a service account or an OAuth grant. A security system blind to that inheritance is blind to the actual attack surface, regardless of how complete the agent inventory appears.
5. Behavioral Analytics and Threat Detection
Baselining normal behavior, then using that to detect prompt injection, agent hijacking, and other anomalous patterns, is where observability starts feeding threat detection. This is also where this area touches Care's Agent Threat Detection and Response (ATDR) category. But the relationship is sequential, not overlapping: observability produces the telemetry ATDR detects on, and ATDR adds the response half (automated or human-in-the-loop remediation) that observability doesn't cover.
6. Policy Enforcement and Guardrails
Detection without enforcement is an expensive dashboard. The real test is whether an agent security system can block, suspend, or require step-up, human-in-the-loop approval in real time, rather than only alerting after the action has already been completed.
7. Explainability, Audit, and Governance Reporting
Can the organization reconstruct why and how an agent did something, in a form that satisfies an EU Artificial Intelligence Act (AI Act), Digital Operational Resilience Act (DORA), or an internal governance, risk, and compliance (GRC) auditor, and not only an engineer reviewing a log file?
Each of these seven control areas fails if treated as an independent feature rather than a connected set of capabilities. Telemetry that does not feed detection is wasted collection. Detection that does not feed enforcement or audit is a lost alert. Whether the full solution comes from a single AI Agent Visibility and Observability Platform (AI-VOP) (the ideal) or from a combination of integrated point solutions, complete observability is the goal.
Before evaluating a single vendor, an internal AI security and governance program should ask some questions of itself to understand its existing gaps and investment priorities. Does every agent in production have a named owner and a lifecycle state, and does that agent get flagged the moment its owner leaves? Can the team reconstruct a complete, ordered sequence of an agent’s actions (prompts, tool calls, and MCP activity) for a single session? Can they show which agents call other agents, and which rights a person delegated directly to an agent? Can they trace an agent’s access back through inherited service account or OAuth credentials? Do they have a baseline of normal agent behavior good enough to make prompt injections or agent hijacking detections? Can their existing controls block or suspend an agent mid-action, or require human approval, rather than only alerting after the fact? Can the team hand an AI Act, DORA, or internal GRC auditor a report and not just a log file? If the honest answer to these sorts of questions is “no,” observability is a gap.
KuppingerCole Analysts is developing a Leadership Compass evaluating the market and vendors against this AI-VOP framework. Consider this post as a starting map for reading any AI-VOP vendor pitch, and for judging an organization’s own program against the framework.
