Application
hardening.
The layer your users actually touch: who can sign in, what they can reach once they are in, and what the product hands out to anyone who asks. AI-assisted code ships this layer fastest — and skips it most often.
A working product proves the happy path. It does not prove that the second account cannot read the first one's data, that a revoked invite really dies, or that an admin route is checked on the server rather than hidden in the UI. Those are the seams this covers.
Permission first. Always.
This is a defensive review, not a hunt. The boundaries are set before anything begins, in writing, and they are the same for every client.
No account enumeration, no destructive inputs, no automated vulnerability tooling against your systems without an agreed scope. If that limits what a first pass can see, that is the correct trade.
Four places it usually gives.
Authentication and session edges
Sign-up, sign-in, reset, invite, and logout — plus everything around them. Whether reset tokens expire and can only be spent once, whether sessions actually end on logout and on password change, whether email verification gates anything or is decorative, and whether the edges of an OAuth or magic-link flow land where they should.
DeliverableEach flow walked end to end, with the failure case written down next to the fix.
Roles and permissions
The most expensive class of bug in AI-built SaaS, because it looks fine from the inside. Whether authorisation is enforced on the server or only hidden in the interface, whether one tenant's identifier can be swapped for another's, whether "admin" is a real boundary or a flag, and whether the API agrees with the UI about who may do what.
DeliverableA permission matrix of roles against resources, with every square that is not actually enforced marked.
Exposed data paths
What leaves the building without anyone deciding it should. Over-broad API responses that return whole records where a name was needed, object storage left readable, keys shipped to the browser, verbose errors and stack traces in production, seed and test data still live, and search or export endpoints that ignore the tenant boundary.
DeliverableAn inventory of what the product currently discloses, ranked by how much it matters.
Integration and AI agent surface
The parts that talk to other systems. Unverified webhooks, third-party keys with far more scope than the feature needs, background jobs running as a superuser — and, where the product runs LLM features, what an agent is permitted to do, what reaches its context, and what happens when a user writes instructions into a field the model later reads.
DeliverableA map of every outbound trust relationship and the blast radius if one is abused.
Engineering judgment, AI-assisted.
The method is not a scanner pointed at your domain. It is an engineer reading the system, with AI-assisted inspection used to cover ground faster across the surfaces you have approved.
- 01
Read the system, not just the symptoms
A scanner reports what a pattern matches. The question worth answering is why the seam exists — because the same shortcut has usually been taken in four other places, and fixing one instance leaves the other three.
- 02
AI-assisted review, against approved surfaces
With your permission, OOPUO runs AI-assisted review against the surfaces in scope. It is a mechanism for covering more ground, checked by hand before anything reaches your report. Nothing is claimed that has not been verified.
- 03
Ranked by exposure, not by severity label
A theoretical critical nobody can reach matters less than a permission gap any signed-up user can walk through today. Findings are ordered by what is actually reachable, so the first thing on the list is the first thing worth an afternoon.
- 04
Written so your team can act without me
Every finding states where it is, how it fails, and what to change. No vendor lock-in, no dependency on OOPUO to interpret the report, no platform to license.
How an engagement runs.
The review is the entry point. It is also how the sprint gets scoped and priced — nobody quotes a fix before knowing what is broken.
Scope
A short call, then written authorisation naming the surfaces in scope, the disclosure path, and what is explicitly off limits.
Review
The application surface is examined against the four areas above. Non-invasive by default; anything deeper happens only inside the agreed scope.
Report
A prioritised written report: what was found, how it fails, what to change, and what can wait. Yours to keep and act on, with or without OOPUO.
Harden
If you want the fixes implemented, the report becomes the sprint backlog — scoped from real findings rather than a guess.
Start with the review.
Send the product and what worries you about it. If application hardening is not the right first move, that is worth saying too — infrastructure hardening and private AI cover the other two layers. Once it is hardened, continuous operations is what keeps it that way.