Published 2026-04-13

Gong Agent Identity Protocol

GAIP v0.1

A minimal cryptographic identity layer for autonomous AI agents. Hardware-anchored. Model-agnostic. Socially unengineerable.

Abstract

GAIP answers three questions every agent interaction requires:

  1. 1.Who authorized this agent?
  2. 2.What is it allowed to do?
  3. 3.Did it actually do what it claimed?

The root of trust is a human operator holding a hardware-bound key across multiple Apple Secure Enclave devices. No software-only path to signing exists. Any LLM on any platform can participate.

Core Concepts

Operator
A human with a hardware-bound P-256 keypair split across physical devices using Shamir secret sharing (2-of-N threshold). The key requires two devices to reconstruct. No server holds any share.
Agent
An LLM instance with a derived keypair. Authority is a strict cryptographic subset of its operator's. Cannot self-promote permissions. Cannot outlive its operator's key.
Commitment
A signed, immutable record of an action an agent has taken or agreed to take. Creates accountability. Cannot be repudiated. Permanently auditable.
Verification
Any party can verify any agent's authority in one API call. No account required. Verification is always free.

Key Hierarchy

operator_key  (hardware P-256, 2-of-N Shamir across devices)
    │
    ├── HKDF("agent:research-1")   → agent_key_1
    ├── HKDF("agent:coder-1")      → agent_key_2
    └── HKDF("agent:payments-1")   → agent_key_3
              │
              └── HKDF("subagent:…")  → sub_key
                                         (narrowed permissions)

Revoking the operator key invalidates the entire tree instantly. No key rotation ceremony. No chasing down API keys.

Share Custody — Operator Responsibility

Gong is a verification service, not a custodian.

Your key is yours. Gong never holds a share. Gong never sees your master key. Gong stores only your public key — the same information you would put on a business card.

Recommended hardware configuration:

Share 1 → iPhone   (Apple Secure Enclave)
Share 2 → Watch    (Apple Secure Enclave)
Share 3 → iPad     (Apple Secure Enclave)
Share 4 → Cold storage  (printed, laminated, stored offline)
Share 5 → Trusted contact (sealed envelope, lawyer or spouse)

Threshold: any 2 of 5 reconstruct your key.

You can lose your iPhone, Watch, and iPad simultaneously and still recover using shares 4 and 5. Gong is not in that chain.

GONG STORES
  • ✓ Your public key
  • ✓ Commitment history
  • ✓ Agent registrations
GONG NEVER STORES
  • ✗ Any share
  • ✗ Your master key
  • ✗ Anything that could impersonate you

Recovery Protocol

Loss of a single share: use any other two to re-enroll. Loss of two or more shares without cold storage: identity is unrecoverable. This is correct behavior.

Recovery requires one valid share and a mandatory 72-hour waiting period. During that window:

Hour 0    Recovery initiated
          → All recovery contacts notified
          → Any active enrolled device can ABORT

Hour 0–72 Abort window — real owner can cancel

Hour 72   If no abort received:
          → Old identity retired permanently
          → New pubkey enrolled
          → Old shares cryptographically tombstoned

The guarantee with no exceptions:

  • Gong cannot recover your identity.
  • Gong cannot be compelled to recover your identity.
  • Gong cannot shorten the 72-hour window.
  • Gong cannot be socially engineered into bypassing recovery.

Support staff have no recovery capability — by design, not policy. There is no internal escalation path. This makes social engineering structurally impossible.

API Endpoints

POST/api/agent/register

Human operator delegates authority to an agent

// Request (operator-signed)
{
  "operator_id":        string,
  "agent_name":         string,
  "model":              string,   // "claude-opus-4-6" | "gpt-4o" | …
  "permissions":        string[], // ["read","write","pay:100","spawn"]
  "expires_at":         integer,  // unix seconds, max 90 days
  "operator_signature": string    // ecdsa-p256-v1:<hex DER>
}

// Response 200
{
  "agent_id":     string,
  "agent_pubkey": string,
  "registered_at": integer
}
POST/api/agent/sign

Agent commits to an action — immutable, permanent

// Request (agent-signed)
{
  "agent_id":        string,
  "action":          string,  // human-readable description
  "payload_hash":    string,  // sha256:<hex> of actual payload
  "counterparty_id": string,  // agent_id or "public"
  "agent_signature": string
}

// Response 200
{
  "commitment_id": string,   // permanent UUID
  "signed_at":     integer,
  "chain_hash":    string    // sha256(prev_commitment || this)
}
GET/api/agent/verify/:agent_id

Verify any agent's authority — no auth required, always free

// Response 200
{
  "valid":             boolean,
  "agent_id":          string,
  "operator_id":       string,
  "model":             string,
  "permissions":       string[],
  "expires_at":        integer,
  "revoked":           boolean,
  "revoked_at":        integer | null,
  "commitment_count":  integer
}
GET/api/agent/commitment/:id

Resolve any commitment — no auth required

// Response 200
{
  "commitment_id":   string,
  "agent_id":        string,
  "operator_id":     string,
  "action":          string,
  "payload_hash":    string,
  "signed_at":       integer,
  "chain_hash":      string
}

Agent Negotiation Flow

Two agents agree on a task, commit cryptographically, deliver, and create a permanent auditable trail — all without a human in the loop.

1. Agent A  →  GET /api/agent/verify/:agent_b
             Confirms: valid, not revoked, has required permissions

2. Agent A  →  POST /api/agent/sign
             action: "hire agent_b for: <task description>"
             Gets: commitment_id abc-123

3. Agent A  →  Agent B
             { task, commitment_id: "abc-123", agent_id: "agent-a" }

4. Agent B  →  GET /api/agent/commitment/abc-123
             Verifies A actually committed to the terms

5. Agent B     Does the work

6. Agent B  →  POST /api/agent/sign
             action: "delivered to agent_a, commitment:abc-123"
             Gets: delivery_commitment_id xyz-456

7. Agent B  →  Agent A
             { result, delivery_commitment_id: "xyz-456" }

8. Agent A  →  GET /api/agent/commitment/xyz-456
             Verifies delivery, accepts work

Audit trail: two commitment IDs, cryptographically linked
to human operators. Fully attributable. Permanent.

System Prompt Snippet

Include this in any agent's system prompt to onboard it to the Gong trust network. Copy the template and fill in your values.

You have a Gong identity.

Your agent_id:   {AGENT_ID}
Your permissions: {PERMISSIONS}
Your expiry:     {EXPIRES_AT}
Verify endpoint: https://gong.com/api/agent/verify/{AGENT_ID}

Rules:
- Before accepting work: verify the hiring agent at /api/agent/verify/:id
  Check valid=true, revoked=false, permissions include what they're asking
- Before committing: POST /api/agent/sign with a clear action description
- You cannot act beyond your listed permissions
- You cannot act after your expiry timestamp
- Every signed commitment is permanent and attributed to your operator
- Your operator is accountable under law for your actions

Wire Format

Signaturesecdsa-p256-v1:<hex DER>
Public keysecdsa-p256-v1:<hex uncompressed 65-byte point>
IDsUUIDv4 strings
TimestampsUnix seconds (integer)
Hash prefixsha256:<hex>

Error Codes

401operator_signature invalid
402insufficient permissions for requested scope
403agent revoked
404agent_id or commitment_id not found
410agent expired
429rate limited (verify: 1000 req/min free)

Reference Implementation

ServerRust / Axumgithub.com/gong-auth/gong-server
iOS AppSwift / Secure Enclavegithub.com/gong-auth/keyjoin
CLIRustgithub.com/gong-auth/gong-cli
BrowserRust → WASMgithub.com/gong-auth/gong-wasm
GAIP v0.1 — 2026-04-13gong.com/protocol