Forge Pool

Appearance

Authentication & Access Model ​

Forge Pool uses a role-scoped token model aligned with the Planetary Kernel execution architecture.

Authentication is separated by authority, not combined into one overloaded token type.

There are three token classes:

  • Project API Tokens
  • User Tokens
  • Node Tokens

Project API Tokens ​

Project API Tokens are the public execution credentials used to call the API.

Used for:

  • POST /api/v0/ops/execute
  • project-scoped execution
  • workload submission through Web Core

Format:

http
Authorization: Bearer fpak_XXXXXXXXXXXXXXXX

Properties:

  • bound to a specific project
  • validated by Web Core
  • associated with billing and quota context
  • required for all public distributed execution calls

These tokens represent execution authority, not human identity.

User Tokens ​

User Tokens represent an authenticated human identity in Web Core.

Used for:

  • dashboard access
  • project management
  • API token generation
  • node management
  • billing and organization actions

These tokens:

  • represent a user session or account identity
  • do not directly execute workloads
  • are not the public compute token format

Node Tokens ​

Node Tokens are used by Forge Pool agents and runtime infrastructure.

Used for:

  • node registration
  • hub connectivity
  • shard execution trust
  • result submission into runtime flows

These tokens:

  • bind a physical or virtual node to an organization or runtime context
  • are separate from public API credentials
  • participate in execution trust and verification boundaries

Why the Token Model is Separated ​

Forge Pool separates user identity, project execution authority, and node trust so the runtime remains clear and defensible.

This prevents dangerous scope overlap such as:

  • a user session acting like a compute token
  • a project token impersonating node infrastructure
  • a node token acting like a dashboard identity

The result is cleaner security and clearer runtime discipline.

Public Execution Flow ​

text
User -> Web Core Project -> Project API Token -> Execute API -> Hub -> Agents

Typical flow:

  1. A user creates a project.
  2. A Project API Token is generated.
  3. The client sends a canonical execution request.
  4. Web Core authenticates and authorizes the request.
  5. Hub executes it through the Kernel runtime.
  6. Agents perform shard-level work using separate runtime trust.

Rotation and Revocation ​

Project API Tokens can be revoked and regenerated from Web Core.

Node Tokens can be invalidated to remove compromised or retired agents.

User tokens follow the identity/session model of the authenticated dashboard layer.