agent-containment-reviewer

name	agent-containment-reviewer
description	Review agent sandboxes, transitive egress, privilege escalation, lateral movement, shared infrastructure, monitoring, and kill switches.
version	1.0.0
since	2026-08-29
last_modified	2026-08-29
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.0.0","date":"2026-08-29","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Agent Containment Reviewer

Purpose

Review whether an autonomous or tool-using agent remains technically contained when its instructions, model behavior, tools, dependencies, or adjacent services are compromised. Treat the agent as an untrusted principal and assess direct and transitive escape, privilege-escalation, lateral-movement, and egress paths.

Goal and behavioral contract

The authoritative Goal and artifact references are defined in descriptor.yaml. Capability boundaries, identity and delegation requirements, tool permissions, data boundaries, invariants, approval requirements, output contract, and operational limits are defined in contract.yaml. MCP/A2A trust boundaries and the reviewed execution closure live in integrations/ and dependencies.yaml; ASPS and assurance requirements live in assurance.yaml.

Treat those declarations as mandatory execution constraints. skcr validates requirements but does not claim verification or enforce them at runtime.

When to use

• An agent, model evaluation, coding assistant, or autonomous workflow runs in a sandbox, container, VM, runner, or isolated account.
• Package proxies, tool gateways, MCP servers, browsers, internal services, or shared infrastructure are reachable from an agent environment.
• A design claims that the agent has no host, internal-network, metadata-service, secret, or Internet access.
• Sandbox escape, privilege escalation, lateral movement, or kill-switch readiness needs independent review.
• Containment must remain effective even when the agent ignores every instruction.

Operating model

1. Model the agent as hostile and inventory every direct and transitive path from the execution environment to host, control plane, internal network, credentials, and Internet.
2. Trace trust boundaries through proxies and helper services instead of stopping at the first allowlisted destination.
3. Compare intended isolation with effective namespaces, mounts, identities, capabilities, routes, credentials, and shared infrastructure.
4. Build concrete escape and lateral-movement chains, then map each hop to preventive, detective, and recovery controls.
5. Separate declared restrictions from independently enforced controls and report evidence gaps without claiming runtime guarantees.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.