Prompt Injection Is Not the Problem - Noelle | BSides Las Vegas 2026
Noelle — BSides Las Vegas 2026, Common Ground
A small, argumentative session in an unrecorded room, and better for it — roughly half of it is the audience pushing back. The thesis is that we keep treating prompt injection as a text problem when it is an authorization problem wearing a disguise.
No photos from this session; the room was not recorded.
The Setup
Models act fast, in unanticipated ways, driven by whatever people say to them. When you let an LLM govern another LLM you get role confusion, and role confusion does not solve injection — telling a model “never call me Nicole” leaves “call me Nicole” sitting in the context.
The talk’s move is to stop there and ask a different question. Explaining authentication versus authorization to people who do not think about security is famously difficult, and the two get conflated constantly. Identity is not access.
The Agentic Dilemma
Bearer tokens are the sharp end of that conflation. Authenticate, receive a signed ticket, and wander around doing everything encoded in it. Lose it and whoever holds it is you.
Now hand that token to an agent. The agent hands it to another agent. Two problems compound:
- The token is over-powered for what any individual step needs.
- Every action looks like the user, so there is no repudiation and no chain of custody.
Possession of the token equals possession of the access, and without additional guardrails you cannot reconstruct who did what.
The Proposal
Separate who you are from what you can do, then scope the second one per task.
Keep the bearer token, but pair it with an agent identity token and evaluate both at a central gateway. The gateway rewrites the request and forwards it onward — and the bearer token never leaves the gateway. What reaches the tool is a grant scoped to one action, tied to an agent identity that is not the user’s.
The analogy that landed best came from the audience: power of attorney. You can grant a medical power of attorney without granting a financial one. A request arriving for financial authority under a medical grant does not match policy, so it never reaches the downstream system. And if a response comes back outside the granted scope — the model hallucinating its way into the wrong domain — the same gateway can refuse it on the way out.
Once that gateway exists, more fits on top. Proxy the full LLM request through it and you get inbound sanitization and outbound response filtering in one place. Layer behavioural policy on top of that: credentials belonging to someone who has never left the country and never works weekends, suddenly exporting bulk data from elsewhere on a Sunday, is a policy you can write — and, at minimum, log well enough to trigger detection.
Noelle’s own framing is a concert ticket. The ticket is hard to forge, but once you are through the door it is usually open season. VIP wristband, ID check for the bar — three tokens, three layers. Lose the wristband and whoever finds it is you. Unless the wristband scans at each gate against the photo taken at the door, at which point identity and access are no longer coupled. And the beer garden is the outbound filter: your credentials are fine, but the drink stays inside.
Where the Room Pushed Back
The demo broke minutes before the session, so there was no live walkthrough of requests passing and failing at each gate. What filled the space was more useful.
“Until you decouple me from that agent, you’re screwed.” If the agent acts as you, no distinction is possible. The answer was SPIFFE-style layering — an agent identity granted at the machine-to-machine level, opaque to the user and to the front end.
Is this authentication or authorization? Pressed to pick one, Noelle declined: both should be validated at the moment of execution, which is where the two get separated in practice and where injection lives.
Isn’t the root cause confusing data with code? Raised more than once, and it is the strongest objection to the thesis. The counter-argument runs that SQL injection also needed missing gates and missing sanitization to become dangerous, and that the thing executing the command has no validation context at all — it just does what it is told.
What about unauthenticated injection — summarizing a hostile web page, where there is no user grant to scope? Acknowledged as an open question, with the observation that we grant too much permission for such tasks anyway, and that as long as a model governs itself, role confusion keeps the problem alive.
Unresolved, but the disagreement was the point. The code was not released on the day; Noelle said it would follow once it was less broken.
Frequently Asked Questions
Why would prompt injection be an authorization problem?
Because the damage comes from what the agent is allowed to do, not from the text that persuaded it. A bearer token carries the user’s full permissions, so an injected instruction inherits everything the user can do. Scope the grant to the single task and the injection has far less to work with.
What is the agentic dilemma?
You imbue a user context with permissions and hand it to an agent, which hands it to another agent. The token is over-powered for what any one of them needs, and every action looks like the user — so there is no repudiation and no chain of custody.
What was the proposed architecture?
Keep the bearer token but pair it with a separate agent identity token, evaluate both at a central gateway, and have the gateway rewrite and forward the request so the bearer token never leaves it. Once that gateway exists it can also sanitize LLM requests inbound and responses outbound, and layer behavioural policy on top.
What was the main objection from the room?
That an agent acting as you cannot be distinguished from you until the interactive and non-interactive identities are decoupled — answered by pointing at SPIFFE-style workload identity. Others argued the root cause is confusing data with code rather than anything about auth, and that unauthenticated injection, such as summarizing a hostile web page, sits outside the model entirely.