G

2. Core Runtime

2. Core Runtime

Version: 1.0.0 Status: Production Layer: 8 — AI OS / Intelligence Layer Last Updated: March 2026


Overview

The Gao Agent Runtime (GAR v1) is the canonical execution engine for AI agents on the Gao Internet protocol. GAR v1 provides a sandboxed, policy-enforced, receipt-native environment for deploying autonomous agents that interact with the full Gao Internet stack.

GAR v1 is not a general-purpose AI runtime. It is purpose-built for:

  1. Verifiable execution — every agent action produces a signed, immutable receipt

  2. Non-custodial operation — agents never hold assets; all value flows through user-signed transactions

  3. Policy determinism — same capability state + same input → same decision

  4. Domain-scoped authority — agents operate within cryptographically bounded identity contexts


Architecture

┌─────────────────────────────────────────────────────┐  
                   GAR v1 Runtime                       
                                                        
  ┌──────────────┐    ┌──────────────────────────┐     
    Agent Input  │───▶️│  Policy Enforcement Gate      
  └──────────────┘    └──────────┬───────────────┘     
                                                       
                    ┌────────────▼──────────────┐      
                      Capability Validator            
                      (CAP check + Risk Tier)         
                    └────────────┬──────────────┘      
                                                       
                    ┌────────────▼──────────────┐      
                      Secure Sandbox Executor         
                      (Isolated runtime env)          
                    └────────────┬──────────────┘      
                                                       
         ┌───────────────────────▼──────────────┐      
                  Receipt Emitter                     
           (Canonical receipt + ledger write)         
         └───────────────────────────────────────┘     
└─────────────────────────────────────────────────────┘

---

### Core Invariants

The following invariants are enforced at the runtime level and **cannot be overridden** by any agent, operator, or governance action:

ID

Invariant

Enforcement Point

INV-01

Agent execution requires a valid, non-expired CAP token

Capability Validator

INV-02

Policy snapshot is hashed and locked at execution start

Policy Enforcement Gate

INV-03

All value transfers require a user-signed authorization

Settlement Layer (L4)

INV-04

Every execution produces exactly one canonical receipt

Receipt Emitter

INV-05

Receipt content is immutable post-emission

Receipt Ledger

INV-06

Agents cannot read cross-domain memory without explicit grant

Memory Store

INV-07

Execution windows are bounded; open-ended sessions are rejected

Sandbox Executor

INV-08

Risk tier escalation requires out-of-band human authorization

Capability Validator

---

### Execution Lifecycle

#### Phase 1: Registration

Agent Definition → Domain Binding → CAP Token Request → Tier Assignment


1.  Agent is defined with a capability manifest (action types, settlement ceiling, expiration)
    
2.  Agent is bound to a specific Gao Domain identity
    
3.  Domain owner signs a CAP token grant
    
4.  Risk tier (03) is assigned based on action scope and settlement ceiling
    

#### Phase 2: Invocation

Input Received → Policy Gate → CAP Validation → Tier Check → Sandbox Entry


1.  Agent receives input (API call, event trigger, scheduled task)
    
2.  Policy Enforcement Gate loads the current policy snapshot and hashes it
    
3.  CAP token is validated (not expired, not revoked, domain match)
    
4.  Risk tier check — Tier 2 requires in-band confirmation; Tier 3 requires out-of-band human authorization before sandbox entry
    
5.  Execution enters isolated sandbox
    

#### Phase 3: Execution

Action Planning → Tool Calls → Settlement Requests → Output Generation


1.  Agent plans actions within its declared capability scope
    
2.  Tool calls are routed through the Gao SDK (L3)
    
3.  Settlement requests are submitted to Gao Payment (L4) — not executed by the agent
    
4.  Output is generated and staged for receipt emission
    

#### Phase 4: Receipt Emission

Output Hash → Policy Hash → CAP Reference → Timestamp → Signature → Receipt Ledger


Every execution produces a receipt with the following canonical fields:

Field

Type

Description

`receipt_id`

UUID v4

Unique receipt identifier

`agent_id`

string

Agent identifier (domain-scoped)

`domain`

string

Owning Gao Domain

`execution_start`

ISO 8601

Execution window open timestamp

`execution_end`

ISO 8601

Execution window close timestamp

`policy_hash`

bytes32

Hash of policy snapshot at execution start

`cap_token_id`

string

Reference to capability token used

`risk_tier`

03

Risk tier at execution time

`action_log`

array

Ordered list of actions taken

`settlement_refs`

array

References to any Payment layer transactions

`output_hash`

bytes32

Hash of agent output

`runtime_version`

string

GAR version (e.g., “1.0.0”)

`signature`

bytes

Runtime signature over receipt payload

#### Phase 5: Failure Handling

Failure Mode

Trigger

Behavior

`POLICY_MISMATCH`

Policy changed between check and execution

Abort; emit failure receipt

`CAP_EXPIRED`

CAP token expired during execution

Abort; emit failure receipt

`TIER_ESCALATION_DENIED`

L3 action without human auth

Abort; alert domain owner

`EXECUTION_TIMEOUT`

Window exceeded

Terminate; emit partial receipt

`SETTLEMENT_REJECTED`

Payment layer rejection

Abort action; log rejection in receipt

`RECEIPT_EMISSION_FAILURE`

Ledger unavailable

Retry up to 3x; escalate to operator

All failure modes produce a receipt. No execution is silent.

---

### Capability Token (CAP) Schema

{  
  "cap_id": "cap_abc123",  
  "aud": "gar.gao.systems",  
  "scope_id": "commerce:order-processing",  
  "agent_id": "seal-agent-v1",  
  "domain": "acme.gao",  
  "domain_anchor_ref": "0x...",  
  "issued_by": "domain_owner_address",  
  "issued_at": "2026-03-01T00:00:00Z",  
  "expires_at": "2026-06-01T00:00:00Z",  
  "nonce": "a8f3c2d1e9b4",  
  "risk_tier": 2,  
  "max_execution_duration": 300,  
  "policy_version": "acme.gao:policy:v3",  
  "permitted_actions": [  
    "read:inventory",  
    "write:draft_order",  
    "settle:payment",  
    "notify:customer"  
  ],  
  "settlement_ceiling": {  
    "amount": "500",  
    "currency": "USDC",  
    "per_execution": true  
  },  
  "revocable": true,  
  "revocation_endpoint": "https://api.gao.systems/v1/cap/revoke",  
  "issued_chain": "base",  
  "signature": "0x..."  
}

**Field descriptions:**

Field

Description

`aud`

Intended runtime audience — validated by GAR before accepting the token

`scope_id`

Human-readable capability scope label for audit and display purposes

`nonce`

Anti-replay field — each CAP token nonce must be unique per domain

`max_execution_duration`

Maximum execution window in seconds this token authorizes

`policy_version`

Reference to the domain policy version this token was issued against

`domain_anchor_ref`

On-chain domain state reference at time of issuance

`revocation_endpoint`

Endpoint for runtime to check real-time revocation status

`issued_chain`

Chain on which domain ownership is anchored

---

### Policy Enforcement Engine

Policies are loaded as **snapshots** at execution start. The snapshot hash is:

1.  Computed over the full policy object
    
2.  Stored in the receipt
    
3.  Verifiable against the domain’s policy registry post-execution
    

Policy changes take effect on the **next execution**, never mid-flight.

#### Policy Object Fields

Field

Description

`allowed_tools`

Whitelist of tool categories the agent may invoke

`blocked_domains`

Cross-domain action restrictions

`settlement_rules`

Currency, ceiling, routing preferences

`memory_scope`

Read/write permissions on memory namespaces

`notification_hooks`

Post-execution notification endpoints

`override_contacts`

Human contacts for L3 escalation

---

### Sandbox Runtime

GAR v1 executes agent logic in an **isolated sandbox** with the following properties:

-   No direct filesystem access
    
-   No raw network socket access (all network via Gao Network L6)
    
-   No access to the host runtime environment
    
-   Execution time bounded by CAP token window
    
-   Memory access restricted to domain-scoped store
    
-   All tool calls mediated by Gao SDK
    

The sandbox is stateless per-execution. Persistent state is written to the domain-scoped Memory Store post-execution, not during.

---

### Versioning

GAR versions follow Semantic Versioning: `MAJOR.MINOR.PATCH`

Version

Status

Notes

1.0.0

**Current (Production)**

Initial production release

0.9.x

Deprecated

Beta; not receipt-compatible

Breaking changes require a MAJOR version bump and a 90-day migration window. The `runtime_version` field in every receipt enables audit verification across versions.

---

### Developer Integration

Agents integrate with GAR v1 via the **Gao SDK (L3)**. See the GAB v2.5 Developer Guide for full integration instructions.

Quick reference:

import { GaoAgentRuntime } from '@gao/sdk';  
  
const runtime = new GaoAgentRuntime({  
  domain: 'acme.gao',  
  capToken: process.env.GAO_CAP_TOKEN,  
  riskTier: 2,  
});  
  
const result = await runtime.execute({  
  agentId: 'my-commerce-agent',  
  input: { action: 'process_order', orderId: '12345' },  
});  

console.log(result.receipt); // canonical GAR receipt


GAR v1 is infrastructure software. Receipts constitute execution records, not financial instruments. All settlement flows through Gao Payment (L4) under user authorization.