AI agent security at the egress

A coding agent with a GitHub token and open egress can push to any repository the token allows, and an allowlist only narrows where it can send data, not what it sends. AI agent security comes down to controlling the requests agents make. To secure AI agents, Formal Endpoint sits in their path as an egress proxy: a forward proxy on the laptop, or a sidecar next to the agent in its sandbox.

What is AI agent security?

AI agent security is the set of controls that limit what an autonomous agent can reach, which credentials it can use and what it can send, and that tie every action back to a human owner. For coding agents and cloud agents, most of those actions are network requests: LLM calls, MCP tool calls, git pushes and API calls.

That’s why we treat it as an egress problem: prompt injection, over-permissioned tools and leaked keys all end with a request leaving the machine. The OWASP AI Agent Security Cheat Sheet lists least privilege, human-in-the-loop controls and monitoring among its core practices. A proxy in the agent’s path applies AI agent access control, asks for confirmation and logs each request in one place.

What are the biggest security risks of AI agents?

• Credentials in reach. API keys in .env files, shell profiles and environment variables are readable by any agent running as that user.
• Exfiltration through allowed destinations. An egress allowlist decides where traffic can go, not what it carries. An allowed domain like github.com still accepts pushes.
• Unreviewed tools. MCP servers and skills nobody approved run with the user’s access.
• Irreversible actions. Agents run git push as easily as they run tests, and cloud agents can enable auto-merge on their own pull requests.
• No attribution. Without process identity, an agent’s request looks exactly like the engineer’s.

Here’s the catch with securing AI agents on the network: Formal Endpoint doesn’t stop a model from being prompt-injected, and it only inspects the flows your network rules select. It limits what an injected or misbehaving agent can do on the network, and records what it tried.

How does Formal Endpoint secure AI agents?

Formal Endpoint is an egress proxy that intercepts and inspects TLS traffic on the host. On macOS and Linux, Transparent Mode intercepts traffic without client changes. Network rules in CEL pick which flows to inspect, by process (macOS), hostname, user and protocol; everything else passes through untouched and isn’t logged.

When a rule matches a TLS flow, the Endpoint terminates TLS with a Formal local CA, classifies the protocol (HTTP, MCP, LLM, AWS, GCP, Postgres, MySQL, MariaDB, MongoDB or SSH) and evaluates your Rego policies locally. The Control Plane manages rules and policies but can’t interact with your data: only the Endpoint and the Connector can.

Egress proxy for agent sandboxes

Egress filtering by domain is where most teams start with AI agent sandbox security. An egress proxy that terminates TLS goes one level deeper: it reads the request inside an allowed connection. You can allow github.com for clones and still block a merge, which a domain list can’t express.

• Kubernetes. A native sidecar outside the application container, injected on labeled Pods by a Helm chart. The sidecar needs Kubernetes 1.29+ and the Helm injector 1.36+. See Formal Endpoint for Kubernetes.
• Amazon ECS. On EC2 and Managed Instances the sidecar intercepts all TCP connections. Fargate doesn’t allow NET_ADMIN, so there it runs as a local HTTP and HTTPS proxy, and clients that ignore proxy settings bypass it. See Formal Endpoint for Amazon ECS.
• Linux VMs and cloud agents. The headless Debian and Ubuntu package runs as a systemd user service, including inside Cursor Cloud Agents and Devin.

Where the platform issues OIDC tokens, the Endpoint signs in with them instead of a stored API key: Cursor, Devin, AWS, Azure, GCP, GitHub Actions and SPIFFE are supported sources. Cursor and Devin sessions map to the human who started the agent, so egress control applies to a short-lived identity, not a shared secret. We explain how we give our own cloud agents production access this way in Giving Cloud Agents Production Access with OIDC.

Credential injection: agents never hold secrets

Credential injection moves the secret from the agent’s environment to the proxy. The Endpoint forwards a selected request to a Formal Connector with the caller’s identity, and a Native User on the Connector adds the real credential before it goes upstream. Formal injects credentials at the proxy, so the key isn’t in the sandbox for an agent to leak.

In our Stripe example, a developer calls api.stripe.com with no key, and a Rego policy limits the injected key to read-only paths for one group. Stripe receives the real key; the laptop never does. The same pattern keeps the Anthropic key out of a Claude Code sandbox: here’s how to proxy Claude Code traffic through a Connector.

Native Users can also hold SSH keys, cloud IAM and kubeconfig, and a hook can fetch the credential at connection time, for example from Vault. For MCP OAuth tokens, the Endpoint can encrypt them with the macOS Secure Enclave so the client only stores ciphertext.

Shadow AI and spend on every laptop

On macOS, process.is_agent and process.has_agent_ancestor match Claude Code, Codex, Cursor, Devin and other known agents by code signature, plus every process they spawn. On Linux, the same flags match process names.

With LLM and MCP traffic intercepted on each laptop that runs the Endpoint, the Control Plane builds an AI inventory: unreviewed MCP servers land in a shadow AI queue to allow or block, usage breaks down by application, model and user, and token prices turn usage into LLM cost tracking that a policy can cap per user. The shadow AI use case covers discovery and approval in depth.

What policies secure AI agents in practice?

Each of these is a documented guide built from one network rule and one policy:

• Block agent git pushes to sensitive repositories over SSH, SSH on port 443 and HTTPS, while pushes from the engineer’s own terminal go through.
• Stop Cursor and Devin cloud agents from enabling auto-merge or merging pull requests.
• Restrict Codex Desktop to LLM traffic and approved MCP servers, so it can’t browse the web directly.
• Block tool calls that put a GitHub token on a command line, and encrypt command lines in Endpoint logs.
• Restrict Anthropic sign-ins to your organization with a header rewrite.
• Block Claude Code sessions launched with --dangerously-skip-permissions, using the input.agent.yolo_mode policy input.

For model and tool traffic specifically, see the AI gateway and MCP gateway use cases. To extend your web gateway controls to agent traffic, see secure web gateway.

Why allowlists aren’t enough to secure AI agents

An egress allowlist decides where traffic can go, not what it carries, so every allowed domain is still a way out for data. Request-level inspection closes that gap. The destination stays allowed, and a policy decides which requests to it go through.

How does the Endpoint fit with the Connector and the platform?

Endpoint controls outbound traffic from laptops and agent sandboxes. The Connector, a reverse proxy in your VPC in front of databases, SSH, Kubernetes and APIs, powers Formal PAM, and it’s where the Endpoint sends traffic that needs credential injection. Both share one control plane for policies, identity and audit logs: the Formal platform. For an enterprise rollout, MDM Endpoint Rollout supports Kandji, Fleet, Jamf Pro and Mosyle on macOS.