1
min read

The Runtime Answer to FS-ISAC's AI Vulnerability Discovery Advisory

Date:
Oct 1, 2026
Category:
Security
Product
Author:
Justin McCann

Earlier this year, FS-ISAC released updated Sector Risk Advisory advice for financial institutions to combat the era of AI vulnerability discovery and exploit development. This post walks through the recommendations and maps how Oligo’s runtime context and protection help customers address them.

In general, the constraint for security teams has shifted from finding vulnerabilities to verifying, fixing, testing, and deploying remediations at scale. Frontier AI finds flaws faster and chains bugs into working exploits, collapsing the time between disclosure and attack.

From a high level, the guidance provided by FS-ISAC can be boiled down into three core shifts:

  1. Assume exploitation by default
  2. Compress remediation SLAs
  3. Shift from vulnerability management to exploit prevention

[Full recommendations available here: FS-ISAC: Updated Sector Risk Advisory, Preparing the Enterprise for AI-Enabled Vulnerability Discovery.] 

And here’s the TL;DR of the recommendations Oligo can directly help address:

FS-ISAC recommendations What it asks for How Oligo helps
1 and 3: Remediate and reprioritize Burn down backlogs, move beyond CVSS, compress SLAs Proves which vulnerable functions execute in production
5, 6, and 7: Inventory, EOL, open source Real-time inventory of dependencies and third parties Real-time SBOM and VEX built from what actually runs
2 and 9: Perimeter and exploit prevention Controls that intervene in exploits in progress Function-level exploit blocking and virtual patching
11: Secure AI workflows and agents Traceability across prompts, tool calls, and results Observes the full AI execution chain
4: Accountability and board reporting Exposure reported as operational risk Evidence-based exposure metrics from one runtime layer

Below, we break down each of these recommendations in more detail – why they matter, what FS-ISAC is asking financial institutions to change, and where runtime security fits.

Actions 1 and 3: Better Prioritization + Compress Patch Timelines

The advisory asks institutions to treat vulnerability backlogs as operational risk, move beyond CVSS, and compress remediation SLAs to hours. The challenge is doing that across thousands of findings without overwhelming engineering.

The old model worked when defenders had more time. CVSS told you what could be dangerous, and reachability analysis estimated whether vulnerable code could be called. Teams could afford to debate which findings deserved priority.

That model breaks when exploitation timelines collapse. Neither CVSS nor reachability tells you whether a vulnerable function is actually executing in production today. If every critical finding inherits the same urgent SLA, compressing remediation windows just means more teams drowning faster.

Oligo Runtime Posture replaces estimation with observation. It shows which vulnerable functions are loaded and executed in production, on which services, right now. That deterministic runtime evidence shrinks the problem drastically. For example, our customers typically see a 90–99% reduction in CVE noise within 48 hours and reduce mean time to remediate by up to 10x.

That is what makes an hours-level SLA survivable: apply it first to the short list of vulnerabilities that are actually executing, starting with externally facing services. It also gives the advisory’s call for automated prioritization a signal worth automating on via execution in production.

‍Actions 5, 6, and 7: An Inventory Built from What Runs

The advisory calls for a real-time inventory of dependencies across internal systems, third parties, and AI providers, good enough to support same-day decisions. It also asks institutions to treat open source as critical infrastructure and track direct and indirect dependencies.

Software composition analysis in the pipeline is the right starting point, and the advisory is right to require it. SCA tells you what was declared at build time. It can't see the vendor application you bought, the third-party container you deployed, or what changed after release. Supplier SBOMs help, but they're often incomplete and out of date within weeks.

Oligo builds the SBOM from observation, mapping every library actually loaded in production, including in third-party and vendor applications, with no source code required. VEX statements are grounded in execution, so a "not affected" status is backed by proof that the vulnerable function never executes.

The practical payoff shows up the morning a celebrity vulnerability drops. The questions from leadership are always the same: are we exposed, where, and is it running? Runtime answers all three the same day, which is exactly the same-day decisioning the advisory describes. The same view surfaces unsupported and end-of-life components that are live in production, so replacement work starts with what's actually exposed.

Actions 2 and 9: Prevention Where Exploits Runs

The advisory asks institutions to harden the perimeter and to block exploits in progress with controls that intervene, naming WAFs, intrusion prevention, and runtime application protection. It also asks for playbooks built around fast containment.

Perimeter controls earn their place. CDNs, WAFs, and edge controls filter enormous volumes of hostile traffic and buy detection time. EDR and CNAPP tools give strong visibility into hosts and cloud configuration.

But once a request clears the perimeter and reaches a vulnerable function, none of those tools block there at all. A WAF inspects the request, but it doesn't know what the application does with it. And AI-crafted exploits are increasingly built to look like legitimate traffic.

Oligo's ADR works inside the running application:

  • Detects exploitation as it begins, at the function and syscall level, observed through eBPF. Detection doesn't depend on signature updates, so it holds for zero-days.
  • Blocks only the malicious function. The rest of the application keeps running, with no killed containers or quarantined processes. That matters for any institution weighing the advisory's warning that containment may disrupt service.
  • Blocks at the technique level. One rule stops the exploit pattern behind an entire class of CVEs, including ones with no patch yet.
  • Virtually patches exposed functions while the real fix moves through testing and deployment. 

That closes the gap between a compressed SLA on paper and the pipeline speed you actually have.

The SOC gets the execution context to act: what ran, the call stack that led there, and what the attacker touched next. A function-level exploit detection is also the kind of high-confidence condition the advisory's action 10 says should trigger predefined, automated containment.

Action 11: Watch the Full Agent Execution Chain

AI agents introduce a different kind of security problem: the model making decisions is often the same system being asked to explain what happened.

That is why FS-ISAC calls for traceability across prompts, model versions, tool calls, approvals, and results – and for controls to sit outside the model itself.

A prompt-injected agent can follow a malicious instruction and still produce output that looks completely normal. Controls that rely on the prompt layer inherit the same weakness.

Oligo Runtime AI Security observes the full AI execution chain from outside the model:

  • Prompts that trigger agent actions
  • Tool calls and OS calls the agent makes as a result
  • Outputs the agent produces

Oligo detects prompt injection, agent abuse, drift, and tool calls that deviate from the application’s expected activity. Because observation happens at the function and system-call level, the agent cannot simply explain its way around the control.

AI-SPM also maintains a continuous AI-BOM of every model, agent, and framework running in production and flags misconfigurations, extending that same runtime visibility to the advisory’s inventory requirements.

Action 4: Give the Board A Number It Can Defend

The advisory frames AI-enabled vulnerability discovery as an enterprise risk problem. It asks institutions to hold business and technology owners accountable for remediation, and to report remediation speed and material exposure to the Board as operational risk metrics.

Accountability only works when the data holds up. If you hand a system owner a list of 4,000 findings and the first conversation is about which ones are real, security loses credibility, engineering loses time, and the metric the board sees measures scanner output more than risk.

Runtime evidence ends that argument. A vulnerable function executing in production on a named service is a fact, and owners can be measured against facts. Exposure metrics built on execution give leadership a defensible answer to the question regulators and boards keep asking: what is running in our environment, and is it under attack right now?

Oligo delivers runtime protection, vulnerability management, and AI security from one lightweight sensor, with roughly 1% overhead and no tuning cycles. That means fewer tools to fund and govern, a smaller audit surface, and evidence that supports PCI, SBOM, and VEX requirements without a separate workstream.

The takeaway

FS-ISAC's advisory makes the case plainly: traditional risk cycles were built for a slower threat landscape, and AI has removed that slack. Every action on the list gets easier with one capability most stacks still lack: a real-time view of what's executing in production.

Runtime is where that view lives. It's how you prove which vulnerabilities matter, block the exploits that reach your applications, see what your agents actually do, and report exposure your board can trust.

Stop modern attacks and keep your business moving

Request a demo
Request a demo
→
→