Quick answer
Google describes AX as a runtime that executes harnesses, skills, tools, and agents in isolated environments, and its architecture diagram labels the AX server multi-tenant with session-tenant actors. Those are important design primitives—not a certification that any deployment safely serves mutually untrusted tenants.
Production security requires evidence across the controller, event log, snapshots, actors, container images, cluster, credentials, models, MCP servers, tools, telemetry, and business resources. A sandbox limits some effects; it does not decide whether an action is authorized.
Isolation boundary map
| Boundary | Failure to test | Required evidence |
|---|---|---|
| Controller/API | One caller reaches another conversation | Authenticated identity, object ownership, denial and enumeration tests |
| Event log | Cross-tenant reads or writes | Row/key scoping, database role limits, encryption, audit, restore tests |
| Actor compute | Process, filesystem, or namespace escape | Runtime configuration, hardened profile, hostile workload tests |
| Snapshot store | Another actor reads a suspended state | Object-prefix policy, encryption, signed access, deletion and restore tests |
| Network | Actor reaches forbidden services | Default-deny egress, DNS and metadata controls, destination allowlist |
| Secrets | Credentials leak into actor, snapshot, log, or output | Short-lived injection, redaction, rotation, revocation, canary tests |
| Tools/MCP | Prompt induces an unauthorized action | Server-side user and resource authorization, scopes, confirmations, audit |
| Telemetry | Sensitive prompts or results leave the boundary | Field inventory, sampling, redaction, access, retention, deletion |
Apply controls independently. One strong boundary cannot compensate for an open downstream tool.
Actor isolation is not tenant authorization
An isolated actor can still carry an overprivileged credential. A tenant-specific actor can still call a shared MCP server that trusts tool arguments instead of verified identity. A restored snapshot can reintroduce an expired token or stale policy. A single controller can accidentally expose identifiers that allow cross-session access.
Pass a verified principal through the runtime and reauthorize at the system of record. Do not use prompt text, conversation ID, actor label, or tenant-provided configuration as authority. Bind credentials to the smallest tenant, resource set, action set, environment, and duration possible.
Multitenancy test plan
Create two adversarial tenants and run both positive and negative tests:
- Enumerate, guess, and replay conversation, interaction, agent, event, and snapshot identifiers.
- Attempt cross-tenant resume, cancel, reconnect, branch, tool call, and artifact access.
- Place canaries in files, environment variables, event payloads, snapshot objects, logs, caches, and tool systems.
- Trigger actor failure and rescheduling; verify the replacement receives only authorized state.
- Rotate and revoke one tenant’s credentials during a paused execution.
- Attempt network access to metadata endpoints, control-plane services, databases, and another tenant’s tool endpoint.
- Run generated code designed to consume CPU, memory, disk, descriptors, subprocesses, and outbound requests.
- Delete one tenant and prove removal across runtime state, snapshots, logs, telemetry, and downstream artifacts.
Test again after every runtime, CRD, sandbox, image, identity, or policy change.
Human approval and side effects
Human-in-the-loop pauses are useful only if the approver sees the exact action, target, scope, cost, evidence, and consequence. Approval must bind to an immutable operation request. If arguments change after approval, request approval again.
Use idempotency keys and reconciliation for state-changing calls. A runtime retry, actor resume, or client reconnect must not silently send a second email, place a second order, or repeat a deletion. The durable execution guide covers those failure points.
For deployment controls, read the Kubernetes and Agent Substrate guide. Record your evidence in the Agent Executor readiness checklist.
Frequently asked questions
Does AX isolate agents?
It is designed to run actors in isolated environments, but the deployment must prove the exact compute, data, identity, network, and tenant boundary it relies on.
Does a sandbox authorize a tool call?
No. Authorization belongs at the tool or system-of-record boundary and must use verified caller and resource context.
Is AX multitenant by default?
The architecture describes a multi-tenant server and session-tenant actors. Safe multitenancy remains an end-to-end property that must be tested.
Official sources
- Google Cloud: Agent Executor announcement
- Google: AX repository and architecture
- Google: AX Kubernetes deployment guide
Source check: August 12, 2026; AX revision 2bcc1637b3c106c16963c5c5464aedb46c6da031. Recheck current runtime, sandbox, identity, protocol, storage, and cluster controls before deployment.