Tool-using agents need production rules
The hot question is no longer just which model writes faster. The real risk is the agent that reads context, chooses tools, calls APIs, runs commands, remembers state, and interacts with other services. When that touches SaaS login, billing, and customer data, the review changes.
OWASP MCP Top 10 names risks that already show up in real builds: tool poisoning, context spoofing, command injection, broad permissions, unsafe memory, and indirect channels. The Agentic Security Initiative widens the lens for autonomous applications where model output can become real action.
Review these first
- MCP servers and tools the agent can call.
- Secrets, tokens, and runtime variables available to the agent.
- Commands that mutate databases, deployments, payments, or files.
- Persistent memory and context retrieved from external sources.
- Tool-call logs without sensitive payloads.
- Human approval for destructive or irreversible actions.
- Scope by user, tenant, plan, and environment.
The common AI-builder mistake
The app works, the agent helps, MCP speeds things up, and nobody draws the boundary. Then a tool meant to read a ticket can touch production; public context influences an internal call; logs store personal data; automation uses a token that is too broad.
The risk is not magic. It is too much permission meeting untrusted context.
Use OWASP without making it empty
For each agent tool, answer: who can call it, with which arguments, in which environment, with which approval, producing which log, and with which rollback. If that answer touches customers, billing, uploads, admin, or production, it deserves Risk Review before it becomes routine.
Sources used
A safe agent is not an agent without tools. It is an agent with boundaries, least privilege, clean logs, and human review when an action can cost money or data.
