Request-level observability

Expanded Definition

Request-level observability is the practice of recording evidence for each AI or application request as it passes through a control layer. That evidence typically includes prompt flow, token counts, latency, policy outcomes, tool calls, and identity context, so teams can inspect behaviour at the granularity where risk actually occurs.

In NHI and agentic AI environments, this is more than traditional logging with extra fields. It is a control-plane view of how an agent, service account, or API-driven workflow behaves on a specific request path. Definitions vary across vendors, but the core idea is consistent: the record must be detailed enough to reconstruct decisions and detect misuse, not just confirm that an endpoint was called. It aligns closely with the intent of the NIST Cybersecurity Framework 2.0, which emphasises visibility, governance, and continuous monitoring.

The most common misapplication is treating coarse application logs as request-level observability, which occurs when telemetry omits prompt content, tool execution, or policy decisions.

Examples and Use Cases

Implementing request-level observability rigorously often introduces storage, privacy, and correlation overhead, requiring organisations to weigh forensic depth against data minimisation and operational cost.

• An agent submits a prompt to a model, receives a response, and then invokes an internal API. The trace captures the full sequence, including the policy decision that allowed the tool call.
• A service account generates unusual token usage across many requests. Teams compare the request traces with the guidance in the Ultimate Guide to NHIs to determine whether the behaviour reflects drift, compromise, or mis-scoped access.
• A prompt injection attempt changes the agent’s intended path. Observability reveals the altered prompt flow and the downstream request that exposed sensitive data to an unintended tool.
• A production incident shows rising latency only for requests that trigger policy checks. The trace makes it possible to separate model latency from control-layer enforcement delays.
• A platform team correlates request traces with the NIST Cybersecurity Framework 2.0 to validate whether monitoring coverage exists for high-risk paths.

Why It Matters in NHI Security

Request-level observability matters because NHI compromise is often invisible until behaviour changes at the request layer. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which makes fine-grained evidence essential for detecting abuse before it spreads. The Ultimate Guide to NHIs also highlights that only 5.7% of organisations have full visibility into their service accounts, which is exactly the gap this control addresses.

Without request-level evidence, security teams cannot prove whether a model output was benign, whether a tool call was authorised, or whether a policy engine intervened correctly. That weakens incident response, hinders auditability, and makes it harder to enforce least privilege for agents and service identities. It also supports governance by showing how decisions were made, not only that a request succeeded.

Organisations typically encounter the need for request-level observability only after a suspicious agent action, token misuse, or data exposure has already occurred, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between network trust and request-level identity trust?
• What breaks when network controls are used instead of request-level policy for machine access?
• Request-level Authorization
• Decision-Level Observability