The short answer

Treat every AI agent as a privileged identity that anything it reads can manipulate. Before production, give it scoped credentials, allowlist its tools, red-team it for prompt injection, sandbox its code, require human approval for irreversible actions, and log every tool call behind a tested kill switch. Ship only when every check passes.

Why is AI agent security different from LLM security?

A chatbot that says something wrong is an embarrassment. An agent that does something wrong is an incident.

Agents plan, hold memory, call tools and act across systems with delegated authority. That is why OWASP published a separate framework for them in December 2025, the OWASP Top 10 for Agentic Applications (ASI01-ASI10), distinct from its LLM Top 10. The risk no longer lives only in what the model says. It lives in what the agent is allowed to do.

The data shows most organizations are shipping agents faster than they can secure them:

None of these are exotic attacks. They are basic pre-production controls that were skipped.

The 10-point pre-production validation checklist

Use this as a release gate. Each item maps to a risk category in the OWASP Agentic Top 10.

AI agent pre-production checklist, 10 checks in 4 stages. Identify: 1 agent inventory (owner and purpose), 2 scoped identity (no shared keys). Constrain: 3 tool allowlist (ASI02, least privilege), 5 sandboxed code (ASI05, no egress), 8 human approval (ASI09, gate risky acts). Attack: 4 injection tests (ASI01, goal hijack), 6 memory integrity (poisoning tests), 7 supply chain (ASI04, pin and vet), 9 agent-to-agent (ASI07, ASI08). Observe: 10 kill switch (ASI10, log every call). All four feed a release gate: all 10 pass, or the agent does not ship, re-run on every model, prompt, tool or permission change.

The 10 checks fall into four stages: identify, constrain, attack and observe. An agent ships only when every one passes.

  1. Inventory and ownership. Register the agent with a named human owner, a documented purpose, the data it touches and a planned decommission date. You can't secure an agent you don't know exists.
  2. Unique, scoped identity. Issue the agent its own credentials with short-lived tokens. No shared service accounts, no borrowed human keys. Every action must trace back to one agent.
  3. Least-privilege tool access (ASI02: Tool Misuse). Allowlist the exact tools the agent may call, constrain their parameters, and default to read-only. If the agent only needs to query invoices, it should not be able to issue refunds.
  4. Prompt injection and goal-hijack testing (ASI01). Red-team the agent with poisoned emails, documents, web pages and tool outputs. Indirect injection, where malicious instructions hide in content the agent reads, is the attack that matters most.
  5. Sandboxed execution (ASI05: Unexpected Code Execution). Run any agent-generated code in an isolated container with no network egress and no production credentials by default.
  6. Memory and context integrity. Validate what gets written to long-term memory, test for memory poisoning, and make sure retrieval respects the end user's permissions, not the agent's.
  7. Supply chain review (ASI04). Pin and vet every model version, MCP server, plugin and third-party agent. Treat a new tool connector like a new dependency in your codebase.
  8. Human approval for irreversible actions. Payments, deletions, external messages and production changes require a human checkpoint. Design the approval prompt to show exactly what will happen, so reviewers aren't rubber-stamping (ASI09: Human-Agent Trust Exploitation).
  9. Inter-agent trust boundaries (ASI07, ASI08). Authenticate agent-to-agent messages and never let one agent's output become another agent's instructions unchecked. That is how a single fault becomes a cascading failure.
  10. Observability and a kill switch (ASI10: Rogue Agents). Log every tool call with its inputs, outputs and identity. Alert on anomalies. Prove, in a drill, that you can revoke the agent's credentials and halt it in seconds.

Who owns what?

Make it a pipeline, not a one-time review

An agent that passed last month is not the agent you're running today. Swap the model, edit the system prompt or add a tool, and its behavior changes. Automate the checklist in CI/CD so security validation runs as often as you ship. That's how teams move fast with agents without becoming the next incident statistic.

How do you automate the checklist?

Some of these checks are hard to run by hand at release speed, especially adversarial testing and mapping an agent's supply chain. That is the pre-production gap the NuGuard AI Trust Platform is built for. It generates an AI bill of materials (AI-SBOM) of an agent's models, tools and dependencies (checks 1 and 7), runs automated red-team tests for prompt injection, tool abuse and data exfiltration (checks 4, 5, 6 and 9), and validates agent behavior in a sandbox before release, so the results can act as your release gate.

Identity and runtime kill switches still belong to your identity and infrastructure stack. The checklist holds whichever tools you choose.

Try it

Experience the NuGuard AI Trust Platform for free (14-day trial, no credit card required).

Sources

Frequently asked questions

What is the biggest security risk for AI agents?

Goal hijacking through prompt injection, especially indirect injection hidden in content the agent reads, combined with excessive permissions that let a hijacked agent do real damage.

Is LLM security testing enough for AI agents?

No. LLM testing checks what a model says. Agent testing must also check what it does: tool calls, data access, memory writes and actions taken on other systems.

How often should AI agents be re-validated?

On every change to the model, prompt, tools or permissions, plus scheduled red-team exercises at least quarterly.

Which framework should we use?

Start with the OWASP Top 10 for Agentic Applications for agent-specific risks and pair it with the OWASP LLM Top 10 for model-level risks.