AI Coding Guardrails

AI coding agents are powerful tools, but power needs boundaries. Guardrails help teams adopt AI safely — whether they use Claude Code, Codex, or both — by limiting potential damage from mistakes or unexpected behavior.

What Are Guardrails?

Guardrails are controls that constrain what AI coding assistants can do:

Guardrail Type	What It Controls
Git safety	Prevents destructive version control operations
Filesystem isolation	Limits which files AI can access
Plugin governance	Controls which extensions are allowed
Network policies	Restricts outbound connections
Configuration standards	Ensures consistent behavior across team

SCC’s Guardrail Layers

Layer 1: Container Isolation

Every agent session runs in an OCI container:

• AI sees only mounted directories
• Host filesystem is inaccessible
• Clean separation between sessions

scc start ~/project
# Claude Code can only access ~/project
# Cannot reach ~/.ssh, ~/.aws, other directories

Layer 2: Built-in Safety Engine

SCC’s core safety engine blocks dangerous commands inside every container (fail-closed):

Blocked	Why
git push --force	Overwrites remote history
git reset --hard	Discards uncommitted changes
git branch -D	Force-deletes branches
git clean -fd	Deletes untracked files

The optional scc-safety-net plugin adds agent-native hook coverage on top (currently Claude Code; Codex support planned):

Installation is automatic with most org configurations:

{
  "defaults": {
    "enabled_plugins": ["scc-safety-net@sandboxed-code-official"]
  }
}

Layer 3: Plugin Governance

Organizations control which plugins are allowed across all providers:

{
  "security": {
    "blocked_plugins": [
      "*experimental*",
      "*untrusted*"
    ]
  },
  "defaults": {
    "enabled_plugins": [
      "scc-safety-net@sandboxed-code-official",
      "approved-tool@internal"
    ]
  }
}

• Blocked plugins: Cannot be used by anyone
• Enabled plugins: Available to all teams
• Team additions: Teams can add plugins within allowed boundaries

Layer 4: Network Policies

Control what external connections the agent can make:

{
  "defaults": {
    "network_policy": "locked-down-web"
  }
}

Note

web-egress-enforced uses real network topology enforcement: the agent container runs on an internal-only Docker network with a Squid proxy sidecar as the sole gateway. locked-down-web uses --network=none. Enforcement is HTTP/HTTPS over IPv4 in v1; raw TCP/UDP is not filtered.

Layer 5: Team Profiles

Ensure consistent configuration across developers:

{
  "profiles": {
    "backend": {
      "additional_plugins": ["java-analyzer@internal"],
      "session": { "timeout_hours": 8 }
    },
    "frontend": {
      "additional_plugins": ["eslint-runner@internal"],
      "session": { "timeout_hours": 4 }
    }
  }
}

Developers run scc setup once to inherit all team settings.

Trust Hierarchy

SCC enforces a trust hierarchy where higher levels override lower ones:

Level	Trust	Can Override
Organization	Absolute	Nothing
Team	Delegated	Within org bounds
Project	Restricted	Within team bounds
User	Advisory	Within project bounds

Security blocks are absolute—no team, project, or user can bypass them.

Implementing Guardrails

Step 1: Define Organization Policies

Create an org config with security blocks:

{
  "apiVersion": "scc.cli/v1",
  "kind": "OrganizationConfig",
  "metadata": { "name": "my-org" },
  "security": {
    "blocked_plugins": ["*experimental*"],
    "blocked_mcp_servers": ["*untrusted*"]
  },
  "defaults": {
    "enabled_plugins": ["scc-safety-net@sandboxed-code-official"]
  }
}

Step 2: Configure Team Profiles

Add team-specific settings:

{
  "profiles": {
    "default": {
      "description": "Standard development profile"
    },
    "security-team": {
      "description": "Stricter controls for security work",
      "additional_plugins": [],
      "network_policy": "locked-down-web"
    }
  }
}

Step 3: Distribute Configuration

Host the config where teams can access it:

# Developers configure once
scc setup --org https://company.com/org-config.json

Step 4: Verify Enforcement

# Check what's blocked
scc config explain

# Dry run to see effective configuration
scc start --dry-run ~/project

Exceptions

Sometimes guardrails need temporary overrides. SCC supports time-bounded exceptions:

scc exception add local-override \
  --allow-plugin "experimental-tool@vendor" \
  --ttl 8h \
  --reason "Testing integration"

Exceptions:

• Have time limits (TTL)
• Require explicit reasons
• Are visible in scc config explain
• Cannot override absolute security blocks

Auditing

Track guardrail status and exceptions:

# List active exceptions
scc exception list

# Audit installed plugins
scc audit plugins

# See configuration sources
scc config explain

Next Steps

Security Model Deep dive into SCC's security architecture

Safety Net Plugin Configure git protection

Security Policies Set up organization-wide policies

Exceptions Handle temporary overrides