The first generation of AI answered questions. The second generation takes actions — via function calls, MCP servers, and tool integrations connected to your real business systems. This guide covers every attack vector, security control, and governance principle for organisations deploying agentic AI with real-world tool access.
Traditional LLMs generate text. Agentic AI systems execute actions. The security implications of this shift are profound. When an AI can only generate text, the worst case is a harmful or misleading response — something a human reviewer can catch before it affects business operations. When an AI can call functions, invoke APIs, retrieve enterprise documents, send emails, and modify records, the worst case is a cascade of real business actions executed at machine speed, without human review, based on adversarial instructions.
This is the core reason why AI agent tool security — specifically securing function calling, MCP integrations, and tool access — is the fastest-growing area of enterprise AI security in 2026. The question is no longer "can the AI say something harmful?" It is "can the AI do something harmful?"
A modern agent with tool access introduces vulnerabilities at every layer of its architecture. Understanding the full stack is essential before applying controls at any single layer.
The amplification problem: Each layer amplifies the impact of compromises above it. A prompt injection at the user layer becomes a real API call at the function calling layer, which becomes a real database modification at the enterprise systems layer. The gap between "the AI said something bad" and "the AI did something bad" is the entire attack surface that tool security is designed to close.
The most dangerous combination: a successful prompt injection that causes the agent to invoke tools with attacker-controlled parameters. The attack bypasses infrastructure entirely — no malware, no credential theft, just a crafted message causing a legitimate tool to execute an illegitimate action.
Each individual tool call appears legitimate. The sequence is malicious. Attackers exploit how agents combine tools to achieve outcomes that no single tool call would trigger — retrieve, process, exfiltrate — each step individually innocuous, collectively devastating.
The AI generates function call parameters based on context. An attacker who controls any part of that context can manipulate the parameters passed to consequential functions — changing amounts, recipients, record IDs, or destinations. The function executes correctly; with attacker-controlled inputs.
MCP servers are central access points connecting agents to enterprise systems. A compromised, misconfigured, or over-exposed MCP server can expose the entire ecosystem it connects to — all databases, APIs, and documents accessible through that server.
Tools require API keys, service accounts, and access tokens. Poor secrets management — hardcoded credentials, shared accounts across agents, credentials accessible to the LLM reasoning context — creates single points of failure that expose every connected system.
Agents granted admin access "for convenience" have a blast radius equal to every system they can touch. This is not an attack by itself — it is the condition that makes every other vulnerability catastrophic. Least privilege limits blast radius regardless of which attack succeeds.
Fully autonomous workflows execute without human review. An attacker who successfully manipulates such a workflow has unlimited time to achieve their objective before anyone notices — executing hundreds of actions across connected systems at machine speed.
Tool chaining is the attack pattern most organisations fail to defend against because each individual step looks legitimate in isolation. Security teams monitoring individual tool calls miss the attack entirely. Here is how it works in practice:
Defence: Monitor tool call sequences, not just individual calls. A retrieve → generate → send-external pattern within a single session should trigger review regardless of whether each step is individually permitted. Implement sequence-aware anomaly detection and require human approval before any external communication following a bulk retrieval operation.
Model Context Protocol (MCP) is an open standard developed by Anthropic that allows AI agents to connect to external tools, APIs, databases, and enterprise systems through standardised server interfaces. Rather than building custom integrations for each application, organisations expose capabilities through MCP-compatible servers — dramatically improving interoperability and accelerating agentic AI deployment.
The security challenge is that MCP servers become centralised access points. A single well-configured MCP server can grant an agent access to dozens of enterprise systems. This is the same reason IAM is so important in traditional IT — and the same reason MCP security requires equivalent rigour.
Every MCP connection requires authentication. No anonymous access. Use service identity tokens, mutual TLS, or equivalent. Rotate credentials on a defined schedule. Never reuse credentials across multiple agents.
Only expose the specific tools a connecting agent requires. An agent that needs to read CRM records should not have access to Finance or HR endpoints on the same MCP server. Expose capabilities by agent role, not by "everything available."
Store all API keys, tokens, and service credentials in a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Never hardcode in configuration files or environment variables accessible to the agent reasoning context. Rotate on schedule.
Log every MCP request with: timestamp, requesting agent identity, endpoint called, parameters passed, response code, and latency. This is the primary evidence source for MCP incidents. Retain for 90 days minimum.
MCP servers should not be publicly accessible. Restrict network access to specific agent service accounts on isolated network segments. Treat MCP servers as internal infrastructure, not public APIs.
Every function an agent can call should have an explicit permission classification. Functions that are allowed by default require no additional control. Functions that require approval pause execution until a human reviews. Functions that are blocked never execute regardless of agent instruction.
| Function | Classification | Control Required | Rationale |
|---|---|---|---|
| get_customer_name() | Allowed | None | Read-only, low sensitivity |
| search_knowledge_base() | Allowed | Scoped to user permissions | Read-only with access control |
| create_support_ticket() | Allowed | Rate limiting | Write but reversible, low impact |
| send_email() | Approval | Human review for external recipients | Communication to external parties is irreversible |
| update_customer_record() | Approval | Human review above threshold changes | Write with business impact |
| transfer_funds() | Approval | Mandatory human sign-off | Financial action, irreversible |
| delete_record() | Restricted | Blocked for AI agents | Irreversible, no legitimate AI use case |
| grant_permissions() | Restricted | Blocked entirely | Privilege escalation risk |
Every agent starts with zero tool access. Permissions are added explicitly as specific functions are demonstrated to be required. Any access not explicitly granted is denied. Review quarterly and remove any access not used in the prior 30 days.
Financial transactions, external communications, record deletions, and any irreversible operation require a human approval gate. The gate is not a performance penalty — it is the primary defence against injection-driven action abuse. An attack cannot cause real-world harm without passing human review.
Monitor every tool call with: which agent, which tool, which parameters, what was returned, at what time. Build behavioural baselines. Alert on 3× volume spikes, cross-scope access, unusual parameter values, and sequence patterns consistent with data exfiltration chains.
Every action should be traceable: who initiated (user), which agent processed, which tool executed, what data was accessed, what outcome occurred. Audit trails are both a security control (post-incident investigation) and a compliance requirement (GDPR Article 5, SOC 2 CC6).
Finance tools, HR tools, and engineering tools should be exposed through separate, isolated MCP servers or function namespaces. An agent authorised for customer support operations should have no technical pathway to financial or HR functions, regardless of prompt instructions.
The HexTyx Agent Security Exposure Assessment evaluates tool permissions, blast radius, approval gate coverage, multi-agent isolation, and prompt injection exposure. Free, 5 minutes, no signup.