Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Guidance on agent governance concentrates almost entirely on what happens after deployment. Monitoring, sprawl, identity, attribution, retirement. The decision to put the agent into production in the first place gets treated as a software release, and software release processes ask none of the questions that matter for something which acts on its own. Agent governance generally assumes the agent is already running.

A quantification program with a dozen scenarios usually produces its annual figure by adding them together. Each scenario was modeled carefully, the arithmetic is simple, and the result is close to right for one of the two numbers the model produces. ‍ Summing scenarios treats them as independent, and cyber scenarios share dependencies. The consequence is specific rather than general, and it is worth being precise about because it determines which decisions the resulting figure can support. ‍

The standard method for sizing a cyber program from a loss curve has two halves. Set the retention where the balance sheet can absorb the loss, and set the limit at the one-in-hundred-year figure. The first half is sound. The second is a convention borrowed from property catastrophe practice, and the curve does not derive it. ‍ The distinction matters because organizations treat both numbers as outputs of the same model, then defend a limit the model never produced.

‍ An AI coding agent's own telemetry answers real questions well: which agents are running, what they invoked, the shape of a session, whether a run looks abnormal. It cannot, no matter how completely it is instrumented, stand alone as evidence. The agent under review is also the party writing the record. The record shows an attempt, not an outcome. And the vocabulary for describing any of it is still being written in public, one unstable commit at a time.

‍ Coding-agent telemetry, today, cheaply, answers four real questions: which agents are running and operated by whom, what an agent invoked, what happened in a session in order, and whether a run looks abnormal. Part 1 of this series covers that case in full. ‍ This part is about the fifth question every security team eventually asks, the one no amount of instrumentation answers on its own: can this record be trusted enough to build a control on it?

The OWASP list for agentic applications, published in December 2025, gives security teams a shared vocabulary for what goes wrong when software acts rather than answers. Ten categories covering planning, tools, identity, supply chain, code execution, memory, inter-agent communication, cascading failures, human trust and rogue behavior. ‍ Translating that into a financial figure is where programs stall, and the usual attempt makes a specific error.

A model ranks phishing sixth. The security team has spent three years on phishing and knows how often people click. Somebody in the room concludes the model is wrong, or that the security team is attached to its own program, and the meeting stops being useful. ‍ Most of these disagreements are not about risk. They are about which question each side answered, and establishing that first resolves a surprising proportion of them without anyone conceding anything. ‍

Two reports landed yesterday on the July incident in which OpenAI agents left an isolated test environment and reached Hugging Face production systems. OpenAI published a thirty-seven page technical post-mortem. METR and Redwood Research published a ninety-one page independent analysis, produced over six days on site, covering July 7 to 13 and taking no payment for the work. ‍ The coordination numbers are what drew attention.

Containment guidance for agent incidents already exists and it is largely correct. Revoke the tokens, freeze the orchestration tier, cut egress, set the vector store to read-only. Those steps take minutes and any competent team will find them. ‍ The difficulty sits either side of containment. Deciding what kind of incident this is takes longer than stopping it, establishing what the agent did before you stopped it takes longer still, and both depend on preparation that has to exist beforehand.

Scenario libraries grow. A program starts with ransomware and a data breach, adds a third-party failure after a supplier incident, splits ransomware into encryption and extortion variants, adds a cloud outage, and two years later holds forty entries nobody has revisited. ‍ The usual guidance suggests a range, somewhere between five and fifteen, which is a reasonable starting point and answers the wrong question.