Wrapper patterns are the boilerplate that wraps your real logic: auth wrappers, middleware guards, SSO config, and route protection. AI coding agents drop them because they compile and look like safe, skippable boilerplate, so they only fail at runtime. Scanners and static analysis cannot flag a missing wrapper because there is no syntax error to find. The absence itself is invisible to every tool that does not run the app.
There is a category of vibe coding bug that does not look like a bug until a user hits it. No red squiggle. No failing lint rule. No compiler complaint. The code is syntactically valid and logically coherent. It just does not protect anything.
The incident that made this concrete for our team: an AI agent rewrote a set of route handlers, kept all the business logic intact, and quietly dropped the auth wrapper around a sensitive settings endpoint. The app compiled. CI passed. The route was open to unauthenticated requests in production for hours before anyone noticed. The full story of what went wrong and how is in the post What Happens When an AI Agent Breaks Authentication in Production. What that post does not cover is the structural reason it keeps happening: why AI agents drop these wrappers in the first place, and why every static tool you have is blind to it.
That is what this post names.
What is a wrapper pattern?
A wrapper pattern is code whose sole job is to stand between a request and your real logic. It does not compute anything useful on its own. It enforces a condition, injects context, or gates access, then either calls through to the underlying handler or short-circuits with a redirect or error.
Auth wrappers, middleware guards, SSO config, and route protection are all wrapper patterns. They exist as a layer, not as a feature. And because they are a layer, they are also what AI coding agents tend to collapse or omit when rewriting or extending a module. The underlying logic (the handler, the query, the mutation) is what the agent focuses on. The wrapper is the boilerplate around it. To a model optimizing for "make this do the thing it is supposed to do," the wrapper looks optional.
It is not optional. Removing it does not break compilation. It breaks your security posture at runtime.
When the agent drops the auth wrapper, the handler still compiles, but the request now reaches it with no session check and the route becomes an open door.
The four wrapper patterns AI agents skip
These are the four categories that come up most often in AI-assisted codebases. They share one trait: each one compiles cleanly when absent, and each one causes a silent security regression that static analysis cannot detect.
| Pattern | What it does | What breaks when it is dropped |
|---|---|---|
| Auth wrapper | Checks a valid session or token before the handler runs | Unauthenticated users can reach protected endpoints |
| Middleware guard | Intercepts every request to a route group and enforces policy | Policy bypassed; direct URL access skips all enforcement |
| SSO config | Registers the identity provider callback and token exchange | SSO login silently breaks; users cannot authenticate |
| Route protection | Redirects unauthenticated requests to the login flow | Private pages load for anonymous users without a redirect |
Each failure mode is a runtime failure. The app builds. The feature works locally with a seeded session. The gap only surfaces when someone hits the route without a valid credential in a real environment.
Why scanners and code review miss them
This is the part that trips teams up. The instinct after a missed auth regression is to add more review: more eyes, a stricter PR checklist, a linter rule. None of those fix the structural problem.
A linter can flag a call to a deprecated API. It cannot flag the absence of a call that should have been there. There is no syntax for "missing auth wrapper." The route handler is valid code. The middleware file is valid code. The wrapper just is not connected to the route anymore.
SAST tools and type-checkers have the same blind spot. They reason about what is present. A missing wrapper leaves no artifact to reason about. Type safety does not care whether your GET /settings handler is guarded. It cares that the handler returns the right shape.
Code review, human or AI, runs into the same wall. A reviewer reading the handler sees the correct business logic and approves it. The wrapper was removed three commits ago in a different file. The connection is gone but nothing in the current diff shows that. We covered the full scope of this blind spot in Why Vibe Coding Scanners Miss the Bugs That Matter and in How to Test a Vibe-Coded App, which goes further into the verification gap that static tools leave behind.
The core point: every static tool you have reasons about what the code says. None of them reason about what the app does when you actually run it and hit an endpoint without a session.
Linting, type-checking, SAST, and code review all pass because a missing wrapper leaves nothing to flag. Only running the app against the route surfaces the gap.
How Autonoma catches what scanners miss
The wrapper drop is exactly the failure mode Autonoma is positioned to surface. Autonoma's Executor agent drives the real running app in a live preview environment, exercising routes the way a user would, including unauthenticated requests, mid-session navigation, and SSO callback sequences. When an auth wrapper is missing, the Executor does not get redirected. It gets in. The Reviewer agent classifies that outcome as a real bug, not an agent error. The Diffs Agent then flags the wrapper omission on the PR where it was introduced, before it reaches production.
This is the runtime layer that static analysis cannot replicate. The code review step sees clean diffs. Autonoma sees an open door.
How to catch them: run the app
The reason wrapper regressions survive to production is not that teams are careless. It is that the standard verification stack: linting, type-checking, unit tests, AI code review, stops before it runs the app as a user.
Running the app as an unauthenticated user is the only way to know whether route protection is in place. Not reading the middleware file. Not checking whether the wrapper function is defined. Actually sending a request to the protected route without a session and asserting that you get redirected, not that you get the protected content.
The same applies to SSO. The SSO config wrapper is wired correctly if and only if the callback URL resolves, the token exchange completes, and a session is established. You cannot verify that by reading the configuration. You verify it by running the login flow in a real environment against a real identity provider or a realistic stub.
For the concrete test structure, including how to assert redirect behavior, how to drive guard logic, and how to test authenticated vs. unauthenticated sessions end-to-end, the practical how-to detail on testing auth middleware and protected routes is covered in a companion piece in this series. The approach in that post maps directly to the failure modes in the table above.
Wrapper verification is not a documentation exercise. It is a runtime exercise. And runtime verification is the only check that tells you whether the wrapper is actually there. Autonoma's role is to run that runtime check on PRs, so missing wrappers are caught before users touch the route.
FAQ
Wrapper patterns are the code layer that stands between an incoming request and your real application logic. They enforce conditions like authentication, authorization, and session validity before passing control to a handler. Common examples are auth wrappers, middleware guards, SSO config callbacks, and route protection redirects. They do not compute business logic themselves. They gate access to the code that does.
AI coding agents optimize for the logic that makes a feature work. Wrapper patterns look like boilerplate: repetitive, not feature-specific, and disconnected from the handler's core behavior. When an agent rewrites or extends a module, it focuses on the handler. The wrapper is the surrounding layer. If the agent does not have a strong signal that the wrapper is load-bearing security infrastructure, it treats it as safely removable. The handler still compiles and runs correctly after the wrapper is gone. The agent has no feedback signal that anything was lost.
By running the app. Send an unauthenticated request to a protected route and assert that you receive a redirect to login, not the protected content. Static analysis, linting, and code review cannot surface a missing middleware guard because there is no syntax error to flag. The only tool that can catch the omission is one that drives the real app and checks the actual response. Runtime verification is the check, not a static one.
Linters flag what is present and wrong: deprecated calls, bad patterns, unused variables. A missing auth wrapper is an absence, not a presence. There is no syntax for 'this route should be wrapped in auth but is not.' The route handler is valid code in isolation. The linter has no model of which routes require which wrappers. That relationship lives in your application's architecture, not in any individual file. Only a tool that understands the full request path, from the entry point to the handler, can detect the gap.
The four most common omissions are: auth wrappers (session or token checks before a handler), middleware guards (policy enforcement on route groups), SSO config (identity provider callback wiring and token exchange), and route protection (redirects for unauthenticated users). These are all wrapper patterns. They share one trait: each one compiles cleanly when absent and only fails at runtime. They are the category of bug that static analysis is structurally blind to.
