AI Coding Agent Security: Governing Cursor, Claude Code, and Copilot
TL;DR
- AI coding agent security means governing what Cursor, Claude Code, and GitHub Copilot send to model providers and which MCP servers they can reach.
- Claude Code, Cursor, and Copilot each route through Bifrost with a base-URL change and a virtual key that carries model access, budgets, and rate limits.
- Bifrost guardrails run Gitleaks-backed secrets detection and a PII Detection template on prompts and responses before credentials leave the request.
- Bifrost Edge, currently in alpha, extends the gateway's policies to every machine, including app and MCP server allow and deny decisions enforced on the device.
In a sample of roughly 20,000 repositories with GitHub Copilot active, GitGuardian found that 6.4% leaked at least one secret, a rate 40% higher than the 4.6% observed across all public repositories (GitGuardian). As Cursor, Claude Code, and Copilot become standard developer tooling, AI coding agent security has become an infrastructure problem: these agents read source code, environment variables, and credentials, then send that context to external model providers, usually with no policy layer in between. Bifrost, the open-source AI gateway built in Go by Maxim AI, is built for enterprises that need to route, govern, and secure this traffic across every model and every machine. This post covers how to govern coding agents at the gateway, then how to extend that governance to the endpoint with Bifrost Edge.
For the rollout side of the same problem, see the guide on how to govern AI coding agents at scale.
Why AI Coding Agent Security Is Different
AI coding agent security is the practice of controlling what data coding assistants send to model providers, which tools they can invoke, and who can use them, enforced through policy rather than developer discipline. It differs from traditional application security because the sensitive data leaves through a prompt, not through a code path a scanner can inspect.
Coding agents concentrate several risks that the OWASP Top 10 for LLM Applications tracks separately:
- Sensitive information disclosure (LLM02): agents pull source code,
.envfiles, and credentials into prompt context, where that data can be logged, retained, or exposed. - Supply chain (LLM03): agents connect to Model Context Protocol (MCP) servers that can read files, call APIs, and execute commands.
- Excessive agency (LLM06): terminal agents run with the developer's own permissions, so a single bad instruction can modify files or run commands across the environment.
The core problem is structural. Coding agents are usually adopted bottom-up, installed per developer and pointed straight at a provider API. Security teams inherit the exposure without the visibility.
That is why coding agent security has to be handled as a governance problem rather than a per-developer setting.
The Shadow AI Problem in Engineering Teams
Shadow AI is the ungoverned AI usage that never gets routed through a policy layer. In engineering, it looks like Cursor, Claude Code, and Copilot running on individual laptops, each sending code and context to a model provider with no shared budget, no audit trail, and no guardrails. Bifrost treats this as a governance problem, one covered more broadly in shadow AI risks and governance in the enterprise: a gateway only governs the traffic that is configured to flow through it, and most coding agent traffic never is.
MCP servers widen the gap. Agents increasingly wire in external tools, and most organizations have no inventory of which servers are connected or what they can reach. Security researchers at Adversa AI documented a class of flaws they call "TrustFall," in which cloned repositories cause coding agents including Claude Code, Gemini CLI, Cursor CLI, and Copilot CLI to auto-execute project-defined MCP servers once the user accepts the folder trust prompt, turning a single trust prompt into remote code execution (Adversa AI). Governing the model traffic an agent sends and the MCP servers it connects to is the same problem, and it needs one control plane.
Governing Coding Agents at the Gateway
Bifrost is the control plane for coding agent traffic. Bifrost exposes OpenAI-, Anthropic-, and Gemini-compatible endpoints, so a coding agent points at Bifrost instead of a provider, and every request inherits the organization's policies before it reaches a model.
Routing agents through the gateway is a base-URL change:
- Claude Code authenticates with a Bifrost virtual key set as its auth token, with no separate provider account login required.
- Cursor connects by overriding its OpenAI base URL and supplying a virtual key, which gives it access to any configured provider plus governance.
- GitHub Copilot routes through Bifrost with Bring Your Own Key support across the Copilot app, Copilot CLI, and the VS Code Copilot Chat extension, using a Bifrost virtual key as the API key.
- Other terminal agents, including Codex CLI, Gemini CLI, and OpenCode, follow the same pattern, so a team standardizes on one endpoint instead of a different configuration per tool.
| Coding agent | How it connects to Bifrost | Credential |
|---|---|---|
| Claude Code | ANTHROPIC_BASE_URL pointed at Bifrost |
Virtual key in ANTHROPIC_AUTH_TOKEN, no Anthropic login |
| Cursor | Override OpenAI Base URL setting | Virtual key in the OpenAI API Key field |
| GitHub Copilot app | OpenAI-compatible or Anthropic model provider (BYOK) | Virtual key as the provider API key |
| Copilot CLI | COPILOT_PROVIDER_BASE_URL environment variable |
Virtual key in COPILOT_PROVIDER_API_KEY |
Once traffic flows through the gateway, the governance layer applies. Virtual keys are the primary control: each key carries model and provider access rules, per-key budgets, and token and request rate limits, and can be deactivated instantly. That gives platform teams per-developer and per-team spend control and a way to revoke access without rotating provider credentials; governing Claude Code usage across engineering teams and tracking coding agent spend with an AI gateway walk through both patterns.
Security controls run in the same request path:
- Guardrails evaluate prompts and responses, with Bifrost-managed secrets detection built on the Gitleaks default rule set and a Custom Regex PII Detection template that catch API keys, tokens, private keys, and PII-like patterns before they leave the request.
- Guardrail rules can target MCP tool calls as well as LLM requests, so the same profiles inspect what an agent sends to its tools.
- Bifrost-managed providers also include Prompt Guardrails, and external providers include Presidio, Azure AI Language PII, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Gray Swan Cygnal, Patronus AI, Check Point's AI Agent Security, and Repello Argus.
- Audit logs record administrative activity as events that can be HMAC-signed and exported, with audit trails designed to be SOC 2, GDPR, HIPAA, and ISO 27001 friendly.
This covers every coding agent that a developer configures to use the gateway. The harder question is the traffic no one configured.
Extending Governance to Every Machine with Bifrost Edge
The gateway governs configured traffic; Bifrost Edge extends that same governance to the endpoint. Edge runs on each machine and routes all AI traffic through the organization's Bifrost automatically, so the virtual keys, budgets, guardrails, and audit logs already configured at the gateway now apply to the AI developers actually use, not just the traffic that happened to be pointed at it. Edge is currently in alpha.
| Traffic source | Bifrost AI gateway alone | AI gateway + Bifrost Edge |
|---|---|---|
| Agents configured with a Bifrost base URL | Governed | Governed |
| Supported agents a developer never pointed at Bifrost | Not visible | Routed through Bifrost automatically |
| AI apps the organization has not approved | Not visible | Blocked on the device |
| MCP servers configured inside AI apps | Only servers connected to the gateway | Inventoried fleet-wide and allowed or denied on the device |
Edge closes the shadow AI gap for coding agents in three ways:
- App governance: administrators decide which AI applications are allowed, and Edge enforces that decision on each device. Allowed apps run normally under governance; disallowed apps are blocked before data leaves the machine.
- MCP governance: Edge inventories the MCP servers configured inside each AI app across the fleet, then enforces per-server allow and deny decisions on the device, so a denied server cannot be used even by an app that had it configured before the policy existed. Discovery covers the major agents today, including Claude Code, Cursor, Codex, and Gemini CLI.
- Guardrails everywhere: because Edge routes endpoint traffic through your guardrails, the guardrails configured at the gateway apply to prompts and responses from desktop apps, browser AI, and coding agents, with nothing extra to set up on the endpoint.
Edge governs the coding agents teams run today, including Cursor, Claude Code, and Codex, and its supported-application list continues to expand; the gateway-to-endpoint model for closing the last mile of AI governance explains the architecture in more depth. Because governance follows the user instead of waiting for opt-in, it reaches the ungoverned usage that a gateway alone cannot see.
Building a Coding Agent Security Policy
A coding agent security policy defines which agents may run, which models and MCP servers they may reach, what content is blocked from prompts, and how usage is audited. A workable policy moves from visibility to enforcement in a defined order:
- Inventory which coding agents and MCP servers exist across developer machines.
- Route agent model traffic through the gateway with per-developer virtual keys.
- Apply guardrails for secrets and PII so credentials cannot leave in a prompt.
- Allow or deny apps and MCP servers centrally, enforced on the device.
- Roll out fleet-wide through an existing device management platform, and audit continuously.
Can a general-purpose API gateway govern coding agents?
Not on its own. A standard API gateway authorizes HTTP traffic, but it cannot inspect prompt content for secrets, apply model and budget policy per developer, or authorize MCP tool calls, which carry their own method semantics. Coding agent governance needs a control plane that understands AI traffic.
How do you stop secrets from leaking through coding agents?
Route agent traffic through a gateway that runs secrets detection on prompts and responses, so API keys and credentials are caught before they reach a provider, then pair that with app and MCP policy so ungoverned tools cannot bypass it. In Bifrost, secrets detection uses the open-source Gitleaks rule set and can run alongside a PII Detection template.
How do you get visibility into MCP servers on developer machines?
Endpoint governance builds a fleet-wide MCP inventory by reading the configuration of each supported AI app, then lets administrators allow or deny each server centrally and enforce the decision on the device.
Enterprise deployment and fleet rollout
For regulated industries and strict enterprise requirements, Bifrost Enterprise adds RBAC, SSO and OIDC, clustering, and in-VPC and air-gapped deployment, and Bifrost Edge rolls out silently through MDM platforms including Jamf, Intune, Kandji, Workspace ONE, and JumpCloud.
The Edge rollout steps are covered in rolling out AI governance with Jamf, Intune, and Kandji. The LLM Gateway Buyer's Guide gives a capability matrix for evaluating this against other approaches.
Frequently Asked Questions
How do I secure AI coding across Copilot, Cursor, and Claude?
Route all three through one AI gateway with per-developer virtual keys. Claude Code uses a virtual key as its auth token, Cursor overrides its OpenAI base URL, and GitHub Copilot uses Bring Your Own Key with Bifrost as the provider. Guardrails, budgets, and audit logs then apply to every agent, and Bifrost Edge covers supported agents, such as Cursor and Claude Code, that no one configured.
How do you govern Cursor and Copilot in a regulated company?
Regulated teams govern Cursor and Copilot by combining gateway policy with endpoint enforcement. Bifrost virtual keys restrict models and budgets, guardrails block secrets and PII, and audit logs record administrative activity. Bifrost Enterprise adds RBAC, SSO, and in-VPC or air-gapped deployment, while Bifrost Edge blocks unapproved AI apps and MCP servers on each device.
Does Bifrost Edge govern GitHub Copilot?
GitHub Copilot is governed today at the Bifrost AI gateway through its Bring Your Own Key support in the Copilot app, Copilot CLI, and VS Code Copilot Chat. Bifrost Edge's current supported-application list covers Cursor, Claude Code, Codex, Claude Desktop, ChatGPT, and OpenCode, and teams can request support for additional apps as coverage expands.
What guardrails protect coding agent prompts?
Bifrost guardrails evaluate coding agent prompts before they reach a model and responses before they return. Bifrost-managed options include Gitleaks-backed secrets detection, a Custom Regex PII Detection template, and Prompt Guardrails, and external providers such as AWS Bedrock Guardrails, Azure Content Safety, and Google Model Armor can be attached through reusable profiles.
Getting Started with Bifrost
AI coding agent security is achievable when the same policies govern both the traffic developers configure and the traffic they do not. Bifrost provides the control plane for coding agents at the gateway, and Bifrost Edge extends that governance to every machine, so Cursor, Claude Code, Copilot, and other agents run under one set of controls for budgets, guardrails, and audit.
Teams comparing options can start with the AI governance tools built for coding agents and the playbook for governing AI coding agents at scale.
Review the governance resources to see how the pieces fit, or book a demo with the Bifrost team to plan a rollout across your fleet.