10decoders
The Attack Surface Nobody Scoped for a Chatbot
An AI agent monitoring a shared support inbox pulls in a customer email that contains, buried below the signature, a line of text instructing it to forward every open ticket to an outside address. The agent has no reliable way to tell the difference between a customer's question and an attacker's command, because both arrive as the same kind of text and the agent's job is to follow instructions written in natural language. This is prompt injection, and it stopped being a research curiosity the moment agents were given tools that can act instead of tools that can only answer.
The scale of the exposure is not theoretical. OWASP's 2026 framework for agentic applications names goal hijacking through indirect instruction injection, tool misuse, and memory or context poisoning as core risk categories distinct from the older generative AI threat list, because a compromised agent acts on the bad output instead of merely producing it. Security researchers have counted more than forty distinct prompt injection techniques across current agent ecosystems, and CrowdStrike's 2026 reporting traces real-world exploitation to production systems that customers were already running.
Traditional application security does not map cleanly onto this problem. Input validation was built to catch malformed data, not a well-formed sentence that happens to contain an instruction. An agent reading a web page, a support ticket, or a shared document treats the content of that page as part of its working context, and anything embedded in that context can compete with the system prompt for the agent's next action. Security teams that are still scoping this as a chatbot content-moderation issue are missing the part of the system that can actually do damage: the tools connected to the agent.
"An AI agent cannot reliably tell the difference between an instruction and a sentence that merely describes one, and that single fact is the entire security problem."
Where Agentic AI Systems Actually Fail
| Risk category | How it shows up in production | Why most teams miss it | Severity |
|---|---|---|---|
| Goal hijacking via indirect prompt injection | Agent reads a poisoned email, web page, or ticket and follows instructions embedded in that content | Testing focuses on the system prompt, not the untrusted content agents ingest at runtime | Critical |
| Tool misuse and excessive permissions | An agent scoped for read-only lookups turns out to hold write or delete access on the same API | Permissions get granted once during a demo and are rarely revisited before production | Critical |
| Memory and context poisoning | False information injected in one session persists and shapes the agent's behavior in later sessions | Long-lived agent memory is rarely audited the way a database would be | High |
| Unsafe agent-to-agent handoffs | A compromised agent passes a poisoned instruction downstream to another agent that trusts it by default | Inter-agent traffic is treated as internal and skipped by perimeter security tools | High |
| No per-agent identity or access scoping | Every agent shares one service account or API key instead of its own scoped credential | Provisioning a distinct identity per agent looks like overhead until an incident needs tracing | Moderate |
| Missing action-level audit trail | Autonomous actions get logged as generic API calls, not as decisions with a reason attached | Logging was built for debugging code, not for reconstructing why an agent did something | Lower |
Not sure where your AI agent security gaps are?
10decoders runs independent agentic AI security assessments that map every tool an agent can call, test for indirect prompt injection, and check whether access scoping matches what the agent actually needs to do its job.
Book a Free AI Assessment →Why Uniform Governance Makes This Worse, Not Better
Gartner's guidance on securing enterprise agentic AI makes a point that runs against the instinct to write one policy and apply it everywhere: treating every agent under the same governance rule, regardless of its autonomy level and the tools it can reach, produces enterprise AI agent failure rather than preventing it. A read-only research assistant and an agent that can issue refunds are not the same risk, and a single blanket approval process either blocks the low-risk agent for no reason or waves the high-risk one through on the same checklist.
Most enterprises don't have a governance problem so much as a visibility problem. Ask a security team how many AI agents are running in production right now, who owns each one, and exactly which tools each one can call, and the honest answer in most organizations is that nobody has a current list. Agents get spun up by individual product teams, plugged into an API, and shipped, while the identity and access management layer built to track privileged actors was designed for humans and service accounts, not for something that decides on its own which tool to call next.
The rollout is not waiting for that inventory to catch up. Industry surveys already put close to 38% of organizations at more than 100 deployed agents as of April 2026, while monitoring coverage and accountability structures for those agents have barely moved. Every month that gap stays open is a month where the number of things a security team cannot currently see keeps growing faster than the number of things it can.
Ungoverned Sprawl
Agents get built and deployed by individual teams with no central record. Nobody in security can produce a current list of what exists or what it can touch.
Inventory Without Runtime Control
A registry exists and lists agents and their tools, but permissions are reviewed once at launch and rarely revisited, and there is no real-time view of what agents actually do day to day.
Scoped, Monitored, Auditable
Every agent has its own scoped identity, tool access follows least privilege on a review cadence, and every autonomous action is logged with enough context to reconstruct why it happened.
Closing the Gap Between Agent Rollout and Agent Security
None of the items below require pausing agent deployment while security catches up. Most slot into a process that already exists somewhere in the org, a field added to a deployment ticket here, a review step inserted before merge there. The point is to stop treating agent security as a policy document and start treating it as an inventory problem with runtime controls attached.
Agentic AI Security Checklist
"The fastest way to lose control of agentic AI is to scale the agents before you scale the inventory that tracks them."
What to Do This Week
01 Build a first-pass agent inventory
List every AI agent currently in production, its owner, and every tool or API it can call. An incomplete spreadsheet started today is worth more than a governance policy describing a system nobody can currently enumerate.
02 Audit tool permissions on your three highest-risk agents
For the agents with access to money movement, external communication, or customer data, confirm each still needs every permission it was granted at launch, and revoke anything that has not been used in the last thirty days.
03 Tag the untrusted input sources feeding your agents
Mark email, web content, and third-party documents an agent processes as untrusted before that content reaches the reasoning step, and require an explicit approval before instructions found in that content class can execute.
04 Write an incident response runbook for a compromised agent
Document how to revoke an agent's credentials, trace what it accessed in the last twenty-four hours, and notify affected systems, kept separate from your standard breach playbook so the team is not improvising during an incident.
Let 10decoders Secure Your AI Agent Rollout
Our agentic AI security assessment maps every agent running in production, tests for indirect prompt injection and tool misuse, and builds the identity and access scoping your team needs before agents get write access to systems that matter.