Agentic AI Security: Govern AI Agents and MCP Tools 

‍

Teams are connecting AI agents to inboxes, shared drives, code repositories and databases, often faster than policy is written. An agent does not just answer a question. It plans a task, calls tools and takes actions on the person's behalf. That is useful, and it changes the security question. Agentic AI security is about what those agents can access and do, and what data moves when they do it.

Gartner lists agentic AI first among its top cybersecurity trends for 2026 and says it is creating new attack surfaces. Its advice is practical: identify both sanctioned and unsanctioned agents, enforce controls for each and develop incident response playbooks. In this guide, we cover the main risks, the MCP layer where agents meet your data and the five-step loop we recommend for governing both.

What is agentic AI security?

Agentic AI security is the set of controls that govern what AI agents can access, which tools they can call and what data leaves through those calls. It applies to the whole chain of an agent's work, not just the prompt that started it.

The difference from chat security is where the risk sits. A chat assistant works with the text a person pastes in. An agent works with files, email, APIs and databases, and it can take many steps before anyone looks at the result. For a wider comparison of the two, see our guide to generative AI vs agentic AI.

In our experience, employees often adopt useful AI tools faster than governance can keep up. Agents are the next step in that pattern, so the goal is to put guardrails around them, not to slow adoption down.

The 6 agentic AI security risks to govern first

The OWASP GenAI Security Project published its Top 10 for Agentic Applications in December 2025. The full list has ten risks, including memory and context poisoning, insecure communication between agents and cascading failures, according to HUMAN Security's breakdown of the list. These six come up first in most business deployments.

1. Goal hijack through hidden instructions

An attacker can redirect an agent by placing instructions in content the agent reads, such as a web page, an email or a shared document. OWASP calls this agent goal hijack. The agent cannot always tell the difference between data it should read and instructions it should follow.

The fix is to treat retrieved content as untrusted, limit what an agent can do after reading it and require approval for high-impact actions.

2. Excessive agency

Excessive agency means an agent holds more permissions than its task needs. An agent that summarizes meeting notes should not have write access to a shared drive. When permissions are broad, a single mistake or manipulated instruction reaches much further.

Set least privilege per task, not per tool.

3. Tool misuse

OWASP lists tool misuse and exploitation as an agent being steered into using its authorized tools unsafely. The call is allowed. The intent behind it is not. An allow-list can confirm that an agent may use a tool, but it cannot tell why the agent is using it now.

Evaluate each call in context: which data is involved, where it is going and whether it fits the task.

4. Identity and privilege abuse

Agents often run on delegated identities or cached credentials. Shared service accounts also make it hard to tell which agent did what. OWASP flags identity and privilege abuse as a distinct risk because a borrowed credential carries every permission the original owner had.

Give each agent its own identity, with short-lived, narrowly scoped tokens.

5. Supply chain risk in tools and servers

Agents depend on third-party plugins, tools and servers, and those can change after approval. OWASP names this agentic supply chain vulnerability. A tool you reviewed last month may not behave the same way today.

Keep an inventory of approved tools and review every change.

6. Sensitive data leaving through tool calls

This one is the most common in practice and has no single OWASP entry. An agent that searches the web, sends an email or calls an external API can carry company data out with the request. A contract excerpt in a search query or a customer list in an attachment is enough.

Classify the data by meaning at the point of the call, then redact or block it before it leaves.

MCP security: where agents meet your data

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to tools and data sources. It is how many agents reach your files, tickets, calendars and databases. That makes MCP security a core part of agentic AI security.

The exposure is measurable. In our own data, 14% of MCP tool calls access sensitive systems. Most calls are routine, and the share that touches sensitive systems is exactly where policy has to apply.

The server side also deserves attention. A Cloud Security Alliance paper from May 2026 cites a 2025 analysis of 1,899 open-source MCP servers. That analysis found MCP-specific attack vectors, such as tool poisoning, in 5.5% of them and general vulnerabilities in 7.2%.

Tool poisoning and rug pulls

Tool poisoning hides malicious instructions in a tool's description or metadata, which the model reads as guidance. A rug pull is related: a server changes its tool definitions after someone has approved them. The same CSA paper describes a September 2025 case in which an unofficial Postmark MCP server was modified to silently copy outgoing email to an attacker.

Consider an agent with a mail tool and a file tool. A poisoned description on a third tool could tell the agent to attach a document to its next outgoing email. The user asked for none of it, and each individual call looks legitimate.

Confused deputy and token passthrough

A confused deputy attack manipulates a server that holds delegated authority into misusing it. Token passthrough is a common cause. The MCP project's security best practices call it an anti-pattern, explain that it breaks audit trails and bypasses downstream controls and state that servers must not accept tokens that were not issued for them.

Shadow MCP servers

Local MCP servers run on a person's machine with the same privileges as the client, and people can install them without review. The same MCP guidance recommends sandboxing and explicit consent before a client runs a new local server. The CSA paper recommends keeping a formal inventory of MCP servers and detecting unsanctioned connections through network monitoring.

How to govern AI agents and MCP tools: a 5-step checklist

This is AI governance applied to a new kind of user. A lean team can run it as a loop. In a company of 20 with one IT lead, the first pass fits on a single page, and the steps are the same whether your team sits in India or the USA.

1. Discover. List the agents and MCP servers in use, sanctioned or not. Include desktop AI apps, coding assistants and browser-based agents. This is the same discovery work as finding shadow AI, extended to agents. This week: ask each team which AI tools can reach company files or email.
2. Scope. Give each agent its own identity and the minimum permissions its task needs. NIST's AI Agent Standards Initiative, announced in February 2026, includes research on agent security and identity as one of its three pillars. It is early-stage work, but it shows where expectations are heading. This week: remove any shared credentials an agent uses.
3. Enforce. Apply policy at the tool call, independent of the model. The CSA paper recommends enforcing policy at the tool invocation boundary, for example by checking parameters against allow-lists. If you are comparing options, our guide to DLP software for AI agents compared sets out the evaluation criteria. This week: decide which data types an agent must never send out.
4. Log. Keep an append-only record of tool calls: which agent, which tool, which parameters and what happened. Logs make incidents explainable and audits shorter. This week: switch on logging for the one agent with the widest access.
5. Review. Re-check tool definitions, servers and permissions on a schedule. Treat tool definitions as supply chain artifacts that can change. This week: put a monthly review in the calendar.

What good AI agent security controls look like

Whatever tools you choose, four properties separate controls that work from controls that get switched off.

Control at the tool call. Agents act through tools, so that is where policy belongs. Controls that only watch the prompt miss everything that happens after the first step.

Classify by context, not pattern. Pattern matching finds credit card numbers and ID formats. It misses a trade secret described in a paragraph. Good AI agent security looks at what information means and how it is being used, so that routine work passes and risky actions stop.

An illustrative example, not a customer case: a sales agent is asked to draft a partner update. It pulls a pricing document and sends a web search query that includes unreleased discount tiers. Nothing in that query looks like a card number or an ID, so a pattern rule lets it through. A control that reads meaning recognizes unreleased pricing, then masks the figures or blocks the call before the query leaves.

Least privilege by default. Narrow permissions limit the damage from any single failure, including the ones you did not predict.

Logs you can review. If a security or IT lead cannot see what an agent did, they cannot govern it. The aim is visibility into how agents use tools and data across your workflows.

Agentic AI security with Wald AI

Wald AI protects sensitive business data across AI interactions, including the agent and tool layer. We built it as AI DLP: data loss prevention designed for how people and agents actually use AI.

Agents read files, call APIs and query databases. Our endpoint AI DLP governs those interactions on the device and supports MCP gateways, so policy applies across chat, desktop AI apps, coding assistants, agents and MCP connections. Instead of relying only on predefined patterns, small language models deployed locally classify the meaning and intent of a prompt, document or tool call. Guardrails apply in real time, and audit logs record the interactions.

That is the idea behind our principle that policy follows the action, not the person. The same guardrail applies whether a person pasted a document into an assistant or an agent opened it on their behalf.

Wald AI works alongside tools such as Zscaler, Netskope and Microsoft Purview. It adds contextual protection at the AI interaction layer and does not replace those controls. Teams adopt it without giving up the AI tools their people already rely on. To see how it works on the device, see Wald AI in action.

Conclusion

Agentic AI security comes down to three habits. Know which agents and MCP servers are running, give each one only the access its task needs and apply policy at the tool call, where data actually moves. Add logs and a regular review, and agents become something a small team can govern.

Our aim is to let people keep using AI agents while sensitive data stays protected. If you want to see how that works for your team, book a demo or talk to our team.

‍