Enterprise AI Coding Agents (2026): Buy the Control Plane, Not the Agent

Every enterprise evaluation of AI coding agents starts by comparing what the agents can do. That comparison is mostly a waste of a quarter, because the serious tools converged on capability some time ago and the differences that remain are smaller than the difference between two of your own teams.

What has not converged is the part around the agent: what your organisation can see, scope, revoke and prove. That is what you are actually buying, and it is what a feature table never shows.

The five controls

Evaluate these before anyone runs a bake-off.

1. Identity. SSO, and specifically SCIM. Without provisioning and deprovisioning wired to your directory, an offboarded engineer keeps access until somebody remembers. Ask what happens to their sessions and their tokens on the day they leave, and ask it in those words.

2. Data handling. Two separate questions that vendors often answer as one. Is your code retained, and for how long? Is it used for training? A "no training" commitment with a thirty-day retention window is a different product from zero retention, and only one of those survives contact with a regulator who asks where the code was at 3am on a Tuesday.

3. Audit. Not a dashboard. An export, into your own log store, of who prompted what, which repositories were read, and which changes were proposed. If the only record lives in the vendor's UI, your incident review depends on their uptime and their retention policy.

4. Scope. What the agent may read and what it may reach. An agent with blanket read across every repository is a lateral-movement path with a subscription. The useful question is whether access can be scoped per team and per repository, and whether the agent respects the permissions your source control already encodes. Sourcegraph's framing of enterprise agents makes this the central point rather than an afterthought, which is the right instinct.¹

5. The merge gate. Whether the agent can put code into your main branch without a human approving it. There is exactly one correct answer during a first rollout, and it is no.

Why there is no compliance matrix here

The obvious thing for an article like this to publish is a table: vendor down the side, SOC 2 Type II, SSO, SCIM, audit logs, zero retention across the top, ticks in the middle.

We are not printing one, and the reason is worth more to you than the table would be.

A compliance matrix is only true on the day each cell was checked against that vendor's own trust page, and it decays fast: certifications lapse and renew, scopes change, enterprise tiers get renamed. A matrix assembled from vendor marketing pages and other roundups, which is how nearly all of them are assembled, is a set of claims about the past presented as facts about the present. And a reader will act on it, because it looks like the answer.

What survives longer is the interrogation. Six questions, in this order:

1. Is the SOC 2 report Type II, current, and can we read it under NDA?
2. What is in the scope section of that report? Badges do not have scopes; reports do.
3. Is retention zero, or is it short? Get the number.
4. Is the no-training commitment in the contract, or in a blog post?
5. Can audit events be exported to our SIEM, and at what granularity?
6. What is the sub-processor list, and how are we notified when it changes?

Any vendor selling to enterprises can answer all six in a call. The ones who cannot have told you something.

Shadow AI is the real risk

The threat model most evaluations write down is the vendor: their retention, their breach history, their sub-processors. The failure that actually happens is internal.

If the approved tool is slower, more restricted, or simply worse than the free one a developer already has open, they will use the free one. On a personal account. With a personal key. On your codebase.

At that point the organisation has paid for a control plane and lost the visibility it bought, which is a worse position than before the purchase, because now everyone believes the problem is handled.

Two consequences for how you evaluate:

• Developer experience is a security control. A tool your engineers prefer is a tool they use inside the boundary. Weight it accordingly.
• Measure the gap, not the policy. Look at what is actually running. Approved-tool licence utilisation against headcount is a rough but honest proxy, and a low number means your policy is fiction.

The same class of blind spot applies to what the code itself exposes, which is why an external scan is a useful complement rather than a substitute; our Vibe Scan review covers what that kind of check can and cannot see.

Measuring it, after the pilot

The metric a vendor will offer is lines of code, or its cousin "accepted suggestions". Both are trivially inflated by an agent and both correlate with the opposite of what you want, because more code is a cost.

Measure three things, before and after, against a comparable team that did not get the tool:

Review latency is the one people forget and the one that moves first. An agent that doubles the number of pull requests without doubling reviewers has not made the team faster; it has moved the queue.

Run the pilot for a full quarter on one team, and instrument it before you start. A pilot with no baseline produces a decision made on vibes at the end of it.

When not to buy yet

The honest cases for waiting, none of which vendors will raise:

• Your codebase has no tests. An agent's value scales with the checkability of the work. Without a signal for done, you are buying volume and paying for it in review.
• Your permissions are already unclear. Adding an actor that inherits confused access makes an existing problem harder to reason about, not easier.
• You cannot yet answer the six questions for your own environment. If you do not know what your retention requirement is, no vendor answer will match it.
• The pilot has no owner. Rollouts without one become shelfware with an invoice.

None of those are arguments against agents. They are arguments for fixing the cheaper thing first.

Where to go next

• The stage-based version of this decision for smaller teams, in AI coding agents for startups.
• The capability comparison, which still matters once the controls are settled: best AI coding agents.
• Every tool with verified pricing in the directory, and the hub at AI coding agents.

FAQ

What makes an AI coding agent enterprise-ready? A control plane rather than capability: SSO and SCIM, documented retention and training terms, exportable audit logs, scoped access, and a merge gate the agent cannot bypass.

Do these tools have SOC 2? Several claim it. Ask for the Type II report under NDA and read its scope section. A badge on a marketing page is not a scope, and a comparison table is a snapshot of a date that has passed.

What is shadow AI? Developers using unapproved tools with personal accounts and keys, which happens whenever the approved tool is slower or more restricted than the free one.

How do we measure a rollout? PR throughput, review latency and change failure rate, against a comparable team, instrumented before the pilot starts. Never lines of code.

Should we self-host? Only when a specific requirement demands it, such as code that cannot leave your network. Self-hosting moves the model and its upgrades onto your team.

How long should a pilot run? A full quarter, on one team, with a named owner and a baseline captured before day one.