The Short Answer
An ibl.ai agent calls a live external API from inside a Linux sandbox that starts with no network: the organization allowlists exact host:port pairs, then binds a secret the agent can use but never read, because the real key is substituted only on TLS requests to that secret's own hosts. On ibl.ai you own all the code and the data, the egress layer included.
That is the trust model a law firm, a bank or an agency can sign off on. The agent can act on a real system; the organization decides, host by host, what it may reach; and the credential never enters the machine where the model's code runs.
One correction to the way this is usually pitched. It is not true that the big platforms offer "blanket network access or none." OpenAI, Anthropic and Microsoft all ship egress controls, and Anthropic ships a key-injection mechanism close to ours.
The difference that matters to a regulated buyer is where that machinery runs, and who holds the key.
Why do law firms stall on AI agents that call external APIs?
Because an agent that calls an API is no longer a drafting tool. It is a process holding a credential to a system full of client data, such as a document-management system, a conflicts database or an e-billing portal.
The American Bar Association's Formal Opinion 512, issued July 29, 2024, applies the existing Model Rules to generative AI tools, including competence under Rule 1.1 and confidentiality under Rule 1.6.
Neither duty is new. What is new is that an agent with a shell and open internet can, in principle, send what it reads anywhere. Showing reasonable efforts to protect client information is hard when the process holding it was never constrained.
So the approval question a general counsel or CISO asks is concrete: what can this agent reach, which credentials can it use, and can it ever see those credentials? An architecture has to answer all three in writing.
What can an ibl.ai agent's sandbox reach on the network?
Nothing, until an administrator says otherwise. On ibl.ai, an agent set to the Virtual Machine Shell sandbox gets a real Linux VM per chat, and that VM starts with no network. Each agent is then given one of four egress profiles, documented in the Sandbox settings.
| Egress profile | What the agent's VM can reach | Secrets allowed? |
|---|---|---|
| No Network (default) | Nothing at all | No |
| Package Registries | PyPI, npm, apt and apk only | No |
| Public Internet | Public hosts; private ranges, loopback and cloud metadata stay blocked | Yes |
| Custom Allowlist | Only the exact host:port pairs in a named network policy |
Yes, and only for hosts the policy also allows |
A network policy is a named allowlist of up to 100 exact host:port entries, with no scheme, path or wildcard. Entries such as localhost, metadata* and .internal suffixes are refused, as are reserved IP ranges.
Policies are written once per organization and reused across agents, never across organizations. Per the September 25 platform update, a missing or cross-tenant policy fails closed rather than falling back to a default.
For a legal team the Custom Allowlist is the one that matters. An agent that files time entries reaches the e-billing host and nothing else, and the policy is a reviewable artifact a risk committee can read line by line.
How does an ibl.ai agent use an API key it can never read?
Through VM secrets. Inside the virtual machine, the secret's environment variable holds a placeholder. The real value is substituted only on TLS requests to the hosts that secret is allowed to reach, so the agent can call the API but cannot print, log or forward the key.
The agent's code sees
DMS_KEY=placeholder, never the real value.A TLS request leaves the VM carrying only the placeholder.
Only a host on that secret's own list gets the substitution.
The real key is swapped in on the way out and never enters the VM.
So a prompt injection hidden in a filed brief cannot talk the agent into pasting the firm's API key into a chat or a request to another host. The agent never had the key to give.
The platform also enforces the combination, as Agent Network Policies and Secrets, Now in Settings describes. Under Custom Allowlist, every host a bound secret needs must also be in the agent's policy, so a secret can never open a path the policy does not.
An agent can bind at most 20 secrets. No endpoint ever returns a stored value, and a pasted value that looks masked, such as sk-****, is refused outright.
A secret can also read one field of an integration credential the organization already stores, which follows rotations automatically. Rotating a key once updates every agent that uses it, which is the property an incident-response runbook wants.
Do OpenAI, Anthropic and Microsoft give AI agents the same controls?
Partly, and it is worth being precise, because a buyer who finds one false row in a comparison stops trusting the rest. All three vendors ship real egress controls. They differ on where secrets live and on who operates the layer.
| Platform | Default network for the agent | How the agent uses an API key | Who runs it |
|---|---|---|---|
| OpenAI Codex cloud | Internet blocked during the agent phase; can be turned on with a domain allowlist and an optional limit to read-only HTTP methods (docs) | Secrets reach setup scripts only and are removed before the agent phase; plain environment variables stay readable (docs) | OpenAI |
| Anthropic Claude Code cloud sessions | Trusted allowlist by default; None, Full and Custom also available | Network secrets: Anthropic's agent proxy attaches the key after the request leaves the VM; not available in a self-hosted environment or with customer-managed keys (docs). Managed Agents vaults use the same placeholder-at-egress pattern (docs) | Anthropic |
| Microsoft Foundry Agent Service | Optional Standard Setup with private networking: no public egress, agent compute in your delegated subnet; your Azure Firewall and NSG rules govern outbound (docs) | Managed identity (Entra ID), or an API key stored in a Foundry project connection and passed on OpenAPI tool calls (docs) | Microsoft, in your Azure tenant |
| ibl.ai | No Network; four profiles, Custom = exact host:port allowlist, fails closed |
Placeholder in the VM; real key substituted only on TLS to that secret's hosts | You, when self-hosted on your cloud or on-premise (ibl.ai also offers a hosted option) |
Anthropic's network secrets are the closest analogue to ours, and they are good engineering. The trade-off is in its own documentation. In Claude Code cloud sessions the key sits with Anthropic's proxy, and a self-hosted Claude Code environment does not have network secrets.
Anthropic's Managed Agents vaults substitute a placeholder at egress the same way, but its docs say that credential type is not yet supported with self-hosted sandboxes, where you run your own proxy.
Microsoft's Foundry path is the strongest on network isolation inside Azure, and its OpenAPI tools keep an API key in a project connection rather than in the spec. It keeps agent data in your tenant, but it is an Azure service, with Azure as the place the network lives.
Why does it matter who runs the proxy that holds an agent's API key?
Because whoever runs the substitution layer holds a live credential to your client systems. With a vendor-run proxy, that vendor is inside the chain of custody for the key, and its retention, staffing and subpoena exposure become yours to diligence.
When you self-host ibl.ai under its perpetual code license, the sandbox, the egress policy and the secret store run inside your own perimeter. The key to your document-management system never leaves infrastructure your firm controls.
An allowlist of internal hosts and a secret store you operate do not depend on reaching any vendor's network, which is the property an air-gapped deployment needs. The same agent can run model-agnostic across any LLM you approve.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
Who can open a host or bind a secret to an agent on ibl.ai?
Only people granted it. Creating, changing and deleting network policies and VM secrets are separate permissions, held by organization admins by default; ordinary users do not have them. Binding a secret to an agent additionally needs the secret-write permission.
That separation maps onto how firms already govern access. Practice-support staff can build an agent; only IT security can decide that it may reach the e-billing host, and only the holder of the credential can attach it.
Sandbox time is metered too: per the sandbox update, VM runtime is prorated per second at $1 per ten minutes by default, set per organization, and recorded next to the agent's model calls.
What should a legal or compliance team check before approving an agent that calls APIs?
Five questions, each answerable from configuration rather than from a vendor's assurance. They apply to any platform, including ours.
- Default state. Does the agent's runtime start with no network, or with a list someone has to remember to trim?
- Allowlist precision. Are entries exact hosts and ports, or wildcards and whole domains? ibl.ai caps a policy at 100 exact entries.
- Key visibility. Can code running in the sandbox read the credential, or only use it? Can a pasted key be echoed back?
- Who holds the key. Which company's infrastructure performs the substitution, and does it still work when you self-host?
- Separation of duties. Are "write a policy," "write a secret" and "bind a secret" separate permissions?
You can watch the whole flow in a three-minute video: an AI agent calls a live API from its sandbox.
Related reading on agent sandboxes and egress
The same mechanism, applied to student data: Letting a K-12 AI Agent Run Code Without Letting Data Out.
What an open-source sandbox showed about where agents leak: Perplexity Open-Sourced Its Agent Sandbox. The Network Leaked, Not the VM.
Why identity matters in legal AI: Legal AI's Next Crisis Is Trust, Not Intelligence. And India's advisory on agents as attack vectors: CERT-In Classed AI Agents as Attack Vectors, Not Targets.
Want to see an agent call your API without seeing your key?
We can walk your security and risk teams through a sandboxed agent on your own policies, on infrastructure you own. Book a 30-minute demo or talk to the ibl.ai team. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.