Categories

Latest

Industries

Featured

Products

Work with us

Navigation

Insights

Connect

AI Leadership· · 8 min read

AI Turns Cybersecurity Into a Timing Problem

The new risk is exposure latency: the lag between a changed attack surface and the moment leaders can see it, decide who owns it, and act.

AI Turns Cybersecurity Into a Timing Problem

The cybersecurity question boards ask most often is still too static: are we protected?

The better question for the AI era is: how long are we blind after our exposure changes?

Call that gap exposure latency. It is the time between a meaningful change in the company’s attack surface and the moment the organization can see it, understand who owns it, decide what to do, and act. A new model connected to production data. A vendor adding an AI feature to software already inside the perimeter. An agent gaining permission to take action across systems. A development team using AI to generate code at a different pace than review can absorb.

None of these changes has to be reckless to create risk. The problem is not only the exposure. It is the lag.

AI compresses the attacker’s clock

Security teams already live with asymmetry. Attackers need one opening. Defenders need a working view of many systems, many workflows, and many human habits.

AI worsens that asymmetry by compressing the cost of exploration. Reconnaissance gets cheaper. Code analysis gets faster. Social engineering becomes easier to personalize. Vulnerability research can be automated more aggressively. A five-day task becoming a five-hour task changes the economics of an attack even if the underlying techniques are familiar.

Anthropic’s April 7 cybersecurity assessment of Claude Mythos Preview is an early signal of that operating environment. Anthropic said the model could identify and exploit zero-day vulnerabilities in major operating systems and browsers when directed to do so. The company also said more than 99 percent of the vulnerabilities it had found were not yet patched, limiting what it could disclose.

The board-level takeaway is not that one model is uniquely dangerous. It is that vulnerability discovery is becoming more automated, and the window between weakness and exploitation is shrinking.

If the attacker’s clock is compressing, the company’s clock has to be measured differently.

AI also changes the inside

The more interesting risk is internal.

AI adoption changes the attack surface from the inside out. Employees paste sensitive context into tools. Product teams attach retrieval systems to internal knowledge bases. Engineers accept generated code. Finance teams experiment with agents that move across spreadsheets, email, and business systems. Vendors quietly add model-powered features to tools that procurement approved years ago.

Each move may be rational in isolation. Together, they create a live attack surface that most companies do not map well.

Traditional cyber dashboards tend to show systems, vulnerabilities, tickets, incidents, and compliance status. Those are still useful. They do not show the full AI-era surface:

  • Which models can touch which data.
  • Which agents can take which actions.
  • Which retrieval sources feed which workflows.
  • Which vendors have introduced model access.
  • Which business processes now depend on probabilistic outputs.
  • Which human reviews are still meaningful, and which have become symbolic.

Without that map, executives discuss “AI risk” as if it were a general mood. It is not. It is a changing set of technical pathways into business damage.

Exposure latency begins there. If leadership cannot see that the surface changed, the timer is already running.

The model supply chain is a useful example. Hugging Face’s Hub documentation warns that loading pickle files can execute arbitrary code, describes repository malware scanning triggered at each commit, and displays the imports found inside pickled files.1 A 2025 arXiv paper on PickleBall found that 44.9 percent of popular Hugging Face models still used pickle, and 15 percent of those models could not be loaded by restrictive policies.2 That is the kind of surface traditional cyber dashboards miss: the risk is embedded in the artifact a team imports.

The missing owner creates the lag

Most exposure latency is organizational, not technical.

When a model gets connected to production data, who can approve it? When a vendor introduces a new AI feature, who reassesses the changed exposure? When a useful agent needs broad permissions, who decides whether the business value justifies the risk? When a security team recommends pausing a workflow, who has the authority to absorb the operational cost?

In many companies, those questions sit awkwardly across the chief information security officer, chief technology officer, data team, legal team, procurement, and the business owner trying to ship. Everyone owns part of the risk. No one owns the decision.

That ambiguity is the lag.

Decision rights are not bureaucracy in this context. They are a security control. A named owner reduces the time between detection and action. A vague committee increases it.

The same pattern appears in platform governance: policy can handle routine cases, but boundary cases need visible reasoning and someone authorized to make the call. AI cyber risk creates more boundary cases because the exposure often sits between product design, data access, vendor behavior, and security posture.

A useful metric has four parts

Exposure latency sounds abstract until it is broken into intervals.

First is detection latency: how long it takes to know a relevant exposure changed. A new model integration, data connector, agent permission, vendor capability, code path, or exploit signal.

Second is interpretation latency: how long it takes to understand why the change matters. Which data is affected? Which workflow depends on it? What business damage could follow? Is the risk theoretical, plausible, or already active?

Third is decision latency: how long it takes for the right person to choose. Approve, constrain, redesign, pause, monitor, or shut down.

Fourth is remediation latency: how long it takes to make the chosen change real.

Most companies measure the fourth interval more naturally than the first three. They track patch times, incident response, ticket age, and control closure. AI makes the invisible intervals more important. A company can remediate quickly after a finding and still carry dangerous exposure latency if it takes weeks to notice that a workflow changed.

That is why “more cybersecurity spend” is an incomplete answer. Spend can buy tools, talent, and monitoring. It does not automatically compress the path from exposure to decision.

AI belongs in the defense, but not as a substitute for judgment

The response cannot be to slow AI everywhere. The same class of tools that makes attackers faster can also make defenders faster.

AI can help security teams scan code, summarize logs, triage alerts, draft detection rules, generate test cases, compare configurations, and prioritize patching based on exploitability. The best use is not as a magic analyst. It is as a way to push security work upstream, closer to architecture and code before systems are exposed.

That matters because exposure latency is not only about responding after something goes wrong. It is about noticing that the design of a workflow is producing risk faster than the company can govern it.

Google’s Big Sleep is the defensive version of the same compression. Google says the agent, developed by Google DeepMind and Project Zero, discovered CVE-2025-6965, a critical SQLite vulnerability known only to threat actors and at risk of being exploited; the company framed the result as threat intelligence plus AI-assisted discovery cutting off the issue before it was used.3

A repeated vulnerability pattern should change architecture, not only tickets. A risky agent permission should trigger workflow redesign, not only monitoring. A vendor’s new model access should reopen the risk review, not wait for renewal. A model connected to sensitive data should create a decision record before it becomes infrastructure.

The most important AI capability here is still human judgment. AI can shorten detection and interpretation. Humans still own prioritization, authority, and trade-offs.

What boards should ask instead

The board does not need to become a technical review body. It needs better questions.

Not: How many vulnerabilities do we have?

Ask: Which AI-connected workflows could create the most business damage if compromised or misused?

Not: Are employees using approved tools?

Ask: Where can sensitive data now travel that it could not travel 90 days ago?

Not: Did security review this system?

Ask: What changed since the last review?

Not: Who is responsible for cybersecurity?

Ask: Who can pause an AI-connected workflow when the risk picture changes?

Not: Are we using AI for defense?

Ask: Which parts of detection, interpretation, decision, and remediation are still too slow?

The shift is subtle but important. The board stops treating cybersecurity as a stock of risk and starts treating it as a rate of change. That is closer to how AI adoption actually behaves.

The operating model

The practical version is simple.

Map the AI-related attack surface: tools, models, agents, data flows, permissions, vendors, and business processes. Rank the areas by business damage, not by technical novelty. Assign decision rights before a boundary case appears. Track the four forms of exposure latency. Use AI defensively to compress detection and interpretation, but keep accountable humans close to the decision.

The hard part is cadence. A company that reviews cyber risk quarterly while its AI toolchain changes weekly is choosing not to see the gap.

Jamie Dimon put the tension plainly on JPMorgan Chase’s April 14 earnings call: cyber risk was already one of the bank’s largest risks, AI was making it worse and harder, and AI was also creating better ways to strengthen defenses. That is not a contradiction. It is the operating environment.

. . .

The AI-era cybersecurity metric that matters most may not be the number of vulnerabilities, tools, or blocked attacks. It may be the length of time the company spends unaware, undecided, or unable to move after its exposure changes.

Exposure latency is where the real risk hides. Not because leaders do not care about cybersecurity, but because their organizations often see the new surface after it has already become normal.