feat: cryptographic agent identity binding for sandbox policy

[aeoess]

Problem Statement

OpenShell enforces policy at the binary/destination/method/path level — strong containment. But sandboxes have no cryptographic agent identity. The sandbox knows what process is running, not who authorized it or what scope they were granted.

This matters in three scenarios:

1. Multi-tenant gateways — when multiple agents share infrastructure, there's no way to verify that the agent requesting sandbox creation was authorized by a specific principal with a specific scope. A compromised orchestrator can spin up sandboxes for any agent.

2. Cross-sandbox delegation — Agent A in Sandbox 1 delegates a subtask to Agent B in Sandbox 2. OpenShell can enforce that B's sandbox has a restrictive policy, but cannot verify that B's authority derives from A's delegation, or that A had the scope to delegate in the first place.

3. Audit attribution — OpenShell logs allow/deny decisions, but the audit trail attributes actions to sandbox IDs, not to cryptographic identities. An agent that rotates through sandboxes loses its audit history.

Proposed Design

Add a identity_policy section to the sandbox policy schema that binds sandboxes to cryptographically verified agent identities. The identity layer sits above the existing four policy domains (filesystem, network, process, inference) and gates sandbox creation.

1. Policy schema extension:

version: 1

# New: cryptographic identity binding
identity_policy:
  require_passport: true
  trusted_issuers:
    - name: aeoess
      public_key: "e11f46f5831432d17852189d5df10ed21d5774797ae9ee52dbab8c650fec16ae"
      verify_url: "https://aeoess.com/.well-known/aeoess-issuer.json"
  delegation_scope_mapping:
    "filesystem:read": { filesystem_policy: "read_only" }
    "filesystem:write": { filesystem_policy: "read_write" }
    "network:*": { network_policies: "allow" }
    "inference:local": { inference_routing: "local_only" }
  max_delegation_depth: 3

# Existing sections unchanged
filesystem_policy: ...
network_policies: ...
process: ...

2. Sandbox creation flow change:

Current:  openshell sandbox create -- claude
Proposed: openshell sandbox create --passport ./agent-passport.json -- claude

At creation, the gateway:

• Verifies the agent's self-signature (Ed25519)
• Verifies the issuer countersignature against trusted_issuers
• Extracts delegation scope from the passport's delegation chain
• Maps delegation scopes to policy domains via delegation_scope_mapping
• Generates a sandbox policy that is the intersection of the YAML policy and the delegation scope
• Stores the passport public key as the sandbox identity for audit attribution

3. Runtime identity binding:

The sandbox metadata (already stored in the gateway's SQLite/Postgres) gains an agent_public_key field. Audit logs include this key, creating a continuous identity across sandbox restarts. The OPA engine gains a new input field agent.public_key available in Rego rules for identity-aware policy decisions.

4. Cross-sandbox verification:

When Sandbox A needs to delegate to Sandbox B, the delegation chain is verified: A's passport must include scope for the delegated action, and B's scope must be a subset of A's (monotonic narrowing). The gateway enforces this at sandbox creation — B cannot be created with broader scope than A granted.

Alternatives Considered

Process identity only (current approach): Sufficient for single-sandbox isolation but breaks down in multi-agent, multi-tenant deployments where knowing which agent matters, not just which process.

API key per sandbox: Simpler but doesn't support delegation chains, scope narrowing, or cascade revocation. An API key is all-or-nothing.

OAuth/JWT tokens: Standard identity but no delegation chain semantics, no monotonic narrowing, no cryptographic scarring on misbehavior.

Agent Investigation

The Agent Passport System (Apache 2.0, npm install agent-passport-system) already implements the identity primitives this design requires:

• countersignPassport() / verifyIssuerSignature() — CA model, issuer countersigns passports, verifiers check published public key
• createDelegation() / verifyDelegation() — scoped delegation chains with monotonic narrowing
• cascadeRevoke() — revoke one delegation, all downstream die
• resolveTierAuthority() — Bayesian reputation gates effective permissions

SDK: v1.29.0, 1852 tests, 94 modules. MCP server: 122 tools.
Issuer public key: https://aeoess.com/.well-known/aeoess-issuer.json
Paper: https://doi.org/10.5281/zenodo.19260073 (Faceted Authority Attenuation)
GitHub: https://github.com/aeoess/agent-passport-system

The proposed delegation_scope_mapping is a thin adapter layer — APS scopes are strings, OpenShell policy domains are YAML sections. The mapping is deterministic and can be evaluated at sandbox creation without runtime overhead.

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request

[aeoess]

Working adapter shipped: src/adapters/openshell.ts (174 lines, 12 tests).

Three functions:

• delegationToPolicy(delegation, agentPublicKey, issuerPublicKey?) — takes an APS delegation chain and produces an OpenShell-compatible policy object with identity_policy, filesystem_policy, network_policies, and process sections
• policyToYaml(policy) — serializes to the YAML format OpenShell expects
• extractEffectiveScopes(delegation) — pulls scopes from the delegation for mapping

Default scope mappings:

APS Scope	OpenShell Policy
filesystem:read	filesystem_policy.read_only: [/sandbox, /tmp]
filesystem:write	filesystem_policy.read_write: [/sandbox, /tmp]
commerce:*	network_policies: gateway.aeoess.com:443
network:*	network_policies (empty, user extends)
inference:local	Inference routing flag

Custom scope mappings are supported for domain-specific policies.

Install: npm install agent-passport-system (v1.29.0, 1864 tests).

Happy to iterate on the design if there's interest in integrating this into the sandbox creation flow.

[aeoess]

Update on the attestation architecture this connects to.

Since the adapter PR, we've shipped a 4-tier evidence model for passport issuance that was designed specifically with sandbox environments like OpenShell in mind:

• Tier 1 (Infrastructure) is where sandbox providers add the most value. When OpenShell provisions a container, it can attest: runtime instance ID, boot epoch, storage identity, workspace manifest hash. These signals are infrastructure-signed — the agent can't forge them.
• Passport grades (0-3) use these signals to distinguish a sandboxed agent (Grade 2+) from a bare script generating keypairs (Grade 0-1). Partners query a single trust profile API to decide whether to transact.
• Workspace manifest checkpoints — the sandbox periodically records a signed hash of the workspace structure (file count, sizes, modification times — not content). Over time, this becomes an unforgeable proof of accumulated work history.

The OpenShell adapter at src/adapters/openshell.ts already maps container identity to APS passport fields. The next step is wiring Tier 1 attestation signals from OpenShell's runtime into the RuntimeAttestation type so sandboxed agents get automatic Grade 2 issuance.

Interested in collaborating on the attestation interface — what signals does OpenShell's container lifecycle expose that would be useful for infrastructure attestation?

SDK: v1.29.0, 1,919 tests. npm: agent-passport-system.

[0xbrainkid]

The problem statement nails the gap: sandbox policy enforces containment but has no identity. An agent in a sandbox knows what it can do, but not who authorized it or what trust it carries.

@aeoess's APS adapter handles the delegation chain well — mapping passport credentials to sandbox policy objects is the right integration pattern. The 4-tier evidence model (infrastructure → behavioral → cross-org → temporal) aligns with what we see across the ecosystem.

One dimension to consider: cross-organizational trust for shared sandboxes.

When Agent A (org-1) runs in an OpenShell sandbox alongside Agent B (org-2) — common in multi-tenant gateways — the sandbox needs to verify trust from external sources, not just the local APS delegation chain.

Three layers that compose:

1. Identity binding (what APS provides): cryptographic proof of who authorized this agent and what scope they granted. The adapter's delegationToPolicy() covers this.

2. Behavioral trust (cross-org attestation): has this agent operated honestly in previous sandboxes? Was it flagged for policy violations elsewhere? This requires a trust oracle that the sandbox can query — something like SATP's cross-platform attestation (45 attestation types, temporal decay) or AgentScore's behavioral scoring.

3. Runtime attestation (the Tier 1 evidence @aeoess describes): the sandbox itself attesting to what it observed during execution. This feeds back into (2) for future trust decisions.

The practical integration: before sandbox provisioning, query both the delegation chain (APS) AND external behavioral trust (SATP/AgentScore/etc.). An agent with valid delegation but low behavioral trust gets a more restricted sandbox policy. An agent with high trust gets expanded capabilities.

This maps to the SPIFFE proposal (#382 on spiffe/spiffe) where trust metadata in SVID extensions gates workload capabilities. Same pattern: identity + trust together, not identity alone.