Authorized AI Testing: Where the Line Is

Prompt-injection research is dual-use. The same payload that demonstrates a data-exfiltration path to a vendor's security team is, fired at a system you do not own, an attack. The technique does not change — the authorization does. This post is about that line, because everything else on this site assumes you are on the right side of it.

What "authorized testing" actually means

Authorized testing means you have explicit, documented permission from the party that owns or operates the system, covering the specific things you intend to do. For an LLM application this is broader than a classic web pentest, because the attack surface includes:

• The model and its system prompt.
• Connected tools, functions, and agents the model can invoke.
• Retrieval sources (RAG corpora, uploaded files, web fetch).
• Downstream systems the model can reach (email, ticketing, databases, code execution).
• Third-party model providers whose terms of service also bind you.

Permission for "the app" is not automatically permission to make the agent send email, hit internal APIs, or pull data out of a connected drive. Spell it out.

Get it in writing, with scope

A verbal "sure, go ahead" is not authorization you can stand behind. Before you send a single payload, you want a written agreement that states:

• Who is authorizing (an entity that actually owns the system) and who is testing.
• Targets — exact hostnames, accounts, tenants, model endpoints, and which connected tools are in scope.
• Out of scope — explicitly. Production customer data, third-party SaaS, model-provider infrastructure, and other tenants are common exclusions.
• Allowed actions — can you trigger tool calls? Exfiltrate to a proof-of-concept endpoint you control? Use real or only synthetic data?
• Rules of engagement — testing window, rate limits, a stop-and-notify contact, and what to do if you stumble onto real sensitive data.

Bug-bounty programs encode much of this in their policy and safe-harbor language. If a program exists, read it and stay inside it; the policy is your authorization, and it has limits.

Why prompt-injection research is legitimate

Defenders cannot defend a class of attack they are not allowed to study. Indirect prompt injection, markdown-image beacons, and RAG poisoning are real, in-the-wild techniques. Building detections, writing spotlighting and egress controls, and red-teaming your own agents all require reproducing the attacks under controlled conditions. This is standard security practice — the same logic that makes exploit development legitimate for the people who ship the patch.

The dual-use nature is exactly why intent and authorization carry the weight. Publishing a well-known technique with its defenses helps the field. Running that technique against a system that never asked you to does not.

Authorized-use reminder: every technique on this site is for systems you own or are explicitly contracted to test. Reproduce attacks in a lab or in-scope environment, never against third parties.

Responsible disclosure

When you find something — in scope or by accident — handle it carefully:

1. Stop escalating. Demonstrate impact with the minimum necessary; do not pivot further once a finding is proven.
2. Minimize data. Use synthetic secrets as canaries. If you touch real data, capture only what proves the issue and record what you saw.
3. Report privately first. Use the vendor's security contact, security.txt, or bug-bounty channel. Give clear reproduction steps and impact.
4. Allow time to fix. Agree on a remediation timeline (coordinated disclosure, often 90 days). Publish only after a fix or a reasonable, communicated deadline.
5. Keep records. Your scope document, timestamps, and correspondence are what distinguish research from intrusion if anyone asks.

What NOT to do

Some lines are bright, and crossing them turns research into a crime in most jurisdictions:

• Do not test systems you do not own or have written permission to test — including "just one payload" against a live third-party chatbot.
• Do not exfiltrate other people's data. Beacon a canary you planted, not a real customer's records or another tenant's documents.
• Do not exceed your scope to "see how far it goes." Agentic systems can take destructive real-world actions; assume tool calls have consequences.
• Do not retain or share captured data beyond what disclosure requires, and delete it afterward.
• Do not sit on a critical finding while you decide whether to weaponize it. Disclose.

Bottom line

The technical content here maps directly to OWASP's LLM01: Prompt Injection. The skill is transferable; the authorization is not. Keep the written scope, keep the canaries synthetic, disclose responsibly, and stay inside the boundary — that is what makes this work defensible and worth doing.