Skip to content
Skip the story

Your AI-built app. Evidence, not assumptions.

Check real sign-in journeys and audit verified websites for known exposures and misconfigurations. See what was checked, what failed and what remains untested.

Public route discovery and passive checks are illustrated here. A report never turns limited coverage into a guarantee that your whole app is secure.

Illustration: a graphite slab supporting a sample website browser, with a verified scope and the audit steps ahead.

Illustration: a graphite slab supporting a sample website browser, with a verified scope and the audit steps ahead.
Illustration · a verified sample website and its audit scope

Prove it’s yours. Set the scope.

No audit runs until you prove you control the website and the authorisation is recorded. The scope is the approved public HTTPS origin and nothing else.

A restricted test account is optional for website audits. Without one, only public routes and passive checks run; authenticated coverage is marked Not tested.

Illustration: a website-audit setup with ownership verification, a bounded public origin, an optional restricted test account and passive checks.

Illustration: a website-audit setup with ownership verification, a bounded public origin, an optional restricted test account and passive checks.
Illustration · a sample website-audit configuration

Routes, sign-in, passive checks.

Inside the approved scope, Gatemark lists routes, checks sign-in when a restricted account is supplied and runs passive checks.

Requests are limited and responses are kept as evidence. Without a test account, sign-in coverage stays Not tested while the public audit continues.

Illustration: bounded route discovery and passive analysis, with the optional sign-in journey clearly marked Not tested when no account is supplied.

Illustration: bounded route discovery and passive analysis, with the optional sign-in journey clearly marked Not tested when no account is supplied.
Illustration · a sample website audit in progress

One finding. All the evidence.

Each finding shows its severity, the confidence behind it, where it was observed and the redacted response it came from, with guidance on what to change.

Severity and confidence stay separate. Passive evidence is not presented as a reproduced exploit, and no automatic fix is offered.

Illustration: a missing security header finding with severity, confidence, passive verification, generic provenance, redacted evidence and remediation.

Illustration: a missing security header finding with severity, confidence, passive verification, generic provenance, redacted evidence and remediation.
Illustration · a sample missing-header finding, not a customer audit

The checks. The limits.

Every audit ends with a coverage summary: what completed, what the restricted account could not reach and what was never run.

A failed sign-in or an unavailable check is reported as such, never as a clean result. Public-only audits state that nothing behind sign-in was tested.

Illustration: a public audit summary separating completed route discovery and passive checks from untested sign-in coverage and unsupported checks.

Illustration: a public audit summary separating completed route discovery and passive checks from untested sign-in coverage and unsupported checks.
Illustration · completed public checks and explicit coverage limits

Monitoring. Audits. Kept separate.

Daily sign-in monitoring is one product. Evidence-backed website audits are another. Each is set up, scoped and shown on its own.

Sign-in monitoring is $19/month, paid from day one. Website audits require verified ownership and are not included in the monitoring plan.

Illustration: two product cards keeping daily sign-in monitoring separate from verified website security audits.

Illustration: two product cards keeping daily sign-in monitoring separate from verified website security audits.
Illustration · separate sign-in monitoring and website-audit offers