AI observability fails when watching is mistaken for governance

At a glance

What this is: This is an analysis of why AI observability often stops at monitoring and fails to provide actionable governance across token usage, cost, user activity, API usage, and agent behaviour.

Why it matters: It matters because IAM, security architecture, and governance teams need to distinguish between visibility and control when AI use spans human users, APIs, and autonomous agents.

👉 Read DataBahn's whitepaper on AI observability and governance gaps

Context

AI observability is becoming a governance problem, not just a telemetry problem. Teams can see usage volume, but they often cannot answer who used AI, what data entered prompts, which API paths were involved, or how autonomous agents chained model calls across a task. That gap becomes more serious as AI usage spreads from employees to developers to background services and agents.

The article’s central claim is that monitoring is not enough when the objective is control. For identity and governance teams, the relevant question is not whether activity exists, but whether policy can be enforced before a call completes. That distinction matters across human identity, secrets, API access, and emerging agent identity patterns.

Key questions

Q: How should security teams govern AI use when users, APIs, and agents all generate different telemetry?

A: Start by separating the governance problem into distinct control domains. Human prompts, service API calls, and agentic workflows need different evidence, different owners, and different enforcement points. A single dashboard rarely gives enough context to govern all three, so teams should build policy around the path where each action begins, not only around the logs it leaves behind.

Q: Why does AI observability often fail to reduce risk even when telemetry is available?

A: Because observability shows activity after it has already occurred, while risk reduction requires control before the action completes. If the organisation only watches token counts, spend, or usage summaries, it can document behaviour without preventing misuse. The gap is architectural: the control point is missing, not the report.

Q: How should organizations approach the governance of AI agents?

A: Organizations should adopt a governance framework that incorporates continuous visibility, adaptive IAM practices, and stringent policy-based controls. This ensures that all agent actions are tracked, authorized appropriately, and assessed for compliance.

Q: When should teams prioritise request-path controls over more AI dashboards?

A: Prioritise request-path controls when the question is whether AI behaviour can be blocked, not merely measured. Dashboards help with audit and trending, but they do not stop data from entering prompts or an agent from completing an unsafe action. If the business needs prevention, the control must sit before the call completes.

Technical breakdown

Why token usage is a weak control signal

Token counts are a billing and capacity metric, not a reliable governance signal. Cached context, fresh input, and vendor-specific charging paths distort the relationship between token volume and actual risk. A large token count may reflect harmless reuse, while a smaller set of calls may move sensitive information into model prompts. The underlying problem is that the number is easy to collect but hard to interpret in policy terms. Security teams should treat token data as an accounting input, not as evidence of safe or unsafe AI behaviour.

Practical implication: do not use token volume alone to decide whether AI use is compliant or risky.

Why direct provider, gateway, and console views fragment AI cost control

AI spend is often split across multiple collection points, including gateways, direct provider accounts, and vendor consoles. That means one team may see only part of the bill while assuming it is complete. The same fragmentation affects governance, because each path may expose different telemetry and enforce different policy points. This creates a false sense of visibility when in reality the organisation has several partial views that do not reconcile cleanly. Cost reporting and policy enforcement need the same source map if teams want consistent oversight.

Practical implication: map every AI usage path to its own control point before you trust cost or policy reports.

How autonomous agent usage changes the meaning of observability

Agent usage is different from interactive AI use because one task can trigger a tree of model calls, tool calls, retries, and chained decisions. That means the meaningful failure may occur in the middle of execution, not at the beginning or end. Traditional dashboards that summarise completed activity miss the point where policy should intervene. This is where identity becomes relevant: agents behave like non-human actors with runtime decision-making, so governance has to account for delegated access, tool scope, and execution timing rather than only user intent.

Practical implication: place controls in the request path for agentic workflows, not only in downstream logs.

Threat narrative

Attacker objective: The practical objective is not always external compromise. In this pattern, the outcome is uncontrolled data movement and policy failure across AI usage paths.

1. Entry occurs when employees paste source code into chat assistants, developers wire provider APIs directly into pipelines, or autonomous agents begin making chained model calls as part of normal work.
2. Escalation happens when partial telemetry creates a false assumption of oversight, while sensitive prompts, API traffic, and agent actions move through paths that the security team does not fully instrument.
3. Impact is governance failure: teams can reconstruct activity after the fact, but they cannot reliably prevent data exposure, control misuse, or policy breaches before the model call completes.

NHI Mgmt Group analysis

Watching is not governance, and organisations that confuse the two will keep missing AI risk. Dashboards can tell teams that AI activity happened, but they cannot stop a prompt, a tool call, or an agentic action in flight. That is a structural control gap, not a reporting problem. The governance lesson is that observability without intervention points creates evidence, not enforcement.

AI observability creates an AI control-plane gap when telemetry is collected downstream of decision-making. If policy is applied after the event, the organisation is always reacting to completed actions. That is especially problematic when human users, service APIs, and AI agents all share the same environment but not the same visibility. Practitioners should treat the control plane as the real security boundary.

Agent activity belongs in the identity conversation because AI agents now behave like non-human actors with delegated runtime authority. Once an agent can chain calls, retry actions, and invoke tools, identity teams must ask who or what is authorised to act, under which scope, and for how long. This is where NHI governance and agentic AI security intersect in a way most observability programmes still miss.

Cost reporting is becoming a proxy metric for governance maturity, and that is dangerous. Spend data can reveal volume trends, but it does not show whether sensitive data entered prompts, whether provider paths were bypassed, or whether autonomous workflows exceeded their intended scope. The field needs policy-grade telemetry, not just finance-grade telemetry, if it wants defensible AI governance.

Schema consistency is to AI governance what identity consistency is to access control. If telemetry is fragmented across paths and formats, the organisation cannot reliably correlate behaviour, assign accountability, or prove control effectiveness. That makes AI observability a governance discipline, not a monitoring feature. Practitioners should design for control points that can enforce policy before the model responds.

What this signals

AI programmes are moving toward a control-plane model whether teams call it that or not. The practical signal is that visibility, billing, and governance will keep separating unless practitioners build policy enforcement into the path where prompts, API calls, and agent actions originate. That shift aligns closely with broader work on [OWASP Agentic AI Top 10](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) and the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework).

AI control-plane gap: this is the condition where organisations can observe activity but cannot reliably intervene before a model responds. For IAM and PAM teams, the lesson is to treat delegated AI access as a governed runtime identity problem, not as a reporting problem. That also means normalising ownership for agents, service APIs, and prompt-bearing workflows rather than leaving them in separate operational silos.

Identity teams should expect more overlap between NHI governance and AI governance as agents become more common in production workflows. The useful question is no longer just who has access, but what runtime authority the AI system has, how long that authority lasts, and how the organisation revokes it when behaviour drifts. That is the point at which observability becomes enforceable governance instead of passive telemetry.

For practitioners

• Define the five AI visibility domains Separate token usage, cost, user activity, API usage, and agent usage into distinct control objectives, then assign owners and evidence sources for each. The same dashboard should not be expected to answer all five questions at once.
• Move policy into the request path Enforce controls where prompts, API calls, and agent actions are initiated so policy can apply before completion. Downstream logs remain useful for audit, but they cannot prevent misuse after the call has executed.
• Inventory all AI access paths Map direct provider accounts, gateways, console usage, and embedded API integrations so no usage path is treated as invisible. Reconcile those paths against identities, service accounts, and delegated agent permissions.
• Treat agent workflows as identity events Classify autonomous agents as non-human actors that require scoped authorisation, traceable ownership, and revocation logic. Their access should be reviewed like any other delegated identity, not left as generic automation.

Key takeaways

• AI observability breaks down when organisations treat dashboards as a substitute for enforcement.
• The core issue is architectural: visibility alone cannot govern prompts, API calls, or autonomous agent actions before they complete.
• Practitioners need control points, identity-aware ownership, and policy in the request path if AI use is to be governed rather than merely measured.

Key terms

• AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
• Agent usage: Agent usage refers to AI systems that plan tasks, call tools, retry actions, and chain multiple model invocations within one workflow. Unlike a single chat interaction, agent usage creates runtime decisions that may need identity, scope, and revocation controls.
• Request-path control: Request-path control means enforcing policy before an AI call completes, rather than only collecting logs after the event. It is the difference between observing behaviour and preventing unsafe data movement, tool use, or delegated action in real time.

What's in the full article

DataBahn's full whitepaper covers the operational detail this post intentionally leaves for the source:

• A breakdown of where token, cost, user, API, and agent telemetry each actually live in the enterprise stack.
• The distinction between monitoring data after the fact and placing controls in the request path before completion.
• Implementation detail on how to map visibility gaps to the right source systems, control points, and owners.
• The full telemetry model for deciding which AI actions can be observed, enforced, or only audited after the event.

👉 The full DataBahn whitepaper details the five telemetry questions and the architectural split between watching and governing.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern identity programmes. It helps practitioners connect access control, lifecycle discipline, and governance ownership across human and non-human identities.