a2a cloud
zero trust runtime

AI agent security with zero-trust execution.

Ephemeral grants. Capability security. Container-hosted skills with a separate microsandbox for explicit code execution. Grant-aware workspace access. Scoped delegation. Receipts. Replay. The authenticated Agent API and trusted execution ingress make the evidence boundary explicit.

explicit authority · no ambient trust

0
defense layers
0
ambient trust
0
sandbox boundary
trust boundary

Four zones. Each one earns access from the next.

Defense in depth as concentric boundaries — untrusted callers on the outside, workspace files in the center. Nothing crosses a boundary by accident.

UNTRUSTEDAUTH EDGERUNTIMEWORKSPACEworkspacefiles · memory · outputsbrowserMCP clientA2A peerreceipt
L1untrusted
3 primitives

callers — browsers, MCP clients, other agents

bearer tokensMCP stdio / HTTPA2A peers
L2auth edge
3 primitives

org auth, service identity, rate limits, audit log

OAuth/OIDCservice identityaudit events
L3runtime
3 primitives

managed agent process — no host creds, no broad fs

sandboxscoped envno /etc/secrets
L4workspace
3 primitives

files reached only via signed grants

grant verifyglob filteroutput prefix
defense in depth

Eight zero-trust layers around governed execution.

Ephemeral grantsCapability securityRuntime isolationScoped workspace accessScoped delegationEvidence recordsReceiptsReplay

Ephemeral grants

Supported delegated operations use Ed25519-signed, audience-bound, time-limited authority constrained by file patterns and output prefixes.

Capability security

Grant-backed workspace and delegation operations use explicit capabilities. Separately configured agent secrets and local process access remain outside that boundary.

Runtime isolation

Hosted skills run in Knative or Kubernetes containers. Code explicitly sent through ctx.sandbox runs in a separate microsandbox microVM.

Scoped workspace access

Grant-aware workspace clients enforce bucket, path, and output-prefix policy. Hosted containers still have their own image and local filesystem.

Scoped delegation

Delegation can carry a signed grant. Formal A2A messages remain protocol state and do not automatically create receipts.

Evidence records

Runs on the API, MCP, and /invoke entry points produce signed evidence; approvals, tool traces, file operations, evaluations, and reviews remain separately correlated unless instrumented into optional fields.

Receipts

The authenticated Agent API and the gateway for public /invoke and standard MCP tools/call sign and persist execution receipts.

Replay

A separately signed, ordered event log for timeline inspection. Re-execution requires replay doubles and seeded randomness.

grant cryptography

Sign the grant. Verify grant-backed operations.

Each grant is a small signed token — audience-bound, path-filtered, time-limited. The runtime verifies six checks before any file op. Forged or stale tokens never reach the workspace.

01 · mint
caller

Caller declares scope on the call site. Runtime constructs a minimal grant.

ctx.call(
  "rfp-responder",
  "draft",
  args={...},
  files=["rfp/*.pdf"],
  outputs_prefix="rfp/draft/",
  ttl="1h",
)
02 · sign
runtime

Platform key signs the payload. Token is opaque to caller and callee.

{
  "aud": "rfp-responder@svc",
  "paths": ["rfp/*.pdf"],
  "outputs": "rfp/draft/",
  "exp": 1748137200,
  "iat": 1748133600,
  "jti": "grt_01HW2C…"
}
sig: ed25519:9f2a8c4e…
03 · verify
callee gate

Six checks run on every file op — not just at task start.

  • signature valid
    ed25519 over header.payload
  • audience matches
    callee identity = aud
  • not expired
    now < exp
  • path in glob
    request matches paths[*]
  • outputs prefix enforced
    writes must start with outputs/
  • single-use guard
    jti not in revocation list
forged signature

Returns 401. Audit event. No workspace touch.

path outside glob

Returns 403. File op never reaches the workspace client.

expired token

Returns 401. Callee can request_scope() for a fresh grant.

scope expansion

Agents can ask for more. Humans decide.

A specialist needs files the planner didn't grant. It opens an approval request mid-task. A human approves in the dashboard; the runtime rotates the grant; approval history and subsequent run evidence stay correlated without pretending approval fields are in the receipt.

01
callee
agent
callee detects insufficient scope
Tool mid-run. Reads workspace. Needs files outside the original grant.
02
callee
agent
callee opens approval request
ctx.request_scope(paths=["contracts/*.pdf"], reason="…", expires="30m")
03
approver
human
human reviews in dashboard
Approver sees: caller chain, callee identity, requested paths, reason, eval history.
04
a2a runtime
runtime
runtime mints rotated grant
Old grant revoked. New grant signed with narrower expiry. Attached to task.
05
a2a runtime
runtime
execution resumes under the new grant
Approval and grant rotation remain ordered records; a later covered receipt can reference the verified active grant id.
why this matters

Most agent failures are over-broad authority. Scope expansion turns the failure mode into a deliberate, human-witnessed, explicitly recorded event that can be correlated to later run evidence.

Review trust model
receipts

Proof is a security primitive.

The control plane signs and persists authenticated Agent API executions. Public `/invoke` and standard MCP `tools/call` responses carry gateway-signed evidence. Formal A2A message and task routes remain protocol state, and connector MCP jobs are outside this coverage.

receipt data
·
proof chain

Signed fields. Inspectable history.

Current platform sealers sign a defined execution payload: caller, skill, bounded input evidence, verified grant references when present, outcome or result preview, and timing. Tool, file, artifact, evaluation, review, and replay records remain separate unless an instrumented path supplies them.

execution receipt · field shape
example
01identity
agent · version · caller
<agent> · <version> · you@example.com
02intent
skill · input hash
<skill> · sha256:<digest>
03authority
grant ids
grt_<id> for each verified grant
04input
bounded preview
truncated copy of the call input
05outcome
status · result preview
terminal status · truncated result
06timing
started · ended · elapsed
RFC 3339 pair · elapsed ms
07optional
tools · files · artifacts
not populated by default
08history
separate session record
when configured → inspect
payload
canonical JSON · schema v1
signature
Ed25519 · signing key id
ledger link
receipt_id · economics separate

Example — illustrative, not a real customer run. Every value above is a placeholder for the field it names; no caller, id, or timing here is a record of anything. Real sealed receipts are rendered from live proof data on /replay.

The receipt payload is signed as one canonical JSON document. Mutating any signed field breaks verification. The ordered replay session can be verified and inspected separately; automatic agent re-execution is not part of the receipt contract.

hardening roadmap

Built for serious production review.

The platform is explicit about security work that matters for enterprise deployments: tenant isolation, grant signing, sandbox validation, secret rotation, audit surfaces.

Platform secret rotation and key management.
Per-tenant source control and stronger tenant isolation.
Asymmetric grant signing for cross-domain federation.
Production sandbox validation under load.
Build and runtime log proxying through the control plane.
Policy-backed egress enforcement at the sandbox boundary.