Security-review an AI feature against the OWASP LLM Top 10

Review this AI feature for the ways it can be turned against us. Sweep it against the OWASP Top 10 for LLM applications, 2026 revision, and tell me where untrusted text can reach something privileged.

What the feature does for the user: {{two or three sentences}}
Model and system prompt: {{which model, and what the system prompt establishes — paste it if you can}}
Untrusted input it reads: {{everything the model sees that a user or third party can influence: chat input, uploaded files, fetched web pages, email or ticket bodies, retrieved documents, tool results}}
Tools and actions it can call: {{each tool, what it does, and whether it writes anywhere, sends anything, or spends money}}
Data it can retrieve: {{indexes, tables, tenant scoping, and whether retrieval is filtered per user before results enter the context}}
Who can trigger it: {{end users, internal staff, a schedule, another agent}}
Where the output goes: {{rendered as HTML, written to a database, passed to a shell or SQL, sent as an email, consumed by another agent}}
Controls in place: {{filters, allowlists, approval steps, rate limits, spend caps, logging — or "none yet"}}

Work in this order.

**1. Trace the untrusted path first.** For each untrusted input, follow it: which prompt it lands in, which tools become reachable once it sits in the context window, and which of those tools has a side effect. Any path that runs from attacker-controlled text to a side effect with no human in between is the headline finding. Everything else is secondary to it.

**2. Sweep the ten categories.** Prompt injection, direct and indirect. Sensitive information disclosure. Excessive agency. Supply chain. Data and model poisoning. Unbounded consumption. Misinformation. Hidden context exposure. Vector and embedding weaknesses. Improper output handling. For each, say whether it applies here and on what evidence from my description. One clause is enough where it does not apply.

**3. Write the findings.** For each surviving risk:

- Who the attacker is and where they place their text
- The path, as a chain: input, prompt, tool, effect
- What they get out of it
- The fix, in the order I should attempt it. Reduce agency first: remove the tool, scope the credential down, allowlist the arguments. Then constrain the output at the consumer. Then filter the input. Say plainly when a filter is the only thing standing between untrusted text and a privileged action, because that arrangement fails eventually.
- Whether this one wants a human approval step rather than a control

**4. Least-privilege pass on the tools.** For each tool: the narrowest credential it could run with, and whether it should be reachable at all on paths where untrusted content is already in the context.

**5. Consumption and cost.** What an attacker can make this feature spend, and what caps a run per user, per tenant, and per day.

**6. What to test.** Three adversarial cases written for this specific feature, each with the input to send and the observable result that means it failed.

Do not assign a severity you cannot support from my description. Where the presence of one control decides whether a finding is real, ask me about that control instead of assuming it.

Tip: The system prompt and the tool schemas carry most of the signal here — pasting them changes the review more than naming the model does. Redact API keys and connection strings first. The 2026 revision moved excessive agency to third and renamed system prompt leakage to hidden context exposure, so a review written against the 2025 list will miss where agent deployments actually fail.