--- title: "Legal AI Agents Can Call Your APIs Without Reading the Key" slug: "legal-ai-agents-live-api-calls-secrets-never-read" author: "Blanca Amigot" date: "2026-11-07 12:00:00" category: "Premium" topics: "legal AI, AI agent security, agent sandbox, egress control, network allowlist, secrets management, attorney-client confidentiality, ABA Formal Opinion 512, regulated industries, self-hosted AI" summary: "An ibl.ai agent can call a live external API from inside a sandbox that starts with no network, through hosts the firm allowlists, using a key it can use but never read. OpenAI, Anthropic and Microsoft ship egress controls too; the question for a law firm is who holds the key." banner: "" thumbnail: "" linkedin: | A law firm's AI agent needs to pull a docket, check a conflicts database or file an e-billing entry. To do that it needs network access and a credential. That is exactly where most legal AI pilots stall. The honest picture in 2026: the big vendors do ship egress controls. OpenAI's Codex cloud blocks internet during the agent phase by default and offers a domain allowlist. Anthropic's cloud sessions add network secrets its own proxy attaches outside the VM. Microsoft's Foundry Agent Service can run with no public egress inside your VNet. So the real question is not whether an allowlist exists. It is who runs the proxy that holds the key to your client systems. On ibl.ai an agent runs in its own Linux VM with no network by default. The firm names the exact host:port pairs it may reach, up to 100 per policy, and binds secrets the agent can use but never read: inside the VM the variable holds a placeholder, and the real key is swapped in only on TLS requests to that secret's own hosts. And when you self-host, the whole layer runs on infrastructure you control. With ibl.ai you own all the code and the data, the egress proxy included. #iblai #AgenticAI #EnterpriseAI #LegalTech #AISecurity #AIAgents --- ## 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](https://www.americanbar.org/content/dam/aba/administrative/professional_responsibility/ethics-opinions/aba-formal-opinion-512.pdf), 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](/docs/os/agent-settings/sandbox).
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](/updates/platform-update-2026-09-25), 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.
1. Inside the VM
The agent's code sees DMS_KEY=placeholder, never the real value.
2. The agent calls out
A TLS request leaves the VM carrying only the placeholder.
3. The host is checked
Only a host on that secret's own list gets the substitution.
4. The API gets the key
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](/updates/virtual-machine-settings-policies-and-secrets) 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](/service/air-gapped-ai) needs. The same agent can run [model-agnostic](/product/agentic-os) 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](/updates/agent-sandbox-virtual-machines-network-policies), 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](/updates/agent-calls-live-api-from-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](/blog/agent-sandboxes-k12-districts-code-execution). What an open-source sandbox showed about where agents leak: [Perplexity Open-Sourced Its Agent Sandbox. The Network Leaked, Not the VM.](/blog/perplexity-space-open-source-agent-sandbox-network-boundary) Why identity matters in legal AI: [Legal AI's Next Crisis Is Trust, Not Intelligence](/blog/legal-ai-trust-crisis-agent-identity). And India's advisory on agents as attack vectors: [CERT-In Classed AI Agents as Attack Vectors, Not Targets](/blog/cert-in-ai-agents-attack-vectors-egress-control). ## 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](https://cal.com/iblai/30min) or [talk to the ibl.ai team](/contact). 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. ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. 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.