How Integrations Expand the LLM Attack Surface

A language model answering questions in a sandbox is a limited risk. The worst it can do is say something wrong. The moment you connect that model to your tools and data, let it query databases, call APIs, send messages, trigger workflows, its risk profile changes completely. The capabilities that make an AI assistant genuinely useful are exactly the ones that expand its attack surface, and understanding that trade-off is essential before you ship.

From answering to acting

Early LLM applications mostly generated text. The current generation acts: it looks things up, calls functions, integrates with your systems, and increasingly operates as an autonomous agent chaining multiple steps toward a goal. This is where the real value is, an assistant that can actually do things, and it is also where the real danger is.

The shift matters because a model that can only produce text has bounded impact; the harm is limited to what a wrong answer can cause. A model wired into tools can take actions, and every action it can take is an action an attacker who manipulates it can attempt to trigger. Capability and exposure grow together.

Every integration is a new path

Each tool or data source you connect adds to the attack surface in two directions:

Inbound: new sources of untrusted content. When the model ingests data from an integration, a document store, a web search, an email inbox, a ticketing system, it ingests whatever instructions an attacker may have planted there. This is indirect prompt injection: the attacker does not talk to the model; they poison the data the model reads through one of its integrations. The more sources the model pulls from, the more places malicious instructions can hide.

Outbound: new actions that can be abused. Every tool the model can invoke is a capability an attacker can try to hijack. A model that can send email can be driven to exfiltrate data. One that can modify records can be driven to tamper with them. One that can execute code or spend money raises the stakes accordingly. The question for each integration is blunt: what is the worst thing this lets the model do if it is fully manipulated?

Combine the two and the danger sharpens: a model that reads untrusted content and can take consequential actions can be attacked by planting instructions in the content it reads to trigger the actions it can take. Inbound exposure meets outbound capability.

The agent multiplier

Autonomous agents intensify all of this. An agent that chains many steps, reading, deciding, acting, reading again, without a human reviewing each one, compounds risk at every hop. A manipulation early in the chain can propagate through subsequent steps, and the absence of human checkpoints removes the natural place to catch it. The more autonomy and the longer the chain, the more carefully the boundaries have to be drawn.

Containing the risk

You do not have to choose between useful and safe, but you do have to design the integrations deliberately:

• Grant least privilege. Give the model access only to the specific tools and data a feature genuinely needs. An assistant that only needs to read should not be able to write, send, or delete.
• Gate consequential actions behind confirmation. Anything sensitive, sending data externally, moving money, changing permissions, should require explicit human approval rather than firing autonomously.
• Enforce authorization outside the model. The model requesting an action is not authorization to perform it. Every tool call must be checked against real access controls in the surrounding system, exactly as any other client would be.
• Treat integrated data as untrusted. Content arriving through an integration can carry hostile instructions. Design so the model treats it as data to analyze, not commands to obey, and limit what it can do in response.
• Constrain agent autonomy. For multi-step agents, insert checkpoints on high-impact actions and bound what the chain can do without human review.

Test the connections, not just the model

Because the danger lives at the integration points, that is where testing has to focus. Throwing jailbreak prompts at the model in isolation misses the real risk. A meaningful AI penetration test maps every integration, inbound and outbound, and tries to bridge them: can content from a connected source drive the model to misuse a connected tool? That is the question that separates a safe deployment from a breach waiting to happen.

Integrations are what make AI assistants worth building. They are also what make them worth attacking. Add each connection deliberately, with least privilege and real authorization around it, and test the whole connected system before it goes live, not just the model at its center. Our AI/ML penetration testing covers the integration layer end to end, and pairs well with API penetration testing for the services behind those tools.