Zero standing access
Two of our three products find real problems before receiving any credential. Why that constraint shapes what we can build, and what it costs in coverage.
Security tooling has an awkward habit of asking for exactly the access an attacker would want. The pitch is that you should trust the vendor because they are the security company, which is circular, and because they have a compliance page, which is a statement about process rather than about exposure.
We would rather reduce the amount of trust required. Not eliminate it — that is not on offer from anyone — but make the honest answer to "what could you do to us" as small as the problem allows.
Four levels of access, and where each product sits
Worth naming the levels, because "read-only" gets used for at least three different things.
Nothing — a public URL
The tool fetches what any visitor could fetch and reasons about it. It holds no credential, so there is nothing to leak, revoke or misuse. The blast radius of the vendor being breached is that somebody learns which public URLs you asked about.
Read-only, unauthenticated
The tool makes the requests an anonymous stranger could make — the public API key that is already in your bundle, with no elevated identity. Everything it sees, anyone could have seen. This is the level that answers "what does my application hand to someone who is not logged in", which is a surprisingly large share of the question.
Read-only, scoped and revocable
The tool holds a credential you issued, limited to reading specific resources, revocable by you at any time without our involvement. This is where continuous monitoring lives, because watching for change over time requires something more durable than an anonymous snapshot.
Write
The tool can change your systems. We do not operate here, and the reason is less about principle than about what a breach would mean: a compromised writer is an attacker with a deployment pipeline into every customer at once.
What each product needs and why
KeyDrift
A public URL. That is the whole requirement for a scan.
The credentials it finds are the ones your CDN is already serving to every visitor, so there is nothing to grant — the tool is fetching files that are public by definition. It reasons about what it finds, and the findings it stores are masked to a short head and tail with a salted fingerprint for identity, never the value.
RowShield
The free audit is read-only and performs no writes: no schema changes, no data modification, nothing that alters state. It asks your database what it will hand to an unauthenticated caller and reports the answer.
Continuous monitoring needs more, and it needs it for an unavoidable reason — detecting drift means comparing today's state to last week's, which requires a durable credential rather than a one-off look. That should be a scoped role rather than an owner, and it should be revocable by you in one action.
FeeGuard
A Stripe restricted key and a webhook endpoint.
This is the product where the level is highest, and the reason is structural: reconciling money means reading the ledger, and no anonymous view of the ledger exists. A restricted key is the right instrument because Stripe lets you constrain it to specific read permissions rather than handing over full API access. If a Connect platform gave us a full secret key, we would ask them not to.
What we give up by working this way
This is the section that matters, because a constraint with no cost is not a constraint.
- Coverage stops at the public boundary. KeyDrift sees what your CDN serves. Code behind authentication, a mobile binary, a private admin bundle behind a VPN — outside the reach of a tool that only fetches public URLs.
- An unauthenticated audit cannot see what a logged-in user sees. It answers "what does a stranger get", which is the highest-consequence question and not the only one. Testing what one authenticated tenant can read of another's data needs identities we do not have.
- A read-only tool cannot fix anything. We generate the SQL, the rotation order, the corrected call — and you run it. That is slower than a product that remediates on your behalf, and we think it is the right trade when the alternative is standing write access to production.
- Some findings are unreachable in principle. A business-logic flaw, a privilege escalation through a legitimate feature, a design decision that is bad rather than misconfigured. None of these are visible from outside, and no amount of access we could plausibly ask for would surface them.
We would rather publish that list than have it discovered. A vendor's stated limits are more informative than its stated capabilities, because the capabilities are marketing and the limits are a commitment.
Two of our three products find real problems without a credential. The third asks for the smallest one that can read a ledger.
Common questions
Why does monitoring need standing access when the audit does not?
Because drift is a comparison and a comparison needs two observations. A single audit is a snapshot you asked for; monitoring is the same question asked repeatedly without you initiating it, which requires a credential that persists between runs. If that trade is not worth it, the audit on its own is a legitimate way to use the product and we would rather you did that than granted access you are uncomfortable with.
What happens to my credential if you are breached?
For KeyDrift, there is nothing to take. For the others, a scoped read credential you can revoke without contacting us, which is the point of insisting it be scoped and revocable — your recovery path does not depend on our incident response. Findings are stored masked, so a stolen database yields prefixes and fingerprints rather than usable secrets.
Can I verify what you actually did?
Yes, and you should. Stripe logs API requests made with your restricted key. Postgres can log the statements a role executed. Neither of those depends on our reporting, which is the property that makes them worth more than any assurance we could write on this page.