Home/Product/Greybox

Greybox.
Share some access. We go deeper.

Your red team plays a malicious user: someone with a real account, looking for what they shouldn't reach.

Give us part of the picture - test accounts, API keys, a diagram, a sandbox - and we test the parts of your product a stranger can't reach.

Talk to the founder →

Start at any level. Move between them whenever you like.

Blackbox
Nothing. Scope and permission only.
Greybox
Test accounts, API keys, docs, a sandbox.
Whitebox
Source, infrastructure, environments.
What it unlocks

What you share, and what it lets us test.

Share any combination. Each piece opens up a part of your product an outside test cannot reach.

Test accounts
What a logged-in user can do, including what they should not: read another customer's data, or act as a role they do not have.
Accounts in 2 tenants
Whether 1 customer can reach another customer's records - the failure multi-tenant products fear most.
API access or keys
The endpoints your own frontend never calls, which an outside test may never find.
Architecture or API docs
Testing aimed at your real trust boundaries, instead of ones inferred from the outside.
A sandbox or staging environment
Heavier testing against a copy of your product, without touching production.

Best for
Products where the risk lives behind the login: multi-tenant SaaS, anything holding customer records.

Your call

Share as much or as little as you like.

Greybox is not a fixed package. 1 test account is Greybox; so is a full staging environment with docs. Start with whatever you are comfortable sharing and add more later, or never. Access is connected per asset in the dashboard - depth is inferred from what you share, never a setting.

Greywatch
OverviewFindings1Assets5Rules7IntegrationsTeamSettings
Testing paused
First cycle complete · 17 attack paths queued · map still live
Continue testing
acme-health.com / AssetsPaused
Assets · Greybox
Depth is inferred from what you connect, never a setting · every change logged
Connected
Bacme-health.comDomain · 4 hosts mapped · 1 excluded
In scope
BPermission to testSigned · production hosts allowed
On file
G2 test accountsapp.acme-health.com · tenant A and tenant B
Connected
GAPI keyRead scope · rotates monthly
Connected
GStaging environmentstaging.acme-health.com
Connected
+ connect an account, key, environment or repo
Rules this access brings
BExclude third-party hostspartner-api.acme-health.com stays untouched
BNever run destructive actionsNo writes, no deletes · 1 sample, redacted
BRate limitPer host, enforced by the harness
20 req/s
BPause after each cycleNothing runs until you press Continue
GUse provided accounts onlyNever a real customer login
GNever touch real tenantsTest data only, in the tenants you created
GWrite actions on staging onlyProduction stays read-only

Every asset you connect brings its own rules.
More access means more guardrails, never less control.

At every level

Same results, whatever you share.

Access changes how deep we can go. It never changes what you get back.

01
Continuous
Our AI agents test your live product the way an attacker would. Continuously, not once a quarter.
Agent activity
surface re-mapped after deploylive
auth boundaries re-tested4m ago
your last quarterly pentest83 days ago
02
Reviewed
A security engineer reviews every finding before it reaches you. You get a short list of real issues. Not 1,000 tickets.
Prioritized findings
IDOR on /api/patients/:idCritical
Overprivileged S3 policy on backupsHigh
Missing security headersLow
03
Reproducible
The exact request that worked, the data it exposed, step-by-step reproduction your engineers can run, and a recommended fix.
Reproduction
$ curl -H "Auth: <user-a>" \
  /api/patients/8815
← 200 OK · returns patient 8815
user-a is not patient 8815

Plans from $1,500 a month. See pricing →

Get in touch

Talk to the founder.

Tell us what you're building and what you're worried about. You'll hear back from a founder, not a sales rep.

✓ Thanks for reaching out. We'll be in touch shortly.