Honest about where we are.

Validera is an early-stage company in active pilot. The page below describes what's in place today, marked with green “live” tags, and what's on the near-term roadmap, marked amber. We'd rather lose a deal than ship a buyer false comfort.

Our philosophy

Three principles shape every architectural decision we make.

Least privilege by default. The extension reads what it needs to verify a specific action and nothing more. The platform stores what it needs to produce an audit trail and nothing more. No data tourism.

Customer data is customer data. We don't train models on it. We don't share it. The Anthropic API calls Validera makes are governed by Anthropic's commercial terms, which prohibit training on inputs.

Honest about where we are. Some certifications take time. We don't pretend to have what we don't yet have. Everything below is current as of the date in the footer; the “Security roadmap” section lists what we're working towards next.

Data handling

What we store.

The claim ticket text the agent is working from. The booking transaction the agent is about to commit (property, dates, price, currency, source URL). The verification outcome (pass / warn / block, which rules fired). Any agent override and the typed reason. Time-stamps and the agent identifier.

What we don't store.

Credit card numbers. Passwords. MFA tokens. Browsing history outside our supported platforms. Screen recordings, keystrokes, or clipboard contents. Personal data of claimants beyond what appears in the source ticket. Location data, device fingerprints, or advertising IDs.

Where it lives.

All operational data lives in a Supabase PostgreSQL database in the Sydney (ap-southeast-2) region. Backend services run on Vercel's edge network. We do not currently offer customer-selected data residency, EU residency, or on-premises deployment. If you need a non-Sydney region, talk to us before signing.

How long it lives.

Audit log data (verdict events, override events, extraction events) is retained by default to support multi-year compliance review by customer auditors. Retention can be capped per customer in the contract. Customer data is deleted within thirty days of contract termination on request, with confirmation provided.

Encryption

In transit. TLS 1.2 or higher on every endpoint, terminated at Vercel's edge with managed certificates. The Chrome extension, the dashboard, and the three backend services all enforce HTTPS.

At rest. AES-256 on all stored data, provided by Supabase's default storage encryption (the underlying volumes are encrypted by AWS RDS). We do not currently offer customer-managed encryption keys.

Secrets. Anthropic API keys, the Supabase service-role key, and per-tenant API keys are stored only in Vercel's encrypted environment variable store. They are never embedded in the Chrome extension, never sent to clients, and never written to logs.

The browser extension

The extension is the most security-sensitive part of the system, so it gets its own section.

Distribution.

Today: distributed via the Chrome Web Store as an unlisted listing for pilot customers, requiring a direct install link. We do not currently support force-install via Google Workspace or Microsoft Intune managed extensions. Public Chrome Web Store distribution is a roadmap item.

Permissions.

The extension declares the minimum permissions needed to run: read access to the DOM on the platforms it adapts (the Zammad ticket platform and supported booking sites), the ability to detect commit-style clicks, and access to Chrome's identity API for sign-in. It does not request access to bookmarks, browsing history, downloads, the file system, or sites outside its declared host permissions.

Authentication.

The extension authenticates the agent via Chrome's built-in identity API, which surfaces the agent's signed-in Google profile email. That email is exchanged with our audit service for the per-tenant configuration the extension needs (tenant id, agent id, bearer token). The bearer token is stored in chrome.storage.local and never leaves the agent's browser except over HTTPS to validera.io domains.

Updates.

Updates are published through the Chrome Web Store, signed and verified by the browser before installation. We do not currently run a phased rollout (canary → partial → full); that's a roadmap item once we have more than a single customer in production.

Code review.

All code is reviewed before merge. We do not yet engage an external security firm for periodic code review. That is on our roadmap before general availability.

Access control

Authentication (admin dashboard).

Admins sign in to app.validera.io using a tenant API key, exchanged for an httpOnly, secure, SameSite=Lax session cookie that expires after 30 days. The cookie is the API key itself for the pilot — token rotation is on the roadmap. We do not currently support SSO via Okta, Microsoft Entra, or any SAML provider; that work is planned for first enterprise customer onboarding.

Authentication (backend services).

Every API call to the extractor, verdict, and audit services carries a Bearer token in the Authorization header. The token is resolved against the tenants.api_key column in our database, with a short in-memory cache. No tenant can read or write data belonging to another tenant — every query in the audit service and dashboard scopes by the resolved tenant id.

Multi-Factor Authentication.

Today: MFA is not enforced by Validera's own auth (because the dashboard uses an API-key cookie and the extension uses Chrome's identity, which inherits whatever MFA the agent's Google account has). Enforced platform-level MFA arrives with SSO support.

Roles.

Today: every authenticated dashboard session has full read/write within its tenant. We do not yet have viewer / editor / admin role distinctions; that's on the roadmap.

Audit of admin actions.

Tenant configuration changes (adding agents, renaming a tenant) currently leave only the changed-state in Supabase, not a per-action audit log. A separate admin-action audit log is on the roadmap.

Compliance

A live, dated view of where we stand on common buyer requirements. We do not have any third-party certifications today.

We are happy to complete vendor security questionnaires (CAIQ, SIG Lite, custom). Email security@validera.io with the questionnaire and turn-around expectations and we'll come back to you with a realistic timeline.

Subprocessors

Every third party that processes customer data on Validera's behalf is listed below. The full, dated version lives at validera.io/subprocessors. We commit to giving customers thirty days notice via email before adding a new subprocessor.

Incident response

If something affects your data or service availability, you will hear from us.

Detection. Today: error monitoring is via Vercel's built-in runtime logs and Supabase's database advisors. Dedicated error monitoring (Sentry or equivalent) is on the roadmap.

Notification. Confirmed customer-affecting incidents trigger an email to your designated security contact within one business day of confirmation. Live service status is at validera.io/status; historical uptime is published at stats.uptimerobot.com/TE2WEMLJx0.

Post-incident. Where an incident affected customer data or material service availability, we provide a written summary of root cause, remediation taken, and changes adopted. No fixed SLA on this until we have an incident-response runbook in place — being honest about that.

Security roadmap

The work below is committed to but not yet shipped. We update this list as items move from roadmap to live.

• Sentry error tracking across all services with PII scrubbing.
• Public status page on our own domain — live status at /status and historical at stats.uptimerobot.com/TE2WEMLJx0 today; a status.validera.io subdomain becomes available once we move past UptimeRobot’s free tier.
• SSO via SAML 2.0 / OIDC (Okta, Microsoft Entra, Google Workspace) for the dashboard, with platform-enforced MFA.
• Role-based access control for the dashboard (viewer / editor / admin).
• Token rotation separate from the long-lived API key, with a per-session token model.
• Per-action admin audit log covering tenant + agent + workflow changes.
• External code review of the extension and backend services by an independent firm before general availability.
• SOC 2 Type II readiness work (control documentation, evidence collection) post-pilot.
• Phased extension rollout (canary → partial → full) once we have more than a single customer in production.

Reporting a vulnerability

We run a coordinated disclosure programme. Email security@validera.io with a description, reproduction steps, and any proof of concept. We aim to respond within one business day. Researchers acting in good faith will not be pursued legally.

We do not currently run a paid bounty programme.

What to do next