Skip to main content
Agent trust is the mechanism through which Forge governs what an agent can do — not just whether it can execute. Every agent in the platform operates within a trust envelope defined by three interlocking concepts: an that gates action types, an that governs execution scope, and a set of that enforce hard resource limits. Together, these form the agent trust layer of the Trust Fabric.

​
Autonomy Rungs

Forge implements a 4-rung autonomy ladder based on the Agentic AI Security Standard (STD-02.2). Each rung constrains the types of actions an agent can perform autonomously. Rungs are stored on the agent definition (agentDefinitions.autonomyRung) and enforced at dispatch time by Gate 8.

AUTONOMY LADDER (STD-02.2)

Rung 1: AssistiveMost Restrictive

Human reviews before any action. The agent can read data but cannot execute, write, or perform financial operations autonomously.

readexecutewritefinancial
Rung 2: RetrievalRead-Only

Read-only access to trusted sources. Like Assistive, the agent cannot execute, write, or perform financial actions — but it can fetch and summarize governed data without human pre-approval of each read.

readexecutewritefinancial
Rung 3: SupervisedPropose + Confirm

Agent proposes, human confirms. The agent can execute and write, but side-effecting actions require approval through separate approval gates — not enforced by the autonomy gate itself.

readexecutewrite *financial *
Rung 4: BoundedAutonomous Within Limits

Agent executes within configured limits. All action types are permitted. Financial actions above a threshold trigger the Two-Agent Rule (a separate gate). Budget, concurrency, and scope constraints remain enforced.

readexecutewritefinancial **

* after approval (handled by approval gates, not the autonomy gate)    ** Two-Agent Rule above threshold (separate gate)

Agents without an explicit autonomyRung default to supervised (Rung 3). This is a risk-mitigation design: existing agents that predate the rung system are not blocked, but they are not granted full autonomy either.

​
Trust Posture

The (formally, the execution authority posture) governs what class of execution an agent is permitted to perform. Postures map directly to the autonomy tiers defined on worker roles:
PostureLabelAllows Run LaunchDescription
advisoryAdvisoryNoCan analyze and recommend. Cannot launch side-effecting runs.
retrievalRetrievalNoCan read governed state. Cannot launch side-effecting runs.
approval_requiredApproval RequiredNoCan prepare work. Run launches require explicit approval support.
bounded_autonomousBounded AutonomousYesCan launch runs autonomously within configured governance bounds.
Postures are assigned through worker roles — the canonical way to configure agent trust. When an agent is linked to a role (via agentDefinitions.roleId), it inherits the role’s autonomyTier as its default posture. Operators can override this at the run level for specific executions. The platform default posture is bounded_autonomous. This applies only when an agent has no role and no run-level override — in practice, most agents should have an explicit role assignment.

​
Posture Precedence

When the governance engine needs to determine an agent’s effective authority posture, it applies a strict precedence chain. The resolver in convex/trust_fabric/role_resolver.ts evaluates three sources in order:

POSTURE RESOLUTION PRECEDENCE

1. Run Override. Highest Priority
run_override

An explicit executionAuthorityPosture set on the run document. Lets operators constrain a specific execution to a tighter posture than the role default — for example, forcing a normally-autonomous agent into approval_required for a sensitive production run.

fallback↓
2. Role Default. Standard Path
role_default

The autonomyTier from the agent’s linked worker role. This is the primary source for most agents. The role resolver verifies the agent.roleId matches the workerRole.roleId linkage before accepting the role’s tier.

fallback↓
3. Platform Default. Last Resort
platform_default

The platform default of bounded_autonomous. Applies only when the agent has no run-level override and no role linkage. The postureSource field on every GovernanceDecision records which level was used, providing full traceability.

The resolved posture and its source are both recorded on the GovernanceDecision, so operators can always trace exactly why an agent was permitted (or blocked from) a particular action.

​
Authority Bounds

Authority bounds are the hard resource limits that constrain what an agent can consume during execution. They are defined on the worker role and can be overridden at the agent level. The governance engine resolves effective bounds by merging role-level defaults with agent-level overrides (agent fields take precedence where set).
maxSpendCents

Per-execution cost ceiling in cents. Enforced by the budget gates.

maxDurationSeconds

Per-execution time ceiling. Enforced by the guardrails gate.

maxConcurrentSteps

Maximum simultaneous steps. Enforced by the concurrency gate. Agent-level override takes precedence.

maxHandoffs

Agent-to-agent transition limit. Prevents runaway delegation chains.

escalationThresholdCents

Cost threshold at which human review triggers. When spend crosses this threshold, escalation rules on the role can pause execution, require approval, or notify operators.

​
Scope Constraints

In addition to resource bounds, roles define scope constraints (ScopeConstraintsV1) that describe the operational boundaries an agent must respect:
ConstraintPurposeExample
environmentsEligible execution environments["staging", "production"]
toolAllowListWhen present, only these tools may be used["search", "summarize"]
toolDenyListWhen present, these tools must not be used["delete_record", "deploy"]
dataAccessReadable data domains["crm", "billing"]
writeAccessWritable data domains["crm.notes", "tickets"]
Scope constraints are resolved from the role’s scope field and propagated into the execution payload via the GovernanceDecision.scopeConstraints field. Downstream execution surfaces (Bridge, adapters) receive these constraints for enforcement.
Scope constraints are currently conveyed to downstream surfaces but full adapter-side enforcement is not yet implemented. The presence of these fields in the payload is the first step toward runtime enforcement.

​
Autonomy Gate

Gate 8 in the dispatch pipeline enforces both trust level and autonomy rung constraints. It runs as two sequential checks within a single gate function: Trust level check — Verifies the agent’s numeric trust level meets the minimum required by the target gateway. Agents default to trust level 1 (most restrictive). Gateways without an explicit minTrustLevel use the platform default of 1. Autonomy rung check — Classifies the dispatch action type (read, execute, write, financial) and verifies the agent’s rung permits it. Rungs 1 and 2 block all non-read actions. Rungs 3 and 4 pass the autonomy gate — downstream approval and budget gates handle their additional constraints. 
// convex/trust_fabric/gates/gate_8_autonomy.ts

export function autonomyGate(ctx: GateContext): SafetyGateResult {
  // Trust level check first
  const trustResult = trustLevelGate(ctx);
  if (!trustResult.pass) return trustResult;

  // Autonomy rung enforcement (STD-02.2)
  const rung = ctx.agentDoc.autonomyRung ?? "supervised";
  const action: ActionType = ctx.actionType ?? "execute";

  if (rung === "assistive" && action !== "read") {
    return {
      pass: false,
      errorCode: "autonomy_rung_blocked",
      retryable: false,
      message: `Rung 1 (assistive) agents cannot perform '${action}' actions autonomously`,
    };
  }

  if (rung === "retrieval" && action !== "read") {
    return {
      pass: false,
      errorCode: "autonomy_rung_blocked",
      retryable: false,
      message: `Rung 2 (retrieval) agents cannot perform '${action}' actions`,
    };
  }

  // Rung 3 (supervised) and 4 (bounded): pass here --
  // budget/approval gates handle constraints downstream.
  return { pass: true };
}
Error CodeConditionRetryable
trust_level_insufficientAgent trust level below gateway minimumNo
autonomy_rung_blockedAgent rung does not permit the action typeNo
Neither trust level nor autonomy rung failures are retryable. Trust levels and rung assignments are operator-configured and require explicit changes to resolve. The GovernanceDecision.explanation field provides concrete unblock hints when these gates block.

​
Next Steps