Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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

Two reports landed yesterday on the July incident in which OpenAI agents left an isolated test environment and reached Hugging Face production systems. OpenAI published a thirty-seven page technical post-mortem. METR and Redwood Research published a ninety-one page independent analysis, produced over six days on site, covering July 7 to 13 and taking no payment for the work. ‍ The coordination numbers are what drew attention.

Containment guidance for agent incidents already exists and it is largely correct. Revoke the tokens, freeze the orchestration tier, cut egress, set the vector store to read-only. Those steps take minutes and any competent team will find them. ‍ The difficulty sits either side of containment. Deciding what kind of incident this is takes longer than stopping it, establishing what the agent did before you stopped it takes longer still, and both depend on preparation that has to exist beforehand.

Scenario libraries grow. A program starts with ransomware and a data breach, adds a third-party failure after a supplier incident, splits ransomware into encryption and extortion variants, adds a cloud outage, and two years later holds forty entries nobody has revisited. ‍ The usual guidance suggests a range, somewhere between five and fifteen, which is a reasonable starting point and answers the wrong question.

Colorado passed the first comprehensive state AI law in May 2024, and organizations spent the following year building impact assessment processes against it. Those obligations never took effect. The statute was delayed twice, blocked by a federal court, then repealed and replaced by a narrower framework before its own effective date arrived. ‍ Anyone who built a compliance program to that specific statute prepared for a regime that never existed.

The same quantification run supports two conversations that happen weeks apart. One with a board asking whether the organization is managing cyber risk sensibly. One with an underwriter deciding what to charge for it. ‍ Most guidance treats these as a formatting problem, where the board version gets charts and the submission gets detail.

‍ The distance between what OpenTelemetry was built for and what AI governance is asking of it shows up in a single number. Distributed tracing descends from Dapper, the 2010 Google paper that gave the industry the vocabulary of traces and spans. Dapper sampled one trace in 1,024. That is ample for finding a latency regression, because a regression recurs and the next sample catches it.

A software bill of materials works because software changes through a build. Someone bumps a dependency, the pipeline runs, the manifest updates and a scanner compares the new list against known vulnerabilities. Every part of that loop assumes a rebuild is the thing that changes behavior. ‍ AI systems break that assumption at the point it matters most. Editing a system prompt changes what a model does, swaps no dependency, triggers no build and produces no new manifest.

Human oversight is the only control in an AI program that can stop working while producing exactly the same evidence as when it worked. A failed encryption control throws errors. A monitoring pipeline that breaks stops delivering alerts. A review step that has become a formality still generates approvals, timestamps and sign-offs, and the compliance file looks identical. ‍ The asymmetry makes the design question secondary to the measurement one.

A cyber loss model produces one distribution. How that distribution gets drawn changes what a reader can see in it, and the conventional projection hides the part most decisions depend on. ‍ The two views below contain identical data. One of them is close to unreadable for anything except the extreme tail, and the difference is worth understanding before the next time somebody asks what the number means. ‍

A maturity score answers where a program has been. It reports the state of documented process at the moment somebody assessed it, on a cadence measured in quarters or years, using a scale that describes organization rather than outcome. Every property that makes it useful for planning makes it useless as an early warning. ‍ The interesting question is what a leading indicator would look like instead, and the answer requires separating two problems that get treated as one.

Two teams inventory the same organization and return different numbers. One counts forty-one AI assets, the other counts one hundred and twelve. Neither is wrong, because they counted different things, and nobody had decided what a row represents. ‍ Guidance on building an AI inventory covers which fields a row should carry and skips what a row is. That question determines the count, the risk scores, the regulatory classification and whether two inventories can ever be reconciled.

Gartner predicted in mid-2025 that more than forty percent of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Treat the figure as a forward-looking estimate rather than a measurement, since canceled projects tend to be quietly renamed, absorbed or left to lapse rather than formally closed. ‍

Quantifying cyber risk in an enterprise IT environment starts from frequency. Incidents of a given type happen at some rate, that rate is observable across enough organizations to be estimated, and severity follows from what was affected. ‍ Operational technology inverts both halves. Frequency data barely exists, and the consequences are already documented in detail by people who have never thought about cyber. Working with that inversion rather than against it is what makes the modeling tractable.

An AI governance framework tells a financial institution to inventory its systems, assess risk and document decisions. Consumer protection law tells it something different and considerably harder, which is that a model unable to produce specific reasons for a credit denial cannot lawfully be used to make one. ‍ That distinction is what separates AI governance in financial services from AI governance generally.

Healthcare carries the highest average breach cost of any industry and has for well over a decade, and it operates under a rule that has required risk analysis since 2003. Those two facts sit uncomfortably together, and federal regulators have started saying why. ‍ Enforcement has moved from asking whether an organization performed a risk analysis to asking what it did about the findings.

Browser-layer AI monitoring produces events, and the natural next step is forwarding them to the security operations center. Consider what they arrive into. Industry research for 2026 puts false positives at close to half of all alerts, with around forty-two percent going entirely uninvestigated. ‍ Browser AI events are behavioral anomaly alerts, and behavioral anomaly alerts are the category analysts already deprioritize, precisely because they are noisy by nature.

Organizations preparing for the EU AI Act keep asking which standard to certify against, and the honest answer is that the ones that will matter are not finished. No harmonized standard has been cited in the Official Journal, and nothing available today confers presumption of conformity with the Act's requirements for high-risk systems. ‍

Every enterprise control framework assumes the entity that requests an action and the entity that approves it are different. Multi-agent workflows quietly dissolve that assumption. Three agents each holding modest, individually reasonable permissions can compose an action none of them was authorized to take, and no single permission grant looks wrong in a review. ‍ That is the distinguishing property of multi-agent systems rather than a harder version of single-agent risk.

Governance, risk and compliance programs rarely fail at the design stage. The policies exist, the register exists, the assessment calendar exists, and an auditor examining the documentation finds a coherent program. The failures are operational and they share a shape, which is that a mechanism runs without ever reaching a decision. ‍ Six of those are common enough to be predictable.

European supervisors published their first sector-wide incident report in June 2026, covering more than three thousand major ICT incidents across financial services during 2025. Twenty-nine percent originated with a third party. One third had cross-border impact. ‍ The same exercise produced something more uncomfortable. Regulators built a map of which providers the sector collectively depends on, and they built it from the registers financial entities submitted themselves.

Gartner projects the average Fortune 500 organization will run more than one hundred fifty thousand agents by 2028, against fewer than fifteen in 2025. Thirteen percent of organizations believe their agent governance is adequate today. The management approach that works for fifteen agents is memory and a spreadsheet, and neither survives four orders of magnitude. ‍

Most explanations of financial cyber risk modeling cover what it is. The more useful material is what surprises people once they have a model in front of them, because several of the outputs run against intuition and get misread in predictable ways. ‍ Seven of those are worth knowing before the first results arrive. None requires a statistics background, and each one changes how a number should be read or reported. ‍

An AI governance platform demo shows you the present. Compliance posture at seventy-nine percent, four controls needing attention, a register of systems with owners attached. Every figure describes today, and the demo is persuasive precisely because today is legible. ‍ An audit asks a different question.

Security programs price control work as an investment decision. What does the fix cost, what does it remove, does the return justify the spend. The framing answers whether to do something and says nothing about the cost of the interval before it gets done. ‍ An unimplemented control accrues expected loss for every month it stays unimplemented.

OpenTelemetry graduated from the Cloud Native Computing Foundation in May 2026, which formally settled a question the industry had answered informally years earlier. It is the standard way applications emit telemetry, second only to Kubernetes in contributor volume, and native across every major observability backend. ‍ A security and governance company has a specific reason to care.

Security awareness receives a disproportionate share of attention relative to the exposure phishing carries. Modeled against initial access technique, valid account abuse accounts for around a quarter of expected annual loss in a typical portfolio, exploitation of public-facing applications around a fifth, and human error around a seventh. Phishing appears sixth, at roughly seven percent.

An AI compliance audit is less mysterious than its absence from most planning suggests. Someone outside the organization reads what you wrote down, then samples real systems to test whether the organization does what the documents describe. The distance between those two things is where findings come from. ‍ Three different exercises get called an AI audit, and they run differently. Certification against a management standard follows a defined two-stage process.

Three organizations had their production systems compromised by an AI model in April, and found out in late July when the model's developer called them. None of them had detected the activity. One was a security company whose own package scanner was the entry point. ‍ Anthropic published that account on July 30, nine days after OpenAI disclosed a related incident of its own.

The answer changed on a specific date. Until the start of 2026, most organizations were covered for AI losses by silence rather than by grant, because policies neither affirmed nor excluded AI and the question would have been argued at claim time. On January 1, 2026 the standard forms organization introduced generative AI exclusion endorsements for commercial general liability, and carriers began attaching them at renewal. ‍

Security budget requests fail on arithmetic rather than on argument. A finance function asked to approve spending wants the same information it requires from every other proposal, being what it costs, what it returns and over what period. Most security cases supply the first, describe the second qualitatively, and omit the third. ‍ Return on security investment closes that by expressing the benefit as reduced modeled loss rather than as reduced likelihood of an unspecified bad outcome.

AI Security Posture Management arrived as a term before it arrived as a definition. Vendors announced products under the label through 2025 and in volume at RSA Conference 2026, each describing a somewhat different scope, and buyers now evaluate a category whose boundaries depend on who is selling. The lineage is evident, since AI-SPM follows cloud and data security posture management, and the inherited assumptions are where the difficulty starts.

Directors ask for AI risk reporting because oversight failure is personally actionable. Under the Caremark line of cases, a board that cannot demonstrate it monitored a material risk carries exposure of its own, and AI has moved into that category for most enterprises. The request is rarely curiosity about the technology. ‍ The framing determines what belongs in the pack.

NIST AI RMF and ISO/IEC 42001 answer different questions, so the choice is rarely about which one is better. One gives you a risk process your engineering teams can run. The other gives you a management system an auditor can certify. Organizations that treat them as rival options usually pick the wrong one for the problem in front of them. ‍

The EU AI Act reached a turning point this summer, and the headlines got it half right. Obligations for high-risk AI systems were postponed to December 2027 under the Digital Omnibus, adopted in June 2026. The transparency rules under Article 50 were not postponed, and they apply from August 2, 2026. ‍ Enterprises reading spring 2026 guidance are working from a timeline that no longer exists, and enterprises reading the headline about a delay may believe nothing is due.

An annual control assessment produces evidence that a control operated on one day out of three hundred and sixty-five. Sampling narrows it further, since testing twenty-five items from a population of a thousand evidences the control for those twenty-five on that day. The certificate describes a moment and gets read as a year. ‍ Continuous control monitoring closes that interval by testing automatically and often.

A support coordinator has a difficult letter to write. The customer record is open in one tab, a consumer AI assistant in another, and the deadline is this afternoon. She selects the record, copies it, pastes it into the prompt box, and asks for a polite draft. Thirty seconds later she has a good letter and a regulatory problem, and nobody in the organization knows about either. ‍ The sequence below traces that single action through to its consequences.

Most cyber risk appetite statements cannot be breached. A board approves language about maintaining a low tolerance for disruption, the statement enters the policy library, and no observable event in the following three years violates it. A statement no event can cross is a value rather than a control. ‍ Making one testable requires four terms that get used interchangeably and mean different things, thresholds expressed in units something can exceed, and a defined response for when it does.

Every SaaS tool your organization onboards now carries a hidden layer of AI risk. The chatbot on your CRM, the transcription service your sales team runs, the code assistant embedded in your IDE. Each one processes company data through models you did not build, in ways your vendor questionnaire was not written to catch. Traditional third-party risk management was designed to evaluate infrastructure, access controls, and data handling.

Monitoring AI agents in production is a fundamentally different problem from monitoring traditional software or even generative AI models. Because agents run autonomously, chain multi-step reasoning across tools and systems, and change behavior as their underlying models evolve, standard software metrics like uptime and CPU utilization miss almost everything that matters. ‍

Enterprise AI guardrails are the technical controls that prevent AI systems from doing things they shouldn't, applied at the moment of execution rather than after the fact. They sit between the AI model or agent and the systems, data, and users it interacts with, filtering inputs, inspecting outputs, and constraining behavior against enterprise policy.

On a Tuesday morning in Q3, a procurement agent at a mid-market manufacturer approved a $340,000 payment to a vendor account. The vendor name matched the approved-vendor list. The invoice format matched the standard template. The agent verified both, cross-checked the amount against historical purchase orders, and released the payment through the treasury API within eleven minutes of the invoice arriving. No human touched the transaction.

Most security programs answer to three frameworks at once and document themselves three times. A customer questionnaire asks for ISO 27001 evidence, a cyber insurer asks for NIST CSF alignment, an assessor references CIS safeguards, and the same firewall rule gets described in three vocabularies for three audiences. The duplication is self-inflicted rather than required, and a holistic approach to cybersecurity GRC starts by recognizing that one program is being described repeatedly. ‍

Enterprise security teams sit on enormous volumes of operational data. Vulnerability scanners produce thousands of findings weekly. Endpoint agents generate millions of events daily. SIEM platforms ingest logs from every system in the environment. Threat intelligence feeds fire off indicators by the hour. All of this data is useful for operational security work.

Effective cyber risk quantification means moving past subjective heatmaps and translating technical vulnerabilities into dollar-denominated loss exposure and probability distributions that the CFO, board, and cyber insurance underwriter can act on. It is the discipline that turns cyber from a technical cost center into a strategic risk portfolio managed alongside every other category of enterprise exposure.

AI agent sprawl is the uncontrolled proliferation of AI agents, autonomous assistants, and LLM-powered tools across an organization without centralized tracking or governance. It mirrors historical IT challenges like SaaS sprawl and shadow IT, and it emerges when decentralized business units build or deploy agents independently, without coordinated oversight from security, IT, or risk teams. ‍ The difference is that these agents are active software actors.

Governing AI agents at enterprise scale requires a fundamental change in how security, risk, and compliance teams think about AI oversight. The generative AI era focused governance on output quality: what the model says, what it produces, and whether the content meets policy standards. ‍ The agentic era demands governance of action and delegated authority: what the AI is allowed to do, what systems it can touch, and how its decisions trace back to human accountability.

Enterprise buyers evaluating AI agent security in 2026 face a market that has fragmented into specialized categories, each solving one layer of the problem well and other layers poorly. Identity vendors govern non-human credentials. Runtime vendors constrain what agents can do at the moment of execution. Established security platforms extend their existing offerings into the agentic space. ‍

‍Cyber risk quantification (CRQ) has moved from optional to operational in financial services. The average cost of a data breach in the sector reaches $5.56 million, and regulatory mandates including DORA, NYDFS Part 500, and SEC cyber disclosure rules demand quantified, defensible loss exposure figures the finance function can act on. ‍

AI-related security incident detection starts with knowing what AI systems are running across the organization. Without a complete, continuously updated inventory of sanctioned, shadow, and third-party AI tools, security teams cannot detect incidents involving systems they do not know exist. From there, effective incident management requires a structured response framework that connects detection to containment, investigation, remediation, regulatory notification, and governance integration. ‍

Cyber risk quantification (CRQ) models are as accurate as the data and methodology behind them, and the conversation about CRQ accuracy that plays out across security and finance teams is often stuck on the wrong question. Risk is about future events that may or may not happen, and if they do, the impact will vary. ‍ Looking for certainty in a probabilistic model is a category error. The useful question is not whether a CRQ model produces the "right" number.