Notifications
Clear all
Topic starter
18/08/2026 2:25 pm
TL;DR: Routing coding agents through an AI gateway captures tokens, cost, latency, and policy decisions, but it still misses reasoning, tool choices, and inbound context, according to Fiddler. Effective governance requires correlating gateway logs with agent-side telemetry before autonomy expands.
NHIMG editorial — based on content published by Fiddler: Internal Coding Agent Monitoring and what the AI gateway sees and misses
By the numbers:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
- 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed.
Questions worth separating out
Q: What breaks when coding agents are monitored only through an AI gateway?
A: Gateway-only monitoring captures traffic, tokens, latency, and policy decisions, but it misses the reasoning steps, tool choices, and inbound context that shaped the action.
Q: Why do coding agents need more governance than ordinary application traffic?
A: Coding agents can select tools, consume inbound context, and forward sensitive data into downstream actions, so they behave like operational non-human identities rather than passive clients.
Q: How do security teams know whether agent telemetry is actually working?
A: Telemetry is working when it captures tool calls, lifecycle events, and message traces in a way that supports investigation and correlation.
Practitioner guidance
- Correlate agent and gateway telemetry Assign a shared trace identifier to each coding agent session, then log that identifier at both the agent and gateway layers so every request can be traced back to the tool call and inbound context that produced it.
- Limit access until context can be observed Do not expand tool or data access for coding agents until the organisation can see what enters the agent from MCP servers, web fetches, and other inbound sources, not just what exits through the gateway.
- Redact sensitive payloads by default Keep payload logging off by default and use inline redaction for secrets, tokens, and PII so the observability pipeline does not become a secondary data exposure path.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- The specific AI gateway capture fields and observability categories used for coding agent traffic
- The agent-side telemetry pattern built with OpenTelemetry and shared trace identifiers
- The inline enforcement model for redaction, blocking, and policy decisions on the request path
- The latency and payload-handling trade-offs that appear when monitoring is moved into production
👉 Read Fiddler's analysis of internal coding agent monitoring and gateway blind spots →
Coding agent gateways: what they miss and why it matters?
Explore further
18/08/2026 3:15 pm
Observability-first governance is now a prerequisite for safe autonomy. Coding agents can make decisions faster than human review loops, which means teams cannot rely on traditional access review after the fact. The control question is no longer whether the gateway records usage, but whether the organisation can explain how a non-human identity reached a tool decision. Practitioners should widen access only when they can correlate request, context, and action.
A question worth separating out:
Q: Who is accountable when a coding agent leaks secrets or makes an unsafe tool call?
A: Accountability should sit with the team that owns the agent's access scope, telemetry, and policy enforcement, not with the gateway alone. The gateway is only one control point. In practice, organisations need clear ownership for the non-human identity, the data it can see, and the conditions under which it can act.
👉 Read our full editorial: Internal coding agent monitoring needs more than gateway telemetry
