Trust Model

Trust Evaluation

Forge evaluates trust at multiple levels — skills, build artifacts, and secrets — to ensure integrity from development through production.

Skill Trust Policy

The default trust policy for skills:

Skills loaded without a signature emit a warning log at scan time. The skill scanner also validates symlinks — symlinks that resolve outside the project root directory are skipped with a warning.

Build Artifact Verification

When a signing key exists, forge build automatically:

1. Computes SHA-256 checksums of all generated artifacts
2. Signs the checksums with Ed25519
3. Writes checksums.json with checksums, signature, and key ID

At runtime, forge run can verify artifacts against trusted keys in ~/.forge/trusted-keys/.

See Build Signing for details on key management and verification.

Secret Reuse Detection

At startup, the runtime detects when the same secret value is shared across different purpose categories. This prevents credential reuse mistakes that could escalate the impact of a single token compromise.

Same-category reuse (e.g., two LLM keys with the same value) is allowed. Cross-category reuse is blocked with an error.

Production Build Checks

Production builds (--prod) enforce additional security requirements:

• No dev-open egress mode
• No dev-only tools (local_shell, local_file_browser)
• Secret provider chain must include env (not just encrypted-file)
• .dockerignore must exist if a Dockerfile is generated