You can buy the best model on the market and still lose your customer database to a paragraph hidden inside a CV. An AI agent reads instructions and data on the same wire. Wire it into your ERP, your helpdesk or your payment tooling, and you have handed a very literal assistant to anyone who can get text in front of it.
An AI agent is a confused deputy holding your credentials
Prompt injection works because a language model cannot reliably separate your instructions from the content it is asked to process. Text arriving in a ticket, an invoice, a CV or a scraped supplier page can carry commands, and when the model also holds tools, those commands stop being words and become actions inside your systems.
The attacker never has to defeat authentication, because the agent already passed it, holding your API key, your database connection and your service account. They only need their text in the pipeline the agent was built to read, and that pipeline is wider than most teams admit: support inboxes, CRM notes, uploaded PDFs, candidate CVs, supplier pages fetched from the web, monitoring alerts, calendar invites, even filenames. Each can be written to from outside, and each is read by an agent that treats a well phrased instruction as yours. The OWASP Top 10 for LLM Applications is worth reading before you ship another integration.
How injected text actually reaches your internal tools
The payload rarely arrives in a chat box. It arrives inside the content the agent was designed to process, addressed to the agent rather than to you. A customer emails support, the agent summarises the thread, and buried in the signature is a line telling the assistant to look up the account holder's stored details.
Three shapes cover most of what we find in assessments:
- ▸Direct injection. Someone with access to the chat interface talks the agent out of its rules. Annoying, limited, mostly an internal misuse problem.
- ▸Indirect injection. The instruction is planted in third party content: a web page, a document, an email, a product review. The agent fetches it during a normal task. This one scales, because the attacker never touches your login page.
- ▸Second order injection. The poisoned text gets stored, in a vector index, a memory feature, a knowledge base article, then fires later for a different user in a different session. The compromise now has persistence and nobody knows when it was planted.
Once an instruction lands, the damage depends on what the agent can do next. Exfiltration is the quiet outcome: the agent encodes what it just read into a URL and renders it as a markdown image, and the moment your interface loads that image, the data has left. Tool abuse is the loud one: issue the refund, reset the password, send the email. Your tool list is the attacker's menu, in plain English.
Legacy internal systems make the blast radius much worse
Older internal systems usually offer exactly one integration path: a single powerful account with broad permissions, no per action scoping, and an audit trail nobody has ever read. Connect an agent to that and you have not built an AI feature, you have published a natural language interface to an unrestricted admin login.
The same pattern shows up across almost every legacy estate. One database user shared by six integrations, so no log can attribute an action to a caller. Endpoints that authenticate once at session start and trust everything afterwards. Flat internal networks where anything inside the perimeter counts as friendly, an assumption that NIST SP 800-207 Zero Trust Architecture exists specifically to dismantle.
Agentic AI is an excellent stress test for integration debt. If your systems can only be addressed by a super user, every new automation inherits total access. That is a modernisation problem rather than a prompt problem, and it is the fork we describe in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software: either you own a clean, scoped integration layer, or you keep paying for the workarounds.
Model choice is not a security control
A better model reduces how often injection succeeds. It does not change what happens when it does. Every capable model is susceptible, system prompts are advisory rather than enforced, and input filters are pattern matching against an adversary who can rephrase at will. Design as if injection will land.
Filters that look for phrases like "ignore previous instructions" are a speed bump. The same instruction survives translation, base64 encoding, homoglyph substitution, white text inside a PDF, or a payload split across two documents that only turns dangerous when both are summarised together. You cannot enumerate the badness of natural language.
Evaluate models the way you evaluate any dependency: capability, cost, latency, data handling terms. Do not buy your security posture from the model vendor. The burden sits with the system builder, which is the argument behind CISA Secure by Design: make the safe path the default path.
Least privilege is the control that actually holds
Scope each agent to the smallest set of actions that makes the feature work, and give every tool its own credential, rate limit and audit line. If an injected instruction can only read three fields for one customer, your worst case is a bad summary, not a wire transfer or a breach notification.
The controls that survive contact with a real attacker:
- ▸One identity per agent. Never a shared service account. If you cannot answer "which agent did this" from the logs, you have no incident response.
- ▸Split read and write into separate tools with separate credentials. Most agent features need read access to a lot and write access to almost nothing.
- ▸Enforce tenancy on the server, never in the prompt. The model supplies intent, your API supplies the customer identifier from the authenticated session. A parameter the model can choose is a parameter the attacker can choose.
- ▸Deny destructive actions by default. Refunds, deletions, permission grants, outbound email and bank detail changes go to a human approval queue showing the raw source context, not a summary written by the compromised agent.
- ▸Allowlist egress and sanitise output. The runtime reaches only the hosts you named, links and images generated from untrusted content are neutralised, and no URL the model produced is ever auto fetched. This kills most exfiltration paths.
- ▸Separate reading from acting. Outside content must never be the thing that decides an action. A deterministic layer validates every proposed action against rules no prompt can edit.
Treat the tool layer as an API, because that is what it is
Every tool you expose to an agent is an API endpoint with an unusually creative client. Apply public API discipline: strict schema validation, parameter allowlists, server side authorisation on every call, rate limits and idempotency keys. The model must never be the authorisation boundary.
Broken object level authorisation, the top entry in the OWASP API Security Top 10, is the failure an agent finds faster than any human tester, because it will iterate identifiers all afternoon without getting bored. Refuse identifiers outside the caller's scope, and never interpolate model output into SQL or a shell command.
Resist the "just give it a SQL tool" temptation. A free form query tool against production is an unbounded capability with a friendly name. Expose named, parameterised operations instead: fewer capabilities, each one auditable and testable in CI.
Log for the incident you are going to have
Assume that one day somebody asks what your agent did, on whose behalf, with what input, and when. If you cannot answer within minutes, you do not have an agent, you have an unaccountable actor with credentials. Log the user request, the retrieved content, every tool call with its arguments, and the identity used.
Make those logs usable. Carry one correlation identifier across the chain, and store a hash of every untrusted document that entered the context, so you can trace which supplier PDF started the incident. Alert on a tool used for the first time, an unusual burst of calls, or egress to an unlisted host.
Then rehearse revocation. Can you disable that agent's credentials in under a minute, on a Sunday, without a code deploy? Detect and respond are the two functions people skip in the NIST Cybersecurity Framework, and they decide whether an incident costs an afternoon or a quarter. That is continuous work, which is why it belongs with What Website Maintenance Should Actually Include (and What You Are Probably Paying For).
A 30 day plan if you have already shipped an agent
You do not have to unplug it. Inventory, scope, contain, test, in that order. Most teams cut their blast radius dramatically within a month without touching the model, the prompt or the roadmap, because nearly all the fixes live in the integration layer rather than in the AI.
- ▸Week one, inventory. List every tool, credential, data source and content channel the agent touches. For each tool, answer one question: what is the worst a single call could do?
- ▸Week two, scope. Split the shared service account. Remove write access the feature never needed. Put destructive actions behind human approval.
- ▸Week three, contain. Egress allowlist, output sanitisation, server side tenancy enforcement, structured logging with a correlation identifier.
- ▸Week four, test. Inject through the real channels a customer uses, not the chat box. Try exfiltration through rendered content, then rehearse credential revocation with a stopwatch running.
If the agent sits behind a public website or portal, pair this with The Small Business Website Security Checklist for 2026, because an agent behind a weak front door is still behind a weak front door.
How TuniCyberLabs helps
We build the unglamorous layer that makes agentic AI safe to run: scoped APIs in front of legacy systems, per agent identities, approval gates on destructive actions, egress control, and audit trails you can query mid incident. We also test agents the way attackers do, through your real content channels.
Tell us what your agent can reach today and we will show you what one injected paragraph could do with it: talk to our engineering team.