Patch and Upgrade SLAs to Require from a Self-Hosted AI Control Plane Vendor

Why self-hosted software changes the contract

When AI policy enforcement software runs in your own cloud, you own the deployment and the vendor owns the code. In a SaaS model, patching risk transfers to the vendor. In a self-hosted model it does not, because your team installs, tests and operates the software. If the contract is silent, each party can reasonably assume the other is responsible.

The stakes are high because this software sits in the execution path of production AI. A vulnerable or outdated enforcement layer is a vulnerable dependency on every model call and tool call it mediates. OWASP's supply chain guidance for LLM applications lists vulnerability scanning, management and patching of components, and recommends a patching policy for vulnerable or outdated components. Its Q1 2026 exploit round-up goes further and recommends emergency patch SLAs for AI frameworks and secure defaults around MCP integrations.

NIST's supply chain risk guidance (SP 800-161r1) advises writing cybersecurity supply chain requirements into supplier contract language rather than relying on policy alone. That is the approach here: convert each expectation into a measurable term.

Severity-tiered windows: separate mitigation from remediation

NIST SP 800-216 distinguishes short-term mitigations, such as a recommended configuration change, from fuller remediation, which may be a patch, fix or upgrade. A useful SLA mirrors that split by defining two clocks per severity tier: time to an interim mitigation and time to a released fix.

Published guidance gives no universal durations, so the numbers should come from your own vulnerability management policy. Ask the vendor to commit to windows that are at least as strict as your internal targets for the same severity. Then pin down the mechanics that make the numbers enforceable:

How the vendor assigns severity, and whether you can dispute it. When the clock starts (confirmation of the issue, or first report) and when it stops (fix released, or fix available to you). How elapsed time is reported to you. What happens on a miss, such as escalation, service credits or termination rights.

OWASP also treats configuration fields in AI systems as potential code paths, not just settings. For that reason, require each advisory to state whether a configuration change is a valid interim mitigation and what residual risk remains.

A draft clause might read: "For vulnerabilities rated [tier], Vendor will provide a documented mitigation within [X] hours and a released remediation within [Y] days of [clock start event]." The bracketed values are yours to set.

Support windows, end of life, backports and rollback

Severity windows mean little if the version you run is no longer supported. Require a published policy that names which releases receive security fixes, for how long, and how much notice you get before a release reaches end of life. Because no standard duration exists, define the minimum support period against your own upgrade cadence and change-approval cycle.

Backporting needs an explicit answer. NIST SP 800-216 says that if an owner chooses not to remediate all supported versions, it should provide a reasonable upgrade path to a version that has remediations. Turn that into a term: either the vendor patches every supported version, or it provides a documented upgrade path to a fixed version, with a stated notice period and migration guidance.

For breaking changes, require advance notice with a defined lead time, plus release notes that identify changes to configuration, policy format, APIs and dependencies. Compatibility with your models, agents, tools and MCP servers is not something a generic standard will define for you, so the contract should. Ask the vendor to state which integration points are covered by compatibility commitments and how it will communicate changes to them.

Rollback should be a contractual expectation, not an afterthought. Require that a prior supported version remains available, that upgrade steps are reversible or that a tested downgrade procedure is documented, and that the vendor supports you if a rollback is needed after a failed upgrade.

Splitting responsibility in a self-managed deployment

NIST describes patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. The vendor produces and distributes fixes; your process covers testing, deployment and verification. Write each step against a named party so no step is left to assumption.

• Identify and disclose: Vendor: monitors, triages and discloses vulnerabilities in its code and dependencies. Customer: monitors its own environment and consumes advisories.
• Provide the fix: Vendor: releases the patch or upgrade, with documentation and an advisory. Customer: acquires it through the agreed channel.
• Test compatibility: Vendor: documents tested configurations and breaking changes. Customer: validates against its own models, agents, tools and MCP servers.
• Deploy: Vendor: supplies installation and upgrade instructions. Customer: applies the update inside its cloud under its change process.
• Verify and record: Vendor: supplies a way to verify artifact integrity. Customer: confirms installation and keeps the record.
• Roll back: Vendor: documents and supports the downgrade path. Customer: decides when to invoke it and executes it.

Advisories, signed updates and evidence for auditors

NIST SP 800-216 says owners should in many cases issue advisories that tell users what actions to take, such as which patches to install. Require an advisory with every security fix, covering affected versions, required customer actions, any interim mitigation, and documentation of the fix. Specify when the advisory is issued relative to the patch release, so you are not learning about required actions after the fact.

Update integrity is the second evidence requirement. NIST SP 800-161r1 says assets that need direct supplier updates should only accept updates originating from the OEM, unless the acquirer deploys them through a centralized patch process. OWASP lists pinning and verifying dependencies and signing and scanning updates among its technical defenses. Together these support requiring signed update artifacts delivered directly from the vendor, with dependencies you can verify.

Finally, plan for what you retain. Document your patching and vulnerability policy, keep your emergency patching procedure current, and record verified installations, since verification is part of the patch management process. Ask the vendor for a recurring report showing, for each tier, advisory dates, release dates and elapsed time against the SLA. Retention periods and which regulator expects what should be set with your compliance team. Emerging material such as the draft NIST Cyber AI Profile, which suggests requiring vendors to apply patches to AI frameworks and software libraries, can support your rationale but is not a binding requirement.