What should agentic AI security solutions actually do?

Agentic AI security solutions should control what an agent is, what it can reach and what it may do, then record all of it. A chatbot only returns text. An agent calls tools, reads data and changes systems, so the core controls are identity, least-privilege tool access, approvals and audit logs.

Why is an agent different from a chatbot?

A chatbot's worst output is wrong text. An agent connected to email, code repositories or cloud accounts can act on a wrong decision, or on instructions an attacker planted in a document it read. OWASP's GenAI Security Project maintains guidance on agentic AI threats and mitigations and lists LLM application risks, including prompt injection, which is the usual route by which untrusted text becomes an action.

The MCP project's own security guidance shows the pattern concretely: confused deputy problems, token passthrough and compromised local servers are all cases where an agent's tool layer gives an attacker something the attacker did not have before.

What are the control areas?

This is our own framing, built from the sources below.

1. Identity. Each agent should have its own identity, not a shared human account or a long-lived key copied from a developer. Without identity you cannot say which agent did what.
2. Tool access. List the tools an agent may call, and deny the rest. Separate read tools from write tools.
3. Credentials. Issue short-lived, narrowly scoped tokens. Validate that a token was issued for the server that receives it, as the MCP guidance requires.
4. Approvals. For actions that are hard to undo, such as deleting data, sending money, merging code or changing access, require a human decision.
5. Input handling. Treat everything an agent reads as untrusted. Keep that content apart from instructions where the design allows.
6. Audit. Log each tool call with its arguments, result and the agent identity.
7. Supply chain. The agent's tools, plug-ins and servers are code. Inventory and verify them.

What questions should you ask a vendor?

• What is the agent's identity, and how is it revoked?
• Can policy block a tool call before it runs, not only report it afterward?
• Where do logs go, and can they be exported?
• What happens when the model is wrong or manipulated? Show a failed case.
• Does it work with the models and agent frameworks we use?
• What does it not cover?

The last question matters most. Be wary of any product that claims to stop prompt injection outright. NIST's adversarial machine learning report describes mitigations with limits, not guarantees.

A constructed example

A support agent reads tickets and can issue refunds through a tool. An attacker files a ticket with hidden text telling the agent to refund a large amount to another account. With only a prompt warning, the agent might comply. With controls in place, the refund tool is limited to a ceiling, over that amount needs a human approval, the destination must match the original payment method, and the call log shows the agent identity and the ticket that triggered it.

How to check or apply this

1. Inventory the agents and tools in use, including ones individuals set up themselves.
2. Give each agent its own identity and remove shared keys.
3. Write an allowlist of tools per agent, and split read from write.
4. Add approval gates for irreversible actions.
5. Turn on logging of tool calls before you widen access.
6. Test with injected instructions in documents and tickets to see what the agent does.
7. Review the list after every new tool or integration.

Safeguard offers an MCP Guardrail, agent identity and policies and gates aimed at these controls, and an MCP server at mcp.safeguard.sh with unlimited tool calls on every plan.

Open the full demo

Quick check

Sources

• OWASP GenAI Security Project, Agentic AI Threats and Mitigations
• OWASP GenAI Top 10 for LLM Applications
• Model Context Protocol, Security Best Practices
• NIST AI 100-2 E2025, Adversarial Machine Learning

Last reviewed: 18 October 2026.