ACP Turns IDE Choice Into An Integration Contract

The Plugin Illusion

Agent Client Protocol (ACP) is not a plugin format. Left ungoverned, it is an unprotected API gateway on a developer laptop.

Most engineers meet ACP as a convenience. Pick an editor, pick an agent, and the two talk over a standard interface. Nobody writes a bespoke extension for each pairing. That’s a real improvement, and it’s also where the risk starts. ACP standardizes how an IDE talks to an AI agent, which decouples the interface from the intelligence. Once the two are separate, the connection between them becomes a contract. A contract nobody owns is a liability.

Ignore that and you end up with agents reading, writing and executing inside your proprietary repositories. Whoever installed them started them. You have no record to hand a security reviewer. The connection is a microservice contract. It deserves the scrutiny you’d give a production backend: who calls it, with what credentials, with what scope, and what happens when it breaks.

What We Learned From The 2017 LSP Migration

We’ve seen this shape before. In 2017 we migrated a local SME development team to Language Server Protocol (LSP) tooling. The technical change was modest. The procurement change was not.

Before LSP, we evaluated IDEs. After it, we stopped. Once language intelligence sat behind a standard protocol, the editor became a preference and the language server became the decision. We compared servers on correctness, maintenance and licence terms, and let developers pick their own front end.

ACP mirrors that shift. Where both the client and the agent implement ACP, you’re no longer buying a single AI editor. You’re choosing an agent backend that can run behind several client interfaces. The question stops being “which editor do we standardize on” and becomes “which agent process are we willing to let touch the repo.”

Here the analogy breaks, and it breaks where it matters most. LSP was never purely read-only: it already lets a client apply workspace edits, renames and code actions, and trigger commands. But those flows are mediated by the client and scoped to language intelligence. Coding agents are routinely delegated multi-file changes, package installs, test runs and shell commands, and the editor now fronts a long-running agent process rather than a language server behind completions. The blast radius is structurally larger, so the governance has to be heavier than anything we bolted onto LSP. Think of ACP as LSP’s younger, more expensive cousin, and budget for the difference.

Enforcing Token Limits Across Multiple IDEs

An ACP agent can run locally, run remotely, or sit behind a corporate proxy, and a single editor surface can front all three. That flexibility is the feature. It’s also how spend and access slip out of your hands.

In our internal wGrow rollout of coding agents, developers brought their own editors, which is exactly what the protocol invites. Each editor was configured to reach its agent, and each agent reached a model provider directly. Budget control vanished. We had no single place to see who was consuming tokens, and no single place to stop them.

So we proxied every agent request. All calls went through one gateway we controlled, and that gateway enforced token limits across the team no matter which editor the traffic came from. Editor choice stopped mattering to finance. That was the point.

The pattern is ordinary. Treat the ACP connection like any external microservice integration. It needs:

• Authentication. Every request carries an identity header, not an anonymous session.
• User mapping. The gateway resolves that identity to a named developer, so usage is attributable.
• Rate limiting. Limits apply before the request reaches the model provider, not after the invoice arrives.

None of this is exotic. It’s what you already do for a payment API or an internal data service. The mistake is skipping it because the client happens to be a text editor.

There is a cost. The gateway is a single point of failure and adds some latency, so it needs its own availability plan. Otherwise a gateway outage becomes a team-wide outage.

Black-Box Models Fail Audit Without System Logs

WaterDoctor operates under strict data governance and compliance requirements. We learned early that a black-box model is hard to defend in an audit unless the system boundary is logged.

You can’t audit the internal reasoning of a language model. Nobody can hand an auditor a trace of why the model chose one token over another. What you can audit is what the model asked to do. That’s a finite, inspectable list of actions, and every one of them crosses the editor-agent boundary.

That makes the ACP layer the natural logging choke point, but only if you make it one. Deny the agent direct filesystem and shell access, and require every file read, file write and command execution to go through the mediated interface. If the agent can touch the workspace directly, your log is incomplete by design. Once the boundary holds, record everything that crosses it. At minimum, each entry should capture:

• the identity of the developer and the agent that issued it,
• the action type and its target path or command,
• the timestamp and the outcome, including refusals.

Store these payloads in a centralized log aggregator, not on the laptop. Local logs disappear the moment a disk is wiped or a developer leaves. A central store gives you procurement evidence when you compare agent vendors, and security evidence when someone asks what an agent touched last quarter. One caution: logs of file contents can themselves hold proprietary code or secrets. Log paths and commands by default, and restrict access to the store.

Registry metadata deserves the same treatment. If an agent arrives through a registry, what that registry says about its publisher, version and declared capabilities is evidence. Capture it at install time and keep it next to the runtime logs. When an auditor asks why a given agent was permitted, you want a record of what you knew when you approved it, not a recollection.

Defining Circuit Breakers And Install Scope

Agents fail, and they fail in specific ways. They hallucinate shell commands. They get stuck in execution loops, retrying the same broken change against a failing test until something external stops them. A human at the keyboard usually notices. An unattended session doesn’t.

Because ACP is an integration contract, define the failure modes up front, as you would for any service dependency. Decide, in writing, how the editor behaves when:

• the network times out mid-task,
• the gateway rejects a request for exceeding a token limit,
• the agent attempts a directory traversal outside the workspace.

Each of those needs a defined outcome: halt, surface the error to the developer, and log it. A retry loop that burns budget until someone notices is not a policy. Cap iterations, cap spend per session, and let the circuit break.

Install scope is the other half. The agent process must not inherit root access, and it shouldn’t inherit the developer’s full environment either. Restrict workspace permissions before the agent reads a single file. Give it the repository it was invoked for, the commands it needs, and nothing adjacent. A local agent launched from an editor runs, by default, with the permissions of whoever started it. That default is too generous, and narrowing it is your job. Don’t assume the protocol will do it for you. Enforce the boundary with operating-system controls such as a restricted user, a container or a sandbox, and use the gateway as a second layer.

Scoped installs also make the logs worth reading. An agent that can reach anything produces a log where you can’t judge actions as normal or abnormal. An agent with a defined perimeter produces a log where the exceptions stand out.

Govern The Traffic Or Lose The Toolchain

Don’t wait for a data exfiltration incident to formalize your agent connections. By then the decision is no longer yours.

Leave ACP traffic ungoverned and you invite a compliance review you can’t pass. Without logs and scope, nobody can tell safe usage from unsafe, and ripping out the AI toolchain becomes the most defensible answer to an integration nobody can account for. The teams that keep their agents are the ones who can show, per request, who asked for what and what came back.

ACP will make coding agents portable across editors, and that portability is genuinely useful. It also means the editor no longer contains the risk. The boundary between editor and agent is where identity, budget, evidence and failure handling now live. Treat it as a production microservice, and give it an owner, a gateway, a log and a perimeter before you need them.