Trust: what this service holds, who can reach it, and what is and is not certified
This page is generated from the product's own documentation and database schema on every release, so it cannot drift from what the service really stores. Where something is not done yet, it says so. The full buyer's review, with evidence for every answer and the plan for every gap, is docs/ENTERPRISE_READINESS.md in the product repository (ask your account team for a copy).
The one rule
Sensitive values the gateway detects never leave the machine in clear. The gateway on each machine replaces them with tokens before a request leaves that machine, and restores them only there. This service — the console — never receives prompts, responses, files, the protected values, file paths, MCP server names or your organisation's salt. Protection runs without it.
A gateway connects only where you point it: the AI providers it forwards to, your console if the machine joined one, and rule-feed URLs your administrators configure. Nothing else, the libraries it is built on included (a full request is tested on every release with every socket trapped; a library that fetched a public list from GitHub was found this way and closed in 0.23.0). It can install and upgrade with no network at all, from an offline bundle signed by the vendor.
Activation of air-gapped installations (Enterprise)
Only when an administrator runs an activation, renewal or deactivation: the installation's public key, a fingerprint of the machine keyed so that we can neither reverse it nor link two installations, a reference and a proof for the activation key (never the key itself), the product version and platform, an optional label your administrator types, and for renewals a chain of sequence numbers, hashes and "days since last renewal". Never hostnames, user names, addresses or content. vguard licence show-request prints any code before it leaves. We keep the activation record (those fields, dates and status) for the life of your licence.
What your gateways send to the console
Only if a machine joined your organisation: versions, health and self-test results, which AI clients are routed (fixed ids), daily counts by data category and outcome, token counts and estimated list-price spend per model name, budget states, latency percentiles, the audit chain's head hash (to detect tampering), and posture counts. Support requests hold only what your people type into them, and the console refuses credentials, keys, payment data and identifiers in them. The telemetry schema has no free-text field; the gateway validates each batch before sending, and the console validates it again and refuses anything else. vguard org telemetry on any machine prints exactly what would be sent.
Commands held for approval (only if your guardrails ask for approval)
When a guardrail rule says a command needs approval, the gateway holds it and tells the console: the request id, the guardrail rule and category, the environment name your policy gave it, the tool name and the times. The command text is sent only to a console you run yourself, or when your policy says share_command: tokenized; it is the command as the AI model wrote it, with every protected value still a token. The hosted console receives no command text by default. Decisions (who, when, why) are kept with the audit trail; any command text is blanked after 30 days.
The console can send your gateways a floor: regime presets and "approvals only in the console". A gateway applies it only as a floor, so it can make protection stricter, never weaker.
What the console stores (generated from the database schema)
Every table that holds a customer's data, and every column in it. Rows are isolated per organisation by PostgreSQL row-level security.
| Table | Columns |
|---|---|
users | id, org_id, email, roles, token_hash, created, disabled, mfa_secret, mfa_enabled, last_seen, token_rotated, pw_hash, pw_set, scim_managed, external_id, scim_attrs, scim_deprovisioned, sso_iss, sso_sub, mfa_last_step |
enrollments | token_hash, org_id, created_by, created, expires, max_uses, uses, note, owner_user_id |
devices | id, org_id, token_hash, user_label, hostname_tag, os, gateway_version, policy, policy_fp, rules, enrolled, last_seen, last_telemetry, license_state, revoked, coverage, audit_seq, audit_head, channel_seen, posture, owner_user_id, update_state, enrolled_by, seal, session_recording, sig_key, sig_key_bound |
rollups | org_id, device_id, day, data, updated |
rules | id, org_id, kind, body, sensitivity, label, compliance, source, status, proposed_by, proposed, decided_by, decided, note, retire_requested_by |
feeds | org_id, version, issued_at, envelope, published_by, published |
events | id, org_id, actor, action, detail, ts, prev_hash, hash |
license_reports | org_id, data, ts |
license_keys | key_hash, org_id, created |
seat_daily | org_id, day, seats_in_use, devices |
audit_anchors | org_id, device_id, ts, seq, head |
dev_reports | org_id, device_id, ts, data |
webhooks | id, org_id, url, secret, events, label, created_by, created, enabled, last_status, last_ts, failures |
webhook_deliveries | id, org_id, webhook_id, event, ts, status, ms, error |
device_commands | id, org_id, device_id, cmd, created_by, created, delivered, done, ok, result |
device_nonces | org_id, device_id, nonce, expires |
user_links | id, org_id, user_id, purpose, token_hash, created, expires, used, created_by |
sso_configs | org_id, config, updated, updated_by |
scim_configs | org_id, config, updated, updated_by, last_sync |
scim_tokens | id, org_id, token_hash, created, created_by, last_used, revoked, revoked_by |
scim_groups | id, org_id, display_name, external_id, created, updated |
scim_group_members | org_id, group_id, user_id |
teams | id, org_id, name, description, source, created, created_by |
team_members | org_id, team_id, user_id, role, added |
org_policies | org_id, config, updated, updated_by |
change_requests | id, org_id, kind, summary, payload, status, proposed_by, proposed, reason, decided_by, decided, note, error, result |
activation_keys | id, org_id, key_hash, key_mac, kind, label, created, created_by, expires, revoked, redeemed_by, redeemed |
activations | id, org_id, key_id, kind, licence_id, instance_pub, fp, fp_source, label, platform, version, created, renewed, cert_expires, status, ended, ended_by, head_seq, head_hash, forks, usage |
api_keys | id, org_id, name, key_hash, perms, created, created_by, expires, last_used, revoked, revoked_by |
action_approvals | org_id, device_id, id, tool, rules, categories, environment, command, requested, expires, status, decided_by, decided, reason |
support_requests | id, org_id, subject, category, severity, status, opened_by, created, updated, plan, due_first, first_response, resolved, assignee, diagnostics |
support_messages | id, org_id, request_id, author, side, body, created |
verification_samples | org_id, device_id, id, ts, received, category, action, origin, sealed |
agent_sessions | org_id, device_id, session, client, agent, surface, model, first_ts, last_ts, turns, in_tokens, out_tokens, usd_micro, found, bytes, title_sealed |
agent_session_events | org_id, device_id, id, session, thread, seq, ts, received, client, agent, surface, route, model, in_tokens, out_tokens, usd_micro, found, ms, pre_ms, outcome, status, bytes, sealed |
provider_credentials | org_id, device_id, provider, rev, kind, hint, sealed, set_at, set_by, applied |
assurance_reports | id, org_id, ts, days, digest, issued_by, status, summary, key_id, document |
assurance_keys | id, org_id, public_key, private_key, created, created_by, retired, retired_by |
assurance_schedules | org_id, schedule, since, last_run, updated, updated_by |
reconcile_jobs | id, org_id, created, created_by, label, n, digests |
reconcile_answers | job_id, org_id, device_id, ts, matched, chain_ok, receipts_since |
custom_roles | org_id, slug, name, description, permissions, created, created_by, updated, updated_by |
Notes on the sensitive-looking columns: token_hash, pw_hash, key_hash are one-way digests (passwords: scrypt); three columns hold secrets the service must be able to use again: users.mfa_secret (the TOTP seed an authenticator needs), webhooks.secret (the key that signs your webhook deliveries) and the client secret inside sso_configs.config. On the hosted service they are encrypted at rest (AES-256-GCM, the purpose bound in, under a key held outside the database), so a dump or a backup holds only ciphertext; a self-hosted console does the same once VGUARD_DATA_KEY is set; rule body values in hosted mode are keyed digests whose key only your administrators and gateways hold — plaintext terms are refused.
Who can reach your organisation's data
- Your people, by role, with the access policy you set (single sign-on, MFA by role, session limits, IP allow list). Offboarding removes everything that acts for a person.
- Vendor staff (operators) see your plan, seats, licence and the same content-free usage figures as your dashboards, never per-person. Every operator view and action on your organisation is written to your audit trail as
vendor.*and sent to your webhooks. You decide whether operators may open usage detail without your time-boxed grant, and whether — and for whom — they may restore a locked-out administrator (Access policy → Vendor access). - Nobody can change what your gateways enforce without your organisation key: rule sets are signed on your administrator's machine and verified by every gateway.
Subprocessors of the hosted console
| Subprocessor | Purpose | Data |
|---|---|---|
| Contabo (Contabo Inc. / Contabo GmbH) | virtual server hosting the console's Kubernetes cluster (St. Louis, Missouri, United States) | everything listed above, at rest and in memory |
| Amazon Web Services (S3, us-east-1) | off-site copies of database backups | database backups encrypted to our offline key before upload: AWS cannot read them |
| Let's Encrypt (ISRG) | TLS certificates | host names only |
The AI providers you use (Anthropic, OpenAI) are your processors, not ours: your gateways talk to them directly, with tokens in place of your sensitive values. Self-hosted consoles have no subprocessor of ours.
Certifications and assessments — stated plainly
- SOC 2: no report yet. ISO 27001: not certified.
- Third-party penetration test: not yet performed.
- What exists instead, and can be checked by you:
vguard prove(your policy, fresh canaries, verdict from the bytes the provider would receive), the adversarial wire probe, the end-to-end isolation test run against the live service on every release (row-level security, grants, zero knowledge), the tamper-evident audit chain, and control mappings to PCI DSS v4.0.1, GDPR and the EU AI Act (mappings, not certifications).
Reliability
Protection does not depend on this service. The console runs two application replicas on one cluster with one PostgreSQL instance; backups every six hours are restore-tested, encrypted to an offline key and copied off-site (S3, 30-day deletion lock). Business and Enterprise have a 99.5% monthly SLA for the hosted console (SLA). Availability is measured from outside our hosting network by health checkers in several AWS regions every 30 seconds; live status is at /status. Recovery targets: data loss of at most six hours of console data (the backup interval; gateways keep their own audit logs and resend telemetry), and service restored within four hours from an off-site backup (a target; every backup is restore-tested, a full rebuild on a new node has not been rehearsed yet). Support response targets: Support Policy.
Reporting a vulnerability
Use the contact in /.well-known/security.txt on this service. Please give us 90 days before public disclosure; we credit reporters who want it.