Alerting on Anomalous Agent Behavior in Production

Coding agents can fail in ways that pass every health check a team already watches. The agent returns a successful response, it finishes inside its latency budget, and it still hallucinates a fact into a pull request, or burns through a credential it was never meant to touch. Catching that requires watching what the agent did, not whether it crashed, and that's the gap this piece is about.

Why coding agents fail silently, and why normal monitoring misses it

Application performance monitoring was built to answer a narrow question: did the request complete, and how fast? Coding agents rarely fail that way. None of that trips a crash detector, because none of it is a crash. It's a judgment failure wearing the shape of normal operation.

The non-determinism makes this worse. Uptime measures whether the lights stayed on, not whether the agent did the right thing with them on.

Conventional APM counts the wrong thing. It monitors model calls: how many requests went out, how many tokens came back, what the latency was. It has no concept of a task, and therefore no way to connect a burst of model calls to the workflow that triggered them or to ask whether the decisions inside that workflow made sense. A tool that tracks API calls instead of tasks will tell you an agent was active, with no indication of whether what it did made sense. It will not tell you whether the agent did something it shouldn't have.

This has stopped being a theoretical concern. Agents are writing and merging code in production at a scale where a behavioral blind spot is an operational risk, not an academic one.

The specific behavioral signals that indicate a problem

Knowing that agents fail silently only helps if you know which signals separate a real problem from ordinary variation. Four categories of signal do most of the work, and each one is diagnostic for a different reason.

An agent built to read a file, run the test suite, and open a pull request has no business calling a network egress tool or opening a .env file partway through that session. The individual tool call might look innocuous in isolation, but the sequence is the tell: tools appearing out of their usual order, or combinations of tools that have never co-occurred in that session type, carry more diagnostic weight than any single call viewed on its own. Research on runtime governance for agent systems treats a deviation in execution path as a policy violation in its own right, not something to note as a performance curiosity and move past.

Token spend rate, not just cumulative spend. Context windows don't grow in a straight line. Every LLM request carries the full conversation history, so if a session starts small, it can be sending inputs that are orders of magnitude larger by the twentieth step. Watching the running total misses this, but watching the rate of spend against a trailing baseline catches it. If a key's spend rate spikes well above its own recent average in a short window, that should trip a circuit breaker, not just generate a line in a cost report. Retry loops make this worse in a specific way: an agent stuck retrying a failed tool call burns tokens at a pace no session budget anticipated, and in a flat log, those retries look exactly like ordinary tool use.

Coding agents routinely connect to source control, CI/CD pipelines, and cloud APIs. The Cloud Security Alliance's 2026 survey found that 92% of IT and security professionals lack confidence that their legacy IAM systems can manage the risks tied to AI and non-human identities, and a scoped-credential alert is meant to close precisely that gap.

This differs from a single bad tool call. No single step in that drift looks alarming. The pattern becomes visible when someone traces the full arc of the session.

A hallucinated answer delivered at normal latency is invisible to any dashboard built around response time and error codes, because the agent did respond, correctly formatted, right on schedule, and wrong. Research on decision evidence in agentic systems frames this as a maturity gap: a team that only logs outputs has no way to reconstruct why the agent made a given decision, and that reconstruction separates a one-off mistake from a failure mode that will recur.

Capturing these signals requires the right trace structure

Alerting on these four signal classes depends on the underlying trace capturing the right unit of analysis. Most teams' current logging records what happened without preserving the decision chain that produced it, and a signal that was never captured can't be detected later no matter how good the alerting logic is.

An agent session is a tree, not a row in a log file. A single run fans out into parent runs, individual tool calls, handoffs between sub-agents, retries, and branching paths that depend on what each prior step returned. Flatten that structure into a single timeline and the thing an on-call engineer actually needs, the shape of how the agent got from the request to the outcome, is gone. Traditional application logging was built to capture outputs. Agent observability has to capture the chain of decisions in between: which tool was called, with what arguments, in response to which reasoning step, at what cost in tokens.

Without attribution at the level of each individual step, tracing a quality regression back to its cause becomes close to impossible, especially once a system involves a planner, a router, and one or more sub-agents each contributing part of the final output. Audit-grade traces need more than a log line per event: immutable, append-only records, before-and-after deltas on anything the agent changed, a named actor for every action, timestamps precise to the millisecond, and a record of what role that actor held at the moment it acted. That is the substrate compliance-relevant alerting sits on top of, and research on decision evidence maturity in agentic systems treats this kind of property-level trace capture as what you need to govern these systems.

Some convergence is happening on what that trace should look like. A team that builds its alerting on a proprietary, non-standard trace schema locks itself into whatever tooling produced that schema and narrows which alerting systems can read the data later. Platforms like Ellipsis, which run coding agents in isolated sandboxes with full audit logs of every command, file change, and tool call, are built around this structural requirement from the start, so that every session is traced and attributable as it happens.

Full visibility into an agent's tool calls, diffs, and spend

A production-grade alerting stack needs three distinct layers: behavioral anomaly detection, cost circuit-breaking, and quality-aware firing. No single tool covers all three, and treating them as one problem leaves gaps that someone eventually finds the hard way.

Behavioral anomaly detection starts with a baseline of normal tool call sequences, built per agent type and per session trigger, and alerts on departures from it: a new tool type appearing for the first time, an established sequence running in reverse, or a combination of tools that has never co-occurred before. Severity should be tiered. Research on runtime governance for agent systems describes this as policy expressed directly on execution paths, an assertion the system checks, not a threshold someone hand-tunes and hopes holds.

Token spend rate monitoring needs circuit-breaker logic; a dashboard that only updates after the fact won't do it. If a session's spend rate looks like it's running an unnecessarily expensive model for a task that doesn't need it, the alerting logic should flag that, not leave it for a cost-optimization review three months later.

Quality-aware alerting covers what the first two layers structurally cannot see. Faithfulness drops, hallucination spikes, and PII leakage patterns need to exist as first-class alert conditions, because a model that answers confidently and incorrectly, at normal latency, is invisible to anything watching only response time and error codes. Continuous anomaly detection on top of this can catch things nobody explicitly wrote a rule for: circular outputs, clusters of timeouts, patterns consistent with prompt injection. The goal is to catch these before a customer files a ticket about them, not after. When a production failure occurs, it should feed directly into the evaluation dataset used in CI, so a change that risks reintroducing that failure mode gets caught automatically the next time, and nobody has to remember the incident.

If nobody is looking at where the alert lands, none of this matters. A behavioral alert sitting in a dashboard that's open on nobody's second monitor is functionally the same as no alert. Routing into PagerDuty, Slack, and GitHub, whether as a PR comment or a failing check, is part of designing the alert, not an afterthought bolted on once the detection logic works. Engineers need to be able to acknowledge, escalate, or suppress an alert from wherever they're already working, whether that's a terminal, a Slack thread, or a GitHub PR, without opening a separate monitoring console to do it.

What the Uber budget breach reveals about late alerting

Uber's experience with agentic coding tools in 2026 is the clearest public illustration of what happens when this stack is missing a layer. After expanding Claude Code access to its full engineering organization in December 2025, Uber's CTO confirmed the company had burned through its entire annual AI budget in four months, by April 2026.

The root cause sits in the cost curve itself. Agentic sessions consume far more tokens per task than a standard generative AI interaction, and because context accumulates as a session extends, the cost of each additional call grows along with it. A budget that looks reasonable on day one of a rollout can be wildly inadequate by day ninety if nothing is built to interrupt the trend early. What was absent wasn't visibility into the total spend; that number appeared in the reporting eventually. What was absent was rate-of-spend alerting that would have flagged the trajectory weeks or months before the annual cap was hit, paired with enforcement that could have throttled individual sessions instead of just recording that they'd gone over.

Uber's lesson isn't that it shouldn't have run agentic coding tools at that scale. Scale without session-level enforcement turns a reporting gap into a budget event. Cost is one dimension of that gap. Credential scope and execution governance are the other, and they fail in the same structural way: a problem that's technically visible somewhere in the system but invisible to whoever could have stopped it in time.

What makes alerting enforceable

An alert only matters if something downstream of it can actually stop the agent from doing more damage. Detecting a problem and having the infrastructure to halt it are two separate capabilities, and a stack that has the first without the second still leaves the door open.

Sandboxed execution is the precondition. An alert that correctly flags out-of-scope credential access is nearly worthless if the agent's execution environment can't enforce that scope in the first place: an unsandboxed agent running with standing, ambient credentials can finish doing the damage before the alert ever reaches a human. 86% of security leaders at large enterprises report they do not enforce access policies for AI identities at all; the credential a compromised or misbehaving agent is holding is very often one with no guardrail on what it can reach. Effective alerting on credential-access signals depends on agents running under governance that enforces scope from the start. Infrastructure like Ellipsis mints credentials fresh for each session and revokes them when the session ends, making an out-of-scope access attempt harder to pull off and visible immediately in the audit trail.

Pipeline design can do some of this enforcement structurally, rather than leaving it to a human watching a dashboard. The propose/dispose pattern in CI separates a "propose" job, which runs with read-only access and no deploy secrets, from an "open-PR" job that sits behind required human reviewers and runs as a configured GitHub environment. Under that design, the enforcement is built into how the pipeline is structured.

Configuration itself needs the same discipline applied to any other piece of production infrastructure. Alert thresholds, declared scopes, and budget caps that live in YAML files checked into the repository get the same code review, version history, and rollback path as any other change to the system. Without a structured trace tying every tool call, every unit of token consumption, and every credential access to a specific session and trigger, teams are left piecing together what an agent did after the fact instead of knowing in real time, which is the reason agent infrastructure has to be built around observability from the start rather than added on top of monitoring designed for something else. Research on runtime governance for agentic systems treats policy expressed directly on execution paths as a formal requirement for safe operation, not a nice-to-have an engineering team gets to if time allows. Alerting tells you something went wrong. Governance built into the sandbox, the credentials, and the pipeline is what makes that alert arrive in time to matter.