Forge — Authority and Interlocks

Who is this agent, and what authority does it actually hold? Forge provides the identity and authority substrate for autonomous systems — cryptographic principals, delegation, quorum, and pre-execution gates that fire before any action proceeds.

Does this agent have the authority to do this?

An autonomous agent requests permission to execute an action — paying an invoice, modifying a production database, deploying infrastructure. Before the action executes, someone must answer: does this agent have the authority to do this, and has that authority been properly granted, delegated, and not revoked?

The question is not about policy. Policy asks "should this happen given the rules?" Forge asks a prior question: "who is this agent, and what authority does it actually hold?"

Product-neutral authority primitives

Forge is the authority and identity layer of the Ardyn platform. It provides six product-neutral primitives for any entity that can hold authority — human, agent, device, service, or organization.

Principal Identity
Durable, cryptographic identities for any entity that can hold authority
Authority Grants
Explicit, revocable statements of what a principal is permitted to do
Delegation
Transfer of authority from one principal to another, with constraints
Quorum
Multi-principal authorization requiring agreement from a threshold of parties
Action Binding
Cryptographic binding of an authorization to a specific action, preventing replay
Pre-Execution Interlock
The authorize_transition gate that must pass before an action proceeds

The Seven Principal Types

Forge recognizes seven categories of principal. Each holds and exercises authority differently.

TypeDescriptionExample
HUMANA natural personA compliance officer
AUTONOMOUS_AGENTAn AI system operating without step-by-step human directionA claims-processing agent
SERVICEA software service with a stable identityA payment gateway
DEVICEA hardware device with a cryptographic identityA TEE-provisioned server
ORGANIZATIONA legal entityA corporation or department
HYBRIDA human-agent pair operating jointlyA supervised agent with human approval
QUORUMA threshold-based group of principalsA board requiring 3 of 5 votes

How Forge gates autonomous execution

Forge operates through a sequence of authority primitives that flow from identity through to the pre-execution interlock.

3.1 Principal Enrollment

A principal is created with a cryptographic identity — typically an Ed25519 key pair. The principal is recorded in Forge with its type, organizational affiliation, and public key fingerprint.

3.2 Authority Grant

An authority grant is a signed statement: "Principal A grants Principal B the authority to perform action X on resource Y, subject to constraints Z." The grant is itself an AEA (aea_kind: GovernancePrincipalAuthorizationV1), making it verifiable, chainable, and revocable.

3.3 Delegation

A principal holding an authority grant may delegate it to another principal. Delegation carries constraints: the delegate cannot exceed the delegator's authority, and the delegation may be time-limited, scope-limited, or single-use.

3.4 Quorum

For actions requiring multiple principals, a quorum grant defines the set of principals whose agreement is required, the threshold (e.g., 3 of 5), and the action scope. Each principal produces a signed authorization AEA. When the threshold is met, a quorum decision AEA (aea_kind: GovernanceAuthorizationQuorumV1) is issued.

3.5 Pre-Execution Interlock

The authorize_transition interlock is the gate that fires before any governed action. It checks:

  1. Is the principal's identity valid and active?
  2. Does the principal hold an authority grant for the requested action?
  3. Has the grant been revoked?
  4. Is the action bound to a specific nonce (replay prevention)?
  5. If quorum is required, has the threshold been met?

If all checks pass, the interlock returns ALLOW. The action proceeds to Axiom for policy evaluation and AAECP for execution.

  Principal
      │
      ▼
  ┌─────────────────────────────────────────┐
  │              Forge                        │
  │                                          │
  │  Identity ──► Authority Grant ──►        │
  │  Delegation ──► Quorum ──►               │
  │  authorize_transition()                  │
  │       │                                  │
  │       ▼                                  │
  │  ALLOW / BLOCK / INSUFFICIENT_AUTHORITY  │
  └──────────────┬──────────────────────────┘
                 │
                 ▼
             Axiom (policy evaluation)

Quorum-gated trade execution

A financial institution operates an autonomous trading agent. Before the agent can execute a trade above $1 million, the institution requires quorum authorization from two human principals.

Scenario: Agent requests execution of a $2.3M trade

  1. The agent (AUTONOMOUS_AGENT principal) submits the trade action to Forge.
  2. Forge checks the agent's authority grants: the agent holds execute_trade authority with a constraint max_amount: 1000000. The requested amount exceeds the grant.
  3. Forge identifies the escalation path: trades above $1M require quorum from two HUMAN principals in the trading desk.
  4. Two human principals (the head trader and the risk officer) each produce a signed authorization AEA.
  5. The quorum threshold is met. Forge issues a GovernanceAuthorizationQuorumV1 AEA.
  6. The authorize_transition interlock checks: identity valid, authority granted, quorum met, action bound to a nonce. Result: ALLOW.
  7. The action proceeds to Axiom for policy evaluation.

Counterfactual: Risk officer refuses

If the risk officer had refused: the quorum would not be met, authorize_transition would return INSUFFICIENT_AUTHORITY, and the trade would be blocked before any policy evaluation.

Boundaries of Forge's domain

Forge is an authority substrate, not a governance engine. It explicitly does not:

Evaluate organizational policy

Forge checks whether authority exists. It does not check whether exercising that authority is a good idea under current rules. Policy evaluation is Axiom's domain.

Execute actions

Forge is a gate. AAECP handles the governed execution of actions that pass the gate.

Record execution evidence

Forge produces governance AEAs (authorizations, revocations, quorum decisions). Execution evidence is produced by the attestation pipeline.

Provide trust scoring

Forge records authority state. ATP aggregates trust posture from evidence.

Replace legal authority

A Forge authorization grant is a cryptographic primitive within the Ardyn platform. It does not confer legal authority or satisfy regulatory requirements on its own.

Operate in isolation

Forge is one layer in a stack. It provides authority state; Axiom, AAECP, and ATP consume it.

Forge in the Ardyn architecture

Upstream

Identity Sources

Sovereign compute platforms provide hardware-rooted device identities. External identity providers (OIDC, SAML) may serve as identity proofing for HUMAN principals.

Downstream

Axiom & AAECP

Axiom reads Forge authority state during policy evaluation. AAECP calls authorize_transition as the first gate in the pre-execution path.

Lateral

ATP & ACTA

ATP includes authority state in trust profiles. ACTA records authority events as organizational cognition: who was granted what, who delegated to whom.

Independently verifiable authority state

Forge authority state is independently verifiable — all verification is offline-capable, with AEAs carrying the necessary bytes.

Principal Identity

The principal's public key fingerprint is recorded. Any verifier can confirm that authority grants and quorum decisions are signed by the correct key.

Grant Chain

Every authority grant references the grant that authorized it. A verifier can walk the chain from the current grant back to the root authority — confirming that no grant exceeds its parent's scope.

Revocation Completeness

A revocation AEA (aea_kind: GovernanceAuthorizationRevocationV1) is cryptographically bound to the grant it revokes. A verifier can confirm that a revoked grant is no longer valid.

Quorum Integrity

For a quorum decision, the verifier can confirm that the required number of principals signed, that each signature is valid, and that the threshold was met.

LIVE — Core Primitives Implemented

LIVE IMPLEMENTED PLANNED

Forge is implemented in the ardyn-tool-authority crate — Kylewilson04/forge @ c844406. The crate provides 12 modules with 75 tests covering all six authority primitives. The premp-authz binary (AAECP bridge) integrates the Forge interlock into a production authorization pipeline.

Principal Identity LIVE
7 principal types (Human, AutonomousAgent, Service, Device, Organization, Hybrid, Quorum). Ed25519 key fingerprint binding. Lifecycle status (Active/Suspended/Revoked/Expired). principal.rs, 8 tests.
Authority Grants LIVE
Explicit, revocable grants with scope, authority ceiling, delegation depth, validity windows, and cryptographic signatures. delegation.rs, 14 tests.
Delegation Chains PLANNED
Chain-of-trust delegation with root-to-leaf validation. Types defined (DelegationChain), full chain validation implemented. Awaiting production integration.
Quorum LIVE
N-of-M threshold authorization with role diversity, duplicate rejection, and separation of duties. decision.rs, 19 tests.
Action Binding LIVE
Cryptographic SHA-256 binding of actions to commit, tree, repo, environment, and policy. Replay protection via cryptographic nonce. action.rs, 11 tests.
Pre-Execution Interlock LIVE
authorize_transition() fail-closed gate with 6 guards (agent status, expiry, policy rules, digest match, evidence presence, attestation). Integrated via premp-authz bridge. interlock.rs, 18 tests.

Integrated via AAECP bridge: The premp-authz binary calls authorize_transition and produces signed AEA envelopes on ALLOW. The Forge interlock is the first gate in the AAECP pre-execution pipeline — verifying identity, authority grants, action binding, quorum, and evidence before any action proceeds.

Next layers in the authority stack