How should security teams let coding agents query observability data without exposing raw traces to model context?

Use a read-only query layer, run agent actions in a sandbox, and return only the final result to the model. The agent should inspect schema first, build a bounded query, and let the database perform filtering and aggregation. This reduces token cost, limits data exposure, and keeps intermediate results out of the model’s context window.

Why This Matters for Security Teams

Coding agents are not just querying dashboards, they are deciding what to inspect next, chaining tools, and turning raw telemetry into actions. If a model receives full traces, spans, or event payloads in context, the exposure is no longer limited to one query. Sensitive identifiers, tokens, endpoints, and tenant data can be retained, reshaped, or leaked through downstream prompts and logs. The safer pattern is to treat observability data as high-risk operational data, not model fodder, and to constrain the agent to read-only retrieval plus narrow outputs. That aligns with the direction of the OWASP Agentic AI Top 10 and the OWASP NHI Top 10, both of which reflect how agentic systems fail when runtime authority is broader than the task requires.

NHIMG research shows the same pattern across identity and secrets failures: Ultimate Guide to NHIs reports that 79% of organisations have experienced secrets leaks, and 97% of NHIs carry excessive privileges. Observability access for agents should be designed with the same discipline. In practice, many security teams encounter trace exposure only after an agent has already ingested far more than the operator intended, rather than through intentional data minimisation.

How It Works in Practice

The operating model is straightforward: the agent asks a bounded question, the query layer enforces the answer shape, and the data platform returns only the minimum result needed. Security teams should let the model inspect schema metadata first, then generate a constrained query that the database or observability backend evaluates at runtime. The agent should never receive a full dump of raw traces if a count, aggregation, filtered subset, or top-N summary will do.

Current best practice is to separate three layers: the model, the policy gate, and the data store. The model proposes the query. The policy gate validates allowed tables, fields, time windows, and row limits. The data store executes the query and returns a restricted response. This is consistent with runtime risk control guidance in the NIST AI Risk Management Framework and the agent security recommendations in CSA MAESTRO agentic AI threat modeling framework.

• Use a read-only service identity with no write, export, or admin privileges.
• Issue short-lived credentials per session or task, not static secrets embedded in prompts.
• Return structured summaries, aggregates, or redacted excerpts instead of raw trace payloads.
• Log the query, policy decision, and returned shape, but keep trace content out of the model context.

That approach is also consistent with NHIMG guidance on agentic attack surfaces in Amazon Q AI Coding Agent Compromised and the broader risk patterns described in 52 NHI breaches Analysis. These controls tend to break down when agents are allowed unrestricted search across multi-tenant telemetry because broad free-text retrieval can surface secrets, customer identifiers, and internal topology in one response.

Common Variations and Edge Cases

Tighter query controls often increase debugging overhead and reduce the model’s ability to “explore,” so organisations have to balance investigative speed against data exposure. That tradeoff is real, especially in incident response, where teams want fast answers but do not want the agent reading every raw span in sight.

For high-volume environments, the safer pattern is to give the agent a purpose-built query API instead of direct access to the observability backend. For multi-tenant SaaS, include tenant scoping and policy checks at the query layer, because a well-formed query can still leak cross-tenant metadata if the boundary is enforced only in the prompt. For regulated workloads, use redaction before retrieval only when it is deterministic; otherwise, let the database filter first and return a smaller result set.

There is no universal standard for this yet, but current guidance suggests treating the model as an untrusted planner and the query engine as the enforcement point. That is especially important when the agent can chain tools, because a benign-looking trace query can become a lateral movement step if the output includes credentials, callback URLs, or internal service names. When the observability stack spans multiple clusters or vendors, this guidance weakens unless schema, tenancy, and policy are normalised consistently across all backends.

Related resources from NHI Mgmt Group

• How should security teams run AI coding agents without exposing the host?
• How should security teams implement MCP access for AI agents in Dropbox without exposing regulated data?
• How should security teams ground AI agents in governed business context when they query enterprise data platforms?
• How should security teams let AI agents complete logged-in tasks without exposing passwords or one-time passcodes?