Security Model

Isolation Layers

OCI Container: Agent runs isolated from host in a standard container (Docker Engine, OrbStack, Colima, or Docker Desktop)
Network Topology: Enforced web egress through proxy sidecar on an internal-only network (web-egress-enforced), or full network isolation (locked-down-web)
Built-in Safety Engine: Fail-closed command interception for git and network tools inside the container
Plugin Governance: Only org-approved plugins execute
Git Protection: Protected branch speed bumps and push-blocking hooks

Container isolation is only one layer. A normal container can still make outbound network calls unless you control the network topology too. SCC documents these boundaries separately on purpose: filesystem/process isolation comes from the container; egress control comes from the network policy and proxy topology.

Built-in Safety Engine

SCC includes a provider-neutral safety engine that runs inside every container:

Shell tokenizer — parses compound commands (pipes, subshells, &&/|| chains) into individual commands for analysis
Git safety rules — blocks destructive git operations: push --force, reset --hard, branch -D, clean -fd, stash drop/clear, checkout (path mode), restore (worktree), reflog expire, gc --prune
Network tool rules — intercepts explicit network tools: curl, wget, ssh, scp, sftp, rsync
Fail-closed — if safety policy cannot be loaded from org config, all guarded commands are blocked by default

The engine runs via shell wrappers installed in scc-base. Each wrapper calls a standalone safety evaluator (stdlib-only Python, no external dependencies) before forwarding to the real binary.

Safety Engine vs scc-safety-net Plugin

Surface	Built-in Safety Engine	scc-safety-net Plugin
Enforcement	Shell wrappers (defense-in-depth)	Agent-native hooks
Bypass resistance	Agent cannot bypass — wrappers intercept at the OS level	Agent could bypass if hooks are disabled
Coverage	Git commands, network tools	Git commands (broader pattern matching)
Policy source	Org config `security.safety_net`	Same org config
Provider support	All providers (provider-neutral)	Claude Code today (Codex support planned)

Use both when available: The built-in engine provides cross-provider hard enforcement. The plugin provides additional coverage via agent-native surfaces where supported. They are complementary, not redundant.

Network Policy Enforcement

SCC supports three network policies:

`open`

No egress restriction. The agent container has unrestricted network access. This is the default.

`web-egress-enforced`

Topology-based isolation with a Squid proxy sidecar:

Agent container runs on an internal-only Docker network (no direct external access)
Squid proxy sidecar is dual-homed: internal network + default bridge
Proxy enforces an ACL compiled from the team’s allowed destinations
Default deny rules block IP literals, loopback, private CIDRs, link-local ranges, and cloud metadata endpoints before any allow rules
Even if the agent ignores HTTP_PROXY env vars, it physically cannot bypass the proxy

`locked-down-web`

The container runs with --network=none. No external network access at all.

Enforcement States

SCC uses these enforcement states in docs and CLI output:

Enforced: SCC changes runtime behavior deterministically.
Partially enforced: SCC enforces part of the intent and warns about the rest.
Advisory: SCC validates and reports but does not enforce at runtime.
Out of scope: SCC does not attempt to govern this surface.

Permissions Mode

SCC launches agents with permission prompts skipped by default inside the sandbox. This reduces friction but does not provide data loss prevention. You can re-enable prompts inside Claude if you want stricter confirmation.

Trust Boundaries

Source	Trust Level	Can Override
Organization	Absolute	Nothing
Team	Delegated	Within org bounds
Project	Restricted	Within team bounds
User	Advisory	Profile apply enforces org blocks; manual overrides are advisory

Security Blocks

Patterns in security.blocked_* are absolute:

Cannot be overridden by teams
Cannot be overridden by projects
Cannot be overridden by exceptions

Provider Plugin Model

Claude Code and Codex have different native plugin, rules, and hook surfaces:

Claude Code: Plugins via settings.json, hooks for command interception, marketplace integration
Codex: Rules via config.toml, hooks via .codex/hooks/, AGENTS.md layering

SCC unifies governance at the approval/bundle level — it does not pretend they share an identical format. The bundle resolver produces a provider-neutral render plan, and provider-specific renderers project it into each provider’s native configuration surfaces.

Exceptions

Time-bounded overrides for governance controls. See Exceptions.