AI Coding Agent Security & Vendor Review Checklist

1. Data exposure: what leaves the repository?

Ask the vendor which prompts, source files, terminal output, generated code, embeddings, telemetry and feedback are processed. Separate training use from operational storage and abuse monitoring. Request retention windows, deletion behavior, subprocessor information and relevant locations for each enabled feature. Treat unknown answers as open evidence requests, not automatically as a failed vendor.

• Evidence to request: the dated data-use terms, applicable contract, model settings and a diagram of the enabled data flows.
• Decision connection: if sensitive code requires a deletion commitment that has not been established, keep that data out of the pilot until the reviewer resolves the gap.
• Do not upload real secrets or customer data just to test what gets collected. Use synthetic fixtures and inspect only systems you are authorized to review.

2. Agent permissions: separate prompts from enforcement

List what the agent can read, modify, execute, install, reach over the network, commit and publish. A permission prompt is a different control from operating-system isolation or an account-level restriction. Cursor describes terminal allowlists and Auto-review as best-effort guardrails rather than a hard security boundary. This is a reason to review the execution environment, not a conclusion that every agent behaves the same way.

Official source for this requirement

• Suggested record: action, resource scope, enforcement mechanism, who can change it, test evidence and exception owner.
• Keep merge and deployment authority separate from permission to generate a patch. Human review should include configuration and workflow changes, not just application code.

3. Secrets: remove access before relying on filtering

Inventory credentials available through files, environment variables, Git history, cloud profiles and connected tools. Keep production credentials out of the pilot environment. Use narrowly scoped test credentials where an integration is essential, and record how they are revoked. An ignore file should be tested for the relevant features; it should not be assumed to constrain every shell command or external tool.

• Suggested evidence: an inventory of credential types and access scopes, without placing the secret values in the approval register.
• Check with dummy markers whether excluded test files appear in agent context, logs or generated changes. Passing a small test does not establish resistance to every prompt injection.
• If an actual credential is exposed, follow your incident process and revoke or rotate it; do not merely delete it from the visible transcript.

4. Shell, network and MCP: check each execution path

Review MCP servers as additional software and data recipients. Record their operator, hosting, version, authentication scope, available actions and update process. Include plugins, hooks, setup scripts and repository instructions in the review. Content read by an agent can contain malicious instructions; a repository file or tool result should not independently authorize wider access.

Official source for this requirement

• Claude Code documents filesystem and network isolation for its sandboxed Bash tool. Confirm the actual sandbox scope and exceptions rather than generalizing that protection to every integration.
• GitHub documents that the Copilot agent firewall does not cover MCP servers or processes started in configured setup steps. Review those paths separately.
• Suggested pilot condition: only explicitly reviewed integrations, no production write access, and no automatic installation of new tools.

5. Enterprise controls: prove availability and enforcement

Ask about SSO, provisioning and deprovisioning, central policies, model restrictions, audit events and repository access controls for the purchased plan. Record whether the control is mandatory, configurable by a member or unavailable. A screenshot of a setting is useful evidence of configuration; an authorized test of the setting adds evidence of behavior.

• Suggested checks: remove a test user, revoke a test integration, and confirm an unapproved test repository remains inaccessible.
• Identify who can add models or integrations. Include personal-account use in the rollout policy so the approved workspace does not become optional.
• Record which events can be exported, who can read them, how long they remain available and whether logs themselves contain confidential material.

6. Assurance: inspect the scope behind the badge

A security report or certification is evidence to assess, not blanket approval for your deployment. AIUC-1 reports that Cursor underwent coding-agent evaluations covering issues such as secrets leakage, prompt injection and secure code generation. Its account describes a representative enterprise configuration; request the scope and detailed evidence instead of assuming the result covers every mode or configuration. AIUC-1 is an example of agent-focused assurance, not a mandatory requirement in this checklist.

Official source for this requirement

• Ask which version, controls, models and operating conditions were assessed, and which exclusions remain.
• Use existing SOC 2 or ISO evidence where relevant, then identify unanswered questions about agent behavior and tool execution.
• Keep vendor statements, independent assessments and your own tests visibly separate in the record.

Worked decision: approve a restricted pilot, block production access

Fictional example: a five-person engineering team wants an agent to draft unit tests for a non-production service. The proposed pilot lasts 14 days on a managed account and one sanitized repository. The reviewer has checked data-use terms and the configured repository boundary, but has not established acceptable conditions for production credentials or external MCP servers. The decision is “pilot with restrictions”, not company-wide approval.

• Allowed: read the sanitized repository, edit a working branch and run tests in a disposable environment with synthetic data.
• Restricted: dependencies come from approved sources; proposed changes receive human review before merge; new integrations require a separate assessment.
• Blocked for this pilot: production credentials, customer datasets, deployment rights, direct writes to the protected branch and unreviewed MCP servers.
• Owner: engineering lead; approver: designated security reviewer; expiry: 14 days after pilot start. Stop if the agent reaches an out-of-scope resource or unexplained data transfer is observed.
• Exit evidence: useful patches, review effort, failed boundary checks, unresolved vendor questions and a recorded decision to extend, narrow or end the pilot. These are illustrative conditions, not a certification of any named vendor.

From a free checklist to a reusable vendor review

Use this page to identify the questions your team needs to answer. The existing AI Vendor Review Questionnaire provides reusable data-use, training, retention, deletion and subprocessor questions plus decision bands and blocker criteria. It does not configure a sandbox, inspect your tenant or certify an agent. If vendor evidence is already complete and you only need to document internal approval, the smaller AI Tool Approval Form and Register may be sufficient.

Official sources

• Cursor — Agent Security
• Claude Code — sandboxed Bash tool
• GitHub — Copilot firewall and limitations
• AIUC-1 — Cursor certification scope and evaluations