Research on AI agent deployments puts the share carrying an unaddressed security gap at 82%.
That number should land differently depending on what your agents actually touch.
Ours hold credentials. They touch DNS records, inboxes, CRM fields and live campaigns across every client account we run.
A prompt injection or a scope mistake there is not a thought experiment. It is a domain getting misconfigured, or a reply going to the wrong contact.
Here is what we do to keep that from happening.
How we scope permissions per bot, what we log, and where the real risk sits once an agent reads content it did not write.
The attack surface grows the moment an agent holds real credentials
We run purpose-built bots rather than one general assistant. One sets up DNS, one creates inboxes, one runs campaign operations, one gathers intelligence from inbound replies and public sources.
Each holds credentials to a different system.
One client fleet alone runs about 40 domains and 176 mailboxes across Google Workspace and Microsoft 365.
That is 216 separate assets a misbehaving agent could touch if it carried one shared credential set.
We do not give it one. Each bot reaches exactly the system it needs and nothing else.
Permission scoping has to be the first thing you build, not a patch later
The instinct when you are moving fast is to hand an agent broad access so it never stalls waiting on a missing permission.
That instinct is how you end up inside that 82%.
Our DNS bot can create and modify records at the registrar. It cannot touch a mailbox or a CRM field.
The campaign bot can pause or launch sequences in the sending tool. It cannot change DNS.
Narrow scope means a bad instruction, whether from a bug or an injected prompt, has a small blast radius rather than a large one.
Audit logging turns a vague worry into a traceable incident
Every action our bots take gets logged: what changed, when, and which bot changed it.
That sounds basic, but most agent deployments we see skip it, because logging never feels like progress on the day you build it.
It is the difference between "something broke somewhere" and "the DNS bot updated an SPF record at 3:40am after reading a malformed reply".
One of those you fix in minutes. The other costs you a day of reconstruction.
If you are wiring agents into client-facing infrastructure, our automation engineering work is built around this logging discipline.
An agent nobody can audit is an agent nobody should trust with production access.
Prompt injection is a live risk the moment an agent reads outside content
Our intelligence bot reads inbound replies, scored content and public sources every week.
That is exactly where prompt injection lives: an agent reads something it did not generate, and acts on instructions buried inside it.
A malicious reply or a poisoned source could, in principle, redirect what the bot does next.
So we treat everything that bot reads as untrusted input rather than instructions, and we keep its write access pointed at a reporting pipeline, never at campaigns or DNS.
Any agent that classifies replies or ingests content from the open web needs that same boundary, however good the underlying model is.
The fix is narrower agents, not smarter ones
The same pattern we see in outbound targeting shows up in agent design: less reach, tighter scope, better outcome.
Heavy AI personalization in cold email has underperformed tighter targeting with less of it, because prospects can tell.
The logic carries over to permissions. A general-purpose agent with broad access sounds efficient right up until it is an incident.
A narrow agent doing one job with scoped, logged access is the one that never becomes a story.
That is the real story behind the 82%. Nearly every gap we have looked at was not a model problem, it was a scoping problem nobody got around to fixing.
The Questions We Get Asked
What is prompt injection in plain terms?
It is when an agent reads content, such as an email reply or a scraped page, that contains hidden instructions, and follows those instead of its original task.
It matters once an agent holds real tool access, because the wrong instruction can send data somewhere it should never go.
How do you scope permissions for an agent that touches client data?
Give each agent one system and nothing else, so a DNS bot cannot reach a CRM and a reporting bot cannot launch campaigns.
Then log every action, so you can trace exactly what happened and when.
Do we need a security team to deploy AI agents safely?
Not necessarily. What you need is discipline: narrow scopes, treating all external content as untrusted, and audit logs on every write.
Most unaddressed gaps come from skipping those basics rather than from missing specialist headcount.