Forge Trust & Security

Project Health

Live Status

Architecture

Security Architecture

Forge's security is organized as a defense-in-depth stack. Each layer addresses a different threat surface, and layers are independently enforceable. No single layer failing compromises the entire system.

Layer 6

Network Posture

A running Forge agent has zero inbound attack surface by default. This is a fundamental design constraint, not a configuration option.

Layer 5

Egress Control

Forge restricts outbound network access at three independent levels, each catching traffic that could bypass the previous layer.

Three-Level Enforcement

Proxy Architecture

┌─────────────────────────────────────────────────────┐
│                   forge run                         │
│                                                     │
│  In-process HTTP ──→ EgressEnforcer (RoundTripper)  │
│                                                     │
│  Subprocesses ──→ HTTP_PROXY ──→ EgressProxy        │
│  (curl, wget,       127.0.0.1:<port>  (validates   │
│   python, etc.)                        domains)     │
└─────────────────────────────────────────────────────┘

Egress Modes

Domain Matching Rules

• • Exact match: api.openai.com matches api.openai.com
• • Wildcard match: *.github.com matches api.github.com but not github.com
• • Case insensitive: API.OpenAI.COM matches api.openai.com
• • Localhost bypass: 127.0.0.1, ::1, and localhost are always allowed in all modes

Domain Resolution

Allowed domains are resolved from three sources, combined and deduplicated:

1. Explicit domains — listed in forge.yaml under egress.allowed_domains
2. Tool domains — automatically inferred from registered tool names (e.g., web_search → api.tavily.com)
3. Capability bundles — pre-defined domain sets for common services (e.g., slack → slack.com, hooks.slack.com, api.slack.com)

Configuration

# forge.yaml
egress:
  profile: standard
  mode: allowlist
  allowed_domains:
    - api.example.com
    - "*.github.com"
    - hooks.slack.com
  capabilities:
    - slack
    - telegram

Production vs Development

Layer 4

Execution Sandboxing

Forge agents execute external code through two sandboxed executors, both designed to minimize the attack surface of subprocess execution.

SkillCommandExecutor

Skill scripts run via SkillCommandExecutor with the following controls:

CLIExecuteTool — 7 Security Layers

The cli_execute tool provides layered security enforcement:

Configuration

# forge.yaml
tools:
  - name: cli_execute
    config:
      allowed_binaries: ["git", "curl", "jq", "python3"]
      env_passthrough: ["GITHUB_TOKEN"]
      timeout: 120
      max_output_bytes: 1048576

Skill Trust

Trust Model

Trust Levels

Autowire Pipeline

Skills are autodiscovered and trust-evaluated through a pipeline:

Directory Scanner → Frontmatter Parser → Security Analyzer → Trust Evaluator
   Find dirs          Parse YAML           Verify hints        Assign trust
   with SKILL.md      + validate           vs actual content   level

Security Analyzer Checks

Trust Rules by Tier

Layer 3

Secrets Management

Forge provides encrypted secret storage with per-agent isolation and defense-in-depth.

Encryption

File format: salt(16 bytes) || nonce(12 bytes) || ciphertext. Plaintext format is JSON key-value map.

Storage Hierarchy

Secrets are resolved in order, with earlier sources taking priority:

Passphrase Handling

File Safety

• • .forge/ directories are automatically added to .gitignore
• • *.enc files are excluded in .dockerignore
• • Secret files use 0600 permissions (owner-only read/write)
• • Secret files never appear in container images

CLI Commands

forge secret set OPENAI_API_KEY              # Prompts for value securely
forge secret set SLACK_BOT_TOKEN xoxb-...    # Inline value
forge secret get OPENAI_API_KEY              # Shows value and source
forge secret list                            # Lists all keys
forge secret delete OLD_KEY                  # Removes a key
forge secret set API_KEY --local             # Agent-local secret

Layer 2

Build Signing & Integrity

Forge supports Ed25519 signing of build artifacts for supply chain integrity verification.

Signing Flow

Verification Flow

Key Management

forge key generate                     # Generate Ed25519 keypair
forge key generate --name ci-key       # Named keypair
forge key trust ~/.forge/signing-key.pub   # Add to trusted keyring
forge key list                         # List signing + trusted keys

Production Build Safety

The build pipeline includes a secret-safety stage that enforces production constraints:

• • Blocks production builds that only use encrypted-file without env provider
• • Warns if .dockerignore is missing alongside a generated Dockerfile
• • Rejects dev-open egress mode in production builds
• • Filters out dev-only tools (local_shell, local_file_browser)

Layer 1

Guardrails

The guardrail engine checks inbound and outbound messages against configurable policy rules.

Built-in Guardrails

Enforcement Modes

Runtime

# Run with guardrails enforced
forge run --enforce-guardrails

# Default: warn mode (log only)
forge run

Observability

Audit Logging

All runtime security events are emitted as structured NDJSON to stderr with correlation IDs for end-to-end tracing.

Event Types

Correlation Threading

Every event carries a 16-hex-character correlation_id that links all events within a single task session. The source field distinguishes in-process enforcer events from subprocess proxy events ("source": "proxy").

Example Output

{"ts":"2026-02-28T10:00:00Z","event":"session_start","correlation_id":"a1b2c3d4","task_id":"task-1"}
{"ts":"2026-02-28T10:00:01Z","event":"tool_exec","correlation_id":"a1b2c3d4","fields":{"tool":"tavily_research","phase":"start"}}
{"ts":"2026-02-28T10:00:01Z","event":"egress_allowed","correlation_id":"a1b2c3d4","fields":{"domain":"api.tavily.com","mode":"allowlist","source":"proxy"}}
{"ts":"2026-02-28T10:00:05Z","event":"tool_exec","correlation_id":"a1b2c3d4","fields":{"tool":"tavily_research","phase":"end"}}
{"ts":"2026-02-28T10:00:06Z","event":"session_end","correlation_id":"a1b2c3d4","fields":{"state":"completed"}}

Deployment

Container Security

Every forge build generates container-ready security artifacts for production deployment.

Build Artifacts

Container Runtime Behavior

When Forge detects it's running inside a container (via KUBERNETES_SERVICE_HOST or /.dockerenv):

• • The local EgressProxy is not started — NetworkPolicy handles egress enforcement at the infrastructure level
• • All other security controls (guardrails, execution sandboxing, audit logging) remain active
• • Secrets must use the env provider (encrypted files can't be decrypted without a passphrase)

Production Build

forge package --prod

Production builds enforce: no dev-open egress mode, no dev-only tools, secret provider chain must include env, and .dockerignore must exist if a Dockerfile is generated.

Reporting

Responsible Disclosure

Standards

Compliance & Standards