Another tenant's invoice is readable by a logged-in user
CRITICALreproduced
Closed beta · seats open
An autonomous security researcher for your app.
inea goes through your application the way a researcher would, and reports only what it has actually reproduced. No noise. No maybes. Every finding comes with the proof.
No request leaves the sandbox without your signed scope.
A password reset token stays valid after it has been used
HIGHreproduced
An export endpoint accepts a URL and follows it
MEDIUMreproduced
Illustrative report — not a customer finding.
The gap
Everyone reports. Nobody proves.
Three ways to check whether your app is safe. Each of them hands you a list, then leaves you to work out which lines are real.
A human pentest
once every 12–18 months
Right once,
then quietly wrong.
then quietly wrong.
Accurate the week it lands. Stale the month after, because your code moved and the report didn't.
A static scanner
not one alert carries a proof
It walks an abstract syntax tree. It reads what the code says, never what the app does. Your team learns to close the tickets without reading them.
A dynamic scanner
hours per scan · an operator required
It fuzzes blind. It finds the generic reflected XSS and misses the authorization logic that actually loses you customer records.
An authorization flaw has two faces. In the code, an ownership check is missing.
In the browser,
GET /api/invoices/8241 returns someone else's invoice.
Only the second one settles the argument. inea works on that side, and it does not
report the flaw until it has produced that response.
Which half is your stack missing? Tell us what your last audit found — and what it didn't.
Request beta access What it needs
Two accounts open more than your source code.
inea never asks for your repository. It works against the running app — and what changes its reach is not code, it's whether it can hold two sessions at once.
Black box
you hand over · a URL and a signed scope
Exactly where an anonymous attacker starts, and nowhere else. It covers what is reachable without an account — and it stops where your login starts.
Grey box recommended
you hand over · two test accounts, an API spec, a staging environment
Two accounts in two separate tenants are the single input that changes the most. They open the authorization flaws that are simply invisible from one session — the ones that lose customer records.
Coverage at beta
Eleven classes, each with a reproducer.
Every class ships with the scenario that demonstrates it, so your engineer can replay the exploit before deciding it matters.
Broken authentication
A token accepted without verification, a session that never expires, a cookie missing its flags.
proven by · replaying a forged session against a protected route
JSON Web Token flaws
A signature the server never verifies, or one signed with a secret worth guessing.
proven by · forging a token the server accepts as its own
Broken object authorization
An endpoint that checks who you are and forgets to check what is yours.
proven by · two accounts, one record, a response that should not arrive
Server-side request forgery
An endpoint that fetches a URL you supply, with no allowlist between it and your internal network.
proven by · pointing it inward and measuring what comes back
SQL injection
Input that reaches the query, and changes what the query decides.
proven by · a pair of requests whose only difference flips the boolean
Command injection
Input that reaches a shell, and runs there.
proven by · a delay the server has no other reason to take
Server-side template injection
Input rendered as template source instead of as data.
proven by · an expression the server evaluates and hands back
Local file inclusion
A path you control, resolved against the server's own filesystem.
proven by · reading a file the endpoint was never meant to serve
Open redirect
A destination you supply, followed without being checked.
proven by · landing on a host that was never in scope
CORS misconfiguration
An origin policy wide enough to let another site read your responses.
proven by · a cross-origin read that returns authenticated data
Reflected cross-site scripting
A field a user controls, returned into the page without escaping.
proven by · injecting, reloading, and observing the payload execute
Need a class that isn't listed? Beta shapes the order we build them in.
Tell us what to add Non-negotiable
Three lines we don't cross.
A tool that runs inside your product earns its place on what it refuses to do, not only on what it finds.
What you hand over never leaves the sandbox
Credentials, captured traffic, every request and response. Encrypted at rest, never written to a log, purged when the scan ends.
Nothing runs without consent
You prove you own the target before a single request goes out. Anything outside the scope you signed is refused, not merely skipped.
Disclosure over marketing
A zero-day we find in one of your dependencies goes through responsible disclosure. It never becomes a sales argument.
Where it sits
Not another scanner.
inea isn't trying to replace your static scanner's breadth or a good pentester's creativity. It closes the gap neither of them covers.
| inea | Static scanner | Dynamic scanner | Human pentest | |
|---|---|---|---|---|
| Needs no access to your code | ✓ | — | ✓ | ✓ |
| Runs your app | ✓ | — | ✓ | ✓ |
| Ships the exploit that proves it | ✓ | — | — | ✓ |
| Finds authorization and logic flaws | ✓ | — | — | ✓ |
| Runs again on every change | ✓ | ✓ | ✓ | — |
Already paying for two of these columns? See what the third finds that they don't.
Request beta access
Closed beta
The competitor isn't a scanner. It's “we'll do security after the raise.”
inea is in closed beta with a small group of CTOs and security leads at SaaS and fintech companies. If that's you, we'd like to hear what your last audit missed.