AI Dependency Quarantine

Technical reference. This page is for integrations, advanced configuration, or platform operations. For portal tasks, start with the user guide.

An AI dependency quarantine record marks a governed AI dependency — a provider SDK, provider proxy route, MCP server, connector sidecar, runtime helper package, runtime image, or external-runtime adapter — as compromised, suspect, or under watch. Active records are matched against the dependency metadata bound to a release at activation time, so an operator can block, warn, or require review before a matching release goes (or stays) live.

Quarantine matching uses stored record metadata only. It runs no scanner, no package-manager resolution, no advisory-feed lookup, and no signature verification in the release path; those signals are captured upstream and recorded on the record. Matching is therefore deterministic and offline.

Lifecycle states

Status	Meaning
`watch`	Tracked, not yet blocking; surfaces as an advisory.
`quarantined`	Active; matched dependencies are denied / warned / sent to review per the record’s effect.
`override_allowed`	An operator vetted the match and allows activation despite it.
`remediated`	The underlying issue is resolved.
`reenabled`	A remediated dependency has been returned to normal service.

Activation effects

A quarantined record carries a default_activation_effect that decides what happens when an active release matches it:

Effect	At activation
`deny_new_activation`	Blocks the transition (HTTP 422) and records a denial audit.
`operator_review_required`	Blocks and routes the release to operator review.
`warn`	Allows activation but records a non-blocking advisory.

Stale records (past their review_after date) escalate advisories to blocking review, and an unrecognized effect fails closed to review — the matcher never fails open.

Operator actions

All actions require the ai_dependency_quarantine.manage permission and a reason, which is recorded in the durable governance audit receipt. The transitions are forward-only; the control-plane rejects an invalid transition with HTTP 409.

Override-allow — vet a match and permit activation (override_allowed).
Remediate — mark the issue resolved (remediated).
Re-enable — return a remediated dependency to service (reenabled).

Affected-release lookup

The affected-release view answers “which active releases would this quarantine hit?” It reuses the exact activation-time projection and matcher, so the impact view never disagrees with what activation enforces: errors are blocking matches, advisories are non-blocking. It requires both ai_dependency_quarantine.read and release.view so it cannot leak release inventory to a reader without release visibility.

Emergency disable (runtime kill-switch)

Emergency disable is an active runtime action, distinct from passive activation denial: it stops the running executions of operator-chosen workloads under a quarantine. It is deliberately gated:

the record must opt in with emergency_disable_allowed = true (else HTTP 403);
it requires ai_dependency_quarantine.manage and an explicit workload_ids target plus a reason;
every target must belong to the workspace — a foreign workload id is refused (HTTP 404) and no kill signal is sent.

Dispatch is best-effort and the response separates outcomes: disabled_workload_ids were stopped, and failed_workload_ids are targets whose signal could not be dispatched. A non-empty failed_workload_ids on a 200 is a retry condition, not a full success — re-issue the disable for just those workloads. If nothing could be disabled, the call returns HTTP 503 and writes no receipt.

Permission model

Permission	Grants
`ai_dependency_quarantine.read`	List records and run the affected-release lookup.
`ai_dependency_quarantine.manage`	Author records and run every operator action.
`release.view`	Additionally required by the affected-release lookup.

Evidence and audit

Every authoring and operator action emits an immutable, hash-chained governance audit receipt (ai_dependency_quarantine.created, .override_granted, .remediation_recorded, .reenabled, .emergency_disabled). Activation denials and advisories are recorded on the release transition audit. These receipts are the record of action; there is no separate evidence artifact for record-scoped quarantine actions.

Surfaces

The same control-plane API backs every surface:

Portal — Monitor › Operate › Dependency quarantine: list and filter records, inspect affected releases, and run operator actions and emergency disable.
CLI — orqestractl ai-dependency-quarantine (list, create, affected-releases, override-allow, remediate, reenable, emergency-disable). The CLI exits non-zero when an emergency disable reports a non-empty failed_workload_ids.
SDK — client.ai_dependency_quarantine exposes the same operations for automation.

Known limits

Matching is metadata-only: no network lookup, scanner, or signature check runs in the release path.
Only release-bound dependencies (today, the bound model policy’s provider routes, or legacy model configuration routes) are matched; component classes without a release-bound source are documented gaps, not silent passes.
Activation matching is not retroactive: creating a quarantine does not stop an already-active release. Use the affected-release lookup to find impact, then emergency disable to act on running workloads.