How to Secure an AI Agent Orchestrator
Agent orchestrators — Google AX, LangGraph, CrewAI, the Microsoft Agent Framework, the OpenAI Agents SDK — make it easy to run fleets of autonomous agents. The official docs show you how to run one. This guide shows you how to run one safely: sandbox the code, default-deny the network, cap the spend, scope the secrets, and keep a trail you can actually query when something goes wrong.
In plain words
Securing an AI agent orchestrator means treating every agent as an untrusted, attacker-steerable workload and building the boundaries the framework does not give you for free: run agent code in a disposable sandbox, default-deny egress to an explicit host allowlist, enforce a spend ceiling outside the agent’s control, issue short-lived least-privilege credentials per task, and keep an append-only audit trail.
The defaults are permissive on purpose — Google AX, for instance, ships a sample Gateway that allows every HTTPS host, and its TaskSpec budget field is reserved but not yet enforced. The security work is yours, and you verify the controls against the source and the exact version you run, not the marketing.
Step by step
- 1
Treat every agent as an untrusted workload
An orchestrator runs code and tool calls that are steered by model output, which is in turn steered by whatever text the agent reads — web pages, files, tickets, other agents. That makes an agent an attacker-influenced process, not a trusted internal service. Threat-model it like you would code pulled from a random repository: assume prompt injection will eventually turn it against you, and design so that a compromised agent can do limited, observable damage rather than anything it can reach.
- 2
Sandbox agent code execution — isolate, do not run in-process
If an agent can execute code or shell commands, run that in a disposable container or micro-VM with its own filesystem, user and network namespace — never in the orchestrator process or on the host. In-process execution means one tool call reads your environment variables, your other tenants and your control plane. Google AX, for example, is built on Kubernetes-style primitives (Task, Workspace, Gateway, Model) and is Apache-2.0 licensed, so you own the runtime: give each Task a fresh, least-capability sandbox and tear it down after.
- 3
Default-deny egress with an explicit allowlist
The orchestrator should reach only the hosts it genuinely needs — your model endpoint, your own APIs, a Git host — and nothing else, so a compromised agent cannot exfiltrate data or pull in a second-stage payload. Start from deny-all and add hosts deliberately. Watch sample configs: AX’s example Gateway egress allowlist ships with host "*" on port 443, which permits every HTTPS destination. That is a demo default, not a production boundary — replace the wildcard with the specific hosts you allow, and confirm each Task actually references the Gateway, because an unused Gateway restricts nothing.
- 4
Enforce a spend and budget ceiling yourself
Agents loop, retry and fan out, and a prompt-injected or runaway agent can burn through model and API spend fast. Do not assume the framework stops this for you: AX exposes a budget field on its TaskSpec, but as reviewed in late 2026 it is reserved and not yet enforced, and cloud billing alerts notify rather than halt. Put the cap outside the agent’s reach — an operator-controlled model proxy that reserves each request’s maximum cost against a shared budget before the call is sent, and hard-stops when the budget is exhausted.
- 5
Scope credentials and secrets per task, least privilege
Never hand an agent a broad, long-lived key. Issue short-lived, narrowly-scoped credentials per task and inject them only into the sandbox that needs them, so a leaked token exposes one task’s blast radius, not your whole account. Keep secrets out of prompts, out of tool arguments and out of anything the model can echo back, and rotate on a schedule. If an agent needs to act as a user, mint a token scoped to exactly that user’s permissions rather than a service identity that can do everything.
- 6
Require an auditable trail you can query during an incident
When something goes wrong you need to reconstruct what each agent read, decided, called and spent — in order, with timestamps. Log every tool invocation, every external request, every credential use and every model prompt/response to an append-only store the agents cannot edit. Make it queryable before you need it: an incident at 2am is the wrong time to discover your orchestrator logs are unstructured, missing the arguments, or stored where the compromised workload could tamper with them.
- 7
Verify the framework’s security claims yourself
Orchestrator marketing describes how to run agents; it rarely describes how a determined attacker breaks out. Read the source for the controls that matter — is the egress allowlist actually enforced, including the port? Is the budget field wired up or just declared? Does the sandbox really isolate, or share a kernel you care about? Pin the exact version you audited, because pre-1.0 agent frameworks ship breaking changes, and a control that worked last month may have moved. Trust what you can see in the code and test, not the README.
See how Google AX, LangGraph, CrewAI, the Microsoft Agent Framework and the OpenAI Agents SDK stack up on sandboxing, egress control, spend limits and auditability — side by side, in your browser.
Related
The side-by-side security comparison this guide walks you through, across the major orchestration frameworks.
Agent topology visualizerMap how your agents, tools and data flows connect so you can see where the trust boundaries and egress paths actually are.
Orchestrator security comparisonA written deep-dive comparing the security posture of the leading AI agent orchestration frameworks.
PlayCISO labsHands-on scenarios and simulations to practice the decisions running untrusted agent workloads forces on you.
Frequently asked questions
Is Google AX secure out of the box?
It is a self-hosted, Apache-2.0 framework built on Kubernetes-style primitives, which means you own and must configure the security — it is not a managed service that is hardened for you. Independent reviews in late 2026 found that the sample Gateway egress allowlist ships with a host "*" wildcard on port 443, and that the TaskSpec budget field is reserved but not yet enforced. Neither is a secret bug; they are defaults and roadmap items you have to account for. Treat AX as a runtime you harden, not a secure product you switch on.
Does the orchestrator sandbox agent code for me?
Do not assume so — verify it. Some frameworks run tools and code in-process by default, which means a single malicious tool call can read your environment, your secrets and your other workloads. The safe pattern is to execute any agent-run code in a disposable container or micro-VM with its own user, filesystem and network namespace, created fresh per task and destroyed after. If the framework does not do strong isolation itself, you wrap it in one that does.
Why is default-deny egress so important for agents?
An agent is steered by text it reads, so prompt injection can turn it into an exfiltration or command-and-control channel. If the orchestrator can reach any host, a compromised agent can send your data out and pull a second-stage payload in. Starting from deny-all and allowing only the specific hosts the agent needs — your model endpoint, your APIs, a Git host — turns that open channel into a narrow, auditable one. Replace any wildcard allowlist entry and confirm the egress policy is actually attached to the task.
How do I stop an agent from running up a huge bill?
Put the spend cap outside the agent’s control, because loops, retries and injection can all drive cost fast and the framework may not enforce its own budget field. The reliable pattern is an operator-controlled model proxy that reserves each request’s maximum cost against a shared budget before the call is made and hard-stops when it is exhausted. Cloud billing alerts help you notice overspend but generally do not halt it, so do not rely on them as the ceiling.
What should I log for agent orchestration?
Everything you would need to reconstruct an incident: each tool invocation with its arguments, every outbound request and its destination, every credential use, and every model prompt and response, all timestamped and ordered. Store it append-only, somewhere the agents themselves cannot edit, and make sure it is queryable before you need it. Unstructured logs, or logs the compromised workload can tamper with, are worse than no plan because they give false confidence.
The official docs show how to run an orchestrator — isn’t that enough?
Running one and running one safely are different problems. Official docs optimise for getting you to "hello world" quickly, which usually means permissive defaults — broad egress, in-process execution, unscoped credentials. The security work is yours: sandbox execution, lock down egress, cap spend, scope secrets per task, and keep an auditable trail. And verify the controls against the actual source and the exact version you run, because pre-1.0 agent frameworks change fast.