Skip to main content
← All buyer guides

Buyer guide · agentic harnesses

Enterprise AI coding assistant procurement checklist

A compact procurement block for security, legal, IT, and finance teams evaluating coding assistants beyond the demo and the seat price.

Who this is for: Security, legal, IT procurement, and finance teams evaluating coding-assistant vendors for org-wide rollout — especially when editor plugins, terminal CLIs, cloud agents, and APIs each need separate approval.

What actually matters

  • SSO/SCIM and lifecycle management must cover every surface: IDE plugin, CLI, cloud agent, and API keys — not just the admin console.
  • DPA/SCC coverage must explicitly include prompts, source code, indexing, logs, subprocessors, and cloud-agent environments.
  • Training opt-out must be org-default and contractually enforceable, not only an individual toggle users can change.
  • MCP allowlisting, folder scoping, and tool-call logging are security controls — not optional developer convenience.
  • Seat price vs metered agent usage need separate budget lines; finance should set hard overage caps.
  • Controls may differ per surface — editor, terminal, API, and cloud agent are not automatically equivalent.

ACE recommendation

Record the answers per product surface before approving a rollout. Price baseline seats plus realistic agent usage and a contingency in the AI stack calculator, pilot with an MCP and model allowlist, and require a human review gate for generated code and cloud changes.

How to run this decision

  1. 01Inventory every product surface the vendor offers and mark which your pilot will actually enable.
  2. 02Send a security questionnaire covering SSO, DPA, residency, retention, training, subprocessors, and audit logs per surface.
  3. 03Require admin controls for MCP/extension allowlists and verify fail-closed behaviour on unknown tools.
  4. 04Model cost: baseline seats plus realistic agent usage from a two-week pilot; add contingency for bursts.
  5. 05Run a pilot with MCP and model allowlists on a non-production repo before org-wide approval.
  6. 06Document the human review gate for generated code and cloud changes in the rollout policy.

Common pitfalls

  • Approving “Cursor” or “Copilot” as a single product without per-surface security review.
  • Accepting marketing “enterprise-ready” claims without DPA language covering code and agent logs.
  • Letting developers use personal accounts on production repos — shadow IT bypasses every control.
  • Budgeting seats only and getting surprised by pooled agent credit exhaustion mid-quarter.
  • Assuming .cursorignore or similar files block MCP or approved shell commands.

Ask before you buy

  • SSO and lifecycle: does the exact IDE, CLI, cloud-agent, and API surface support SSO/SCIM, managed accounts, offboarding, and a ban on personal shadow seats?
  • DPA and residency: will the vendor sign a DPA/SCCs for the relevant jurisdiction, and does that agreement cover prompts, source code, indexing, logs, subprocessors, and cloud-agent work?
  • Training opt-out: is no-training the default, contractually stated, and enforceable by the organisation, or is it only an individual setting that users can change?
  • MCP allowlist: can administrators allowlist MCP servers and extensions, fail closed on unknown tools, limit folder/network access, and review tool-call logs?
  • Seat versus usage: what does each seat include, which agent/chat/cloud/API actions consume pooled credits or metered usage, and can finance impose a hard overage cap?
  • Surface scope: are security, retention, residency, audit logs, and model controls identical across the editor plugin, terminal client, API, and cloud agent, or must each be approved separately?

More buyer guides

Related decisions

Other harness buyer guides that answer the next question after this one.