The API That Returned Every Customer’s Private AI Assistant
An authorization flaw in an AI product API that exposed every customer’s private assistant data.
Read the writeup →
Founder and Principal Security Researcher, The Hidden Finds
The Hidden Finds was created after seeing a recurring problem across modern SaaS platforms and APIs:
Organizations often receive security reports filled with scanner output, while the vulnerabilities that actually matter remain undiscovered.
The focus became simple: identify real attack paths, validate exploitability, and provide findings that engineers can act on.
The Hidden Finds LLC is registered in Wyoming, USA, and works with clients remotely, worldwide. It is a solo practice: the person who scopes an engagement is the person who tests it and writes the report, so nothing learned while scoping is lost by the time the findings are written up.
Published write-ups from active bug bounty and responsible disclosure work. The same techniques are applied to every client engagement.
An authorization flaw in an AI product API that exposed every customer’s private assistant data.
Read the writeup →A profile-edit flow with no ownership check, letting one tenant reach another tenant’s data.
Read the writeup →An overly permissive resolver leaking registered accounts, internal identifiers, and user metadata.
Read the writeup →Two lower-severity API flaws chained together into a confirmed $2,000 bounty payout.
Read the writeup →Direct senior involvement and practical product understanding without layers of generic delivery.
Scope, testing decisions, validation, and reporting remain connected to senior review.
Automation supports coverage, while important behavior and exploitability are validated manually.
Findings are interpreted through roles, tenant models, sensitive data, and business workflows.
Reports prioritize reproduction, impact, remediation clarity, and efficient retesting.
Good security work should make product risk clearer, not bury teams beneath more output.
Findings should represent realistic attack paths rather than theoretical weaknesses.
Security testing must understand how systems behave in practice.
Reports should help engineering teams make decisions, not create confusion.
Every finding should include actionable guidance and retesting support.
All testing is manual. Scanners are used for coverage, not for findings. A scanner can flag an outdated library, but it cannot tell that a viewer role should not be able to export, or that a refund can be requested twice. That takes knowing who each user is and what the product is meant to allow.
SaaS and API teams whose product keeps customer data behind roles and tenants: a platform where one customer must never see another's records, an API that partners call directly, or a product adding AI features that can read data or call tools.
Testing starts by learning the product the way its users do: what each role is for, which data belongs to whom, and which actions involve money or trust. It then follows the paths where a mistake would matter most. Alongside the areas listed further down, that includes race conditions and AI and LLM application security.
An active bug bounty and responsible disclosure practice runs alongside client work. Ongoing retainers are available on request.
Nothing goes in a report until I have reproduced it by hand.
Ratings reflect what an attacker could actually reach.
Anything marked off limits during scoping stays untouched.
A test reports what it finds. It cannot prove that nothing else exists.
A steady focus on practical application security, direct delivery, and findings that improve real products.
Founded with a focus on practical application security testing.
Expanded across SaaS applications, APIs, authentication, and access control reviews.
Strengthened focus on IDOR, broken access control, business logic abuse, and API security.
Built deeper review workflows for SaaS and product teams.
Expanded structured services, positioning, and security consulting delivery.
Founder-led reviews focused on exploitability, product risk, and engineering-ready remediation.
Focused expertise for security-sensitive product behavior across modern SaaS and API systems.
REST and GraphQL authorization, object access, token scope, and data exposure.
Role boundaries, ownership checks, tenant isolation, and privilege escalation.
Login flows, sessions, recovery, token handling, and account takeover paths.
Valid product actions that can be chained or manipulated into unintended outcomes.
Manual testing across critical features, sensitive data paths, and user flows.
Validated weaknesses, exposed assets, prioritization, and remediation direction.
I am not hiring at the moment, but if you test applications seriously and want to be on my radar, the career page lists the areas I pay attention to.
Practical guidance grounded in real attack paths, business impact and remediation support.