Every question your security team will ask, answered here.

Public, internet-facing signals for domains you have authorized: HTTPS availability, TLS certificates, HTTP security headers, DNS records, SPF and DMARC email-authentication records, and public domain-registration (RDAP) status.

Anything requiring credentials, anything intrusive, and anything you have not authorized. Sentinel performs no exploitation, no credential use, no denial-of-service testing, and no intrusive vulnerability validation. Scan classes S2 and above are outside V1 entirely.

The checks are passive and low-impact reads — the same requests any visitor's browser makes, on a schedule. There is no write path to your systems.

No. Sentinel is external monitoring with evidence and a verified remediation loop. It complements a human-led penetration test; it does not replace one, and it is not endpoint protection, SIEM, or a 24/7 SOC.

Not yet. Repository security (Sentinel Code) is a planned controlled beta and is not available today. No repository is connected and no source code is processed.

Every customer-visible finding links to the observation that produced it: the detector and its version, the target, the timestamp, and the retained data itself. Each evidence record carries a SHA-256 hash covering that content, so later modification is detectable. No evidence, no finding.

Open any finding in the portal and expand its Evidence panel.

Challenge it. A disputed finding is suspended from your risk score while it is under review, and both the challenge and the written outcome stay on the record. Target response is 2 business days.

It is not, in any customer-visible output. Every finding, score, claim, report sentence, and receipt in the product today is produced by deterministic code from recorded observations. If that changes, any AI-assisted output will be labelled and will remain incapable of creating a finding without deterministic evidence behind it.

No models are used, so no customer data trains any model. This will remain contractually prohibited if AI assistance is introduced.

A signed record of one verified change: what was exposed, the evidence before, the approved action, the rescan result, the evidence after, and the change in risk. It is issued only when a rescan confirms the finding is gone.

Anyone holding a receipt identifier can verify it on the public verification page or through the JSON endpoint, without an account. Verification re-derives the content hash and checks the platform signature. Offline verification without contacting us requires an asymmetric key and an open-source verifier — planned, not yet available.

It can be revoked, with a reason, and the verification page reflects that immediately. Receipts are never silently edited.

Yes — each carries a freshness window. A receipt describes a verified moment, never a permanent state, and the verification page says so once the window has passed.

Account and identity data, the assets you authorize, check results and the evidence derived from them, findings, alerts, reports, receipts, audit events, and access logs. Evidence is redacted before storage to strip secrets, tokens, and personal data.

Resend for outbound alert email when enabled. Public DNS resolvers and RDAP registries are queried for lookups but receive no customer data beyond the domain being checked. The current deployment is a single operator-managed server.

Your whole graph — assets, authorizations, findings with evidence lineage, claims with control mappings, alerts, reports, and snapshots — exports as documented JSON on request. No fee, no exit friction.

Deleting an organization removes its members, assets, checks, results, findings, alerts, snapshots, reports, receipts, and authorization records. Audit entries are deliberately retained: they are the record of what scanning was authorized, and editing them would break the tamper-evident chain. They age out wholesale on a 24-month retention schedule.

In the region of the deployment you are onboarded to. In-region and private-deployment options for specific jurisdictions are planned and are not claimed as available today.

Sessions are httpOnly, SameSite, hash-stored, capped by both idle and absolute lifetimes, and revocable. Cross-origin state changes are rejected. Security headers including a content-security policy are set on every route. Login is rate limited. Administrative actions are recorded in a tamper-evident hash-chained audit log that can be independently re-verified.

Not yet. An independent penetration test and retest are required before commercial general availability, and the summary will be published here when it exists. There is no test to point to today.

Yes — that is the point. The self-check runs the production check modules and scoring formula against our own domain, and the deployment must clear the threshold before customer-facing claims are made.

Live status: /status

Email security@9keys.io. The policy, scope, and response targets are published at /security and in /.well-known/security.txt.

Published plans with an instant quote for standard scope. Pricing is labelled as pilot pricing until per-customer costs are measured — we will not publish a validated price we cannot stand behind.

Email support with a first-response target of one business day for standard plans; enterprise response is contract-specific. These are targets, not a contractual SLA, until measured.

None today. SOC 2 and ISO 27001 are on the roadmap with readiness work planned; we will not imply certification before a certificate is issued.

Full export in a documented format, then verified deletion. No exit fee and no lock-in.

Yes, structurally. The remediation channel is not an input to severity, confidence, or scoring, and self-fixes, partner fixes, and 9Keys Cyber fixes receive identical verification and identical receipts.