An AI agent handed a browser, a set of credentials, and a single instruction — “log in” — can silently discover that removing the password entirely still grants access. That is the reality of AI-driven authentication and authorization vulnerability detection: agents expose the class of auth bugs that are too contextual, too custom, and too logic-dependent for classical scanners to touch. Custom authentication schemes ship daily, and no static validator can reason about whether a 200 OK really means the user is authenticated.
For security engineers tasked with testing modern web applications at scale, this talk from [un]prompted 2026 delivers a working methodology. You will see how to build verifiable login validators, repurpose them offensively to find MFA bypasses, and use auth transmogrification to automate differential authorization testing across privilege levels — without planting CTF flags by hand.
Key Takeaways
- You'll learn how AI agents can systematically discover authentication bypasses — including hardcoded secrets, MFA bypasses, and forged JWTs — by reusing the same validators that confirm a successful login.
- You'll be able to apply the "auth transmogrification" technique to automatically translate admin-context requests into low-privilege-context requests, enabling scalable differential analysis for authorization bugs.
- Apply differential response analysis to prioritize endpoints that behave differently across privilege levels, giving your attack agent a concrete, verifiable goal that eliminates false positives.
Why AI Agents Outperform Classical Scanners for Auth Bug Detection
Application security testing for auth bugs has a structural problem that predates AI agents entirely. AI agents for authentication and authorization vulnerability detection represent a fundamental shift in how security engineers approach one of the hardest classes of bugs in web application security. Classical scanners — rule-based, pattern-matching, deterministic — fail here not because they are poorly built, but because the problem itself is definitionally resistant to static analysis.
The Auth Mechanism Explosion Problem
The modern web application authentication landscape is not standardized. As Brendan Dolan-Gavitt and Vincent Olesen outlined at [un]prompted 2026, the list of auth mechanisms in production today is staggering: HTTP Basic, OAuth 2.0, signed URLs, JWTs, OIDC, OAuth 1.0, Kerberos, magic links, session cookies, TOTP, LDAP. Each mechanism has its own failure modes, edge cases, and implementation variants.
But the single most common auth mechanism deployed today is arguably none of those. It is custom auth — the in-house, developer-authored authentication system where someone decided they understood the problem well enough to build their own. No spec. No reference implementation. No formal validation. Just a developer’s mental model of how authentication should work, shipped to production.
This is not an edge case. It is the dominant reality. And it is precisely the condition under which classical validators collapse.
Why Classical Scanners Cannot Reason About Auth
A classical scanner operates deterministically: it sends a request, inspects the response, and applies a rule. The rule is either pattern-based (“does the response contain a 401 status?”) or signature-based (“does this response match known error patterns?”). That works for injection vulnerabilities where the payload produces a syntactically distinctive output. It does not work for authentication and authorization bugs, for a simple reason: the same HTTP response can mean completely different things depending on application context.
Consider the example from the talk: a request returns a 200 OK with a JSON body. Is the user authenticated? Maybe — or maybe it is a public phone book endpoint where authentication is irrelevant. Now consider the same 200 OK from a medical appointment booking system. There, authentication almost certainly matters. A classical scanner cannot distinguish these cases. The response surface is identical; the semantic meaning is not.
This is not a solvable problem within the classical paradigm. You cannot write a rule that says “this 200 OK means the user is authenticated” without understanding the application’s intent — and understanding intent requires contextual reasoning, not pattern matching.
The AI Agent Advantage: Contextual Verification
AI agents close this gap by reasoning about application context rather than response syntax. The approach described in the talk starts with a browser-equipped agent given credentials and a login task. Rather than inspecting a single response in isolation, the agent:
- Navigates the application to find places where the contrast between authenticated and unauthenticated state is observable
- Identifies confirmation signals — not just a 200 OK, but evidence that the application has actually transitioned to an authenticated session state
- Passes two validation checkpoints before any authenticated state is declared confirmed (more on the validator architecture in the next section)
The key insight from the talk is that agents can find “places in the app where there’s a contrast between being locked in and locked out.” Classical scanners look for error signals. Agents look for state transitions. That difference in approach is what makes the technique work across custom auth implementations, regardless of the specific mechanism used.
The Verification Loop: Why Validation Is the Core Innovation
The second reason AI agents outperform classical tools here is not the attack capability — it is the verification capability. AI models are probabilistic. When given an open-ended task like “find a security vulnerability,” they will produce false positives. As Dolan-Gavitt noted directly: “no matter what, they’re going to end up making things up.”
The solution is not to make the agent more conservative. It is to build a deterministic verification layer around the agent’s outputs. Every candidate vulnerability the agent surfaces must pass a validator before it is reported as real. This shifts the reliability problem from the probabilistic reasoning layer (the agent) to the deterministic verification layer (the validator) — exactly the architectural separation that makes automated security testing trustworthy at scale.
This is the foundational principle for everything that follows in the methodology: agents reason, validators confirm, nothing ships without both.
Why This Matters for Security Engineers
The practical implication for engineers building or operating penetration testing pipelines is direct: if your current toolchain relies on classical scanners for auth coverage, you have a systematic blind spot. Custom auth implementations, OAuth variants that deviate from spec, and authorization logic that requires understanding application semantics are all categories your existing tools cannot reliably reach.
AI-agent-based testing is not a replacement for all security tooling. But for the specific problem of auth-by-one errors — the class of bugs where authentication or authorization fails not because of a known vulnerability pattern but because of a logic error in a custom implementation — agents with verification loops are currently the only approach with demonstrated detection capability at scale.
Actionable Takeaways
- Audit your current security testing pipeline for auth coverage gaps: identify which authentication mechanisms in your target applications are custom-built or non-standard, and flag them as outside the reliable detection range of classical scanners. These are the targets that require agent-based testing.
- When designing any AI-assisted security testing workflow, separate the reasoning layer (the agent) from the verification layer (a deterministic validator). Never report a vulnerability based solely on agent output — require the agent's finding to pass a verifiable, ground-truth check before treating it as confirmed.
- Look for contrast points in your target applications: locations where the application behaves observably differently depending on authenticated versus unauthenticated state. These are the anchors for building reliable authentication validators and the starting points for offensive reuse.
Common Pitfalls
- Treating a 200 OK response as confirmation of successful authentication. As the talk explicitly demonstrates, the same HTTP response can indicate authenticated access on one endpoint and completely unauthenticated public access on another. Response status alone is not a reliable authentication signal without application context.
- Assuming that OAuth 2.0 or other standard protocol adoption eliminates custom-auth risk. The talk notes that "even if people implement OAuth 2, it's not necessarily spec compliant." Standard protocol names on a tech stack do not guarantee spec-compliant implementation — the agent-based verification approach is still required.
Building Reliable Login Validators for Automated Authentication Testing
The Core Problem: Defining “Logged In” for an AI Agent
AI agents for authentication and authorization vulnerability detection depend entirely on one foundational capability: knowing with certainty whether a login attempt succeeded. This sounds trivial until you try to implement it reliably across real-world applications. As Vincent Olesen explains in the talk, authentication is hard because there is so much of it — HTTP Basic, OAuth 2.0, signed URLs, JWTs, OIDC, OAuth 1.0, Kerberos, magic links, session cookies, TOTP, LDAP — and the single most common mechanism in practice is custom auth, where developers roll their own implementation without following a known spec.
Classical validators cannot handle this diversity. You cannot write a deterministic rule that says “this response means the user is authenticated” when the same 200 OK might mean the user is authenticated or that the endpoint is a public phone book that returns the same response regardless of credentials.
The Two-Checkpoint Validator Architecture
The approach used at Expo[1] builds authentication confidence through two sequential checkpoints, both of which must pass before an agent is considered genuinely logged in:
Checkpoint 1 — Browser-State Login Confirmation
The agent is given a browser, a set of credentials, and the instruction to log in. After the login attempt completes, the first validator checks whether the browser state reflects a confirmed authenticated session. This is not simply checking for a 200 OK on the login endpoint — it requires finding signals in the application state that unambiguously distinguish a logged-in user from an anonymous one.
Checkpoint 2 — API Request Authentication Confirmation
The second checkpoint validates that the agent has sufficiently reverse-engineered the application to translate its browser state into correctly authenticated API requests. This matters because many automated testing workflows need to issue raw HTTP requests, not just drive a browser. If the agent can produce authenticated API calls that also pass the validator, you have strong evidence it genuinely understands the application’s auth model — not just that a browser cookie happened to persist.
As Olesen states: “If an agent passes these two checkpoints, we’re pretty damn sure it’s logged in.”
The Ambiguous 200 OK Problem
One of the most instructive examples in the talk is the “is this logged in?” audience exercise. Olesen shows a screenshot of what appears to be an Apple login screen and asks the audience to vote. Many assume it is a confirmed authenticated session — but it is not. The visual appearance of a logged-in state is not the same as a validated authenticated state.
The second example makes the engineering problem concrete: given a single HTTP request in isolation, it is impossible to determine whether it represents an authenticated interaction. The same request pattern could be:
- A public phone book endpoint — authentication material is irrelevant
- A medical appointment booking endpoint — authentication is mandatory and load-bearing
The solution Olesen identifies is deliberately finding contrast points within the application: places where the difference between a logged-in and logged-out state produces a detectable, unambiguous signal. These contrast points become the basis for the validator’s logic. The validator does not attempt to understand the auth mechanism generically — it looks for specific, application-level evidence that the authenticated context is active.
Why Getting These Validators Right Is Non-Trivial
Olesen is direct about the engineering cost: “These validators took a lot of effort to get right.” The difficulty comes from real-world application variety. Internal banking applications, custom enterprise auth flows, and non-spec-compliant OAuth 2.0 implementations all present edge cases that break naive validators.
The approach that hardened these validators was sustained adversarial use — running them at scale against the widest possible range of applications, discovering corner cases, and iterating. This is an important design principle: the validators were not built to be theoretically complete. They were hardened empirically, by encountering failure modes in production-like conditions and resolving them one by one.
The payoff is that once you have robust, battle-tested validators, they become a reusable primitive. Every subsequent capability in the methodology — offensive bypass detection, authorization differential analysis — is built on top of this same validator layer rather than requiring its own authentication confirmation logic.
Key Design Principles for Validator Construction
- Find contrast points, not generic signals. The validator must observe application behavior that differs between authenticated and unauthenticated states, not just HTTP status codes.
- Validate browser state AND API request capability separately. A browser session that persists does not guarantee the agent can produce correctly authenticated API calls. Both must be confirmed.
- Build for the weird stuff. Custom auth schemes, non-compliant OAuth, and session management edge cases are the norm in real targets. Design validators against adversarial inputs, not the happy path.
Actionable Takeaways
- Identify at least two distinct contrast points per target application where authenticated versus unauthenticated state produces an unambiguous, machine-detectable difference — use these as the basis for your validator logic rather than relying on HTTP status codes alone.
- Implement validators as two independent checkpoints (browser-state confirmation and API request confirmation) so that both the session layer and the request-construction layer are verified before treating any downstream result as trusted.
- Harden validators by running them against the broadest possible range of real-world applications, not just synthetic test cases — corner cases in custom auth schemes only surface under adversarial conditions at scale.
Common Pitfalls
- Treating a 200 OK or a visually convincing logged-in UI state as sufficient proof of authentication — the talk explicitly demonstrates that these signals are unreliable, and a validator built on them will produce false positives that propagate through every downstream offensive check.
- Building a single monolithic validator that attempts to confirm both browser state and API authentication simultaneously — splitting these into two independent checkpoints makes it possible to diagnose which layer failed when authentication confirmation breaks on a new target.
Offensive Validator Reuse: Authentication Bypass and MFA Bypass Detection
Turning a Defensive Tool Offensive
The same validators built to confirm genuine authenticated state are, by design, the ideal instruments for detecting authentication bypass vulnerabilities. Once you have a two-checkpoint system that reliably distinguishes logged-in from logged-out state, you have an answer key — and you can use that answer key to ask adversarial questions.
The core insight from Brendan Dolan-Gavitt and Vincent Olesen’s [un]prompted 2026 talk is deceptively simple: if a validator built to confirm login can be fooled by a broken authentication implementation, that failure is the vulnerability. You do not need to reason about the authentication logic. You outsource the judgment to the validator.
The Authentication Bypass Pattern
The method works as follows:
- Give the agent credentials (username and password) and instruct it to log in.
- Run the two-checkpoint validator: confirm browser-state login and API request authentication.
- Strip the password from the credential set.
- Instruct the agent to attempt login again with only the username — no password.
- Re-run the validator. If both checkpoints pass, the application has an authentication bypass: it accepted the login without valid credentials.
This is a direct offensive reuse of the login validator. No additional tooling is required. The same infrastructure that powers reliable authenticated crawling is now a vulnerability detector.
Hardcoded Secret Key: AI Agent Forges Session Tokens for Admin Access
Proof of Concept
-
Baseline authentication run: The AI agent is given a browser, admin credentials, and a login task. It completes the login flow normally, passing two validators: (a) a browser-state login confirmation that checks whether the UI reflects an authenticated session, and (b) an API request authentication confirmation that verifies the agent has correctly reverse-engineered the application’s auth mechanism. At this point, a known-good authenticated state is established as the reference.
-
Source code reconnaissance: Operating in authentication bypass detection mode — where credentials are withheld or stripped — the agent pivots to static analysis. It reads through the application’s source code rather than attempting a credential-based login.
-
Hardcoded secret key discovery: The agent locates the JWT[2] signing secret hardcoded directly in the application source. This is the vulnerability originally discovered and documented by Horizon 3[3]: the application shipped with a default secret key embedded in the codebase rather than injected via environment variable or secrets manager.
-
Session token forging: Using the recovered secret, the agent constructs a new JWT with an admin-level claim (e.g.,
role: adminor equivalent privilege indicator). The token is signed with the hardcoded key, producing a cryptographically valid session token that the application’s backend will accept as legitimate. -
Browser state injection: The agent loads the forged token into the browser — replacing any existing session material — simulating what a real attacker would do after obtaining the key out-of-band (e.g., from a public repository, a leaked binary, or a misconfigured container image).
-
Validator confirmation: The agent is re-evaluated against both login validators. The browser-state validator confirms the UI now reflects an admin-authenticated session. The API request validator confirms that requests made with the forged token are accepted by the backend as authenticated. Both validators pass — confirming a complete, verified authentication bypass.
-
Outcome: The attack agent achieved admin access without supplying any valid credentials. The vulnerability class is a hardcoded secret key enabling JWT forgery, and the AI agent’s ability to combine source code reading with token crafting and validator-based verification made discovery and confirmation fully automated.
The MFA Bypass Pattern
The same removal logic applies to multi-factor authentication. For applications that require a second (or additional) factor at login:
- Run the full login flow with all required factors (password + TOTP, password + magic link, etc.).
- Confirm the agent passes both validators.
- Remove the second factor from the login flow — give the agent only the primary credential.
- Attempt login again and re-run the validators.
- If the validator passes, the application has an MFA bypass: the second factor is enforced inconsistently or not at all.
This is significant because MFA bypasses are frequently subtle. A developer may correctly enforce MFA on the primary login endpoint but fail to apply it on an OAuth callback, a session restore path, or an API endpoint that issues tokens directly. The agent’s browser-level exploration combined with the validator’s binary pass/fail judgment can surface these inconsistencies without requiring the tester to manually trace every authentication code path.
MFA Bypass Detection by Factor Removal and Validator Re-check
Proof of Concept
-
Establish baseline authenticated state: Configure the AI agent with a browser and provide it with valid credentials including all required authentication factors (e.g., username, password, and TOTP or OTP code). Run the agent through the full login flow. The two-checkpoint validator confirms: (a) the browser state reflects a genuinely logged-in session, and (b) the agent can construct valid API requests under that authenticated context. This establishes that the site requires MFA and that the validators correctly confirm its presence.
-
Remove the MFA factor: Repeat the login attempt with the same username and password, but deliberately withhold the MFA factor — do not supply the TOTP code, OTP, push notification approval, or whatever secondary factor the application requests. The agent is instructed to proceed through the login flow as far as possible without providing the second factor.
-
Re-run the login validators against the resulting session state: After the MFA-stripped login attempt completes (or partially completes), pass the resulting browser state through both validators — the browser-state login confirmation and the API request authentication confirmation. The validators do not know whether MFA was supplied; they only assess whether the session is genuinely authenticated.
-
Interpret the validator result:
- Validators pass (both checkpoints confirm authenticated state): The application granted a fully authenticated session without the MFA factor. This is a confirmed MFA bypass — the backend does not enforce the second factor before issuing a valid session.
- Validators fail: The application correctly blocked the session at some point in the flow. No bypass is present for this factor removal path.
The Broader Attack Class This Surfaces
Beyond simple credential removal, this validator-reuse approach covers a wide range of authentication bypass techniques at the API level:
- JWT forging attacks: Manipulating token claims, changing the algorithm to
none, or exploiting weak signing secrets — any technique that produces a token the server accepts. If the validator confirms authenticated state, the attack worked. - Hardcoded tokens and default credentials: Agents can locate these in source code, configuration files, or API documentation and attempt to use them directly.
- Session expiration failures: Testing whether an expired or invalidated session token still passes the validator.
- Parameter bypasses at the authentication layer: Adding parameters like
admin=1orauthenticated=trueto bypass authentication checks — if the validator passes, the bypass is real.
The validator acts as a ground-truth oracle. The agent does not need to understand the authentication mechanism. It needs only to find any technique that causes both checkpoints to pass. This is the same principle that makes the approach scalable: the hard reasoning is outsourced to deterministic validation, while the creative exploration of bypass paths is delegated to the agentic AI.
Actionable Takeaways
- Instrument your login validator to accept a "credentials manifest" that can be selectively stripped — password field, MFA field, or both — so that bypass testing is a single parameter change rather than a separate test harness. Run the stripped-credential attempt immediately after confirming a successful full-credential login to establish baseline contrast.
- Before testing authentication bypass, confirm the agent has successfully logged in at least once with full credentials so the validator is calibrated to that specific application's authenticated state. A validator that has never seen a genuine authenticated session for the target app will produce unreliable results.
- Extend source code browsing to explicitly search for hardcoded secret keys, default credentials, and token-signing material before attempting JWT forging attacks. The Horizon 3 case study demonstrates that agents can locate these artifacts and use them to forge tokens that satisfy the validator — making this a high-yield, low-effort attack vector.
Common Pitfalls
- Assuming that a 200 OK response or a redirect to a dashboard is sufficient to confirm authentication. The talk explicitly demonstrates cases where a 200 OK is returned for a public endpoint — the validator must test a contrast point in the application where authenticated and unauthenticated responses are meaningfully different.
- Running MFA bypass tests without first confirming the agent can complete the full MFA flow successfully. If the validator never confirmed a genuine MFA-authenticated session, a bypass result may be a false positive caused by validator miscalibration rather than a real application vulnerability.
Auth Transmogrification: Automated Differential Authorization Testing
The Core Problem: Authorization Bugs Are Harder Than Authentication Bugs
AI agents for authentication and authorization vulnerability detection face a fundamental asymmetry. Authentication failures are dramatic — the agent either logs in or it doesn’t. Authorization failures are subtle: the application accepts every request, but returns different data depending on who is asking. That difference is invisible unless you can make the same request under two different privilege contexts simultaneously.
The speakers frame this directly: “Much more common is you have working authentication, but now you’ve messed up something about how people authorize — get authorized to access particular resources.” A complete authentication bypass is rare. A broken access control check is endemic. The methodology shifts accordingly.
What Auth Transmogrification Is
Auth transmogrification is the technique of automatically translating an HTTP request made under one authentication context — say, an admin session — into the equivalent request made correctly under a different context — say, a low-privilege user. The term is deliberately playful, but the technical requirement is precise.
The problem it solves: if you are browsing as a low-privilege user, you may never encounter the admin interface at all. You cannot compare responses you cannot generate. The transmogrification script bridges that gap by constructing the authenticated, correctly signed, correctly cookied request as it would look from any target privilege tier — without requiring the agent to re-explore the entire application.
The script’s interface is deliberately narrow:
- Inputs: A browser state (session, cookies, tokens) and a target URL
- Output: A valid HTTP request as it would be made under that authorization context
The agent writes this script once. After that, it can replay any observed admin request as a low-privilege request in a single function call — no re-authentication, no re-exploration.
Differential Response Analysis: Turning Requests Into Signals
Once the transmogrification script exists, the methodology becomes a triage pipeline. The agent visits every endpoint under multiple privilege tiers and compares responses. The result is a prioritized list of endpoints segmented by behavior:
- Unauthenticated vs. authenticated: Endpoints that return the same response regardless of authentication status — possibly public APIs, possibly a forgotten authorization check
- Authenticated low-privilege vs. authenticated high-privilege: Endpoints where a regular user and an admin see different data — the differential that signals a real authorization boundary worth attacking
The speakers describe this explicitly: “We can get this kind of nice prioritized list where we say great, here are the endpoints that you want to look at that give different responses when you’re authenticated versus unauthenticated, versus authenticated as a low-privileged user or when you’re authenticated as a low-privileged user versus a higher-privileged user.”
Endpoints with identical responses across all tiers are deprioritized — they are either genuinely public or IDORs requiring contextual judgment (see the Limitations section). Endpoints with a differential become attack targets.
The Validator as Answer Key: Eliminating False Positives
The elegance of this approach is that the attack agent does not need to invent a success criterion. The differential already provides one.
When an admin visits an endpoint and receives a user profile, that response becomes the ground-truth answer key. The attack agent — operating only with a low-privilege session and the target URL — is given a single task: “Reproduce what the admin saw.” If it can, the bypass is confirmed. If it cannot, the attempt is rejected.
The validator’s job is correspondingly simple: compare the agent’s submitted response against the stored admin response. A match is a confirmed authorization bypass. No subjective judgment. No false positive from a hallucinating agent.
The speakers articulate why this matters: “As capable as these AI models are, when you give them a task like find a security vulnerability, no matter what, they’re going to end up making things up. So the validator is what makes this reliable.”
This same structure also handles authentication bypasses at the API level — the two privilege contexts become “authenticated” and “completely unauthenticated,” and the same differential logic applies.
Vulnerability Classes Surfaced by This Approach
Because the transmogrification script operates at the HTTP request level, it captures a broad class of broken access control techniques:
- JWT forging attacks — Taking a token, modifying the claim, and re-signing with a known or brute-forced secret
- Broken Object Level Authorization (BOLA) — Direct object references that lack privilege enforcement
- Session expiration failures — Expired or revoked tokens still accepted by the backend
- Hardcoded tokens — Static credentials embedded in source code that can be used directly in the transmogrified request
- Parameter-based authorization bypasses — The most practically important class: adding a URL parameter like
admin=1oradmin_projects=1that the backend uses as an authorization signal but does not validate against the session
The Redmine[4] case study (covered immediately below) is the canonical illustration of the last class.
Redmine admin_projects=1 Parameter Bypass: Privilege Escalation via Authorization Check Omission
Proof of Concept
-
Establish baseline differential via auth transmogrification: The agent is given a pre-written Python transmogrification script (inputs: browser state + URL; output: correctly authenticated HTTP request under the target privilege context). It uses this script to request the
/projectsendpoint under both a low-privilege user context and a high-privilege admin context. Result: low-privilege user sees one public project; admin user sees one public project plus one private project. This differential confirms the endpoint is a viable authorization bypass target. -
Generate a prioritized attack target: The differential response (low-privilege: 1 project, admin: 2 projects) is surfaced in the agent’s prioritized endpoint list. The validator records the full admin response — both project names — as the ground-truth answer key. The attack agent’s task is now concrete and verifiable: reproduce the admin’s two-project response while operating only under the low-privilege session context.
-
Source code inspection for authorization logic: Rather than blindly fuzzing parameters, the agent begins reading Redmine’s open-source codebase. It searches for the logic governing project visibility — specifically, the code paths that filter projects based on the requesting user’s privilege tier. This phase takes approximately five agent iterations.
-
Parameter discovery —
admin_projects=1: Within the fifth iteration, the agent identifies that the Redmine codebase contains a conditional check on anadmin_projectsquery parameter. Whenadmin_projects=1is present in the request, the visibility filter that restricts private projects to admin users is bypassed entirely. The authorization check is not enforced when this parameter is set; the application trusts the client-supplied value without verifying that the requesting user actually holds admin privileges. -
Exploit construction and confirmation: The agent appends
?admin_projects=1to the low-privilege context request for the/projectsendpoint, using the transmogrification script to ensure the request is otherwise authenticated correctly as the low-privilege user. The response now returns both the public project and the previously hidden private project — matching the admin’s ground-truth response. -
Validator confirmation: The agent submits the result to the validator. The validator compares the agent’s obtained response (both projects visible) against the stored admin answer key (both projects visible). The responses match. The validator confirms: the low-privilege agent has successfully reproduced the admin’s view of private project data without possessing admin credentials or an admin session.
-
Root cause: The vulnerability is an authorization check omission — a parameter-driven privilege escalation where the application code offers a backdoor path (
admin_projects=1) that skips the visibility filter. No cryptographic attack, token forgery, or session hijacking is required. The entire exploit is a single appended query parameter. The bug class aligns with broken object level authorization / authorization bypass via parameter injection.
The Reusability Advantage
A key operational benefit of generating the transmogrification script as a standalone artifact is that the agent does not re-engineer the auth mechanism on every request. Complex applications — OAuth 2.0 flows with PKCE, JWT-signed API calls, OIDC refresh chains — require significant reasoning to authenticate correctly. Doing that reasoning once and encoding it in a Python script means subsequent requests are fast, deterministic, and testable.
The speakers note: “Once you produce this script, it’s a really powerful tool for the agent to use. It doesn’t have to reverse engineer the authentication and authorization mechanisms every time — you just give it a Python script and it can use it.”
This also means the script can be audited, version-controlled, and reused across multiple attack agents working on the same target in parallel.
From Manual CTF Flags to Automated Triage
The previous iteration of this approach required manually setting up a Redmine instance, planting CTF-style flags, and using those flags as verification anchors. That is viable for a single target. It does not scale to thousands of bug bounty targets or the open-source ecosystem.
The transmogrification + differential + validator pipeline replaces the manual setup entirely. The admin session’s observed responses are the flags. The agent generates the transmogrification script automatically. The validator comparison is deterministic. The result is a methodology that can be applied to any web application with a multi-tier user model without any per-target configuration.
Actionable Takeaways
- Generate the auth transmogrification script once per target and treat it as a reusable artifact: instrument it with the admin browser state, verify it against recorded browser requests as a test suite, then hand it to every attack agent rather than forcing each agent to re-reverse-engineer the authentication mechanism.
- Build your differential triage list before launching attack agents: compare endpoint responses across unauthenticated, low-privilege, and high-privilege contexts first, then direct agents only at endpoints showing a real differential — this concentrates effort on confirmed authorization boundaries and eliminates noise.
- Use the admin session's response as the validator's answer key: give the attack agent only the URL and its low-privilege context, then confirm success by comparing the agent's submitted response against the stored admin response — this eliminates false positives caused by agent hallucination without requiring any manual ground-truth setup.
Common Pitfalls
- Treating same-response endpoints as confirmed public APIs: an endpoint returning identical data to both an admin and a low-privilege user may be a missed authorization check (an IDOR) rather than a genuinely public resource — the differential approach intentionally excludes these from automated attack, but engineers should not dismiss them entirely; they require separate contextual review.
- Deploying the transmogrification script without validation: if the script incorrectly constructs the authenticated request — missing a required header, using a stale token, or mishandling a multi-step auth flow — the differential will produce false negatives, silently missing real authorization bugs. Always validate the script against a recorded test suite of known-authenticated browser requests before using it offensively.
Limitations and Scope Boundaries of Agent-Driven Authorization Testing
What This Methodology Is Explicitly Not Designed to Catch
The differential response approach that powers AI agents for authentication and authorization vulnerability detection is precise by design — and that precision comes with intentional scope boundaries. Understanding what falls outside the detection envelope is as important as understanding what sits inside it.
Classical IDORs are out of scope. An Insecure Direct Object Reference (IDOR) occurs when a user accesses a resource they should not by directly referencing its identifier — for example, navigating to /cart/5 when authenticated as a different user than the cart’s owner. The core problem with applying differential analysis to IDORs is that they do not produce a reliable cross-privilege differential. Both a low-privilege user and a high-privilege user might receive the same 200 OK response from /cart/7. Whether that constitutes a vulnerability depends entirely on application-specific judgment: is that cart endpoint intentionally public? Is the resource something a phone book would expose? That judgment call cannot be automated with a binary validator. As the speakers explicitly stated, the methodology focuses on technical authorization bypasses — cases where the application is clearly attempting an access control check, getting a different result per privilege tier, and simply failing to enforce it correctly.
The Transmogrification Script as a Critical Failure Mode
The entire authorization-testing pipeline is only as reliable as the auth transmogrification script the agent produces. This is the single most important quality gate in the system. If the script makes mistakes in how it translates an admin-context request into a low-privilege-context request — incorrect header substitution, missed cookie scoping, wrong token injection — the differential analysis produces garbage. False negatives occur when the script fails to correctly authenticate the low-privilege context, making an exploitable endpoint look like it correctly rejects unauthorized requests. False positives are equally possible if the script inadvertently sends a malformed request that triggers a server-side error unrelated to authorization logic.
The speakers acknowledged this dependency directly: “we really have to be very careful to make sure that it doesn’t make very many mistakes when writing that script.”
Validating the Script Before Offensive Use
The methodology includes a self-validating feedback loop that reduces the risk of transmogrification errors. Because the agent browses the target application using a real browser, the JavaScript executing on the page makes authenticated requests that can be recorded. Those recorded request-response pairs — gathered passively during reconnaissance — form a test suite for the transmogrification script.
The validation flow works as follows:
- Step 1: Allow the agent to explore the site via browser, recording all HTTP requests made by the JavaScript runtime along with their authenticated responses.
- Step 2: Run those same requests through the transmogrification script with the correct privilege context.
- Step 3: Compare the script’s output against the recorded ground truth. Discrepancies indicate script errors that must be corrected before offensive use begins.
This gives the team “tons and tons of built-in test cases” without any manual instrumentation. The test suite grows organically as the agent explores more of the application surface, and script confidence increases proportionally with coverage.
Practical Scope Summary for Security Engineers
| Scenario | In Scope | Notes |
|---|---|---|
| Authentication bypass (no password) | Yes | Validator confirms login state |
| MFA bypass (factor removal) | Yes | Validator confirms login state |
| JWT forging / hardcoded secrets | Yes | Agent finds and exploits token flaws |
| Parameter-based authorization bypass | Yes | Differential response confirms bypass |
| Broken Object Level Authorization (BOLA) | Yes | Differential across privilege tiers |
| Classical IDOR (same response across users) | No | Requires application-specific judgment |
| Authorization bugs requiring business logic inference | No | Out of automated scope |
The methodology is deliberately narrow and verifiable. That narrowness is what makes it deployable at scale against thousands of bug bounty targets or open-source applications without producing an unmanageable false-positive backlog.
Actionable Takeaways
- Before running the auth transmogrification script offensively, build a validation test suite by recording browser-driven requests during passive reconnaissance and diffing them against the script's output — any mismatch is a script defect, not a vulnerability signal.
- Exclude classical IDORs from automated differential analysis pipelines; reserve them for manual review where an engineer can apply application-specific judgment about whether a resource is intentionally public.
- Treat the transmogrification script as a first-class test artifact: version it, validate it per target, and re-validate after any application update that changes authentication or session mechanics.
Common Pitfalls
- Trusting the transmogrification script without validation: if the script incorrectly substitutes auth material for the low-privilege context, the differential analysis is unreliable — endpoints that are genuinely vulnerable may appear safe, and vice versa.
- Treating a same-response result (no differential) as automatically safe: a public endpoint and a completely unprotected private endpoint can look identical to the differential checker. Same response means "not a technical auth bypass target," not "no vulnerability exists."
Conclusion
Brendan Dolan-Gavitt and Vincent Olesen’s methodology at [un]prompted 2026 offers security engineers something practical and rare: a scalable, verifiable approach to a class of vulnerability that has historically resisted automation entirely. The three-layer structure — reliable login validators, offensive validator reuse for authentication and MFA bypass detection, and auth transmogrification for differential authorization testing — is both technically grounded and operationally deployable without per-target manual setup.
The key principle running through the entire methodology is the strict separation between probabilistic reasoning (the agent’s creative exploration of bypass paths) and deterministic verification (the validator’s binary pass/fail judgment). That separation is what makes the approach trustworthy at scale. Without verification, AI agents produce false positives. Without agents, classical scanners miss the contextual, logic-based bugs this methodology is specifically designed to surface.
For engineers building offensive security pipelines, the immediate takeaway is concrete: invest first in your login validators. Everything else in this methodology — authentication bypass detection, MFA bypass detection, authorization differential analysis — is built on top of that foundation. Get the validators right, and the rest of the pipeline follows.
For further reading on related topics covered on this site:
- AI agent security — broader coverage of how agentic systems introduce and expose security risks
- Broken access control — the OWASP Top 10 category that encompasses the authorization bypass classes this methodology targets
- Offensive security — talks and deep dives on automated and AI-assisted attack techniques
References & Tools
- Expo — Mobile and web application development platform; the internal AI agent and validator tooling described in this talk was developed at Expo. ↩
- JSON Web Token (JWT) — RFC 7519 — IETF specification defining the JWT format, claim structure, and signing requirements. ↩
- Horizon 3 AI — Security research firm whose public vulnerability research on hardcoded JWT signing secrets was cited as a real-world example of the authentication bypass class this methodology surfaces. ↩
- Redmine — Open-source project management and issue tracking application used as the authorization testing target in the talk's live demonstration; the
admin_projects=1parameter bypass was discovered within five agent iterations. ↩
Questions from the audience
Related deep dives
Breaking AI Agents: Exploiting Managed Prompt Templates to Take Over Amazon Bedrock Agents
When Passports Execute: Exploiting AI Driven KYC Pipelines | [un]prompted 2026
Code Is Free: Securing Software | [un]prompted 2026
