AI Agents as an Attack Surface: Why Tool Access Must Be Controlled

Many discussions around AI security still begin at the model level: How reliable are the responses? How are hallucinations reduced? Which guardrails prevent toxic or undesirable outputs? These questions remain important. But they describe only part of the risk.

With agentic AI systems, the focus shifts. An agent doesn't just respond to an input — it can call tools, aggregate information from multiple sources, decompose tasks into substeps, and trigger actions in connected systems. It's no longer just about what the model says. It's about what the system does based on that output.

From Chatbot to Actor

A classic LLM that answers questions or summarizes text remains limited in its reach. It processes inputs, generates outputs, and essentially stays within a communication context. Risks arise primarily where responses are incorrect, manipulated, confidential, or misleading.

An agentic system has a different reach. It can be connected to applications, APIs, databases, file systems, email clients, or internal workflows. A model response can quickly become a system action. An agent can update a ticket, retrieve data, prepare a message, initiate a process, or pass a recommendation into a downstream workflow.

The difference can be summarized briefly:

Classic Application Security remains necessary. Authentication, authorization, input validation, encryption, logging, and secure interfaces don't become less important. The point is different: agentic systems introduce additional risk patterns into operations because they don't just execute fixed paths — they act context-dependently.

The New Attack Surface Emerges at the Transitions

The attack surface of agentic applications rarely lies solely in the model itself. It emerges primarily where an agent is connected to other systems: tool access, data sources, memory, delegation, external content, and automated follow-up actions.

This makes securing them more demanding. A single API call can be technically permitted. A single data query can seem uncritical. A single recommendation can look plausible. The risk often arises only in combination:

An agent reads data → interprets manipulated content → calls a tool → triggers an action that was not intended in the original user request.

This is exactly why it's not enough to treat Agentic AI Security merely as an extension of classic prompt filters. Prompt injection is an important attack type, but in an agentic context it's dangerous primarily because it can influence tool usage, data access, or follow-up actions.

Tool Access Must Be Individually Controllable

As soon as an agent can use tools, least privilege becomes more concrete. In classic applications, permissions are often tied to services, roles, or user groups. With agents, this logic alone is insufficient because behavior depends more strongly on the task context.

An agent may, for example, be authorized to retrieve customer data to handle a support request. The same access can become problematic if a manipulated input causes the agent to use the data for a different purpose or to combine it with another tool. The problem is not just the access itself, but the connection between access, context, and follow-up action.

For production agents, clear rules are needed about which tools are permitted in which context, which actions require human approval, and which calls are blocked or specially logged. An agent doesn't need to be allowed to do everything just because an interface is technically reachable.

Memory Is Helpful but Security-Relevant

Memory makes agents more useful because previous interactions, preferences, or work states can flow into later decisions. At the same time, memory itself becomes a security-relevant component.

When an agent stores information permanently or over longer periods, it must be clear:

• Which content is allowed to enter this memory
• How it's verified
• When it's removed

Otherwise, manipulated or outdated information can flow into decisions later without the original context still being visible.

What's often overlooked: the risk lies not only in obviously malicious inputs. Even seemingly harmless content from documents, tickets, emails, or websites can contain instructions that an agent later processes as context. In agentic workflows, not only the current prompt is relevant, but also the question of which stored information the agent draws on at runtime.

Delegation Needs Clear Boundaries

In more complex setups, multiple agents or specialized subsystems work together. One agent researches, another evaluates, a third prepares an action. This division of labor can be sensible but creates new trust relationships.

When Agent A passes a task to Agent B, it must be clear which permissions apply. Can Agent B use the same tools? Is the original user request passed along? Are restrictions inherited? And what happens when Agent B in turn involves another system or agent?

Especially critical: A low-privileged agent indirectly triggers actions that are later executed by a higher-privileged system. Without clear delegation rules, a permission structure quickly emerges that's hard to audit. For companies, this means: delegation needs technical limits, logging, and where in doubt, human approvals.

Follow-Up Actions Are Not Always Predictable

Agents are supposed to decompose tasks into substeps. That's part of their utility. At the same time, this creates action chains that are not always fully predictable.

An agent analyzing a support request might retrieve additional customer data, prioritize a ticket, create an internal note, and prepare a response. Each individual step can be plausible. The combination can still become problematic:

• The agent uses a wrong source
• It adopts confidential information
• It triggers an action that should have required approval

Classic security tests often check known paths and known misconfigurations. With agents, it must additionally be tested how the system behaves in different contexts — with contradictory information, manipulated documents, unclear user requests, or tool responses that contain instructions.

Prompt Injection Becomes More Operational in an Agentic Context

Prompt injection is not a new topic. With agentic systems, however, the impact changes. A manipulated document, a prepared website, or a targeted user input then doesn't just lead to an undesirable response. It can influence which tools an agent calls, which data it processes, or which action it executes as a next step.

The attack surface grows because agents process content from multiple sources: user inputs, API responses, tickets, emails, database entries, documents, or websites. Each of these sources can contain instructions that must not be treated as trustworthy control logic.

For the architecture, this means: External content must be cleanly separated from system instructions, tool rules, and approval logic. An agent must not interpret every piece of found information as an equivalent action instruction. This separation becomes a core point of agentic security.

Why Classic App Security Alone Is Not Enough

Traditional application security remains the foundation. Without proper authentication, authorization, network segmentation, secrets management, monitoring, and secure APIs, no agent can be operated securely. Agentic AI Security does not replace these measures.

It supplements them with an additional layer. Classic applications mostly follow defined paths. Agents work more through context, tools, and intermediate steps. Therefore, security must not only check whether an individual request is permitted, but also whether an action chain as a whole remains sensible and permitted.

This primarily affects three areas: permissions must become more context-dependent, logs must capture more than technical requests, and tests must consider runtime behavior rather than just static paths. A single tool call can be legitimate. A sequence of tool calls can still be risky.

What Companies Should Check Now

For production agents, a completely new security discipline alongside everything existing isn't needed. But an expansion of existing security and architecture work to cover agentic risk patterns is needed.

Companies should primarily check:

• Which tools, APIs, and data sources an agent can reach.
• Which permissions apply per tool and per context.
• Which actions require human approval.
• Which data and intermediate steps are logged.
• Whether memory contents are verified, limited, and deletable.
• How delegation between agents or systems is controlled.
• How prompt injection is tested across documents, websites, emails, or API responses.

These points don't belong only in the security review shortly before go-live. They influence architecture, integration design, role models, and operations. Anyone wanting to deploy agents productively must clarify early which capabilities an agent should have and which should be deliberately excluded.

Red Teaming and Monitoring Need to Be Closer to Operations

A one-time test is rarely sufficient for agentic systems. Agents don't change their behavior arbitrarily, but they react to changing contexts, new data sources, different user requests, and additional tools. This can create risks that weren't visible in a classic test case.

Red teaming should therefore not only test prompts but entire action chains. What happens when a manipulated document sits in a knowledge base? How does the agent react to an API response containing hidden instructions? Which tools does it call when the user request is unclear? And where is an action stopped before it has productive impact?

Monitoring must also be thought of more broadly. Audit logs should not only store results but also tool calls, data sources used, approvals, blocked actions, and relevant intermediate steps. Only then can it be traced later whether an agent worked within its intended boundaries.

Security Emerges in the Architecture

The most important change is not that classic security is suddenly wrong. It's just no longer sufficient when AI systems independently use tools and trigger actions. Security then arises not only through secure APIs or good model responses, but through controlled scopes of action.

For companies, this means: agents need clear identities, limited permissions, controlled tool access, traceable logs, and defined intervention points. Security must take effect where a model response becomes a system action.

Agentic AI thus becomes an architecture question. Not because every agentic application is automatically high-risk, but because its security depends on how access, context, tool usage, and operations interact.

Ai11 supports companies in designing and securing agentic AI applications — from architecture to governance to production operations. Contact us for a no-obligation conversation.