Practical checklist

AI Agent Security Checklist

Use this checklist before an AI agent touches browsers, customer systems, files, SaaS APIs, email, CRM, billing, support tickets or internal documents. It is written for small teams that need practical launch-readiness evidence, not a full enterprise security program.

0. Standards Anchor

  • Map high and medium issues to practical OWASP Agentic, OWASP LLM or NIST AI 600-1 themes.
  • Use the mapping to focus fixes, not to claim a formal certification.
  • Separate confirmed findings from hypotheses.
  • For every high or medium issue, write the fix, retest step and reason it pays back.

1. Scope And Permissions

  • List every tool, API, file path, browser profile and external domain the agent can reach.
  • Replace broad permissions with allowlists for domains, commands, records and action types.
  • Separate read-only tools from write-capable tools.
  • Set rate limits, spend caps, retry limits and maximum batch sizes.

2. Prompt Injection Boundaries

  • Treat web pages, PDFs, tickets, emails, CRM notes and API responses as untrusted content.
  • Do not let untrusted content change system instructions, tool policy or approval rules.
  • Test hidden instructions, role impersonation, data-exfiltration requests and encoded payloads.
  • Keep tool outputs clearly separated from trusted operator instructions.

3. Browser And Session Safety

  • Use a dedicated browser profile for the agent instead of a personal session.
  • Disable or tightly control downloads, uploads, clipboard use and saved passwords.
  • Constrain navigation to the minimum required domains.
  • Record enough evidence to replay what happened without exposing secrets.

4. Approval Gates

  • Require human approval before sending external messages, issuing refunds, changing permissions or updating many records.
  • Show the exact tool call, arguments, target account and expected impact before approval.
  • Log who approved, when, and what changed after approval.
  • Block approval if the agent cannot explain why the action is safe.

5. Logs, Secrets And Recovery

  • Redact tokens, credentials, customer secrets and private messages from logs by default.
  • Store prompts, tool outputs and screenshots only when they are needed for debugging or audit evidence.
  • Document rollback, token revocation and incident-response steps before launch.
  • Run a small retest after every permission or tool-scope change.

6. What A Paid Report Should Add

  • A launch verdict: ship, ship after fixes, or stop until a high-risk gap is closed.
  • Top findings with evidence, severity, framework mapping, fix and retest step.
  • One to three remediation tickets ready to assign.
  • A short customer/security note the team can reuse.
Run the free self-check View sample deliverable