AI coding agent security checklist: 15 checks before you trust one

You are about to grant a program read and write access to your repository, your shell, and — indirectly — your credentials. It will execute commands you did not write, read files you have never opened, and send summaries of its work to a model you do not control. Before you trust it, walk through these 15 checks. Each is a concrete thing you can verify in an afternoon, and each addresses a failure mode seen in real incidents.

Secrets and context: checks 1–5

1. Do secrets ever enter the agent’s context? If API keys or tokens appear in the prompt or the model’s input, a leak is a matter of when. Values should be referenced by name, never by value.
2. Can the agent read your credential store without a prompt? If the store answers any request silently, the agent is effectively holding every credential. Require confirmation at the boundary.
3. What happens to tool output that echoes secrets? Tools print environment dumps, connection strings, and debug output. Verify that stdout and stderr from agent-run commands are sanitized for secret-shaped strings, including base64 and URL-encoded variants.
4. Does the agent’s own config contain credentials? Agent config files accumulate tokens, API keys, and key paths. Audit them like you audit .env.
5. Is outbound traffic protected? If the agent talks to an LLM API, that traffic is the exfiltration channel. Route it through a DLP layer that scans for known secrets and high-entropy strings before they leave the machine.

Access and persistence: checks 6–10

6. Are the credentials it uses least-privilege? The agent should use scoped, short-lived keys that do the minimum and can be revoked without touching production credentials.
7. Can the agent modify the credential store? An agent that can add or delete entries is one injection away from persistent control. Keep the store read-only from the agent’s perspective.
8. Does the agent persist what it saw? Checkpoints, transcripts, and logs capture context. If secrets entered the context, they persist too. Know where session data is written and who can read it.
9. Does it fail closed? When a session key is invalid or a store is unreachable, the agent should stop — not continue with degraded or cached access.
10. Can web content reach the agent as instructions? Reading a README, a webpage, or an issue is how indirect prompt injection happens. Fetched content should be treated as data, not as commands.

Verification and recovery: checks 11–15

11. Are tool integrations pinned and reviewed? MCP servers, plugins, and extensions expand the attack surface. Each one is a new way to read files or run code.
12. Is there an audit trail? You should be able to answer “what did the agent run, and what did it resolve?” with an append-only log that does not contain the secret values themselves.
13. Is the toolchain verified? The agent binary, runtime, and plugins should be installable with checksums or signatures so a supply-chain compromise is detectable.
14. Is there a revocation plan? Decide in advance what happens when an agent-held key leaks: which keys rotate, who is paged, and how long it takes.
15. Have you tested the failure mode? Assume the agent is fully compromised and ask what it can exfiltrate in ten seconds. Whatever it can reach, an injection can reach.

Where the checklist leads

Most of these checks share a theme: the agent should have access, not keys — and what it cannot be trusted with should be kept out of its reach structurally rather than by instruction. A credential broker that injects secrets at process spawn, sanitizes output, and logs every resolution covers checks 1, 3, 9, and 12, plus parts of 2 and 8. trustless is an implementation of that pattern; the command reference is in the docs.

Which of these 15 checks would your current setup fail — and how quickly could you verify it?