Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Cross-mapping tables for AI evidence in life sciences already exist and are broadly right. Data integrity practice lines up against data governance requirements, software lifecycle logs against technical documentation and logging, human review checks against human oversight duties, post-market surveillance against post-market monitoring. Build one repository, present it two ways. ‍ All of that is sound and it starts one step too late.

Monitoring an agent tells you what that agent did. Every useful question about a multi-agent deployment concerns what happened between agents, and those are properties of the connections rather than of the participants. A per-agent view records nodes and the problems live on the edges. ‍ The shortfall is not a tooling problem waiting on a product.

An annual quantification gets produced in March and quoted as fact in November. Everyone involved knows the figure has aged and nobody knows by how much, so it keeps being presented with the same confidence it had on the day it was signed off. ‍ The usual framing is that a number decays gradually and needs refreshing more often. The framing is half right and it misleads on the part that matters, because most of the decay does not happen gradually at all. ‍

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. ‍