Appearance
Security Model
Identity, Isolation, Verification & Execution Integrity
Forge Pool is designed to operate across partially trusted and fully untrusted hardware environments.
Security is enforced structurally — not optionally.
This document outlines the core security architecture.
1. Threat Model
Forge Pool assumes:
- Agents may be malicious
- Agents may be faulty
- Hardware may produce inconsistent results
- Network environments may be hostile
- Clients may misconfigure workloads
- Tokens may be compromised
- Economic incentives may create attack surfaces
The system is designed so that:
- no single Agent can define execution truth
- no execution result depends on a single machine
- deterministic aggregation prevents silent corruption
- identity boundaries isolate authority
Security is based on minimization of trust.
2. Identity vs Authority
Forge Pool separates identity types:
User Identity
- Managed in HQ
- Role-based permissions
- Controls Studio and project access
API Keys (Client Identity)
- Project-scoped
- Rate limited
- Revocable
- Used for Kernel execution calls
Node Tokens (Provider Identity)
- Organization-scoped
- Bound to billing ledger
- Revocable
- Required for Agent authentication
Cryptographic Agent Identity
Each Agent generates:
- ed25519 keypair
- Public key registered with Hub
- Signed execution responses
Tokens authenticate. Keys verify integrity.
Authority is never shared across identity classes.
3. Trust Boundaries
Forge Pool defines explicit trust zones:
| Component | Role | Trust Assumption |
|---|---|---|
| HQ | Control Plane | Trusted |
| Web Core | Policy & Billing | Trusted |
| Hub | Deterministic Orchestrator | Trusted |
| Agents | Execution Workers | Untrusted |
| Memory Fabric | Controlled Storage | Trusted (configurable) |
Agents are considered untrusted executors.
Verification exists because Agents are not trusted by default.
4. Execution Integrity Model
Security in Forge Pool centers on deterministic execution integrity.
Enforced mechanisms:
- deterministic shard planning
- seed-controlled randomness
- deterministic reduction
- shard result hashing
- optional shard duplication
- verification routing
If an Agent returns corrupted results:
- deterministic aggregation exposes inconsistency
- verification shards detect divergence
- health score adjusts
- scheduling priority reduces
Integrity is enforced structurally.
5. Shard Isolation
Agents:
- receive shard-only context
- do not access full job payload
- do not access other shard outputs
- cannot inspect organization secrets
- cannot access billing ledger
Each shard is executed in isolation.
Agents are incapable of:
- modifying other shards
- influencing aggregation logic
- altering replay metadata
6. Secure Communication
Transport security includes:
- HTTPS (TLS) for client API
- QUIC/TLS for Hub ↔ Agent
- Authenticated NATS channels (if enabled)
- Signed shard results
All communication is encrypted in transit.
Hub validates:
- token authenticity
- signature integrity
- job binding
7. Secret Handling
Clients
- API keys must be stored securely
- Never embed in client-side code
- Rotate periodically
Agents
NODE_TOKENstored in.env- Not exposed via API
- Requires restart for rotation
Studio
- Uses server-side session
- Does not persist sensitive tokens in browser storage
Secret scope is minimal.
8. Verification Modes
Verification is policy-controlled:
nonesamplefull
Verification may include:
- shard duplication
- cross-agent comparison
- statistical validation
- result hash comparison
Verification reduces risk of:
- malicious nodes
- faulty hardware
- silent corruption
9. Replay & Audit Security
Jobs are immutable after completion.
Replay requires:
- identical Kernel contract
- identical seed
- identical workload version
Replay guarantees:
- auditability
- forensic reproducibility
- regulatory defensibility
Replay metadata is cryptographically bound to job.
10. Economic Attack Mitigation
Forge Pool mitigates:
- fake node inflation
- result manipulation for credit farming
- verification bypass attempts
- shard withholding
Mitigation mechanisms:
- health scoring
- verification participation tracking
- shard correctness scoring
- scheduling weight adjustments
- billing tied to validated output
Economic incentives align with correctness.
11. Isolation Between Environments
Nodes may be configured for:
- PUBLIC global workloads
- PRIVATE organization-only workloads
Enterprise deployments may include:
- private Hub
- private Studio
- restricted node pools
- network segmentation
- air-gapped compute clusters
Isolation is configurable at deployment layer.
12. Token Rotation & Revocation
Best practices:
- rotate API keys periodically
- rotate Node Tokens on hardware changes
- revoke unused credentials immediately
Revocation is immediate and enforced at next connection.
13. Enterprise Security Model
For high-security institutions:
- dedicated private Hubs
- restricted region routing
- hardened node allowlists
- custom verification policies
- audit logging exports
- deterministic replay archival
Forge Pool supports institutional-grade security posture.
Security Philosophy
Forge Pool does not assume trust.
It assumes potential failure.
Security emerges from:
- deterministic structure
- cryptographic identity
- isolation boundaries
- verification enforcement
- replay integrity
Execution truth must be defensible.
Security is structural, not procedural.