Software Factory is designed around the principle that AI agents should never be trusted implicitly. Every capability is gated, every action is auditable, and control files are tamper-proof.

Six prioritized threats, derived from the PRD:

┌─────────────────────────────────────────────────┐
│  TRUSTED ZONE                                   │
│                                                 │
│  Base branch configs ──→ Trusted Base Context   │
│  (pinned at intake, immutable for task lifetime) │
│                                                 │
│  Policy Engine ──→ governs all file access      │
│  State Machine ──→ enforced at DB level         │
│  Audit Log     ──→ RLS prevents tampering       │
└─────────────────────────────────────────────────┘
                    │
                    │ (one-way: trusted zone governs untrusted)
                    ▼
┌─────────────────────────────────────────────────┐
│  UNTRUSTED ZONE                                 │
│                                                 │
│  LLM Agent   ──→ runs inside Docker sandbox     │
│  Agent output ──→ validated before use          │
│  Working branch ──→ can't influence own rules   │
└─────────────────────────────────────────────────┘

At task intake, the system captures behavioral control files from the base branch (e.g., main) at a pinned SHA:

• CLAUDE.md, AGENTS.md, and similar instruction files
• .factory/setup.yml (build/test contract)
• .factory/policies.yml (path-level governance rules)

These are frozen for the task's lifetime. If the agent edits these files on its working branch, the edits are treated as diff content — they don't change the agent's behavior or validation rules.

Validation (tests, lint, security scans) uses configuration from the base branch:

• The agent cannot modify .eslintrc, tsconfig.json, vitest.config.ts, etc. to make its code pass
• Validation runs in a separate context from the agent's sandbox
• Results are recorded in the evidence packet for human review

Path-level governance with strict priority ordering:

read_exclusion  →  blocks read, index, and search (highest priority)
edit_deny       →  blocks all writes
edit_protected  →  allows writes but flags for mandatory review
edit_allowed    →  allows writes (lowest priority)

These paths are excluded regardless of user policy configuration:

secrets/**    .env*        *.pem       *.key
*.p12         *.pfx        *.jks       .git/**
node_modules/**

1. Check default exclusions → block if matched
2. Find highest-priority matching policy
3. Apply operation-specific rules (read vs write vs index vs search)
4. Return decision with reason and protection class

Credentials are scoped by workflow phase:

• Setup phase — has install-time credentials (npm tokens, package registry auth)
• Execution phase — install-time credentials are removed; only runtime credentials available
• PR phase — has GitHub write tokens for PR creation

This prevents the agent from exfiltrating install-time secrets during code execution.

• Secrets stored in Postgres with AES-256-GCM encryption (secret_bindings table)
• Injected into Docker containers at runtime via environment variables
• 50-minute credential leases with automatic rotation
• Lease tracking in credential_leases table

Every significant action is recorded in audit_entries:

• Task state transitions
• Side effects (GitHub API calls, file writes, command executions)
• Cost records (LLM tokens, compute time)
• Policy decisions (allowed/denied file access)

• PostgreSQL Row-Level Security (RLS) prevents UPDATE and DELETE on audit entries
• SHA-256 content hashes for integrity verification
• Entries include actor, timestamp, and correlation IDs

All backed by Redis for low-latency checks:

• Global — halts all tasks immediately
• Per-task — halts a specific task
• Checked at every activity entry point (before any work begins)
• Triggers the kill signal on the Temporal workflow → immediate cancellation

• Per-task spending limits set at creation
• Tracked in Redis for real-time enforcement
• Overridable via cost_override signal (requires authorized actor)
• Cost records persisted to Postgres for audit

• Automatic halt after configurable failure threshold
• Scoped per failure domain (e.g., GitHub API errors, LLM timeouts)
• Prevents cascading failures and runaway costs

• Prevent two tasks from working on the same branch concurrently
• Lease acquired at setup, released at completion/cancellation
• Stale lease detection and cleanup

• Format: sf_<random> prefix for easy identification
• Storage: SHA-256 hashed in Postgres (raw key never stored)
• First-run bootstrap prints an admin key to stdout

The task submitter cannot be the sole approver of their own task's evidence. This prevents a single actor from submitting and rubber-stamping AI-generated code.

• No network access — network_mode: none or isolated bridge with no external routes
• Resource limits — CPU, memory, and disk quotas
• Ephemeral — containers destroyed after each phase
• Read-only root filesystem — writes only to designated volumes
• No privilege escalation — --security-opt=no-new-privileges