Security

Forge separates execution authority from execution trust.

Security determines who may participate in execution.

Trust determines whether execution may be believed.

These responsibilities intentionally remain independent.

Security protects the execution system.

The Trust Layer validates computational integrity.

What You Will Learn

After reading this guide you will understand:

how execution authority is established
how runtime identities are separated
how execution environments remain isolated
how providers authenticate
how secrets are protected
how security differs from verification
how enterprise deployments isolate execution

The Security Mental Model

Execution security begins before computation starts.

text

Identity
      │
      ▼
Authority
      │
      ▼
Authentication
      │
      ▼
Authorization
      │
      ▼
Execution
      │
      ▼
Verification
      │
      ▼
Replay
      │
      ▼
Trust

Security governs access to execution.

Trust governs confidence in execution.

Security Philosophy

Forge assumes distributed infrastructure may be only partially trusted.

Rather than assuming trusted hardware, trusted operators, or trusted networks, Forge minimizes the amount of trust required for correct execution.

Security therefore emerges from:

explicit identity
constrained authority
structural isolation
cryptographic authenticity
deterministic execution boundaries

Trust is minimized.

Verification compensates.

Threat Model

Forge assumes that distributed execution environments may include:

malicious execution agents
faulty hardware
inconsistent operating environments
hostile network conditions
compromised credentials
client configuration mistakes
economic attack incentives
replay manipulation attempts
execution evidence tampering

The execution model is intentionally designed so that:

no individual provider establishes computational truth
no individual node controls reduction
no execution depends upon one machine
execution authority remains isolated from execution verification

Security is based upon minimizing trust assumptions.

Runtime Identity

Forge distinguishes multiple identity classes.

User Identity

User identities govern access to:

Forge HQ
Studio
organizations
projects
administrative operations

Authorization follows role-based access control.

Client Identity

Applications authenticate using project-scoped API Keys.

API Keys:

authorize execution requests
belong to projects
are revocable
may be rate limited
participate in billing

Client identities express computational intent.

They do not participate in execution.

Provider Identity

Execution providers authenticate using Node Tokens.

Node identities determine:

execution participation
scheduling eligibility
provider accounting
operational history
execution attribution

Provider identities contribute computational capacity.

They do not determine computational truth.

Cryptographic Runtime Identity

Execution agents additionally maintain cryptographic identities.

Typical runtime identities include:

Ed25519 key pairs
signed execution responses
authenticated runtime communication

Tokens establish authority.

Cryptographic identities establish authenticity.

These responsibilities intentionally remain separate.

Authority Model

Authority is intentionally scoped.

Applications may:

submit execution contracts
inspect authorized execution
access permitted artifacts

Execution providers may:

authenticate
receive assigned shards
submit execution results

Providers cannot:

inspect unrelated workloads
influence deterministic reduction
modify replay metadata
access billing ledgers
elevate execution authority

Execution authority follows the principle of least privilege.

Execution Trust Boundaries

Forge explicitly separates trusted and partially trusted runtime components.

Runtime Component	Responsibility	Trust Assumption
HQ	Control Plane	Trusted
Web Core	Identity, Policy, Billing	Trusted
Kernel	Execution Semantics	Trusted
Hub	Execution Coordination	Trusted
Agents	Distributed Execution	Partially Trusted
Memory Fabric	Persistent Storage	Deployment Defined

Execution providers remain intentionally outside the trusted execution core.

Verification exists because execution infrastructure is not assumed to be trustworthy.

Execution Isolation

Distributed execution is structurally isolated.

Execution agents receive only the information required to execute assigned computational work.

Execution agents do not receive:

complete execution contracts
unrelated shard data
organization secrets
billing information
replay metadata
aggregation logic

Execution isolation limits both accidental disclosure and malicious behavior.

Secure Communication

Forge secures communication between runtime components using authenticated encrypted channels.

Typical transport protections include:

HTTPS/TLS
QUIC/TLS
authenticated messaging
signed execution responses

Runtime communication validates:

identity
authority
execution ownership
message authenticity

Transport security protects communication.

Verification protects computation.

Secret Management

Sensitive credentials should remain narrowly scoped.

Typical secrets include:

API Keys
Node Tokens
deployment credentials
infrastructure secrets

Production environments should:

rotate credentials regularly
revoke unused credentials
avoid embedding secrets in client applications
isolate provider credentials
minimize credential scope

Secret management protects authority.

It does not replace execution verification.

Verification

Security and verification serve different purposes.

Security determines:

who may execute
who may participate
who may inspect execution

Verification determines:

whether execution followed the execution contract
whether computation remained internally consistent
whether execution evidence is trustworthy

Verification is documented separately within the Trust Layer.

Replay Protection

Replay depends upon preserved execution identity.

Replay references include:

execution contracts
root seeds
execution versions
replay metadata
execution artifacts

Replay reconstructs execution semantics.

It does not grant additional authority.

Economic Security

Forge also protects against economic manipulation.

Mitigation mechanisms may include:

verification participation
execution reliability
scheduling adjustments
execution accounting
replay evidence
computational attribution

Economic settlement derives from documented execution rather than declared participation.

Deployment Isolation

Execution infrastructure may be deployed in multiple operational models.

Examples include:

public execution networks
private organizational clusters
dedicated provider pools
regional deployments
air-gapped infrastructure
regulated enterprise environments

Execution semantics remain identical across deployment models.

Deployment policy determines isolation.

Enterprise Security

Enterprise deployments frequently require additional controls.

Examples include:

private Hubs
restricted provider pools
region-aware scheduling
audit exports
replay retention
evidence retention
compliance logging

Forge supports institutional security requirements without changing execution semantics.

Relationship to Trust

Security and Trust solve different problems.

Security establishes:

execution authority
runtime protection
identity boundaries
communication integrity

Trust establishes:

execution integrity
deterministic execution
replay semantics
computational evidence

Security protects execution.

Trust validates execution.

Together they establish dependable distributed computation.

Practical Mental Model

A useful way to understand Forge security is:

text

Identity
      │
      ▼
Authority
      │
      ▼
Execution
      │
      ▼
Verification
      │
      ▼
Replay
      │
      ▼
Computational Trust

Security determines who may participate.

Trust determines whether execution may be believed.

Where to Go Next

Continue with:

Trust Layer — understand verification, replay, heterogeneous execution, and execution evidence.
HQ — operate the execution control plane.
Observability — understand execution transparency.
Architecture — explore runtime isolation, execution coordination, and deterministic execution.

Together these documents describe how Forge protects, validates, and explains distributed computation.

Final Thought

Security is not the reason Forge can be trusted.

Security determines who may participate.

Trust determines whether computation may be believed.

By intentionally separating authority from integrity, Forge minimizes trust assumptions while preserving deterministic, replayable, and independently verifiable execution across distributed infrastructure.

Security ​

What You Will Learn ​

The Security Mental Model ​

Security Philosophy ​

Threat Model ​

Runtime Identity ​

User Identity ​

Client Identity ​

Provider Identity ​

Cryptographic Runtime Identity ​

Authority Model ​

Execution Trust Boundaries ​

Execution Isolation ​

Secure Communication ​

Secret Management ​

Verification ​

Replay Protection ​

Economic Security ​

Deployment Isolation ​

Enterprise Security ​

Relationship to Trust ​

Practical Mental Model ​

Where to Go Next ​

Final Thought ​