Governing AI coding tools and local MCP servers on developer laptops
Coding assistants and local MCP servers often run directly on developer laptops. Learn how to discover local configurations, move credentials to a gateway, and govern tool calls.
By Halo Security Engineering
Engineering teams are often the first to adopt new AI capabilities. Alongside browser chat tabs, developers install desktop assistants, IDE extensions, command-line agents, and local Model Context Protocol (MCP) servers that connect directly to source code, issue trackers, and cloud environments.
Those tools speed up everyday engineering work. They also move model calls and tool execution onto the workstation, where network proxies and cloud-only dashboards rarely look.
Why developer workstations look different
A browser session usually reaches one domain. A coding assistant on a macOS or Windows laptop behaves more like a local runtime with several outbound paths.
- Local MCP configurations. Many desktop assistants and IDEs launch MCP servers as child processes from a configuration file on disk. Those processes inherit the developer's local environment and file permissions.
- Long-lived tokens in configuration files. To connect an MCP server to GitHub, Jira, or a database, engineers frequently paste a personal access token or API key into a local JSON file.
- Direct provider calls. Desktop apps and CLI tools can call model providers directly over HTTPS, including when a developer works from home or on a hotspot outside corporate network monitoring.
- Local model runtimes. An engineer testing an open-weight model on a laptop generates no external model traffic at all.
When an AI tool runs as a local process, it can reach whatever files, tokens, and network paths the developer account can reach.
Start by discovering what is installed and configured
You cannot govern developer AI with a policy memo alone. Engineering leads and security teams need a shared, factual picture of which coding tools, IDE extensions, local runtimes, and MCP configuration files exist across enrolled laptops.
Metadata-first endpoint discovery gives teams that starting point without reading source code or prompts. On macOS and Windows devices, Halo Endpoint identifies installed AI applications, IDE plug-ins, local runtimes, model artifacts, and MCP configuration locations. It records file paths, binary hashes, and configuration metadata so reviewers can see what is present and how broadly it is used.
Standard collection does not capture source files, prompt text, model responses, or secret values. Keeping code and prompts out of discovery makes it much easier for engineering and privacy reviewers to support an initial rollout. You can review the exact collection boundaries in the Endpoint Privacy Notice.
Separate experimentation from shared access
Once the first scan populates your AI inventory, group the findings by how they touch company systems. A practical review usually sorts developer tools into three buckets.
| Finding type | Main risk | Practical control path |
|---|---|---|
| Approved IDE or desktop assistant | Unmanaged model spend and personal API keys | Route model traffic through the model gateway with team budgets |
| Local MCP server calling internal or SaaS tools | Broad personal tokens stored in plaintext on disk | Move the connection to the MCP gateway with brokered credentials |
| Unreviewed desktop app or local runtime | Unknown data handling or unapproved software | Keep in audit mode during review, or block launch on managed endpoints |
This separation keeps security teams from treating every developer tool as an emergency. Engineers keep the coding assistants that help them ship, while credentials and policy move to a place the organization can manage.
Move credentials and policy to the gateway
The hardest problem with local MCP setups is credential sprawl. When twenty engineers each configure a local MCP server with their own personal access token, the organization has twenty long-lived credentials sitting on laptops and no unified log of what those tools did.
Routing model and tool calls through Halo's model gateway and MCP and tool gateway changes that operating model.
- Keep provider keys and app tokens at the gateway. Developers connect their assistant or agent to Halo rather than pasting provider keys or broad SaaS tokens into local configuration files.
- Scope which tools and actions are allowed. Policy evaluates the caller identity, the target MCP server, the tool name, and the arguments before the call executes.
- Hold sensitive actions for approval. Reading a pull request or searching issues can run automatically, while merging code, changing production settings, or deleting records can pause for human approval.
- Record one evidence trail. Each model request and tool call produces a consistent decision record with the actor, the tool, the policy result, and the cost.
For a closer look at how MCP server inventory connects to runtime rules, read MCP security from server inventory to runtime enforcement and the practical checklist for MCP governance.
Roll out with engineering, not against them
Controls that break an engineer's editor in the middle of a sprint invite workarounds. A phased rollout works better.
Start with a pilot group in engineering. Turn on endpoint discovery and gateway routing in observe mode first. Share the inventory findings with engineering managers so they can see which tools and MCP servers their teams actually rely on. Once the sanctioned path is fast and reliable, move unapproved binaries and unmanaged connections from audit to warn or block.
How Halo helps
Halo brings endpoint discovery and gateway enforcement together in one AI governance platform. Halo Endpoint discovers AI apps, IDE tools, local runtimes, and MCP configurations on macOS and Windows, while the model gateway and MCP gateway apply identity, policy, approvals, budgets, and evidence to model and tool traffic. To see how this works across your engineering laptops, book a walkthrough.