AI agent security checklist

AI agent security checklist

AI agents are a new attack surface wearing a familiar shape: a program with credentials, network access, and a tendency to follow instructions — including instructions that arrive in the data it reads. Securing an agent is not exotic; it's the same disciplines as securing any service, with a few agent-specific twists. This checklist is ordered roughly by impact. Work it top to bottom.

1. Credentials: least privilege, always

• Give the agent the minimum keys it needs — never your admin credentials, never a key with access to things the agent doesn't touch.
• Prefer scoped keys (per-service, per-project) over master keys. A leaked agent key should hurt like a leaked service key, not like a leaked root password.
• Store secrets in the platform's secret handling, not in prompts, not in skill files, not in agent memory. Agent memory is the most common place people accidentally persist credentials — and the most likely to be read by a prompt-injected instruction.
• Rotate anything the agent touches on a schedule, and immediately on suspicion.

2. Prompt injection: assume it will happen

Prompt injection is when an instruction embedded in data (an email, a web page, a document) hijacks the agent's behavior. The OWASP Top 10 for LLM applications (owasp.org/www-project-top-10-for-large-language-model-applications) treats it as a first-class vulnerability class, because it is.

• Assume untrusted content can steer the agent. Design workflows on that assumption: separate instructions from data, tell the agent what to do with suspicious content (stop and ask), and add human approval for high-stakes actions.
• Bound the blast radius. A prompt-injected agent with full tool access is a disaster; one with a scoped key and an approval gate is an annoyance.
• Watch the browser. Agents that browse the web are the classic injection vector — see item 5.

3. Egress and SSRF: control where it can go

An agent with network access can be pointed at internal services, metadata endpoints, or anything the server can reach. OWASP's SSRF guidance (owasp.org/www-community/attacks/Server_Side_Request_Forgery) describes the class: the agent fetches a URL supplied by an attacker, and the fetch lands somewhere privileged.

• The agent's network scope should not include your internal network or platform metadata endpoints.
• Outbound destinations should be constrained (deny link-local and internal address spaces; allowlist what you can).
• Browser automation (agents that drive a real browser) deserves its own scrutiny: it is a full client, with cookies, extensions, and history — cap sessions, isolate them, and don't run it on the same network as your control plane.

4. Backups and recovery: the security control people skip

Security isn't only about preventing access; it's about surviving the aftermath. A compromised agent whose memory and skills you can't restore is a permanent loss — often worse than the breach itself.

• Back up the agent's memory, skills, and configuration — the state that makes the agent yours.
• Verify backups (checksum, restore drill), encrypt them, and keep them separate from the runtime. NIST's contingency planning guidance (csrc.nist.gov/pubs/sp/800/34/r1/final) is the canonical reference for recovery planning discipline.
• Know your recovery point: how much work can you afford to lose? Your provider should be able to state retention and verification practices — or you're self-hosting by another name.

5. Updates: patch the agent like a service

Agents are software, and software gets vulnerabilities. Run updated versions — and prefer a provider or process that deploys tested versions with a rollback path, not "whatever the newest tag is." Version pinning (digest-level) and a changelog review before updates are the minimum bar for anything that holds credentials.

6. Audit and monitoring: know what it did

• Enable audit logging for sensitive actions: key issuance, config changes, restores, admin actions.
• Review agent activity periodically. A good question to ask weekly: what did the agent do that I didn't ask it to do? If you can't answer that, you don't have enough logging.
• Monitor the boring operational signals too: crashes, failed backups, unexpected restarts. Most incidents announce themselves in metrics long before they appear in headlines.

7. Human approval for irreversible actions

Anything the agent can do that you can't undo — sending money, deleting data, posting publicly — should require a human step. This is not cowardice; it is the single cheapest control in this checklist, and it converts most injection attacks from "disaster" into "noise."

8. Platform diligence

If you use a managed platform (including ours), ask the same questions you'd ask of any vendor: How are secrets encrypted at rest? Is there tenant isolation — separate storage, no shared memory across customers? What does the provider's backup verification actually check? Is there an SLA, and if not, what are the operational targets? Who are the subprocessors, and what do they process? A provider that can't answer in writing is a provider you're operating yourself.

The honest summary

None of this makes an agent unhackable — prompt injection in particular is not fully solvable with today's tooling. What this checklist does is convert the risk from "catastrophic and unknowable" into "bounded and detectable": scoped keys limit what a compromise reaches, egress controls limit where it can go, backups make it recoverable, and audit makes it visible. That's the entire game. Play it in that order.