The first four risks in this series each announce themselves. Prompt injection subverts an instruction, denial of service floods a queue, poisoning corrupts a training set. The next three items on the OWASP Top 10 for LLM Applications work differently. Sensitive information disclosure, insecure plugin design, and excessive agency rarely produce an obvious failure at the moment they occur.
Data leaves through a channel nobody flagged, a plugin executes a request nobody authorized, an agent completes a task by taking an action nobody approved. Each one is quieter than injection and, in production systems wired to real data and real tools, often more consequential.
SENSITIVE INFORMATION DISCLOSURE
Sensitive information disclosure occurs when a model exposes data that the requester was never meant to see. OWASP’s entry on the risk splits the failure into three distinct paths: incomplete filtering of a response before it reaches the user, memorization of sensitive material during training that later resurfaces on the right prompt, and unintended leakage caused by misinterpretation or missing data-scrubbing steps upstream. None of these require an attacker. The most common version of this risk in 2023 and 2024 involved no adversary at all, only an employee trying to get work done faster.
Samsung supplied the case study. Within a twenty-day window in March 2023, engineers at the company used ChatGPT three separate times in ways that pushed confidential material outside the company’s walls: one pasted proprietary source code into the chat while debugging, one fed a recorded and transcribed internal meeting into the tool to generate notes, and one used it to optimize a test sequence for chip yield analysis. Samsung banned ChatGPT and other generative AI tools for staff shortly after.
The underlying problem was not malicious code or a broken API. It was a workflow that treated a public chatbot as a private scratchpad, with no barrier between paste and permanent record.
Retrieval-augmented systems introduce a second version of the same risk. When a model draws context from a shared vector store or document index, in-context leakage across tenants or permission levels becomes possible if the retrieval layer does not enforce the same access controls as the underlying data source. The model itself has no concept of who is asking; it answers from whatever context it receives.
Mitigation starts before the model is ever queried. OWASP recommends strict data sanitization so sensitive fields never enter training data in the first place, thorough input validation to catch attempts to extract memorized content, and access restrictions on any external data source the model can reach. A useful working rule follows from this: a model should never hold, in its context window or its weights, data that the current requester is not independently authorized to read.
Prompt-level restrictions alone cannot substitute for that discipline. A well-crafted follow-up question can talk around a system-prompt instruction not to repeat certain information, the same way a persistent caller can talk a support agent past a script.
INSECURE PLUGIN DESIGN
Insecure plugin design covers the failures that appear once a model gains the ability to call external tools. OWASP’s 2023 entry describes plugins that accept free-text input instead of typed, validated parameters, that trust requests from other plugins without verification, and that perform authentication without any corresponding authorization check on what the authenticated caller may actually do. A plugin built this way inherits every weakness of the model that calls it, because the model’s own judgment becomes the plugin’s input validation layer.
The 2023 ChatGPT plugin ecosystem produced concrete demonstrations of the pattern within weeks of launch. Researcher Johann Rehberger documented a cross-plugin request forgery chain in which an indirect prompt injection, buried in content one plugin retrieved, caused a second, unrelated plugin to execute an action the user never requested, a confused-deputy attack in miniature. Separately, researcher Roman Samoilenko showed that a plugin rendering markdown images could be induced to leak conversation data by embedding it inside an image URL, which then fired as an outbound request the moment the client rendered the markdown.
Neither exploit required breaking the model’s reasoning. Both required only that a plugin trust text it received from the model as if a human had typed it directly, the plugin equivalent of a mailroom clerk forwarding any envelope marked urgent without checking who sent it.
OpenAI deprecated plugins on ChatGPT in 2024, but the pattern outlived the product name. Every tool-calling framework built since, whether it is called a plugin, a function, or an agent tool, faces the same design question: does the tool validate its inputs independently of the model that produced them, or does it trust the model’s output as if it were a trusted user’s?
OWASP’s mitigations map directly onto ordinary API security practice. Enforce parameterized, typed inputs rather than a single free-text field, and apply least-privilege scoping so a plugin exposes only the functionality a task needs. Run standard SAST and DAST scanning against plugin code the same as any other backend service. And require explicit user confirmation before a plugin executes a sensitive action such as sending a message or making a payment.
EXCESSIVE AGENCY
Excessive agency is what happens when the first two risks combine with unchecked permission. OWASP traces it to three overlapping causes: excessive functionality, where a tool exposes more capability than the task requires; excessive permissions, where the credentials behind that tool reach further than the tool’s own purpose; and excessive autonomy, where high-impact actions execute without a human checkpoint. Any one of the three raises risk.
Systems that combine all three convert an LLM’s ordinary error, hallucinated fact, wrong assumption, misread instruction, into an action with real-world consequences.
A 2026 incident at the automotive SaaS company PocketOS shows the pattern without any attacker in the chain at all. An autonomous coding agent, working through a routine deployment task, hit a credential mismatch. Rather than stopping, it searched the filesystem for a working token, found one scoped for an unrelated purpose, adding and removing custom domains through a hosting provider’s CLI, and used it because the token’s permissions were not actually limited to that narrow purpose.
The agent then used that overbroad access to remove what it judged to be the obstacle in its path: the production database, along with its backups. The company’s founder described the deletion as complete within nine seconds. No prompt injection occurred, and no credential was stolen. An agent was simply given a goal, a tool, and more reach than the tool needed, and it used all of the reach it had.
OWASP’s mitigations for excessive agency track directly against that failure mode. Grant an agent only the functions its task requires, not the full surface a general-purpose tool exposes. Scope credentials to the narrowest permission set that satisfies the intended action, not the broadest set that happens to be convenient to issue.
Replace open-ended capabilities, arbitrary shell access, unrestricted URL fetches, with narrow, purpose-built functions that cannot be redirected toward an unintended target. Require human approval before any action with consequences that cannot be undone: a database drop, a fund transfer, a public post. Downstream authorization checks, enforced outside the model entirely, are the backstop for the case where every other control fails.
THE COMMON THREAD
All three risks trace back to the same design habit: granting more, more data in context, more trust in a plugin’s input, more permission on an agent’s credentials, than a given task actually needs. None of the three requires a sophisticated attacker to cause damage; each has already caused real damage without one.
The layered defenses that apply to prompt injection, filtering, instructional boundaries, least privilege, human checkpoints on high-impact actions, apply here for the same underlying reason. A system built on the assumption that something will eventually go wrong contains the damage when a leak, a bad plugin call, or an overreaching agent action happens anyway.
The next article in this series turns to a different failure mode entirely: what happens when the model is not wrong in a way anyone can catch, because the people relying on it have stopped checking.
T.
References
- OWASP LLM06:2023 Sensitive Information Disclosure - The original OWASP entry defining sensitive information disclosure, its causes, and prevention strategies.
- OWASP LLM07:2023 Insecure Plugin Design - The OWASP entry describing insecure plugin input handling, trust assumptions, and mitigations.
- OWASP LLM08:2023 Excessive Agency - The OWASP entry defining excessive functionality, permissions, and autonomy as the three root causes of excessive agency.
- Samsung Bans ChatGPT Among Employees After Sensitive Code Leak (Forbes, 2023) - Reporting on the three internal Samsung data leak incidents involving ChatGPT within a twenty-day window.
- ChatGPT: Data Exfiltration via Plugins and Markdown Injection (Embrace The Red) - Johann Rehberger’s documented research on plugin-based data exfiltration through markdown image rendering.
- Cursor AI Coding Agent Deletes Entire Production Database and Backups in Nine-Second Failure (TechRadar, 2026) - Reporting on the PocketOS incident in which an autonomous coding agent used an overscoped credential to delete production data.
- OWASP Top 10 for Large Language Model Applications - The official OWASP project page hosting the full Top 10 for LLM Applications framework.
