Penetration testing, rebuilt around proof.
Human-led, AI-assisted penetration testing.
GreySurface tests your apps, APIs and cloud the way attackers do, proves every finding and gives engineers the fix.
What every test delivers
Drawings are samples, not client data.
Sample report pages for Acme Corp: the cover, the executive summary, overall risk Critical, and a finding with its proof. A report people read
Plain language first, with the full detail behind it.
Sample: a timeline from the report to day 30, the retest inside it One retest of our findings
Within 30 days of the report.
src/api/invoices.ts // GET /api/invoices/:idconst id = req.params.id;Removed line: return find(id);Added line: return findOwned(id, req.user);
Fixes engineers can ship
The root cause and the change to make.
Agenda - What we tested
- What an attacker could reach
- What to fix first
An executive briefing
The business risk, for leadership.
Built for teams that ship
Each kind of product fails in its own places.
SaaS products
Tenant isolation, roles and the admin routes customers never see.
Fintech and payments
Payment flows, limits and the approvals nobody should skip.
Health tech
Who can open a patient record, and what an export leaks.
E-commerce and marketplaces
Checkout, refunds, coupons and what sellers see of each other.
AI products
Prompt injection, and the data and tools a model can reach.
What you can hold us to
Six commitments you can check on your first test.
A person leads every test
Testers who have defended systems and attacked them choose each step.
AI does the groundwork
AI speeds up recon, triage and reporting. A tester makes every call.
Every finding proved with evidence
Each one carries the request and response your team can replay.
Business risk, stated plainly
What each finding puts at risk, in your board's terms.
Checked by a person
Nothing reaches your report before a person reviews it.
Reply within one business day
Send what you run, even before the scope is settled.
Where automated scanning stops
Scanners find known issues. A tester works the logic they cannot judge.
| Compared on | An automated scan | A GreySurface test |
|---|---|---|
| What it looks for | Known flaws: outdated software and misconfigurations | Access control, business logic and chained flaws |
| What comes back | Possible issues to verify | Proof of exploit for each finding, and a fix |
| Best at | Breadth and frequency, between tests | Depth: what an attacker could reach today |
One finding, from first map to verified fix
Five steps on one sample finding at Acme Corp.
Recon
We map the surface in scope, with AI sorting the leads. A tester decides which are worth the time.
Recon notesSample: Acme Corp - app.acme-corp.comCustomer web app, email sign-in
- /api/invoices/{id}PickedNumeric ids, one per invoice
- /api/exportsLeadBuilds a CSV of account data
- /api/users/meProfile updates, JSON body
- portal.acme-corp.comOut of scopeStaff portal, single sign-on
AI sorted the surface. A tester chose which leads to work.
Exploit
A tester works each lead by hand until one holds up. Dead ends never reach your report.
Tester's noteSample: Acme Corp Signed in as customer B- Invoice10481Customer B, their own
- Invoice10482Customer A, another customer
Same session, the next number. Nothing checks who owns the invoice.
Proved: customer B can read customer A's invoice.
Prove
We follow the exploit to the data it puts at risk. Only a working exploit makes a finding.
Attack pathSample: Acme Corp - StartAny customer account
- WeaknessNo ownership check
- ReachEvery customer's invoices
- At riskNames, addresses and amounts
Report
A person reviews every finding's proof, risk and fix. Engineers get the fix; leadership gets the risk.
Sample finding HighOWASP API1:2023, CWE-639
Invoices readable across customer accounts
Broken object level authorisation
Request
GET /api/invoices/10482 HTTP/2Host: app.acme-corp.comCookie: session=<customer B>
Response
HTTP/2 200 OK{ "id": 10482, "account": "Customer A", "amount_due": "[redacted]" }
- Business impact
- Any signed-in customer can read other customers' invoices by changing one number in the URL.
- Fix
- Check the invoice belongs to the caller's account on every read, in one shared check.
Retest
We rerun the original exploit against your fix. Proof the fix holds, not just that it shipped.
Retest resultSample: Acme Corp The same request after your fix, as customer B
Before the fix, statusOpenHTTP/2 200 OK{ "id": 10482, "account": "Customer A", "amount_due": "[redacted]" }
After the fix, statusFixed, verifiedHTTP/2 404 Not Found
Seven tests, matched to what you run
Each page sets out the scope, the method and a sample finding.
Our seven services lead into one method, in three steps. Recon: mapping what is reachable. Exploit: a tester works the lead. Prove: proving the exploit.
Web application penetration testing
Sign-in, access control, injection, business logic
API penetration testing
Object and function level authorisation, and abuse
Mobile application penetration testing
Local storage, traffic and the backend it calls
Cloud penetration testing
Identity, exposed storage and network paths
Red team assessment
A goal-based attack, within agreed rules
LLM and AI penetration testing
Prompt injection, data leakage, tool misuse
Continuous penetration testing
A full test every quarter, checks on request
Not sure which?
Tell us what you run.
Request a quote
Before testing starts
In scope
- app.acme-corp.com
- api.acme-corp.com
Scope agreed. Your quote follows.
How do you test live systems safely?
Live systems are tested by default, in agreed windows, with a named contact and no destructive actions. Testing starts after we agree the scope with you.
How long does a penetration test take?
It depends on the scope: a single web app takes less time than a cloud account.
What do you need from us before testing?
The agreed scope, the testing windows and an account for each user role you want covered.
How is a test priced?
On its scope, so there is no list price. A scoping conversation comes first, then the quote.
Aligned with five public standards
Each test follows the standards that fit its scope.
OWASP Top 10, OWASP Top 10 web application security risks
The most critical web application risks
OWASP ASVS, OWASP Application Security Verification Standard
Application Security Verification Standard
NIST SP 800-115, NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment
Technical guide to security testing and assessment
CWE Top 25, Common Weakness Enumeration Top 25 Most Dangerous Software Weaknesses
The most dangerous software weaknesses
MITRE ATT&CK, MITRE Adversarial Tactics, Techniques and Common Knowledge
Adversary tactics and techniques
Aligned with, never certified by. Names belong to their owners; no endorsement implied.