What belongs on an AI agent security checklist?

Identity binding, scoped credentials, tool inventory and allowlists, authorization, untrusted content handling, runtime policy enforcement, human approval, egress controls, monitoring, testing, and incident response.

What is the minimum viable agent security before launch?

Tool allowlist, scoped credentials, authorization on every execution, Agent Action Guard before every tool call with enforced decisions, approval for send and destructive actions, untrusted content scanning, and audit logs.

How often should I re-run the agent security checklist?

Before initial launch, when adding tools or integrations, when changing models or prompts materially, and after any agent-related security incident.

Does the checklist replace runtime policy?

No. The checklist verifies you implemented controls including POST /api/v1/security/agent-action on every tool execution. Policy enforcement in code is a required checklist item.

Why separate checklist sections for authorization and Agent Action Guard?

They answer different questions: IAM whether the principal may act, guard whether the specific proposal matches security policy. Production requires both plus human approval for high-impact cases.

AI Agent Security Checklist

An AI agent security checklist is a production readiness audit for autonomous LLM workflows that call tools — covering identity, credentials, tool exposure, permissions, untrusted content, external communication, runtime policy, monitoring, and incident response. Use this checklist before launching or materially changing any agent that can read production data, send messages, modify records, or browse external systems.

This guide expands each item with what to verify, why it matters, and how it connects to AI agent security architecture. Check items off in order; later sections assume earlier foundations (you cannot runtime-gate tools you have not inventoried).

1. Identity and session boundaries

1.1 Define who the agent acts on behalf of

Check: Every agent session is bound to an authenticated user, service account, or explicit system job identity — never an anonymous "global agent."

Why: Authorization, audit trails, and tenant isolation depend on knowing the principal. Agents without identity binding become shared super-user channels.

Verify: Session creation requires auth; agent loops receive principalId and tenantId from your server, not from model output.

1.2 Separate user intent from agent automation

Check: Distinguish actions the user explicitly requested from actions the agent inferred while "helpfully" continuing a task.

Why: Users may authorize a lookup but not a bulk export. Explicit consent boundaries reduce excessive agency incidents.

Verify: Product UX shows when the agent moves from read to write or external send; optional user confirmation for mode changes.

1.3 Time-bound and scope-bound sessions

Check: Long-running agents have session TTL, idle timeout, and maximum tool-call budgets.

Why: Stale sessions accumulate context, secrets, and manipulated instructions over time. See Securing Long-Running AI Agents.

Verify: Sessions expire; exceeded budgets halt the loop with a logged reason.

1.4 Re-authentication for elevated operations

Check: High-impact operations (financial, destructive, cross-tenant) require fresh user verification or step-up auth — not only agent continuation.

Why: Session hijack or injection mid-conversation should not silently enable elevation.

Verify: Step-up auth events logged; agent cannot bypass via tool arguments.

2. Credentials and secrets

2.1 Agents never hold raw production secrets in prompts

Check: API keys, database passwords, and bearer tokens are not embedded in system prompts or chat history visible to the model provider.

Why: Prompts leak via logs, fine-tuning pipelines, and provider retention. Models parrot secrets into tool args and replies.

Verify: Audit assembled prompts; use server-side credential injection in tool runtime only.

2.2 Scoped credentials per agent type

Check: Each agent class uses dedicated credentials with minimum required scope — read-only for lookup agents, narrow write roles for action agents.

Why: Least privilege limits blast radius when the model is manipulated.

Verify: Credential inventory maps agent type → IAM role / DB user → permitted operations.

2.3 No credential pass-through in tool arguments

Check: Tools reject model-supplied Authorization headers, connection strings, and API keys in arguments.

Why: Injection may trick the agent into exfiltrating or misusing credentials supplied in user content.

Verify: Static analysis or tests assert tools ignore auth fields from proposal args.

2.4 Scan for secrets before external egress

Check: Outbound payloads (email body, HTTP body, file uploads) pass through secret and PII scanning.

Why: Agents copy secrets from context into send tools — a primary data exfiltration path.

Verify: Integrate POST /api/v1/security/pii-secrets or rely on Agent Action Guard secret rules; block unsafe payloads.

3. Tool inventory and exposure

3.1 Complete tool inventory documented

Check: Spreadsheet or code registry lists every tool name, integration, read/write/destructive class, and owning team.

Why: You cannot secure unknown tools. Inventory drives allowlists and policy rules.

Verify: Inventory matches tools exposed in production agent JSON schemas.

3.2 Allowlist tool exposure (default deny)

Check: Production agents use allowlists — only permitted tools appear in the model schema.

Why: Blocklists fail open when new tools ship. Allowlists fail safe.

Verify: CI test fails if production schema includes tools outside allowlist.

3.3 Destructive tools removed from general agents

Check: Delete, drop, revoke-all, and similar capabilities are absent from customer-facing agents or isolated to maintenance agents with stricter controls.

Why: Destructive operations need preview, approval, and audit — not general autonomy.

Verify: No destructive action names in general agent allowlists.

3.4 Split high-risk tools (draft vs send, preview vs delete)

Check: Email, payments, and mutations expose separate preview/draft and execute actions with different policy posture.

Why: Lets agents compose safely while gating side effects. See Secure AI Email Agents.

Verify: Send/execute paths require guard + approval; draft/preview paths logged only.

4. Permissions and authorization

4.1 Authorization independent of the model

Check: Application authorization runs on every tool execution — independent of LLM reasoning and independent of Agent Action Guard verdict alone.

Why: Guard evaluates policy on proposals; IAM evaluates whether the principal may perform the operation. Neither replaces the other. See AI Agent Permissions.

Verify: Tests show authorized user + policy block = no execution; unauthorized user + policy allow = no execution.

4.2 Read vs write vs admin separation

Check: Permission model explicitly separates read, write, destructive, and admin capabilities per role.

Why: Read access still enables exfiltration when paired with send tools — classify accordingly.

Verify: Role matrix documented; agent service accounts assigned minimal roles.

4.3 Tenant isolation enforced below the LLM

Check: Row-level security, repository filters, or API scoping enforce tenant boundaries — not prompt instructions.

Why: Models propose cross-tenant IDs under injection or error. Enforcement must be deterministic in code.

Verify: Negative tests attempt cross-tenant access via agent tools; all must fail.

4.4 Database access hardened

Check: Database tools use capped row limits, allowlisted tables, parameterized queries, and no arbitrary SQL from model text.

Why: Database agent incidents are high severity.

Verify: Tools reject dynamic table names and unbounded SELECT/export patterns.

5. Untrusted content (RAG, web, tool output)

5.1 Treat retrieved and fetched content as hostile

Check: RAG chunks, web pages, emails, and tool outputs are labeled untrusted data — never instruction overrides.

Why: Indirect prompt injection and web page injection steer agents toward harmful tool calls.

Verify: Prompt templates structurally separate system instructions from untrusted data blocks.

5.2 Scan untrusted content before re-prompting

Check: Injection and secret scanning runs on retrieved/fetched text before it enters the agent context.

Why: Reduces instruction override and secrets entering memory.

Verify: Pipeline logs scan verdicts for retrieved content; block or strip high-risk chunks.

5.3 Tool output injection controls

Check: Tool results are scanned or sanitized before returning to the model; high-risk outputs trigger stricter sink policy.

Why: Compromised APIs and hostile pages return malicious instructions. See Tool Output Injection.

Verify: Documented handling for unsafe tool output; session flags when injection detected.

5.4 Web browsing SSRF and URL controls

Check: Browse tools validate URL scheme and host, block internal/metadata addresses, sandbox browser automation.

Why: Browsing agents extend attack surface to the public web and internal network if misconfigured.

Verify: SSRF test suite against internal IPs and redirect chains.

6. Runtime policy (Agent Action Guard)

6.1 Guard called before every tool execution

Check: Single tool dispatcher calls POST /api/v1/security/agent-action with tool_name, action, arguments, and context before side effects.

Why: Runtime security is the last responsible gate before credentials are used.

Verify: Code search shows no bypass path to tool runtime; integration tests mock guard responses.

Example request:

curl -X POST https://www.identicapi.com/api/v1/security/agent-action \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "tool_name": "email",
    "action": "send",
    "arguments": { "to": ["u@example.com"], "subject": "Hi", "body": "..." },
    "context": "Support agent reply"
  }'

6.2 Enforce allow, review, and block in application code

Check: block never executes; review queues for approval; allow still passes authorization.

Why: API decisions are advisory if your runtime ignores them.

Verify: Unit tests for all three decisions; metrics emitted per decision type.

6.3 Custom policy_id aligned to tool naming

Check: Production uses custom policies matching your tool and action conventions — not only default keywords.

Why: Default rules miss domain-specific destructive names and external send patterns. See Policy design.

Verify: Policy rules version-controlled; CI fixture set tests allow/review/block expectations.

6.4 Fail-closed for write-capable agents

Check: When guard API is unavailable, write/external/destructive-capable agents stop execution and alert — not silent proceed.

Why: Fail open during outage creates a policy bypass window.

Verify: Chaos test or simulated timeout confirms documented fail behavior.

7. Human-in-the-loop approval

7.1 Approval triggers defined

Check: Documented list of conditions routing to human review — financial thresholds, bulk export, first external send, destructive preview, guard review, post-untrusted-content sinks.

Why: Prevents approval fatigue and gaps. See Human-in-the-loop workflows.

Verify: Triggers match product policy; reviewers trained on queue semantics.

7.2 Approval UI shows structured proposal

Check: Reviewers see tool, action, arguments, affected counts, recipients — not only model narrative.

Why: Models mis summarize; injection hides in details.

Verify: UX review with security team; proposal hash displayed.

7.3 Proposal binding and TTL

Check: Approved actions bind to cryptographic hash of proposal; approvals expire.

Why: Prevents bait-and-switch after human clicks approve.

Verify: Modified args after approval do not execute.

7.4 Reviewer authorization re-checked

Check: Approver must hold permission for the underlying operation at approval time.

Why: Approval queues are not a bypass for IAM.

Verify: Tests deny approval from under-privileged reviewer accounts.

8. External communication and egress

8.1 Destination validation for email and HTTP

Check: Recipient allowlists, domain blocklists, and HTTP host allowlists enforced in tool code and policy.

Why: Agents otherwise become exfiltration channels.

Verify: Send to non-allowlisted domain fails in tool layer and in guard policy.

8.2 Rate limits and bulk controls

Check: Limits on recipients per email, HTTP requests per session, and export row counts.

Why: Slow exfiltration and accidental mail merges still cause incidents.

Verify: Load tests hit limits; agent receives safe failure.

8.3 Source-to-sink path analysis

Check: Document which sources (web, RAG, user) may precede which sinks (send, post, write).

Why: Source-to-sink security catches read-then-send chains.

Verify: Stricter policy when session flagged after untrusted fetch or retrieval.

9. Monitoring, logging, and incident response

9.1 Log proposals, decisions, and outcomes

Check: Every tool proposal logs guard decision, policy_reason, findings, principal, tenant, correlation ID — without storing full sensitive payloads.

Why: Forensics and tuning require structured telemetry. See Runtime monitoring.

Verify: Sample logs reviewed for PII leakage; retention policy documented.

9.2 Alert on anomaly patterns

Check: Alerts for spikes in block, review queue depth, cross-tenant proposal attempts, read-then-send sequences.

Why: Early detection limits incident scope.

Verify: Runbooks link alerts to on-call actions.

9.3 Incident response runbook for agent abuse

Check: Runbook covers disabling agent tools, rotating scoped credentials, preserving audit logs, and customer notification criteria.

Why: Agent incidents combine security and product response.

Verify: Tabletop exercise completed; kill switch tested.

9.4 Policy and prompt change control

Check: Agent prompt, tool allowlist, and policy changes require code review and staged rollout.

Why: Drift is a common source of new exposure.

Verify: Git history links deployments to checklist re-validation.

10. Testing and continuous validation

10.1 Adversarial test set for tool proposals

Check: CI runs fixture proposals — benign reads, normal writes, destructive actions, secret-laden args, injection phrases in context — against production policy_id.

Why: Policies regress when tools change.

Verify: Expected decisions asserted in automated tests.

10.2 Red-team indirect injection scenarios

Check: Test RAG poison chunks and hostile web fixtures driving send/delete proposals.

Why: Validates source-to-sink controls end to end.

Verify: Documented results; failures tracked to remediation.

10.3 Pre-launch checklist sign-off

Check: Security and product owners sign checklist for each new agent or material capability change.

Why: Accountability and repeatable launch process.

Verify: Sign-off recorded with date, agent name, and scope.

Quick reference: minimum viable agent security

If you implement nothing else before production:

Tool allowlist (default deny exposure)
Scoped credentials (no secrets in prompts)
Authorization on every execution
POST /api/v1/security/agent-action before every tool call with enforced decisions
Human approval for external send and destructive mutations
Untrusted content treated as data; scan before re-prompt
Audit logs with correlation IDs

Start runtime policy with Agent Action Guard default rules, then add custom policy_id as your tool surface stabilizes.

Limitations

No checklist guarantees zero risk. Models adapt phrasing; tools evolve; vendors change. Re-run this checklist when you add tools, integrations, models, or tenants. Agent security is architecture and operations — not a one-time audit.

Use this document alongside cluster guides: Secure AI Agent Tools, Validate AI Tool Calls, Runtime Security, and What Is AI Agent Security? for depth on each control area.