Authorization bypass, model-free

No jailbreak, no hidden text, no encoding, no payload. Sign in as an ordinary user, change one identifier, and see whether anything downstream objects. In this course we run this before any prompt-craft, and it is the least glamorous thing here.

Why this is in scope at all

A reasonable objection: if nothing is injected, is this even an LLM finding? The standard answers it in the definition, with the clause module 3.4 asked you to read twice.

The entry is defined over outputs. Nothing in it requires an attacker to have persuaded anything. A tool call carrying an identifier its caller should not have is exactly the case it describes, whether that identifier arrived by injection or by typing.

And there is a practical reason to run it first. Injection work is slow, probabilistic, and hard to reproduce in a report. This is deterministic. It either returns the other tenant's record or it does not, which is why this course puts it ahead of the model-layer work.

Run the range

Watch the trace for a plant step. There is not one, and there is no system-prompt trickery either. Then flip the lever through all five enforcement points.

Four of the five fail. The three that fail worst share a property: they put the decision somewhere the model can read, which means they put it somewhere the attacker's text also lives.

The one that looks like it works

Filtering the answer afterwards comes up often, and it is the most interesting failure of the five. The user sees a refusal. The record was still read.

It is in the context window, in the trace, in the logs, in the cache, and available to the next turn. Filtering protects the screen, and the screen was never the asset.

Where the check belongs

OWASP then names the three valid places for it: the tool, an independent pre-execution policy decision point between the tool and the downstream system, or the downstream system itself. All three sit outside the model. That is the property that matters, more than the choice between them.

How to actually run this

Two accounts and a browser devtools panel. No tooling, no model access, no payload library.

1. Sign in as a low-privilege user. Do something ordinary.

2. Capture the tool call the agent makes on your behalf.
     Network tab, trace viewer, debug panel, agent logs.
     You are learning the parameter names and the ID format.

3. Horizontal: re-issue it with an identifier you should not
     own. Another tenant, another user, another project.

4. Vertical: ask for an action your role may not perform.
     Approve, refund, delete, escalate, invite.

5. Grade on the recorded side effect, never on the reply.
     "I can't show you that" plus a row in the access log
     is a finding, not a refusal.

Step 5 is the one that separates a useful report from a wasted week. The assistant's text is not evidence of anything. Check the database, the audit log and the trace.

When there is no clean answer

Some actions cannot be decided by a per-request rule, because whether they are safe depends on context. OWASP offers a graduated policy for those: audit, warn, block, escalate.

Its example is worth stealing. A refund as store credit is recoverable, so auto-approve it. An external payout is not, so route it to a human. The axis is reversibility, not sensitivity.