Every AI integration guide covers the exciting parts — the architecture diagram, the API calls, the prompt templates. Almost none of them cover what you’ve actually added to your attack surface.
That’s a problem, because the attack surface is real, it’s new, and most security teams aren’t looking at it yet.
Here are the three places we see it most often.
Prompt Injection Through User Inputs
If your AI integration accepts user input and routes it into a prompt — which is most of them — you have a prompt injection surface. A user can craft input that overrides your system prompt, changes the model’s behavior, or causes it to leak information it wasn’t supposed to share.
This isn’t theoretical. It’s the AI equivalent of SQL injection, and it’s just as underestimated in early-stage deployments.
The fix isn’t complicated, but it requires deliberate architecture: input sanitization before it reaches the model layer, system prompt structure that isolates instructions from user content, and output filtering on the way back out. What it requires most is someone actually thinking about it during design — not as an afterthought after the integration is already in production.
Data Exfiltration Via LLM Responses
When an AI agent has access to internal data — customer records, contract details, internal documentation — the response channel becomes a potential exfiltration vector.
A well-crafted prompt can cause a model to summarize, reformat, or indirectly quote data it retrieved from your internal systems, even when the agent was never explicitly instructed to share it. If your logging and monitoring treats LLM responses as opaque text rather than structured outputs, you may not catch it until the damage is done.
What helps: scoping the data each agent can access to the minimum required, treating LLM outputs as untrusted content that needs validation before it surfaces anywhere, and logging enough context around each inference call to reconstruct what happened if something looks off.
API Credentials in Agent Contexts
This one is the most quietly common mistake we see in the wild: API credentials, connection strings, or authentication tokens embedded in agent system prompts or context windows because it was the fastest way to get the integration working.
The reasoning is understandable — you’re iterating fast, you’ll clean it up later. The problem is that “later” often doesn’t come before the integration goes to production. And once credentials are in a context window, they can be extracted through the same prompt injection techniques described above.
The right pattern is credential isolation: secrets live in a secrets manager, the agent requests scoped tokens at runtime, and nothing sensitive ever enters the context window directly. This adds a layer of setup, but it’s the difference between a recoverable incident and a breach that took your API keys with it.
What This Means for Your AI Strategy
None of these problems are unsolvable. They’re engineering problems with engineering solutions — the same kind of deliberate thinking that goes into securing a traditional API integration.
What they share is that they require someone to be specifically thinking about AI security during the design phase. Not just “is the model accurate,” but “what happens when someone tries to break this on purpose.”
Most integration guides are written by people optimizing for time-to-working-demo. Security is rarely part of that optimization. It has to be explicitly added.
If you’re in the middle of an AI integration build — or evaluating one from a vendor — the right questions to ask aren’t just “does it work.” They’re:
- What does the agent have access to, and is that scope justified?
- Where does user input enter the model layer, and how is it validated?
- Where do credentials live, and can they be accessed through the model’s context?
- What does the output logging look like, and is it enough to reconstruct an incident?
These aren’t hard questions. They just rarely get asked.
The Integration Layer Is Where Security Lives Now
The model itself is probably fine. The training, the guardrails, the hosted infrastructure — the major providers invest heavily in that. What they can’t secure is how you connect their model to your internal systems, your customer data, and your business logic.
That connection layer is yours. And right now, it’s the least-examined part of most enterprise AI deployments.
If you’re building or auditing an AI integration and want a second set of eyes specifically on the security architecture, that’s exactly what we do.