Containers and CI / Deployment
The guard travels with the agent
Teams increasingly run their AI coding assistants inside containers - one service per project, often with permission prompts switched off for flow. That is the right call for blast-radius containment, but it moves the session logs and the tool calls inside the container, out of reach of a host-side scanner. Skarn moves with them.
Drop the guard into your image
Skarn's real-time guard is distributed as a multi-arch container image, so you add it to your agent image as a build stage - one line, no runtime dependency, the right architecture selected automatically. The same binary guards Claude Code, OpenAI Codex, and GitHub Copilot CLI agents; only the hook wiring differs, and worked Codex and Copilot CLI images ship as Dockerfile.codex and Dockerfile.copilot:
Wired as a pre-execution hook, it inspects every tool call before it runs - Bash,
Write, and MCP under Claude Code, and Codex's apply_patch and spawn_agent - and refuses a leaked secret
heading for an exfiltration channel or a typosquatted package install. Because the hook runs before the
agent's permission checks, it holds even when the agent runs with prompts skipped - the standard setup
for a sandboxed, containerized agent. The image is public - docker pull ghcr.io/skarn-security/skarn:0.19.0 needs no login, no account, and no token - and it carries the full local product; skarn check uses a free license and the paid tiers add the org controls - see Editions. The install page carries the build-stage line and the cosign verification command.
Scan the session store in CI
The same binary scans the session logs a containerized run leaves behind. Mount the store read-only and gate the pipeline on what leaked - by severity or by the 0-100 risk score - emitting SARIF for the security stack you already run. Nothing leaves the runner.
At a glance
| Aspect | What you get |
|---|---|
| Image | Multi-arch (linux/amd64 + arm64), distroless, runs non-root |
| Install into an agent image | One COPY --from build stage; binary at /skarn |
| Artifact integrity | cosign-signed (Sigstore) + SPDX SBOM + SLSA build provenance |
| Guard timing | Runs before permission checks - holds under skipped prompts |
| CI gating | Scan the mounted session store; fail on severity or risk score |
| Network egress | None by default |
Common questions
- Can I run Skarn inside a container?
- Yes. Skarn is published as a multi-arch (linux/amd64 and arm64) container image. Mount a session store read-only and run skarn check or recall over it, for example as a CI step, with no network call by default.
- How do I add the Skarn guard to a containerized AI agent?
- Copy the binary out of the Skarn image into your agent image as a build stage with COPY --from, then wire it as a pre-execution hook. The same image works for Claude Code, OpenAI Codex, and GitHub Copilot CLI agents - worked Codex and Copilot CLI images ship as Dockerfile.codex and Dockerfile.copilot. It then inspects every tool call the agent makes before it executes - Bash, Write, and MCP under Claude Code, plus Codex's apply_patch and spawn_agent - and refuses a leaked secret heading for an exfiltration channel or a malicious package install.
- Is the Skarn container image signed?
- Yes. The image is cosign-signed (Sigstore keyless) and ships an SPDX SBOM and SLSA build provenance, all verifiable with cosign verify. It is built on distroless and runs as a non-root user.
- Does the guard still work if the agent runs with permissions skipped?
- Yes. The pre-execution hook runs before the agent's permission-mode checks, so it can refuse a dangerous tool call even when the agent runs with permission prompts skipped - which is exactly why teams sandbox aggressive agents in a container.
More for your team: CTO and VP Eng, Procurement, Developer
Bring Skarn into your pipeline
The image and the binary are public - pull them and wire the guard yourself. We are happy to walk your platform team through the integration.