AI Vulnerability Management: SLAs and Patching for Foundation Models

Treat AI vulnerabilities as enterprise flaws with different remediation paths

AI vulnerability management should extend enterprise vulnerability management rather than replace it. The main difference is that remediation is often not a conventional patch. Security teams may need to upgrade or replace a model, revise a system prompt, restrict a tool, change retrieval data, adjust guardrails, reduce agent permissions, apply runtime policy controls, or formally accept residual risk with monitoring.

Build the severity model around exploitability, exposure, and agency

A useful severity model should reflect whether the weakness is reachable, whether sensitive data or high-impact actions are exposed, and whether an AI agent has authority to act through tools, connectors, or autonomous workflows.

Set practical AI security SLAs

AI security SLAs should be risk-based and operationally practical. They should account for active exploitation, sensitive data exposure, agent authority, compensating controls, and the governance required for any deferred remediation.

• Prioritize active exploitation: Findings with demonstrated exploitation, reachable input paths, or known bypasses should move ahead of theoretical issues.
• Accelerate sensitive data exposure: Shorten due dates when prompts, responses, retrieval results, logs, or connectors can expose regulated or confidential data.
• Account for agent authority: Agents with write access, external tools, or autonomous actions need stricter SLAs than read-only assistants.
• Recognize compensating controls: Runtime blocking, tool disablement, access restriction, and monitoring may reduce urgency but should be time-bound and documented.
• Require exception expiry: Deferred remediation should have business approval, residual risk, monitoring requirements, and an expiration date.

Define remediation paths before the first urgent finding

Foundation model patching rarely follows a single path. Some providers support model version controls, automatic updates, or deprecation timelines. Other cases require the enterprise to change the application around the model. Teams should define standard remediation choices in advance so every finding does not become a one-off negotiation.

For provider-driven issues, the usual response is to evaluate the recommended model version or replacement model in a pinned test environment, run security and functional regression tests, then promote the deployment through change control. For application-level issues, the fix may be narrower: change a system prompt, remove unsafe instructions, sanitize retrieval data, restrict connector scope, reduce tool permissions, or add output handling checks. For agent risks, the fastest safe mitigation may be disabling write actions, requiring tool approval, or routing high-risk actions through policy enforcement.

Design for safe foundation model patching and rollback

1. Maintain an AI asset inventory

   The architecture of the AI application determines whether vulnerability remediation is safe and fast. Start with an AI asset inventory that maps each application to its provider, model name and version, deployment region, prompts, tools, connectors, retrieval sources, guardrails, owners, and data classification. Without this inventory, teams cannot reliably answer whether an advisory or red-team finding affects production.

2. Separate model invocation from tool execution and data access authorization

   Separate model invocation from tool execution and data access authorization. This makes it possible to restrict high-risk actions without shutting down the entire application. For example, an agent can remain available for low-risk responses while write tools, sensitive connectors, or external actions are disabled pending remediation. Least privilege should apply to agent identities and tool permissions just as it applies to human and service identities.

3. Use version-pinned test environments where possible

   Use version-pinned test environments where possible to compare the current and candidate model versions. Regression testing should cover both security behavior and business function because a model upgrade or guardrail change can affect refusals, task completion, latency, cost, and output quality. A fix that blocks the exploit but breaks the core workflow may still be operationally unacceptable.

4. Capture privacy-aware evidence

   Logging should capture enough privacy-aware metadata to reconstruct decisions: prompt and response identifiers, tool calls, guardrail outcomes, policy decisions, model version, connector use, and deployment time. The goal is not to store unnecessary content. The goal is to verify that the vulnerable path was active, the control was changed, and the exploit path no longer succeeds.

Maintain audit evidence and governance records

Audit records should make remediation decisions explainable after the fact. At a minimum, records should connect severity, SLA, remediation path, compensating controls, exception approval, and closure evidence to the affected AI assets and the controls changed during remediation.

For runtime, model, prompt, tool, connector, retrieval, or guardrail changes, evidence should support a clear answer to three operational questions: whether the vulnerable path was active, which control changed, and whether the exploit path no longer succeeds.