Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

When an AI system misfires inside a large company, the question that follows is who was responsible for it. The answer usually lands on the CIO, and frequently the CIO had no part in choosing, approving or deploying the thing that failed. ‍ This gets described as a governance problem, which undersells it. Governance implies a process that exists and performs badly.

‍ ‍Most cyber risk quantification (CRQ) platforms ask for trust. They describe their data sources in general terms, display an average annual loss at the top of a screen, and offer nothing in between. Anybody wanting to check the number is asked to accept the connection on expert judgment alone, which is a reasonable thing to decline when the figure is about to support a nine-figure decision.

Somebody in the organization will eventually propose running documents through an AI text detector. The instinct is reasonable and the method is the one approach the published evidence rules out, for reasons a security or risk function should understand before the policy gets written. ‍ The organization that built the most widely used language model tried this and withdrew its own tool after six months. Its reason was accuracy, and the figures it published before withdrawing explain why. ‍

Every major identity vendor shipped an agent offering during 2026, and the datasheets converge on the same three claims. Agents get first-class identities, permissions are scoped, and access is governed. ‍ The question that separates them is narrower. When the engineer who built an agent leaves the company, what happens to the agent? The answers differ enormously, and they differ for reasons that trace back to what each vendor was originally built to do. ‍

A team that can write a Monte Carlo simulation over a loss distribution can build a cyber risk quantification model in a few weeks. The mathematics is undergraduate statistics and the code is not the obstacle. ‍ Three other things are, and each one outlasts the build. Loss data good enough to calibrate against, the work of keeping the model current once the person who wrote it moves on, and documentation that holds up when somebody who did not build it starts asking questions. ‍

LiteLLM, a widely used open source gateway for routing requests across language model providers, was compromised twice in 2026. Malicious releases reached its public package registry in March and again in October, through two separate intrusions, each carrying a credential stealer into every environment that installed them. ‍ Neither attack touched a model. Neither one manipulated weights or tampered with training data.

Measure carries four categories and twenty-two subcategories, and they divide cleanly by what kind of evidence satisfies them. Some ask whether something was observed. Others ask whether something was tested. Monitoring answers the first group and contributes almost nothing to the second.

Quantification integrated with a governance platform and quantification sitting beside one behave nothing alike after the first quarter. The integrated figure moves when control status moves. The standalone figure describes the date somebody last updated it. ‍ Two directions of data traffic make the difference, and most implementations build only the first one. ‍

Microsoft states the position plainly. Copilot only surfaces organizational data to which individual users have at least view permissions, so it grants nobody access to anything they could not already open. What changes is that material somebody had permission to reach and never would have found now arrives in a summary. ‍ The governance work is therefore permissions work that predates the deployment.

Conventional vendor risk tooling asks whether a supplier will suffer a breach. For an AI provider that question is necessary and incomplete, because the larger exposure is what the provider does with your material while operating exactly as intended. ‍ Retention periods, training use, inference location and the model serving an endpoint are data governance questions rather than security ones. Most platforms in this market have no field for them, which is the first thing to check. ‍

Buying a cyber risk quantification platform means asking a vendor to defend numbers that will end up in front of a board, an auditor, or a regulator. Most evaluation calls never press that hard. The questions below are the ones that separate platforms from each other, and they are written so that any vendor can answer them, including vendors who would beat Kovrr on several of the answers.

Most governance platform comparisons written for financial services lead with the EU AI Act high-risk regime. For a bank deploying credit scoring today, that is the obligation furthest from biting, and the ones already in force get less attention than they deserve. ‍ The criteria below follow the provisions rather than the subject areas, with dates attached, because the sequence they arrive in decides what a platform has to do first. ‍

The two registers hold different objects, run on different clocks and answer to different people. Where they are treated as one list at different levels of detail, items get counted twice and others fall between them. ‍ A vulnerability register holds findings on assets and numbers in the thousands. A cyber risk register holds loss scenarios and numbers in the tens. Neither is a summary of the other. ‍

Seven fields carry an agent registry, and they split into two kinds. Some a person has to state, because the answer exists only in somebody's intention. The rest can be read from systems that already hold them. ‍ Which kind each field belongs to decides whether the registry drifts. Typing an observable value creates a record that was accurate on the day somebody typed it, and recording a declared value is the only way to capture it at all. ‍

Run both approaches against one company and the figures differ, which is expected. The useful part is that they differ in a predictable direction, which makes the distance between them informative rather than embarrassing. ‍ Bottom-up tends to come in lower and top-down higher, for reasons that follow from how each is built. Knowing which way each one leans is more useful than choosing between them. ‍

Most register comparisons rank products on fields, workflow and integrations. A more useful test is which decisions the register can settle, because a register that cannot settle a decision is a record of one made elsewhere. ‍ Five decisions get asked of a register. Which risk to treat first, how much to spend treating it, whether to accept it, whether to transfer it, and whether the treatment worked.

Interaction monitoring covers four of the ten risks in the 2025 Top 10 for LLMs and generative AI applications well, three partially and three not at all. The split is not arbitrary, and the line it follows tells a buyer more than the coverage count does. ‍ Monitoring observes systems being used. Several entries on the list describe defects in how a system was built, which no amount of observation at the point of use will surface.

A coding agent on a laptop runs as the developer. It reads the same keychain, carries the same tokens and appears in every downstream log under the same name. The identity record is accurate and it cannot answer the question governance needs answered. ‍ Every control keyed to identity therefore operates on a merged subject.

A budget presented as a total invites one question with two answers, approve or reduce. A budget presented as a ranked list invites a different question, which is where to draw the line, and that is a decision a board can make rather than a negotiation it can only win or lose. ‍ The ranking comes from one calculation per candidate control. Expected loss before, minus expected loss after, divided by cost. Order the list by that ratio and the budget builds itself, including the part that says stop.

Search for agent risk quantification tools and most results are risk assessment tools. Questionnaires, maturity scores, compliance trackers and templates, all producing an ordinal rating. A rating ranks one agent against another. It does not tell anybody what to spend, what to insure or what to stop. ‍ The separating question is whether the output arrives in currency.

An audit trail is usually judged by how much it contains. The more useful question is how many innocent explanations it rules out, because a record that admits a benign reading supports an assertion rather than a conclusion. ‍ Each source added to a trail removes an alternative explanation rather than adding detail. Confidence therefore climbs in steps rather than smoothly, and three sources of the same kind are worth less than two of different kinds. ‍

Enterprise AI governance guidance assumes a review board that meets monthly, an independent validation function, an impact assessment per system and somebody whose job title contains the words AI and compliance. A company of three hundred people has none of those and is governed by the same regulations. ‍ The difference runs deeper than budget. Enterprise programs are assessment-led, which scales with headcount because every system needs an assessor.

The extortion demand is the figure that gets quoted and rarely the largest line. Downtime, restoration, forensics, legal hours and notification each contribute, and for a mid-market company the regulatory components behave in a way that catches finance teams out. ‍ Reporting deadlines do not scale with headcount.

The Model Context Protocol states plainly that it cannot enforce these security principles at the protocol level, and that implementors should follow best practices in their integrations. Every control an organization gets therefore comes from where it places the gateway and what it does there. ‍ The protocol publishes its own security best practices document, currently at revision 2026-07-28, naming the attacks a deployment has to handle.

Monitoring has to happen on the device, because three categories of AI use never reach the network in a form anything can inspect. Local models run without leaving the machine. Desktop applications that pin their certificates sit on an inspection bypass list by design. A laptop on a home connection routes through nothing the organization operates at all. ‍ The uncomfortable part is that the first two are deliberate. Somebody approved the bypass, and the approval was correct on its own terms. ‍

A model built on industry data produces an industry answer. The obvious next step is to calibrate it to the specific environment, and the obvious place to start is the threat picture, because every organization believes its own is distinctive. ‍ It is the wrong parameter to start with. Some inputs should stay general, some must be local, and the ones that must be local are the harder ones to observe, which is why they get left at a default. ‍

Plenty of material explains what ISO/IEC 42001 contains. Clause by clause, control by control, with a checklist of documents to prepare. The standard itself is a management system specification rather than a control catalogue, and the distinction is where audit preparation goes wrong. ‍ The checklists share one omission.

The usual case for governance return is that it speeds up enterprise sales, because buyers ask security questions and a prepared answer closes faster. It is true and it is the weaker argument. ‍ The stronger one is loss avoidance, and almost nobody makes it, because it needs a loss figure that most governance programs do not have. What makes it affordable is a distinction between two kinds of evidence. ‍

A correlation rule can be tuned. The window can be widened, the join key improved, a source promoted from optional to required. Each of those is a parameter with a defensible setting. ‍ What remains after all of it is the residual, meaning the events that would produce a finding if a source existed for them, which is a form of residual risk expressed in detection terms. Naming it is the question an auditor asks after being shown a detection, and the answer is not a tuning exercise. ‍

A quantification exercise reports a one-in-hundred-year loss and the figure travels well. It sounds precise, it sounds severe, and everybody in the room believes they understand it. ‍ Most of them do not. The phrasing describes an annual probability and it reads as a statement about timing, and the two produce different decisions from the same number. ‍

AI governance evidence is usually prepared for a neutral reader. A regulator with no stake in the market, an auditor with no competing product, an examiner who gains nothing from what the documentation contains. ‍ In securities and derivatives markets that assumption does not hold. Exchanges and clearing organizations register as self-regulatory organizations, and most of them operate the market while regulating its participants. The reader of your evidence is also an operator. ‍

An exposure figure is produced once and read three times. The audit committee sees it, the risk committee sees it, and the board sees it, and each is answering a different oversight question. ‍ The figure travels well and the reasoning behind it does not. What arrives at the third reading is a number with no assumptions attached, and by then it reads as a fact. ‍

Compliance content answers the question of when an obligation starts. For the serious incident reporting duty in the AI Act, the honest answer is that it is disputed, and the dispute is not a failure of research. ‍ Two readings of the text point in different directions, neither is obviously wrong, and no authority has resolved it. What follows is the reasoning on both sides and what to do without picking one. ‍

An outage is normally modeled as deferred revenue. Production stops, orders wait, operations resume and some of the backlog is recovered by running longer. ‍ Where the inventory perishes, none of that applies. The stock is destroyed during the incident, restoring the systems does not bring it back, and running longer afterward produces new product rather than recovering the old. ‍

A trained model is expensive to produce, cheap to copy and impossible to recall. Where one is taken, the organization still holds it, and the loss is not that the asset is gone. ‍ What ends is exclusivity. Lost exclusivity is a different quantity from a destroyed asset, it carries no notification obligation, it appears in no breach cost dataset, and most estimates therefore put it at zero by omission rather than by judgment. ‍

Transitional relief normally works one way. A new rule arrives, existing products are carved out or given years, and anything built afterwards complies from the start. ‍ The marking obligation for synthetic content inverts that. Article 50 has applied since 2 August 2026, and a targeted transitional period gives extra time to systems that were already on the market rather than to new ones.

A session to a sanctioned AI provider looks the same on the network whichever account it ran under and whatever was in it. Transport encryption means a proxy sees a connection to an approved domain and a payload size. ‍ Which is fine until somebody asks whether an exposure is reportable. The question turns on three facts the network never held, and none of them can be reconstructed from a log afterward. ‍

Cyber risk in transport is usually framed around a collision. Signals manipulated, a train sent onto occupied track, an accident caused deliberately. ‍ Signalling is built to make that outcome unavailable. Any failure forces the system into its most restrictive state, so a compromise produces a halt rather than a crash. The loss is the halt, and rail is unusual in already having a published price for one. ‍

A cyber loss model has dozens of inputs and every one of them can be argued about. Record counts, downtime costs, control effectiveness, secondary loss factors, event likelihoods. ‍ A few of them determine the answer and the rest barely move it. Knowing which is which tells you where estimation effort belongs, and more usefully which disagreements about the model are not worth having. ‍

A model produces a figure, an event happens, and somebody asks whether the figure was right. It is the obvious question and it has almost no published answer, because the comparison is harder than it looks. ‍ A single realized loss cannot falsify a distribution. If a model puts a one percent chance on exceeding a threshold and the threshold is exceeded, the one percent case occurred, which is what the model said would sometimes happen. ‍