Security and trust

Security & Trust Centre.

If you are assessing Klarvant as a supplier, this page is written for you. It sets out how Namespace Command is built, hosted and operated, how your data is protected, and how those controls are tested. The summary below answers the questions that open most assessments; the sections that follow give the detail behind each one.

Where the platform runs, where data lives, how it is protected, and how change reaches production.

At a glance

The one-minute assessor summary.

Row	Value
Hosting	Google Cloud Platform, independent regional deployments in London, the Netherlands and Iowa
Data residency	UK (europe-west2), EU (europe-west4), US (us-central1); tenant database, backups and AI generated audio briefings held in region; per-region encryption keys
Scanning infrastructure	Central collection plane in the United States processes publicly observable data in transit; tenant data is written to and held in your region
Encryption at rest	AES-256; dedicated per-region keys in Google Cloud KMS held and managed by Klarvant, automated 90-day rotation; AES-256-GCM at the application layer for sensitive values
Encryption in transit	HTTPS only, TLS 1.2 minimum, HTTP Strict Transport Security enforced; hybrid post-quantum key exchange (X25519MLKEM768) on TLS 1.3
Authentication	Passwordless: Google or Microsoft SSO (OIDC), passkey under WebAuthn, or single-use email link; no stored passwords
Tenant isolation	PostgreSQL row-level security under a restricted database role, plus separate regional databases; fails closed
Access to customer systems	None. No agents, no credentials; publicly observable data only
Independent testing	Annual external penetration test by an independent third party; most recent completed 2025, findings remediated
Availability	99.9% target each month per environment, measured out-of-band every five minutes, monthly reports per environment
Sub-processors	Six, published below, including named AI providers. No credentials or user account data reach any AI provider

Klarvant Namespace Command™ runs on Google Cloud Platform as independent regional deployments. This page sets out where the platform runs, where your data lives, how it is protected, and how change reaches production. It is written for third-party risk assessment and supplier onboarding.

Platform architecture

Independent regional deployments on Google Cloud Platform.

Google Cloud Platform

Namespace Command runs entirely on Google Cloud Platform as independent regional deployments, each serving customers in one jurisdiction: the UK (europe-west2, London), the EU (europe-west4, Netherlands) and the US (us-central1, Iowa).

Hard isolation boundaries

Each region has its own application tier, its own PostgreSQL database with a live streaming standby in a second availability zone, its own virtual private cloud and its own load balancer. Regions share no databases and their networks are not connected to one another. They are isolation boundaries built for data residency, not replicas of one another.

Zero-integration design

No agents, no credentials, no API keys and no privileged or network access to customer systems. Assessments collect only publicly observable data, so deploying the platform does not expand your attack surface.

Where scanning runs

The scanning and enrichment pipeline, covering DNS resolution, certificate and web probes and related enrichment, runs on shared infrastructure in the United States. It processes data in transit before results are written to your regional database. What it handles is publicly observable internet data about your own estate, the same information any external observer can see. Website screenshots and customer uploaded brand assets are held in a content store hosted in the United States.

For a UK tenant, the tenant database holding all inventory, findings, configuration, user accounts and history, together with its backups and any AI generated audio briefings, is held and served in London.

Group

Protecting your data.

Data protection and encryption

Encrypted at rest and in transit.

Encryption at rest

AES-256 at rest for all data.
Dedicated encryption keys in Google Cloud KMS, held and managed by Klarvant, with key rings per region, so UK database keys live in London. Keys rotate automatically every 90 days.
Application-layer encryption with AES-256-GCM for sensitive values already stored in the encrypted database.
Secrets isolated from code: API credentials and signing keys are held in Google Secret Manager and mounted at runtime, never stored in code or images.
Log redaction: application logs pass through automatic redaction of fields shaped like credentials.

Encryption in transit

HTTPS only, TLS 1.2 minimum, with a modern cipher profile enforced by a Google Cloud SSL policy on every load balancer.
HTTP Strict Transport Security is enforced.
Hybrid post-quantum key exchange on TLS 1.3 connections, using X25519MLKEM768, which combines X25519 with the NIST standardised ML-KEM algorithm. Session confidentiality is protected against harvest now, decrypt later collection. The platform measures post-quantum readiness across customer estates, and negotiates post-quantum key exchange on its own edge.

Access control and authentication

Passwordless sign-in, least-privilege access.

Authentication and identity

Passwordless sign-in: Google or Microsoft single sign-on over OIDC, a passkey under WebAuthn, or an email sign-in link that works once and expires quickly. The platform stores no passwords.
Multi-factor and risk-based challenges are inherited from your own identity provider.
Hardened sessions: cookies locked to the host and marked Secure, HttpOnly and SameSite Strict; 256-bit random session tokens stored only as hashes, with a bounded lifetime; each session records its method, address and device; a sign out control and a sign out everywhere else control that ends every other session.
Sign-in abuse containment by rate limiting at the web application firewall and again in the application.

Access management

Klarvant operator access is limited to a small named engineering team using Google single sign-on.
Step-up for privileged actions: privileged platform operator actions in the product require an additional time-based one-time code.
Server-side allowlists: support roles are restricted on the server to explicit allowlists of permitted operations.
Least-privilege infrastructure access using Google Cloud IAM with per-environment service accounts.

Roles and scoping

Role-based access covering administrator, writer and read only, managed by your own organisation.
Organisational unit scoping optionally restricts a user to an allowed slice of the estate, enforced on the server.

Group

Data protection.

What a tenant holds

Account data: a user name, work email address, role and sign-in records. This is the only routine personal data the platform keeps.
Customer configuration: organisation structure, domain scope, settings and uploaded brand assets, provided by you.
Collected observations: DNS records, certificates, TLS probe results, email security records, public web content and screenshots, IP and autonomous system data, registration metadata and technology fingerprints. Publicly observable internet data about your own estate.
Derived data: the findings, indicators and briefings generated from the rest.

Privacy and deletion

Exposure to personal data is deliberately low. Registration data is stored at registrar level only, and no registrant contact details are kept. Incidental personal data is limited to whatever you publish on your own public estate.
UK GDPR: Klarvant processes personal data in accordance with UK GDPR, and a data processing agreement is available.
Deletion: on completion of an evaluation, the tenant and its collected data can be deleted on request.

Group

Sub-processors.

Name	Purpose	Data
Google Cloud Platform	Regional hosting, storage and monitoring	All platform data, in the regions above
Google, Gemini API	AI analysis, briefings, text to speech	Scan derived data and posture metrics only
OpenAI	Secondary AI provider	Scan derived data only
Twilio SendGrid	Transactional email and sign-in links	User email addresses
GitHub	Source code hosting and build pipeline	No customer data
IP and domain data providers	Enrichment lookups	Observed addresses and queried domain names

No credentials or user account data reach any AI provider. Enrichment providers are named in the data processing agreement, and further documentation is available on request.

Sub-processor list last updated August 2026.

Group

How we build and run.

Secure software development

Security in every phase.

Every change is reviewed

Private repository; all changes ship by pull request
Continuous integration on each: build and automated test suites including race detection
Static application security testing with CodeQL
Automated dependency updates and advisories, and Go vulnerability scanning
Peer review required for schema, authentication, access control and infrastructure

Releases are staged and gated by people

A standard release deploys first to pre-production and must soak for at least 24 hours with no regressions
More urgent releases can bypass soak if approved
Production rollout is sequential by region: United States, then European Union, then United Kingdom
Each region is gated by an explicit approval from a named engineer
Production ships the exact artefact that was tested: images are promoted, never rebuilt

Rollback is documented

Any prior release can be redeployed at any time
The database schema is kept forward compatible by rule, so redeploying stays safe
Security fixes outside the normal cycle take an expedited flow through the same regional gates
A customer-facing changelog accompanies every release

Network and application security

Multi-layered defence.

Cloud Armor WAF

OWASP Core Rule Set inspection at the Google global external HTTPS load balancer via Google Cloud Armor, covering SQL injection, cross site scripting, file inclusion, remote code execution, scanner activity, protocol attack and session fixation.
Per-address rate limiting, stricter on authentication endpoints.
Adaptive layer 7 denial of service protection over a global network that absorbs volumetric attack.

Network controls

Per-environment virtual private cloud with firewall rules that deny by default and least-privilege segmentation.
No internet ingress to data: databases and internal services hold private addresses with no ingress from the internet.
Flow logs enabled across all networks.

Application security

Tenant isolation in the database: all access to customer data runs as a restricted database role under PostgreSQL row-level security policies scoped to your organisation, on top of fully separate regional databases. This sits beneath the application code and is designed to fail closed: a request without a valid tenant context returns no rows rather than another tenant's data.
First-party code only: a content security policy on every page restricts third party scripts, styles or fonts anywhere in the product. All application code is served first party, and the only external content loaded is public map imagery from an explicit allowlist.
Anti-forgery protection on state-changing requests.
Parameterised queries throughout.
Hardened security headers, with request size limits and rate limiting.

Monitoring and incident response

Continuous visibility, rapid response.

Continuous monitoring

Out-of-band availability measurement by a separate monitoring system outside the platform, probing the web application and the API every five minutes, producing a monthly report for each environment.
Alert policies covering latency, error rates and resource pressure, routed to the engineering team.
Centralised structured logging with restricted access.
Self-healing application tier on Google managed serverless infrastructure with capacity kept warm; core scanning and enrichment services are deployed redundantly across two availability zones.

Incident management

Incident process covering incidents affecting availability or customer data, including customer notification.
Vulnerability reports are welcome at security@klarvant.com . We aim to give a first response within two working days.

Group

Assurance and testing.

Compliance and independent testing

Verified through regular assessment.

Penetration testing

Annual independent testing by an independent third-party firm. The firm is not named by choice.
Most recent engagement completed in 2025, and the findings were remediated.
2026 engagement is under way. A summary can be provided on completion.

Continuous assurance between tests

Static analysis and dependency and vulnerability scanning run in the build pipeline on every change.
Web application firewall behaviour is monitored for regressions.
Synthetic negative path probes run against the authentication controls.

Standards and frameworks

Development

OWASP secure development practice

Architecture

Google Cloud security reference architecture

Data protection

NIST guidance for key management and media sanitisation
UK GDPR

Group

Resilience.

Business continuity and resilience

Built for availability and recovery.

Regional deployments

Independent regional deployments in the UK, EU and US keep customer data in jurisdiction. Regions share no databases and their networks are not connected to one another; each connects only to the central collection tier.

Backup and recovery

Automated encrypted snapshots on production environments: daily with seven day retention, and weekly with six month retention. Snapshots are stored in region, so UK backups never leave London. They inherit the same managed encryption keys, and every database host carries deletion protection. The snapshot interval supports a 24-hour recovery granularity, allowing point-in-time restoration to any day within the preceding week if both primary and secondary databases are lost. An automated restore test runs every week and proves that backups restore into a working database.

Availability

A 99.9% availability target each month per production environment, measured continuously by a separate monitoring system outside the platform. Each production database runs a live streaming standby in a second availability zone, with an operator controlled failover procedure.

Security contact.

We welcome security researchers, customers and collaborators to contact us on security matters. For vulnerability disclosures, please include detail on the issue, steps to reproduce, and any supporting materials. We aim to give a first response within two working days.

Security and vulnerability disclosure

security@klarvant.com

Further documentation is available on request.