AI Coding Agent Security: Egress and Secrets

A coding agent runs with its engineer’s shell, tokens and network, so it can reach whatever the engineer can. Permission prompts and sandboxes help, but they live inside the agent. AI coding agent security adds controls outside it: an AI coding agent security platform sees each request the agent makes, decides whether it goes through and records who it was for. That’s a different job from AI coding assistant security, which mostly asks what a suggestion leaks.

What is AI coding agent security?

AI coding agent security limits three things about a coding agent (where it connects, which secrets it holds, what it sends out) and ties each of its actions to the person who started it. Coding agents act through the network: model calls, MCP tool calls, git pushes, package installs and API calls. That makes the agent’s network path a practical place to enforce limits and keep a record.

It’s a narrower job than AI agent security in general, which covers any autonomous agent. Coding agents bring their own patterns: they run inside an engineer’s session on a laptop, or in a cloud VM that anyone on the team can launch. The OWASP Top 10 for Agentic Applications is a useful map of the agent-specific risks behind both.

AI coding assistant security vs coding agent security

AI coding assistant security is mostly about what leaves with a suggestion: code context sent to a model, and insecure code coming back. Coding agent security adds execution. An agent runs shell commands, edits files, installs packages and pushes branches with no review step in between, so the question becomes what it’s allowed to do, not only what it sees.

Both differ from scanning the code an agent writes. SAST, dependency and secret scanners check the output for vulnerabilities and leaked keys; runtime controls check the actions taken along the way. Most teams need both layers. Formal is the runtime part, on the network path. It doesn’t scan code, so keep your scanners and code review for what the agent produces.

What are the biggest AI coding agent risks?

Most of them come from one fact: the agent inherits the engineer’s access, so its attack surface is everything that engineer can reach. Here’s where each risk shows up, the control that addresses it, and where we cover that control in depth.

Here’s the catch: an attacker’s text in a README, an issue or a web page can still steer the model, and Formal doesn’t prevent that. It also sees only the flows a rule selects. Its job is to cap the damage: a hijacked or mistaken agent can’t get past what policy blocks, and each attempt is logged. That’s why the network control sits next to code review and scanning, not in place of them.

How do you secure AI coding agents on engineer laptops?

On macOS and Linux, Formal Endpoint runs in Transparent Mode: it intercepts traffic without changes to the agent, terminates TLS for the flows a network rule selects, and evaluates your policies before the request leaves. Windows is the exception: there’s no Transparent Mode on Windows today, so the Endpoint reaches Formal resources through formal connect listeners only.

The reason to put the control on the laptop is process identity. An agent and its engineer share a user, a device and an IP address, so a rule keyed on the user can’t tell them apart. Formal’s rules read the code signature (macOS) or process name (Linux) and the parent chain. In the block agent git pushes guide, that’s one rule and one policy on macOS.

Allowlisting commands inside the agent is weaker than it looks: a handful of allowed build commands can end up running almost anything, as we found when allowlisting bash commands in Claude Code. For egress allowlists keyed on the process, which many teams run next to their existing web gateway, see egress control for AI agents.

How do you secure cloud coding agents like Cursor Cloud Agents and Devin?

Cloud agents work in development VMs nobody logs into, and a whole team can launch them from Slack, Linear or GitHub. The headless Endpoint, a Debian package, starts inside the agent environment and signs in with the platform’s own short-lived OIDC token, which Formal exchanges for a machine session. No Formal API key is stored in the VM, and the setup guide sets Transparent Mode to fail closed.

The OIDC integration maps each run to a person: Cursor’s claims.owner_email, or Devin’s claims.requesting_user_email, matched to the Formal user with the same email. Network rules and policies can then read both identities: the machine user the agent signed in as, and the human it works for. Logs record the same pair, so a blocked request points to someone who can explain it.

A common first policy keeps merges human. GitHub merges pull requests through a GraphQL mutation or the REST merge endpoint, so the cloud agent merge policy blocks enablePullRequestAutoMerge, enqueuePullRequest and mergePullRequest as well as the REST call. Our own setup, and why we stopped handing agents static credentials, is in giving cloud agents production access with OIDC.

Agents you host yourself follow the same pattern. In Kubernetes, the Endpoint is a native sidecar in each pod; in Amazon ECS, it’s a sidecar container in each task. Either way, the policies you apply on a laptop apply there too. On Fargate the sidecar acts as an HTTP and HTTPS proxy, so clients that ignore proxy settings bypass it.

How do you keep API keys and tokens out of coding agents?

Hold the credential at the proxy instead of in the agent’s environment. When the agent calls an API such as api.stripe.com, the Endpoint sends that request, tagged with the caller’s Formal identity, to a Formal Connector. The Connector stores the secret, attaches it on the way out, and a Rego policy decides which calls that secret may make. The agent works with no key at all.

Our post on hiding secrets from Claude Code with a proxy applies this to the Anthropic API key. Tokens that agents paste into shell commands are a separate leak; a policy can keep Git tokens off command lines. Credential injection itself is covered in depth on the Endpoint page.

Which AI coding agents does Formal recognize?

Each known agent is identified from its code signature on macOS and its process name on Linux, and process.has_agent_ancestor extends a rule to every process the agent spawns. The list includes Claude Code, Codex, Cursor, Devin, GitHub Copilot CLI and Windsurf, among others. The known agent identities table in the docs is the current, complete list.

For the four agents this page covers:

Two limits to plan for. Some agent flags, such as the ones for GitHub Copilot CLI and Windsurf, work on macOS only. And Linux has no code signatures, so rules there match process names. Check the docs table for each agent your team runs before you write a rule that depends on it.

Claude Code, Cursor, OpenAI Codex and Devin

Claude Code

Claude Code runs in the engineer’s terminal with their tokens. Formal selects its traffic, and that of the processes it starts, by code signature; keeps API keys on the Connector; and blocks the actions you list, such as pushes to sensitive repositories. A policy can also restrict Anthropic sign-ins to your organization. The full picture is on Claude Code security.

Cursor

Cursor works on laptops and as Cloud Agents. On laptops, rules tell Cursor’s traffic from the engineer’s. In Cloud Agents, the headless Endpoint signs in with Cursor’s OIDC token and maps each run to its owner, and a policy stops agents from merging their own pull requests. See Cursor security for teams and Cloud Agents.

OpenAI Codex security

Formal recognizes the Codex CLI and Codex Desktop, along with the processes they launch. A documented recipe for macOS restricts Codex Desktop to LLM and MCP traffic: model calls and approved MCP servers go through, while web search calls and any browser Codex launches are blocked. The rule matches on Codex as a parent process, so a browser you open yourself isn’t affected.

Devin

Devin authenticates with its own short-lived OIDC token instead of a shared password, and each session is tied to whoever launched it. Database access can wait for that person’s approval in Slack, and the Endpoint in the Devin VM applies your egress policies to what Devin sends out. See Devin security.

Which MCP servers and skills can coding agents use?

The ones you approve, if the Endpoint sees their traffic. An unreviewed server can be malicious or just over-permissioned. Formal captures agents’ LLM and MCP traffic, puts MCP servers outside your Catalog and skills seen in Claude Code requests into Shadow AI review, and lets Guardrails decide what happens to them until someone approves or blocks each one. Shadow AI detection covers discovery; the MCP gateway covers per-tool access to remote servers.

Packages are tools too. If you point npm, PyPI or another registry at a Socket Registry Firewall, Socket checks each package and Formal still decides who may fetch it. From then on, a dependency an agent pulls in gets the same check as one an engineer adds by hand.

What should an AI coding agent security platform include?

Whichever coding agent security solution you evaluate, ask where it enforces, not only what it detects. Here’s the checklist we use, and we hold Formal to it too:

• Enforcement outside the agent. Controls that don’t depend on the agent’s own permission settings.
• Agent and human told apart. Process identity on laptops, so a policy can restrict the agent without restricting the engineer.
• Cloud agents covered. The same policies in cloud agent VMs and pods, with a short-lived identity instead of stored keys.
• No secrets in the agent. Credentials injected at the proxy and scoped by policy.
• A human for irreversible actions. A block, or an MFA confirmation, on pushes and merges.
• Logs tied to a person. Each request attributed to an engineer and exportable to your SIEM.

Where does Formal stop?

Formal controls what coding agents do on the network. It doesn’t scan the code they write, it doesn’t prevent prompt injection, and it only inspects the flows a network rule selects. Transparent Mode works on macOS and Linux, not Windows, and some agent flags are macOS only. OpenAI Codex cloud and GitHub Copilot’s cloud agent have no documented setup today.

Who uses Formal to secure agent access?

Cursor routes its Cloud Agents’ access to internal data through Formal. Each Cloud Agent signs in with its own limited Formal identity, and Formal attaches the employee behind the task, so Cursor’s security team sets limits on both the agent workflow and the person who launched it. Before Formal, Cursor kept its Cloud Agents away from internal systems entirely; the Cursor case study explains what changed.

“We’ve limited the amount of data that those cloud agents can access and we’re able to tie that back to the specific user who is using that cloud agent, which is a feature that I’m only aware of Formal having.”

— Roy Xu, Software Engineer, Security @ Cursor