Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

An organization licenses ChatGPT Enterprise. An employee opens a second browser profile, signs into the personal account already logged in there, and pastes a customer extract into it. Same laptop, same managed browser, same corporate egress, same person, same web address. ‍ Every control in the path reads that session as ordinary and correct, because by every attribute any of them can see, it is.

A company too young or too small to have an incident history still has to answer the underwriter at renewal, the enterprise customer running a security review, and the board asking what the exposure is. The usual objection is that quantification needs a baseline and there is none. ‍ The objection rests on a mistaken assumption about how these models work.

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

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.

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

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