Compatible by protocol sounds reassuring: if an external agent speaks to Devin Desktop in one language, then it behaves like one of your own. That is a convenient but wrong reading. ACP, the Agent Client Protocol, standardizes communication between an editor and an agent - much the way the Language Server Protocol once standardized the connection of language servers. A shared communication language is a lot, but it is not a shared trust policy, and this is exactly where the naive picture fails.
The naive move is to connect a favorite third-party agent as one more tab inside Devin and treat it like Devin Local: the same expectations about data, privacy and billing. Devin Desktop encourages this by showing compatible agents right in the Command Center next to its own. Among the official examples are Codex CLI from OpenAI, Claude Agent from Anthropic, OpenCode, Junie from JetBrains and Gemini CLI from Google.
It breaks exactly at the boundary between communication and policy. The protocol sets how the editor and the agent exchange messages (for local agents - JSON-RPC over stdio) and reuses the representations from MCP where possible. But with external ACP the operations are executed not by Devin but by the third-party agent. The documentation warns directly: Devin Desktop's privacy policy and legal terms do not apply to an external ACP agent, and billing is directly between you and the agent's provider.
The professional mechanism here is to separate two layers of the decision. The first layer is technical: is the agent ACP-compatible, is it shown in the Command Center, how does it launch. The second layer is trust: whose terms these are, where your data is stored, whether it is used for training, what rights the subprocess has, whose account is billed. Compatibility is decided by the protocol; trust is decided by you, and no protocol makes that decision for you.
Why the protocol is useful nonetheless, despite this boundary. ACP decouples agents and editors: an agent implementing the protocol works with any compatible editor, and an editor gains access to a whole ecosystem of agents without a separate integration for each. This is the same benefit LSP gave: one standard point instead of a quadratic number of pairwise integrations. Without such a standard every agent-editor pair would require a separate integration, and the ecosystem would grow slowly and unevenly. The value is real - but it is about communication, not about whom you trust with code and data.
The cost of ignoring this boundary is legal and financial at once. By granting an external ACP agent access, you carry code, data and billing beyond Devin's policy, often without noticing the moment. So before granting access you check the provider's terms on four points: retention (what is stored and for how long), training (whether data goes into training), subprocess permissions (what the agent's process may do on your machine) and account (whose account and whose responsibility all of this runs under).
An external ACP agent is justified where you need precisely its specific ecosystem or capabilities Devin lacks, and where you have read and accepted the provider's terms. The sign of a deliberate choice is that you can name what this agent gives beyond Devin and which terms on data and billing you agreed to in doing so. If there is no answer to the second half, the choice was made on the first half only, and the second will arrive as a bill or a leak.
Here you must check before the action, not after. Before connecting - the provider's terms and what exactly the ACP agent will get on your machine. On availability - that ACP is included in Pro, Max and Teams, and in Enterprise is enabled through the account team. And separately remember Restricted Mode: it disables ACP along with the other agents, so where autonomy is unacceptable an external agent does not run by definition. Checking before rather than after is not over-caution here but the only cheap moment: once access is granted the terms already apply, and what was handed over usually cannot be recalled after the fact.
Hence the engineering conclusion: protocol and policy are different layers, and confusing them is expensive. A shared protocol makes the connection possible and uniform; it says nothing about whose rules apply inside a third-party agent's session. Treat an ACP agent as an external contractor with its own contract, not as a part of Devin: the communication is shared, the responsibility is separate. This is a consequence of the design, not over-caution.
The typical failure is trusting an external agent as your own and catching yourself when data and money have already gone beyond Devin's boundary. The symptom is recognized like this: the agent was connected for its capabilities, no one opened the provider's terms, and the question where is our code now and who pays for it arises after the first serious task. Before granting access, name whose terms these are and what goes outside - the protocol is shared, but no one agrees the trust policy for you.