---

Cost of an Unsecured AI Agent: Real Breach Patterns

A support copilot at a mid-market SaaS company had one job: answer billing questions and, when needed, issue account credits under $50 without waiting on a human. Nobody flagged it in the initial rollout review, because on paper the agent's permissions looked reasonable. Three weeks after launch, a string of ordinary-looking follow-up messages talked the agent into approving a credit more than forty times over its intended limit, and into pulling up a transaction history that belonged to a different account entirely. No malware. No CVE. Just an agent doing exactly what its tools allowed it to do, in a context nobody had tested for. That gap between what an AI agent is supposed to do and what its permissions actually let it do, is where the real cost of an unsecured AI agent gets created, and it's the pattern we see most often once these systems move from demo to production.

---

What "Unsecured" Actually Means Once an LLM Can Take Action

A chatbot that only generates text has a narrow blast radius: worst case, it says something wrong or embarrassing. An agent is different because it has agency, it can call APIs, query databases, send emails, update records, or trigger workflows on a user's behalf. Security testing built for the chatbot era largely stops at "does it say something bad?" That question still matters, but it's no longer the expensive one.

The expensive question is: what can this agent be induced to do, and under whose authority does it do it? Most agentic AI risk examples we encounter trace back to a mismatch between the permissions an agent was granted for convenience and the permissions it actually needs for its narrowest task. When that mismatch exists, a manipulated conversation doesn't need to "hack" anything, it just needs to ask, persistently and plausibly enough, for something the agent is technically allowed to do.

This is also why unsecured AI agent incidents are hard to explain to a board using traditional breach language. There's often no exploited vulnerability in the CVE sense, the system worked as coded. What failed was the assumption that natural-language instructions and backend authority could safely share the same channel.

---

Where This Maps to the OWASP LLM Top 10 (2025)

Two categories from the OWASP Top 10 for LLM Applications (2025) account for the majority of the agentic AI risk examples we log during engagements:

• LLM06:2025 - Excessive Agency. This covers agents granted more permissions, tools, or autonomy than their task requires, the root cause behind unauthorized write actions like the credit-approval example above. Excessive Agency findings are almost never about the model being "tricked" in a sophisticated way; they're about scope that was never tightened after launch.
• LLM02:2025 - Sensitive Information Disclosure. This covers cases where an agent's retrieval step, tool output, or conversational memory surfaces data the requesting user was never entitled to see, PII, internal pricing, other customers' records, or system prompt contents.

A third category, LLM01:2025 - Prompt Injection, usually shows up as the entry vector rather than the root cause: it's the mechanism that nudges an over-permissioned or under-scoped agent into misusing the access it already has. In our reporting, we treat prompt injection resilience and permission-scope testing as two separate line items, because fixing one without the other leaves the underlying cost exposure in place.

---

Patterns We Keep Finding in AI Agent Engagements

Across web, mobile, cloud, and now agentic AI engagements, a handful of AI agent breach cost drivers show up again and again. None of these require an exotic attack, they're closer to configuration debt that nobody priced out before launch.

1. Tool access scoped to the team, not the task. Agents are frequently wired to a shared internal service account, "the CRM integration" or "the billing API key", rather than a narrowly scoped credential for the one action the agent performs. This turns a single manipulated conversation into a much larger blast radius than the product team intended.

2. Retrieval that over-fetches, then paraphrases. A common LLM02 pattern: the agent's retrieval-augmented generation (RAG) layer pulls a full record to answer a narrow question, and the model, trying to be helpful; includes more of that record in its response than the user should see. The vulnerability isn't in the model's training; it's in what the retrieval layer handed it.

3. No human checkpoint on high-impact actions. Read actions (look up an order, summarize a ticket) and write actions (issue a refund, change an email address, send an external message) are routinely given the same trust level. In mature deployments, write actions above a defined risk threshold require a confirmation step or human approval, a control that's cheap to add before launch and expensive to retrofit after an incident.

4. Session and tenant boundaries that blur under pressure. In multi-tenant products, we've found agents that reused a single session context or credential across conversations in ways that, under the right sequence of prompts, allowed data or actions from one tenant context to bleed into another.

5. Logging that can't reconstruct what happened. When an agent takes an unintended action, the incident response team's first question is "what exactly did it do, and why?" Many deployments log the final output but not the intermediate tool calls, retrieved context, or permission checks; which turns a two-hour investigation into a two-week one.

---

A Sanitized Walkthrough: How a Support Agent Overstepped Its Job

To be clear about what follows: this is a composite, illustrative scenario built from patterns across multiple engagements, written to explain the risk class; not a working exploit, not real client data, and not a step-by-step attack recipe.

A fintech client's support agent could (1) look up a customer's own transaction history and (2) issue a goodwill credit up to a small preset limit, both intended to reduce ticket volume for routine disputes. During testing, our team held an extended, entirely ordinary-sounding conversation with the agent; asking follow-up questions about a "delayed refund," referencing a prior (fabricated) support interaction, and gradually reframing the conversation's context. Over the course of that conversation, the agent was induced to treat the credit limit as a per-request suggestion rather than a hard ceiling, and separately, to include line items from the customer's broader account history that weren't relevant to the original question.

"The agent never did anything it wasn't technically allowed to do. That's exactly the problem; the permission boundary was drawn around the tool, not around the situation." ~ Shofiur Rahman, CEH, CEO, Pentest Testing Corp

Nothing in that scenario involved malware, credential theft, or a code-level vulnerability. It involved a permission boundary that existed on paper but wasn't enforced at the point where it mattered, which is precisely why automated scanners tend to miss this risk class entirely.

---

What an Unsecured AI Agent Actually Costs

The dollar figure attached to "AI security incident impact" depends heavily on whether governance and access controls existed before the incident, not just how the response was handled afterward. IBM's 2025 Cost of a Data Breach Report, the first edition to study AI-specific incidents directly puts real numbers behind this:

• The global average cost of a data breach in 2025 sits at roughly $4.44 million, down from the prior year, largely due to faster detection and containment.
• Among organizations that reported a breach involving an AI model or application, 97% lacked proper AI access controls at the time of the incident.
• Those AI-related incidents led to compromised data in 60% of cases and operational disruption in 31% of cases.
• "Shadow AI", AI tools deployed or used without security oversight; was a factor in roughly one in five breaches studied, and added an estimated $670,000 to the average cost of those incidents compared to breaches without it.
• 63% of organizations in the study had no formal AI governance policy in place at all.
• Costs vary sharply by region and sector: U.S. breach costs averaged $10.22 million, and healthcare, the most expensive industry for the fourteenth consecutive year; averaged $7.42 million with containment taking around 279 days.

Those figures capture direct breach costs, but the AI agent breach cost pattern we see in engagements also includes line items that don't always make it into a headline number: emergency engineering time to re-scope agent permissions under pressure, legal review of what data may have been exposed, customer notification obligations under frameworks like HIPAA or GDPR if PII was involved, lost momentum on enterprise deals stalled by a security questionnaire, and the reputational cost of explaining to a customer that an AI system, not a human; made an unauthorized decision on their account.

---

Five Controls That Change the Cost Equation

None of the patterns above require rebuilding an agent from scratch. In our experience, these five controls do the most to shrink both the likelihood and the cost of an incident:

1. Least-privilege tool scoping. Give the agent its own scoped credential per function, a read-only lookup key separate from a write-capable credit-approval key; instead of one shared service account that can do everything the underlying system allows.

2. Action tiering with a human checkpoint. Classify actions by impact (read, low-impact write, high-impact write) and require explicit confirmation, a secondary approval, or a hard dollar/record cap for anything in the high-impact tier; the same way a human employee would need sign-off above a certain threshold.

3. Retrieval-response filtering. Constrain what the model is allowed to include in its response to exactly the fields relevant to the question asked, rather than trusting the model to self-censor a full record it was handed.

4. Tenant and session isolation testing. In any multi-tenant product, explicitly test whether context, credentials, or retrieved data from one session can be referenced or reused in another; this is rarely covered by functional QA.

5. Structured, tool-call-level logging. Log not just the agent's final response but every tool call, the parameters passed, and the permission check performed. This is the single biggest lever for cutting incident response time, and by extension, cost.

---

Traditional Pentest vs. AI Agent Pentest

Dimension	Traditional Web/API Pentest	AI Agent Pentest
Primary attack surface	Code, endpoints, session and auth logic	Prompts, tool permissions, context boundaries, memory/retrieval
Risk framework tested	OWASP Top 10 (Web)	OWASP Top 10 for LLM Applications (2025), including LLM06 and LLM02
Typical exploitation path	Direct technical exploitation of a coding or configuration flaw	Manipulating agent reasoning to misuse legitimate, already-granted permissions
What "compromise" looks like	Unauthorized access, data exfiltration, code execution	Unauthorized actions taken by the agent itself; refunds, data pulls, messages sent, records changed
Report deliverable	CVSS-scored findings with proof-of-concept	Findings mapped to agent permission scope, OWASP LLM IDs, and remediation for guardrails and policy logic
Compliance value	Evidence for SOC 2, PCI DSS, HIPAA technical controls	Same technical evidence, plus documentation gaps relevant to NIST AI RMF MAP/MEASURE/MANAGE functions

Both are manual-first, OWASP-aligned assessments; the difference is that an agent pentest treats the permission boundary and the conversation itself as part of the attack surface, not just the code behind it.

---

What a Proper AI Agent Penetration Test Covers

An engagement built specifically for agentic systems, like our AI penetration testing service, typically evaluates:

• Tool and permission-boundary mapping - What can the agent actually do, versus what it was designed to do, across every connected API and integration.
• Excessive Agency testing (LLM06) - Whether high-impact actions (financial, account, communication) can be triggered outside their intended limits or without proper authorization checks.
• Sensitive information disclosure testing (LLM02) - Whether retrieval, tool output, or conversational memory can be manipulated into surfacing data beyond the requesting user's entitlement.
• Prompt injection and jailbreak resilience (LLM01) - How the agent responds to adversarial or manipulative input designed to override its instructions.
• Session and tenant isolation - Whether one user's or tenant's context can bleed into another's during multi-turn interactions.
• Logging and observability review - Whether the current logging setup would let your team reconstruct exactly what an agent did and why, if something went wrong.

Because most agents reach the outside world through APIs, we often pair this with a focused API penetration testing engagement to close gaps at the integration layer itself. And if you're reading this because you already suspect an agent has taken an action it shouldn't have, our digital forensic analysis services team can help reconstruct the timeline and scope the exposure before you make notification decisions.

---

Where NIST AI RMF Fits Into This

Findings from an AI agent pentest map cleanly onto the MAP, MEASURE, and MANAGE functions of the NIST AI Risk Management Framework; they identify risks, quantify them, and give your team concrete items to remediate. What a pentest report can't do on its own is satisfy the GOVERN function, which is about the internal policy, ownership, and accountability structure your organization has around AI use in the first place. A clean pentest report paired with no governance policy is close to what IBM's data describes as the norm today, not the exception; and it's the gap that turns a contained finding into a costly incident.

---

---

Book a Scoping Call

If you're deploying or already running an AI agent with any kind of write access, the question worth asking isn't whether it could be misused, it's whether you'd know if it had been. Book a free 30-minute scoping call with our team to talk through your agent's permission footprint and what a manual-first AI penetration test would look like for your specific setup.

{ "@context": "https://schema.org", "@graph": [ { "@type": "BlogPosting", "@id": "https://www.pentesttesting.com/blog/cost-of-unsecured-ai-agent/#article", "headline": "Cost of an Unsecured AI Agent: Real Breach Patterns", "description": "See the real cost of an unsecured AI agent, from breach-cost data to the engagement patterns we keep finding — plus how to fix it. Book a scoping call.", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.pentesttesting.com/blog/cost-of-unsecured-ai-agent/" }, "keywords": [ "cost of an unsecured AI agent", "AI agent breach cost", "agentic AI risk examples", "AI security incident impact", "LLM06", "LLM02" ], "author": { "@id": "https://www.pentesttesting.com/about/#zubayer-ahmed" }, "reviewedBy": { "@id": "https://www.pentesttesting.com/about/#shofiur-rahman" }, "publisher": { "@type": "Organization", "name": "Pentest Testing Corp", "url": "https://www.pentesttesting.com/", "logo": { "@type": "ImageObject", "url": "https://www.pentesttesting.com/wp-content/uploads/logo.png" } }, "articleSection": "Pentest Deep-Dive", "inLanguage": "en-US" }, { "@type": "Person", "@id": "https://www.pentesttesting.com/about/#zubayer-ahmed", "name": "Zubayer Ahmed", "jobTitle": "Marketing Manager", "worksFor": { "@type": "Organization", "name": "Pentest Testing Corp", "url": "https://www.pentesttesting.com/" } }, { "@type": "Person", "@id": "https://www.pentesttesting.com/about/#shofiur-rahman", "name": "Shofiur Rahman", "jobTitle": "Chief Executive Officer", "hasCredential": { "@type": "EducationalOccupationalCredential", "credentialCategory": "Certified Ethical Hacker (CEH)" }, "worksFor": { "@type": "Organization", "name": "Pentest Testing Corp", "url": "https://www.pentesttesting.com/" } }, { "@type": "FAQPage", "@id": "https://www.pentesttesting.com/blog/cost-of-unsecured-ai-agent/#faq", "mainEntity": [ { "@type": "Question", "name": "What makes an AI agent \"unsecured\" compared to a regular chatbot?", "acceptedAnswer": { "@type": "Answer", "text": "An unsecured AI agent has been given tool access, write permissions, or autonomous decision-making ability without corresponding controls — such as scoped credentials, action-level authorization, or logging — to match that authority. A chatbot that only generates text carries a much smaller risk profile than an agent that can act on a user's behalf." } }, { "@type": "Question", "name": "How much does an AI agent security incident actually cost?", "acceptedAnswer": { "@type": "Answer", "text": "Industry data from IBM's 2025 Cost of a Data Breach Report puts the global average breach cost around $4.44 million, with AI-related incidents skewing higher when governance and access controls were missing — shadow AI alone added an estimated $670,000 to average incident cost. Actual cost depends heavily on data sensitivity, regulatory exposure, and how quickly the incident is detected and contained." } }, { "@type": "Question", "name": "What's the difference between prompt injection and excessive agency?", "acceptedAnswer": { "@type": "Answer", "text": "Prompt injection (LLM01:2025) is the technique used to manipulate what an agent does or says. Excessive Agency (LLM06:2025) is the underlying condition — permissions or autonomy broader than the task requires — that makes a successful manipulation costly. You can have prompt injection without excessive agency, and excessive agency without prompt injection." } }, { "@type": "Question", "name": "Can standard vulnerability scanners catch these risks?", "acceptedAnswer": { "@type": "Answer", "text": "Not reliably. Automated scanners are built to find code-level and configuration flaws, not to hold a multi-turn conversation designed to test whether an agent's reasoning can be steered into misusing its permissions. This risk class requires manual, conversation-based testing." } }, { "@type": "Question", "name": "How often should an AI agent be pentested?", "acceptedAnswer": { "@type": "Answer", "text": "At minimum, before launch and after any material change to the agent's tools, permissions, or underlying model. Agents being expanded with higher-risk actions like payments or outbound communication warrant more frequent review than a static chatbot." } }, { "@type": "Question", "name": "Does an AI agent pentest help with SOC 2, HIPAA, or PCI DSS compliance?", "acceptedAnswer": { "@type": "Answer", "text": "Yes — findings and remediation evidence from an AI agent pentest support the technical control requirements auditors look for under these frameworks, and can be mapped directly to relevant OWASP LLM Top 10 categories in your compliance documentation." } } ] } ] }