Why do observability logs create outsized risk when AI agents can query them through MCP?

Observability logs often contain user emails, IP addresses, request bodies, tokens, and connection strings that were never classified as sensitive. When an AI agent can query those logs through MCP, the model can ingest that data directly. Because Grafana can proxy into multiple backends, one query path can expose regulated data across several systems.

Why This Matters for Security Teams

Observability data is usually treated as operational telemetry, not as a protected data store. That assumption breaks quickly once an AI agent can reach logs through MCP, because the agent does not just display data, it can ingest, summarize, chain, and reuse it across follow-on actions. In practice, logs often carry user emails, IP addresses, request bodies, tokens, and connection strings, which means a single broad query path can turn routine troubleshooting into data exposure.

This risk is amplified in agentic workflows because access is often inherited from the tool, not constrained by the task. NHIMG’s Astrix Security research on MCP server security shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why log access becomes so overbroad so quickly. The issue is not just whether a human could search the logs, but whether the agent can do so at machine speed and combine findings from multiple backends. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime control and context-aware governance rather than static trust in tool access.

In practice, many security teams discover the blast radius only after an agent has already queried more telemetry than any human operator would have been allowed to see.

How It Works in Practice

When an AI agent uses MCP to query observability systems, the exposure usually comes from three layers at once: the data in the logs, the breadth of the tool, and the autonomy of the agent. A dashboard query that seems harmless to a human can become high-risk when the agent can repeat it, widen it, pivot into adjacent sources, and correlate the results with other retrieved context. That is why static RBAC alone is usually too blunt for this environment.

More practical patterns are emerging. First, scope the MCP tool to the minimum query surface possible, ideally per backend and per data class. Second, use intent-based or context-aware authorisation so the agent is approved for a specific task, not for a standing role. Third, issue JIT credentials or ephemeral access tokens that expire when the task ends. Fourth, treat workload identity as the anchor, using cryptographic proof of the agent workload rather than relying on a shared secret. That approach aligns with the direction described in CSA MAESTRO agentic AI threat modeling framework and the broader control emphasis in NIST Cybersecurity Framework 2.0.

For example, a log agent that supports incident triage should be restricted to structured metadata, redacted fields, and case-specific time windows. It should not be able to pull raw request bodies, auth headers, or cross-system traces unless the policy engine explicitly allows it. NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations report AI agents have already performed actions beyond intended scope, which is exactly why real-time policy evaluation matters more than fixed, pre-approved assumptions. These controls tend to break down in multi-backend observability stacks where one MCP endpoint can proxy into several logging, tracing, and metrics systems because the proxy layer hides the true downstream data surface.

Common Variations and Edge Cases

Tighter log controls often increase operational friction, requiring organisations to balance incident response speed against exposure reduction. That tradeoff is especially visible when engineers want broad telemetry access during outages, while compliance teams need hard limits on regulated or secrets-bearing fields. Best practice is evolving, and there is no universal standard for how aggressively to redact observability data before it is exposed to autonomous tools.

Some environments need exceptions. Security operations may permit broader access for a named incident-response agent, but only with short TTL credentials, full audit trails, and explicit request approval. Development and staging logs may tolerate more freedom than production, yet they still require filtering because test environments frequently contain copied production tokens, personal data, or service credentials. The safest pattern is to classify logs by sensitivity before they are ever made available to an agent, then apply request-time policy checks instead of relying on the assumption that “logs are already internal.”

NHIMG’s OWASP Agentic Applications Top 10 and Moltbook AI agent keys breach both reinforce the same lesson: once an agent can reach a broad data plane through a trusted tool, the security problem is no longer simple access control, but uncontrolled data reuse across contexts.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents create a different access-risk profile than traditional applications?