AI Agent Security Checklist for Production Systems

List the data the agent can read, the systems it can reach, the actions it can request, and the people affected. Include model providers, retrieval stores, tool servers, queues, logs, analytics, and human approval interfaces.

Classify actions by consequence and reversibility. Searching approved knowledge is different from changing access, sending a customer message, deleting a record, or initiating a payment.

The agent should know which verified user, tenant, and role initiated the work. Apply those permissions to retrieval and tools instead of letting a shared service credential expose everything the backend can access.

Authorization belongs at every protected boundary. A prompt that says the user is an administrator is not proof of identity or permission.

Expose business-level operations with bounded parameters rather than arbitrary database, shell, or HTTP access. Separate sensitive operations so they can receive stronger authorization, validation, and approval.

Use short-lived, scoped credentials where the platform supports them. Restrict network destinations and fields returned, and disable unused capabilities by default.

Prompt injection can arrive through a user request, document, web page, email, or tool result. Instructions inside retrieved content should not override system policy or authorize a tool call.

Separate data from instructions, allowlist tools, constrain destinations, and require deterministic checks before sensitive actions. No prompt wording can replace controls enforced outside the model.

Use strict schemas, length limits, enums, tenant checks, and server-side validation for every tool input. Treat model output like input from an untrusted client; never insert it directly into code, queries, HTML, or downstream commands.

Return minimal, structured tool results and avoid leaking credentials, internal errors, or full records. Mark incomplete or partial results so the agent cannot present them as definitive.

Set maximum steps, model calls, tool calls, runtime, cost, and data volume. Add idempotency for state-changing actions and stop the workflow when repeated failures suggest the plan is no longer valid.

Require a person for named high-consequence actions, novel destinations, policy exceptions, or combinations of authority that create material risk.

Capture who initiated the task, which versions ran, what tools were requested, validation results, approvals, state changes, and final status. Redact secrets and unnecessary personal or proprietary content before logs leave the application boundary.

Rehearse credential rotation, tool disablement, queue cancellation, user notification, evidence preservation, and rollback. Security is an operating capability, not a checklist completed once before launch.