Intelligence
Join the waitlist
AEW-016

Authentication failure converted into an accepted authority state

A gateway's own credential check fails, and a fallback path on the same code reads that failure as a result rather than a rejection, producing an accepted, if empty, identity able to reach connected capability the failed check was supposed to gate.

Status: candidateAgent IdentityExecution Authority

Description

This weakness sits at the moment a caller's credential validation fails at an identity translation boundary, the point a gateway or proxy decides what principal a request continues as toward the systems behind it. A rejection is the correct outcome of that failure. This weakness appears when a fallback path built for a separate, correctly configured case instead fires on the failure itself, substituting a constructed, minimal or empty identity object for the rejection and letting the request continue as though authentication had produced a result. It is distinct from an agent accepting a claim of authority nothing ever checks (AEW-007): here a check runs, and runs correctly, and the failure is discarded afterward by different code on the same path. It is distinct from reachability substituting for authorization in the absence of any check (AEW-008): here reach is gated by a check that exists and fires, and the gap opens in what happens immediately after it fires negatively. It is distinct from an actor controlling whether its own control applies (AEW-004): the caller here does not set a switch: the gateway's own fallback design does the converting, without needing the caller to configure or influence anything beyond presenting a credential that fails. The corrective, evidenced so far by exactly one vendor's own fix, is narrow and mechanical: scope a fallback to the precise configuration it exists to serve, checked before it fires, and let every other failure terminate the request the way an identical failure on any other path already does.

The authority gap

The authority required to reach the downstream capability is a validly established identity. The authority presented is an identity the gateway itself constructed after its own check of the caller's credential failed, and nothing distinguishes the two once the request continues.

Failure conditions

  • A credential validation failure at a gateway or proxy identity boundary is caught by a fallback path rather than propagated as a rejection.
  • The fallback constructs an accepted identity object, empty or minimal, without first confirming the request matches the specific configuration the fallback exists to serve.
  • The request continues past the boundary carrying that constructed identity as though it were a validated one.

Consequences shown by the evidence

  • A caller presenting a credential that fails a gateway's own validation reaching configured tooling anyway, through an identity the gateway manufactured rather than validated.
  • A narrow, correctly scoped fallback mode firing for requests outside the configuration it was built for, because the fallback's own trigger was the failure itself rather than the configuration.

Detection signals

  • A gateway's exception handling path for a failed authentication check constructs a default or empty identity object rather than re-raising the failure.
  • A fallback authentication mode's own precondition, such as a specific upstream configuration, is not checked before the fallback fires.
  • The fix for an incident adds a check gating an existing fallback to its intended configuration, rather than removing the fallback or adding a new rejection path.

Known examples

  • LiteLLM's MCP authentication handler supported an OAuth2 passthrough fallback for upstream MCP servers explicitly configured for it. When LiteLLM's own key validation failed, the vulnerable handler replaced that failure with an empty UserAPIKeyAuth object regardless of whether the request's actual target was configured for OAuth2 at all, letting a request carrying a fabricated Bearer token reach configured MCP tooling. CISA added the vulnerability, CVE-2026-59822, to its Known Exploited Vulnerabilities catalog on 2 September 2026.
  • LangChain's managed-deepagents runtime, fixed in v0.7.1 (2026-09-10, changelog entry "Studio callers resolve to an authenticated principal"): the Agent Server's own injected langgraph_api.auth.studio_user.StudioUser object read like a mapping but was not a registered collections.abc.Mapping, so an isinstance gate in the runtime's Studio-detection code dropped it, build_runtime_identity returned None, and everything downstream that reads it, server_info.principal, server_info.user, source.provider: "studio", actor-scoped memory and store namespacing, behaved as though the run were anonymous rather than surfacing the failed detection as an error. This session independently cloned langchain-ai/managed-deepagents and confirmed the changelog text directly; the repository carries no runtime source, so the internal mechanism rests on the vendor's own changelog narrative rather than an independent source-level read, unlike this weakness's own LiteLLM example. The trigger differs from LiteLLM's own genuinely invalid credential: here the caller's session was genuinely authenticated and a narrow, incorrect structural check misclassified a real signal as absent, not a credential-validity failure. What still instantiates this weakness is the same second half of the mechanism this weakness's own authorityGap already states generally: a failed identity-establishing check's negative result is read downstream as an accepted, anonymous identity able to keep executing, rather than as a rejection. No CVE, advisory or reported exploitation accompanies this changelog entry, and whether the anonymous fallback let two distinct Studio users' actor-scoped memory or store entries actually collide is not stated by the source and stays UNKNOWN.

Recorded instances