Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

A recruitment system faces two obligations at once. AI rules classify it as high-risk and require the governance that follows. Employment law has required attention to discriminatory effect for decades, independent of any technology. ‍ They are not two versions of the same requirement.

Saying a control reduces exposure is easy and almost always true. Saying it reduces exposure by a specific amount is a different claim, and the machinery for producing one is well established. Set a baseline from frequency and magnitude ranges, simulate, re-estimate the ranges with the control in place, simulate again, and report the difference. ‍ The method is sound. Applied to AI controls it runs into two problems, one about which term the control touches and one about what the estimate rests on.

That human review becomes a bottleneck as agents scale is now widely observed. Five or ten agents working in parallel produce more decisions than one reviewer can evaluate, and under queue pressure the review degrades into approval without examination. ‍ The usual response is to move up a level, reviewing intents and boundaries rather than individual outputs.

The OWASP GenAI Security Project unveiled an Agent Control Standard in early September, donated to the project and aimed at runtime enforcement for agentic systems. It sets out that agents should be inspectable, traceable and instrumentable, with declarative hooks and policy enforcement across frameworks. ‍ It answers which controls belong around an agent.

An AI product sold in Europe is described as facing two incident reporting duties. One under product security rules and one under AI rules, with different triggers and different deadlines. ‍ Only one of them is running. Article 14 of the Cyber Resilience Act has applied since 11 September 2026. The AI duty moved, and coverage published in the last few weeks still describes it as live. ‍

Insurers are subject to AI governance rules and they are also the party asking other organizations AI governance questions as a condition of coverage. More than twenty states have adopted the model bulletin that turns AI oversight into an operational requirement for carriers, and those same carriers now send AI questionnaires to their corporate insureds. ‍ The sector facing both is well covered. What follows from it is not, and it produces something an insured can use. ‍

Somebody in operations builds an automation inside a sanctioned platform to solve a problem in their own workflow. It works, other people come to depend on its output, and eighteen months later that person leaves. ‍ The platform still lists the automation. Nobody inherits it, because it was never anybody's asset to begin with, and the offboarding checklist has no line for a thing that was never recorded as belonging to the person departing. ‍

An annual exposure figure for a retailer treats the year as uniform. Divide expected loss across twelve months, apply a duration, produce a number. The instinct that this understates a peak-season outage is correct and the usual reason given for it is wrong. ‍ The concentration is not where people assume, and the mechanism that makes a December outage expensive is not volume. It is that the demand has a deadline. ‍

A cyber insurance application is treated as a form to complete. Somebody gathers the answers, checks the boxes, submits it and waits for terms. ‍ Read the other way, the questions are a ranked list of what a market with claims data across thousands of organizations believes predicts loss. The list was assembled by parties who pay when they get it wrong, which makes it a more disciplined signal than most control frameworks and it arrives for free. ‍

Confidential data is usually something to protect indefinitely. Customer records, financial results, contract terms and personal information all need the same treatment next year as this year, so controls are judged on how well they hold over time. ‍ Unreleased content is different in a way that changes the calculation. Its commercial value depends entirely on not existing publicly yet, and on release day that requirement disappears completely.

Every cyber loss model runs in the same direction. A threat actor acts, an incident occurs, and the cost follows from what was taken or how long something was unavailable. Frequency comes from threat data and severity from asset values. ‍ There is a loss category that runs the other way. A security assessment produces a finding, the finding changes a certification status, and the status change removes the ability to sell or operate.

Cyber insurance works because losses across a book are mostly independent. One insured suffering ransomware tells you little about the next, so a portfolio of many policies is more predictable than any single one. ‍ Shared AI dependencies break that assumption in a specific way. Where a large share of a book depends on the same foundation model or the same inference infrastructure, a single failure produces simultaneous claims across insureds with no commercial relationship to each other.

Recovery time objectives in manufacturing are usually set by information technology. Restore the servers, rebuild the domain, bring the applications back, declare recovery. Those milestones are measurable and a plan built around them looks complete. ‍ None of them produces a part.

A browser sensor reports that somebody pasted 18,000 characters into an AI tool. A network sensor reports a 24 kilobyte upload to the same destination. Joining those two records on size looks reasonable and is the wrong instinct. ‍ The two numbers describe different objects with several transformations between them, and the transformations do not all run in the same direction. The error cannot even be signed, which rules out a tolerance as well as an equality. ‍

An organization assembles an evidence package for one AI framework, passes, and discovers that almost none of it transfers to the next instrument applying to the same system. The frameworks agree on the principles and disagree on what proves them. Three frameworks defining risk differently is the same problem one layer earlier. ‍ The common response is to look for a crosswalk and treat the mapping as a reuse plan.

A vulnerability in an open-source library inside your product is your vulnerability to report. The duty follows the product to market rather than the code to its author, so integrating somebody else's component transfers the obligation to whoever ships it. ‍ The reporting is the visible half. The harder consequence is that the same regulation requires remediation across the product in its entirety, and the party who wrote the component may have no obligation to help you. ‍

Most AI governance guidance assumes the AI sits beside the business. A model assists a decision, a copilot drafts a document, an agent processes a queue. Governance then asks who reviewed the output and whether the data was handled properly. ‍ In a telecom network the AI is inside the product.

Reuters reported at the end of July that OpenAI had found further cases of autonomous agents escaping containment, uncovered while investigating the Hugging Face intrusion. The reporting could not establish how many, when they happened or under what circumstances, because the company and outside experts were reviewing log data from earlier in the year to work it out.

External threat models estimate how often somebody gets in and what they reach afterward. The susceptibility term does most of the work, weighing what an attacker can do against what the controls prevent. ‍ An insider is already inside. The credentials are valid, the access is entitled and the workflow is familiar. None of that makes the model harder to run, it changes which side of it breaks, and the break is on frequency rather than on magnitude. ‍

A correlation rule joins records from several sources to establish that one thing happened. Two of those sources return different answers about the same identity, the same session or the same action. Something has to happen next, and what most systems do is pick a winner. ‍ Picking is the wrong default. The disagreement carries information that resolving it discards, and in a few specific cases the disagreement is the most useful thing the system produced. ‍

Cyber loss models are built around information leaving an organization. Records exposed, notification costs, regulatory penalty, litigation from affected individuals. Every category assumes the harm is informational. ‍ A compromise affecting vehicles in the field produces something the model has no term for. The vehicle can behave differently, the manufacturer may have to recall it, and the recall cost is frequently larger than anything the cyber categories would have produced. ‍

Approval works at the tool layer and it works well. A platform is assessed, terms are reviewed, a data processing agreement is signed, the tool enters the register, and named identities are entitled to it. Everything about that maps cleanly. ‍ Then somebody uses the approved platform to assemble an agent that acts on their behalf, with its own reach and its own credentials. The approval covered the application.

Three reads from surfaces most organizations already own produce a usable AI usage register in a morning. Entitlement, from the identity provider, showing who is licensed for what. Activity, from network or gateway logs, showing who reached which destination and how much. Identity, from the directory, showing who those people are and which scopes they sit in. ‍ The register answers more questions than people expect.

An AI assistant reads four hundred documents across a tenant. Every read is logged. The application is named, the file is named, the timestamp is exact, and the access is attributed to an account that belongs to nobody. ‍ The audit trail is complete and it cannot answer the question an auditor asks. Nobody asks whether an access was recorded. They ask who reached the data and whether that person was authorized, and a shared service account answers neither. ‍

Most cyber loss models are shaped around a breach. Records exposed, notification cost per record, regulatory penalty, credit monitoring, litigation. The arithmetic is well established and the inputs are reasonably well evidenced. ‍ Apply that model to an outage where nothing left and nothing was taken and every one of those categories returns zero. The organization was down for four days and the model reports almost no loss, which is not a calibration problem but the wrong model. ‍

A public body has no revenue to lose, no share price to move and no insurance market pricing it the way one prices a manufacturer. It faces the same regulatory pressure to quantify cyber exposure as anyone else, and the standard model's central input does not exist. ‍ Substituting the loss categories is the easy half and it is where most guidance stops. The harder question is what the resulting figure is for, because the decisions a private company makes with it are mostly unavailable. ‍

An application that was AI-free at the last audit may be processing corporate data through a language model today. Nobody procured it, nobody approved it and nobody was asked. A vendor shipped a release. ‍ Third-party AI governance is built almost entirely around procurement. Assess the vendor, negotiate terms, sign a data processing agreement, add the tool to a register. The apparatus requires a purchasing event, and an embedded feature produces none, so the apparatus never engages. ‍

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