Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The standard answer to fragmented AI compliance is a responsibility matrix mapped across the lifecycle. Procurement accountable at intake, legal responsible for regulatory vetting, engineering accountable at implementation, security accountable for monitoring. Every stage has an owner and every function knows its part. ‍ Read that arrangement carefully and the problem is visible inside the solution.

A governance program looks complete until somebody asks it to prove something on a deadline it did not set. A supervisor sends an information request. An underwriter asks for control coverage before binding. A prospect's security team asks how a specific control operated last quarter, and the deal waits on the answer. ‍ Most programs can describe what they do accurately and cannot evidence it inside the window. The difference is not a documentation problem.

Arguments for quantifying cyber risk are abundant and mostly sound. What gets published far less often is a plain account of what a modeled figure does not tell you, which is unfortunate, because stating the limits is more persuasive to a skeptical audience than another argument for the method. ‍ We build these models. What follows is what they cannot do, written plainly, followed by what remains useful once those limits are accepted. ‍

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

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