Security Review Checklist for Rolling Out AI Agents

Define exactly what the review approves

Open a review record for one deployment: agent and version, execution location, MCP endpoints, upstream systems, permitted datasets, task owner and pilot expiry. A laptop assistant and a CI worker need separate records when their identities or reachable systems differ. Attach the effective configuration used during testing.

• ☐ Name an allowed task, such as summarizing staging incidents, and prohibited actions, such as changing production incidents.
• ☐ Map where prompts, retrieved records, tool results and transcripts leave the execution environment.
• ☐ Record each check below as pass, fail or not applicable, with an owner and evidence location. Explain every not-applicable decision.

For a Claude Code pilot, this uses the documented HTTP setup syntax; replace the example endpoint with your reviewed server:

claude mcp add --transport http review-tools --scope local https://mcp.example.com/mcp

Anthropic documents local scope as project-specific configuration private to the user. It does not grant read-only access or limit upstream privileges. For an OAuth server, complete sign-in through /mcp before testing.

Account for every credential and its revocation path

Require a credential inventory covering agent-facing keys, upstream tokens, refresh tokens and local credential files. Each entry needs a custodian, storage location, granted resources, expiry or rotation policy, and tested revocation procedure. Keep secret values out of the review packet.

• ☐ Give each pilot agent an attributable identity; separate development, CI and production access.
• ☐ Check repository files, VM images, environment variables and job artifacts for unintended credential copies, using synthetic secrets during testing.
• ☐ For HTTP MCP OAuth, submit a token intended for another resource and verify rejection. The MCP authorization specification requires intended-audience validation.
• ☐ If a gateway connects onward, document its separate upstream authorization. MCP security guidance forbids accepting incorrectly targeted client tokens and passing them unchanged downstream.

For GitHub Actions accessing a supporting cloud provider, evaluate OIDC: GitHub documents exchanging a workflow identity for short-lived cloud credentials. Review the cloud trust conditions; do not assume that this also authenticates an unrelated MCP endpoint. Use a separately scoped identity for each agent when that endpoint uses keys.

Prove permissions at the execution boundary

Attach an allowlist of source, tool, target resource and allowed operation. Review the upstream account's actual privileges alongside gateway policy. The MCP tools specification says annotations are untrusted unless supplied by trusted servers; a read-only label alone cannot prove what an implementation does.

• ☐ Run one permitted read and one prohibited write against disposable fixtures. Confirm the denial at the service enforcing permission.
• ☐ Request another team's resource using its identifier. Verify that neither its content nor sensitive metadata returns.
• ☐ Call a prohibited tool directly, even if discovery omits it. Hiding a tool is insufficient evidence of authorization enforcement.
• ☐ For approved writes, require a preview identifying the target and proposed change. Test whether changing those parameters invalidates the approval.

Keep autonomous writes disabled during the first read-only pilot. If a later phase needs writes, approve that expanded scope separately. Record the denied request and resulting resource state, rather than treating the agent's refusal message as proof. The annotations and permissions guide explains the distinction.

Test the sandbox and the software it actually contains

Specify the runtime boundary: whole VM, container, or an individual command sandbox. Anthropic's sandbox documentation explicitly places Claude Code's MCP servers and hooks outside its Bash sandbox. Review those processes separately; enabling shell isolation does not establish their isolation.

• ☐ Attempt access to a synthetic credential file outside the approved workspace and an unapproved network destination. Exercise shell commands and tool processes separately.
• ☐ Inventory host mounts, inherited environment variables, helper processes and access to host services. Remove capabilities the pilot task does not need.
• ☐ Record installed server packages, versions, runtime versions, installation sources and update owners. Identify every laptop, image and runner that needs rebuilding after a patch.
• ☐ Recreate the pilot from its approved image and configuration, then repeat the boundary tests. Record any escape or unsandboxed retry path.

A disposable VM still needs explicit network and credential restrictions. Include the output destination in the test: an agent that can read an incident record and send it to an arbitrary host has exceeded the proposed rollout boundary.

Review memory and skills as persistent inputs

Make persistence a separate approval decision. Document what survives a session, who can read or edit it, how long it remains, and which service receives transcripts for extraction. OWASP's AI Agent Security guidance calls for isolated memory, expiration limits and sensitive-data review before persistence.

• ☐ Begin with capture disabled. If enabled later, test a synthetic token through capture, extraction and recall; inspect every retained representation.
• ☐ Save a canary in one user's private memory and attempt retrieval as another user and workspace. Verify denial through search and direct reads.
• ☐ Plant an instruction in a retrieved document asking the agent to persist a permission override. Test the next session and record whether it influences tool requests.
• ☐ Review shared skills for commands, downloads and credential expectations before distribution. Assign an editor and a way to withdraw a version.

Delete the canary and verify its absence from later recall. Include derived indexes and a documented backup retention policy in the review; deleting a visible note proves only that particular deletion.

Make misuse visible and containment measurable

Produce a trace from the pilot identity to the source, tool, time, outcome and duration. For a consequential write, require enough redacted target information to distinguish what changed. Keep raw secrets and unnecessary record contents out of logs.

• ☐ Trace a successful call, an authorization denial and an upstream timeout. Verify that failure is visible to both the caller and the operator.
• ☐ Set tool-call, retry and concurrency budgets for the pilot. Exhaust a small test allowance and verify execution stops instead of repeatedly retrying.
• ☐ Revoke the pilot credential while its session remains open. Attempt another call and record the observed denial time.
• ☐ Disconnect a source and test access again. Check whether separately issued upstream credentials still permit a bypass.

Run a tabletop exercise with the actual operator: identify the agent from a suspicious event, stop new access, preserve relevant evidence and identify resources requiring recovery. Measure detection-to-denial time. Use the compromised-agent response guide to expand the procedure after the pilot's basic containment drill passes.

Evidence to collect when using SPYN3

SPYN3 provides one MCP endpoint per workspace; upstream credentials remain envelope-encrypted in the workspace and never reach the agent. Keys can be scoped to sources; writes need call:write_tools, while memory writes separately need write:memory. Proxied tool calls record source, tool, outcome and duration. Revoking a key or disconnecting a source takes effect on the next call. For the review, demonstrate those denials with the pilot key and confirm whether Memory & skills and capture, both off by default, are enabled.

Use a release gate with recorded results

The following is a proposed acceptance sheet for a staging incident-summary pilot. Populate the evidence column with observed results before granting access to company data.

The security reviewer and system owner sign the permitted scope, unresolved exceptions and pilot end date. A failed credential, isolation or authorization test blocks that access path. Retest after changing the agent version, tool implementation, credential grants, sandbox policy or persistence settings. Preserve the approved configuration with the results so the next review can identify exactly what changed.