Vaultless Guard: frequently asked questions

Vaultless Guard is a privacy gateway for AI coding agents. It runs on each developer's machine, between the AI tool and the model provider. Before a request leaves the machine, it replaces the sensitive values in it with tokens. When the answer comes back, it puts the real values back, on the same machine. Your developers keep using Claude Code and Codex the way they do today, and the provider only ever sees tokens.

This page is written for security teams, IT administrators and engineering leaders. Every claim here can be traced to the product documentation or code; where a figure has not been measured yet, the page says pending.

What it is and how it works

What problem does it solve?

AI agents now read real files, run real commands and see real output: configuration, database rows, customer tickets, secrets printed by kubectl or terraform. Everything they see becomes part of the prompt, and the prompt is sent to a model provider. A contract with the provider limits what they may do with that data. It does not stop the data being sent. Vaultless Guard decides what is sent in the first place.

How does a request flow?

 developer's machine (trust boundary)                                 model provider
 ┌───────────────────────────────────────────────────────────┐
 │ Claude Code / Codex ──► vguard gateway (127.0.0.1:8788)    │
 │                          1 detect sensitive values          │
 │                          2 tokenize / withhold / refuse     │──► tokens only ──► Anthropic / OpenAI
 │                          3 check tool calls (guardrails)    │◄── answer with tokens
 │ Claude Code / Codex ◄──  4 restore real values locally      │
 │                          5 write a content-free audit line  │
 └───────────────────────────────────────────────────────────┘
          optional: counts only ──► your console (self-hosted or our SaaS)

1. The AI tool is pointed at the local gateway (one command: vguard clients configure claude or vguard clients configure codex, reversible with --rollback).
2. The gateway inspects every text field of the request: your prompt, files and command output the agent read, tool calls and their results, IDE context.
3. Personal data, internal identifiers and credentials become self-contained, authenticated tokens such as [VG1:1a2b3c4d:…]. Credential files and the output of secret-reading commands are tokenized or withheld; content it cannot inspect is refused rather than forwarded.
4. The provider answers using the tokens. On the way back, the gateway restores the real values for your screen and for the agent's own tool calls on your machine, but never into a URL, a link or an HTML attribute.

What does "vaultless" mean?

There is no database that maps tokens to values, anywhere. Each token carries its own value, encrypted with AES-SIV under a key that stays on the machine, and bound to the conversation it was issued in. Recovering a value needs the key file and the authenticated conversation scope. There is no central vault to breach, and nothing for us, the vendor, to hold (details in the security review pack).

Do my developers have to change how they work?

No. They keep their own sign-in (claude.ai or ChatGPT) or an API key, their editor and their commands. Answers, commands and files come back with the real values in them, so the work is correct. Images are sent by default since 0.8.0; optional local OCR can black out sensitive words in screenshots first.

What else does it do besides hiding data?

It enforces action guardrails: a hard wall on what the agent may run, checked on the response before the tool call reaches your machine. Nine built-in packs cover destructive file, Kubernetes, infrastructure-as-code, cloud, database, git-history and host commands, secret exfiltration, and reads of credential stores (SSH keys, cloud credentials, browser passwords). See the security review pack.

Supported AI tools, models and providers

Which provider APIs does the gateway speak?

A credential never crosses providers: a Claude credential on the Codex route, or a ChatGPT one on the Anthropic route, is refused before anything is sent.

Which models?

Whatever your provider serves on those APIs. Since 0.32.0 you can allow or deny models per gateway, by MDM and for the whole organisation from the console, and set daily or monthly token and dollar budgets. A refused model or a spent budget is answered with HTTP 403 before anything is sent, with a message naming the model or the cap. The console's Usage & spend page shows estimated cost by model, team, person and gateway. The gateway does not route between models or providers.

Which AI clients are supported, and which were verified live?

Which operating systems?

macOS (Apple Silicon) is where the gateway is developed and verified daily. Linux runs natively and in the provided container image (non-root, read-only filesystem), and CI tests on Ubuntu. Windows: preview, not generally available. File permissions, locks and a login service are ported and a Windows CI job runs on every push; WSL2 works today.

Core functionality

What does it detect?

Credentials (cloud keys, tokens, private keys, passwords, connection strings, dozens of vendor key formats), payment cards (Luhn-checked) and card verification data, personal data (names, emails, phones, addresses, dates of birth, government and health identifiers), network identifiers, and your organisation's own terms and identifier formats. Detection combines patterns, checksums, dictionaries, table-column awareness and an English named-entity model, all running locally.

What happens to each kind of value?

• Tokenized (reversible): personal data, internal identifiers and, by default, credentials. The agent can still pass a token to its next command, where it is restored locally.
• Withheld: things that should not leave at all under your policy, such as oversized secret dumps; the model is told the content exists and stayed on the machine.
• Refused: content the gateway cannot inspect safely (for example PDFs, provider file ids, most provider-side tools), unless your policy strips it instead.
• Card verification data can never be made reversible, by schema.

Can we teach it our own sensitive data?

Yes, three ways, none of which sends the data to us:

• Central rules in the console: client names, project codenames, identifier formats. A second person approves each rule (four-eyes), and it is signed with your organisation's own key before gateways accept it.
• Signed sensitivity feeds you host yourself: formats, field names, and hashed exact values.
• The environment profiler (vguard profile scan) learns field names and identifier formats from your dev, QA or staging data and publishes them as a signed feed. Its report holds statistics and synthetic examples only.

What does the console give an organisation?

A fleet view (who is protected and who has bypassed the gateway), what was kept from AI providers by data class and regulation, guardrail hits, an AI posture view (AI clients, MCP servers with hygiene flags, local model runtimes), a live control mapping, people and roles, an audit trail, signed webhooks and CSV exports. It runs as our hosted service or on your own infrastructure; it is the same program.

Security and privacy

What leaves the developer's machine?

• To the AI provider: the request after protection, which means tokens in place of every value the gateway recognised.
• To your console, if you link one: daily counts per data class, rule label and model, latency percentiles, versions, a policy fingerprint, and posture counts. The telemetry schema is closed and has no free-text field; it is validated on the gateway before sending and again on the server. vguard org telemetry prints exactly what would be sent.
• Nothing else. The gateway never needs a console to protect anything.

What can the vendor's SaaS see, and what can it not?

It sees your organisation's name, your people's email addresses, and the content-free counts above. It cannot see prompts, files, command output, protected values, tokens or keys. Your central rules reach it only as shapes or keyed digests; your organisation's salt and signing key never reach it. The database isolates each tenant with PostgreSQL row-level security, and an in-cluster test checks that no plaintext protected value or organisation salt exists anywhere in the database (details in the security review pack).

Where are the keys?

On each machine, under ~/.vguard/keys, readable only by the user (the loader refuses looser permissions). Keys are generated from the operating system's random source, never from a password. Backups are encrypted (scrypt and AES-256-GCM). Since 0.34.0 the key ring can be wrapped under a key held by the macOS keychain, the Linux desktop keyring, AWS KMS, Google Cloud KMS or your own program (HashiCorp Vault, an HSM's tool): a copied key file then opens nothing, and with KMS every unwrap is a logged call you can cut off centrally. IT can make this mandatory by MDM (keyProtection). The audit log's signing key is still a 0600 file.

What if the gateway misses something?

It will miss some formats nobody taught it, paraphrased identities and deliberately disguised values. We publish where (the security review pack, the security review pack). You can measure your own position at any time: vguard prove sends fresh random test values through every channel an agent uses, with your policy and your rules, and reports exactly what the provider would have received. Every gateway also re-runs a self-test daily and the console shows the result per machine.

What if the gateway is down or broken?

It fails closed. A client pointed at a gateway that is down gets errors, not an unprotected path, and a gateway that cannot write its audit log refuses requests. vguard health explains the cause in plain words, and --rollback returns a client to direct access if you decide to.

Is it a sandbox?

No. It protects the traffic that goes through it. An agent's shell can still reach the network directly unless you restrict egress; the isolated-agent pattern (deploy/isolated-agent) shows how to make the gateway the only path out.

Compliance and regulated environments

What evidence does it produce?

• vguard evidence export: a zip for auditors with the policy, what the provider receives per data class, counts, the hash-chained audit log and its verification, the rules in force, the latest proof run and a control mapping, with a manifest hash.
• A tamper-evident local audit log (HMAC chain), anchored at the console so a rollback is detected (vguard audit verify --control).
• OCSF 1.3 export of the content-free audit events to your own SIEM (Splunk HEC or NDJSON). The events go only where you point them; we never receive them.
• A live controls-and-frameworks table in the console.

Which frameworks is it mapped to?

The console maps each control to OWASP LLM Top 10 2025, NIST AI RMF, SOC 2, ISO 27001, HIPAA, GDPR and PCI DSS. This is evidence that supports your own assessment, not a certification. Nothing in the product has been assessed by an auditor, QSA or regulator.

Is Vaultless Guard SOC 2 certified?

No. We have not yet attained a SOC 2 report or published a penetration-test report. A SOC 2 readiness plan is planned, not started. Terms of Service, a Privacy Policy and a Data Processing Agreement are being prepared with counsel and are not yet published.

Does it help with GDPR?

Tokens are pseudonyms under a key held separately from the transcript, which is pseudonymisation (GDPR Art. 4(5)), not anonymisation. The hosted service holds no personal data from AI traffic. Offboarding erases every row the service holds for a tenant. Your provider's own retention terms still apply to what it receives.

Are there presets for HIPAA, PCI DSS or GDPR?

Yes: hipaa (AI provider without a BAA: identifiers removed irreversibly), hipaa_baa (provider under a BAA: identifiers as reversible tokens), pci_dss and gdpr. Each is a floor: it only ever raises a setting, never lowers one, so it is safe to turn on for a whole fleet, from the policy file, an MDM profile or the console's Gateway floor (applied without restarting gateways). Each states what it supports and what remains yours (the BAA, a lawful basis, a QSA assessment). See the security review pack.

Can a risky command wait for approval instead of being blocked?

Yes. A guardrail can give a command a different action per environment (allowed in dev, held for approval in production, blocked where the gateway cannot tell). A held command does not run; an approver releases it in the console (never the person whose agent asked) or, where your policy allows it, the user does with vguard guardrails approve. The agent then re-issues the identical command and it runs once. The hosted console is not sent the command text unless you choose to. See the security review pack, "Scopes and approvals".

Deployment and IT management

How is it installed?

On a developer's machine: an install script or a Python package (uv), then vguard init, vguard up and one vguard clients configure per tool. For a fleet, the console creates enrolment bundles; the bundle carries your organisation's salt and is distributed through your own channels (MDM or a password manager), never through our service. A container image is provided for servers.

Can we push it with Jamf, Intune or Kandji, silently, with settings users cannot change?

Yes, from 0.14.0. The organisation pushes a managed policy through the operating system's own managed locations, which only an administrator or the MDM agent can write: a configuration profile on macOS (domain io.vaultless-guard.gateway), the HKLM\SOFTWARE\Policies\VaultlessGuard key on Windows, or a root-owned /etc/vguard/managed.json on Linux. It can lock modules (for example guardrails on), fix the guardrail mode, list the AI clients to route, and carry the enrolment bundle.

• The gateway forces the managed values in every time it starts, so editing the local policy file does not switch a managed control off; vguard modules set refuses and names your support contact.
• vguard managed apply, run by the MDM as the signed-in user, joins the organisation and routes the listed clients; it is idempotent, so it can run on a schedule.
• vguard managed profile settings.json --platform macos|windows|linux produces the artefact to upload to Jamf, Kandji, Intune or Workspace ONE; vguard managed status shows drift.
• Environment variables are deliberately not a source: a setting a user can override by exporting a variable is not managed.

See the security review pack.

Can we host the console ourselves, or run air-gapped?

Yes. The console runs on your own Linux host, VM or Kubernetes cluster in self_hosted mode, where it may also hold your rule catalogue in plaintext because it never leaves you. Enterprise licences can be long-lived and verified offline; feeds can be delivered by file for air-gapped sites. The gateway itself never needs the internet except to reach your chosen AI provider.

Does it work behind proxies, VPNs and TLS inspection?

Yes. The gateway only dials out. It supports an explicit proxy and a custom CA bundle, keeps one outbound HTTPS long-poll for console commands (no inbound port), and vguard org doctor walks DNS, TCP, TLS, HTTP, authentication, clock and channel to name the failing layer.

Identity and access

Does the console support single sign-on?

Yes, since 0.13.0: OpenID Connect with Microsoft Entra ID, Okta, Google Workspace, Auth0, Keycloak or any OIDC provider. Authorization code flow with PKCE, a nonce and one-time state; the ID token is verified in-house; email domains are allow-listed. "Require SSO" keeps owners and admins on passwords as break-glass access. SAML is not supported (most providers offer OIDC alongside it). See the security review pack.

What about provisioning and deprovisioning (SCIM)?

Yes, since 0.14.0: SCIM 2.0 (users and groups) for Entra ID, Okta and other identity providers. An administrator generates a per-organisation token in Settings (shown once, stored only as a digest, rotatable), pastes the SCIM URL and token into the provider, and maps provider groups to console roles. Offboarding (active: false or delete) disables the account and ends all its sessions at once; nothing is hard-deleted, so the audit history stays. SCIM never creates or grants an owner, grants admin only if you opt in, and refuses a change that would leave nobody able to manage people. Tested on PostgreSQL with row-level security; a run against a real Entra ID or Okta tenant is pending. Offboarding (from the console, SCIM or the dormant-account sweep) also revokes the gateways registered to that person, unless the access policy turns that off. See the security review pack.

How are console sessions protected?

Sessions last twelve hours and end after two hours idle, are bound to one plane, and can be listed and revoked. TOTP multi-factor authentication works with any authenticator app; once enrolled, a credential alone no longer opens a session. Roles separate duties (owner, admin, approver, analyst, auditor, viewer).

Performance

How much latency does it add?

The gateway runs in-process on the developer's machine; there is no network hop to a separate decision service. vguard health and the local dashboard already split each turn's time into the model's share and the gateway's share (p50 and p95), so a slow model is not blamed on the gateway. Since 0.14.0 every turn records pre_ms: everything the gateway did before the request left the machine (authentication, parsing, inspection, tokenization, re-serialisation).

Latest (v0.32.0, 2026-10-05): 179 live Claude Code turns of one long VS Code session, from the gateway's own audit log (pre_ms): p50 195 ms, p95 656 ms, median 2.3 % of the turn. Earlier measurement, kept for comparison:

Measured live on 2026-09-25, on a long multi-agent Claude Code session in VS Code (one lead agent and two sub-agents in parallel, conversations of 1,986 to 6,157 fields, median 3,656), macOS on Apple Silicon, the security review pack:

The last row is a design choice: an upgrade must never answer with an old detector's result. It is paid once per conversation, then turns are back to the steady state.

Earlier lab measurements are recorded with their conditions in the security review pack and the security review pack. They were taken in-process against a mock provider and are not a substitute for the live figures above.

Does it break prompt caching?

No, by design. Tokens are deterministic within a conversation, so replayed history is byte-identical from turn to turn, and repeated history is served from a local cache instead of being inspected again.

Pricing and plans

The gateway is free on every plan, and protection is never behind the paywall: detection, tokenization, the local audit log, local rules and proof runs work the same in every licence state. A subscription buys the organisation layer: the console, central rules with approval, analytics and console evidence. A seat is a person active in the last 30 days, not a device.

Full price list and discounts: /pricing. If you stop paying, protection continues unchanged; only management conveniences pause.

Limits and honest non-goals

• Detection does not find every sensitive meaning: paraphrased identities, secrets split across sentences and deliberately disguised values can pass. Named-entity detection is English-only; pattern detectors run on every language.
• Routing is a strong default, not a sandbox. Without network egress restrictions, an agent's shell can reach the internet directly.
• A token restored into a command that reaches the network (for example curl -d) is sent in clear by that command, which is also how an agent legitimately uses a credential. With a prompt injection in view, tool calls to non-local hosts keep their tokens.
• The regular ChatGPT chat, web AI apps in a browser, and AI tools without a configurable endpoint cannot be routed.
• Not built, by decision: a browser extension, brokering of MCP server credentials, and a hosted "purpose" judge (it would send your prompt to another cloud). A local judge that only sees tokenized text is on the roadmap.
• No SOC 2 report yet, no SAML, no native HSM integration (an HSM is reachable through the key-protection command hook), and Windows is not yet released.

Getting started

1. Start a trial at /signup (a sign-up code from us is required): a 30-day Business trial with the hosted console.
2. Install a gateway on one machine and run vguard init, vguard up and vguard doctor.
3. Route a tool: vguard clients configure claude --apply or vguard clients configure codex --apply. Undo any time with --rollback.
4. Prove it: vguard prove shows what the provider would receive with your policy.
5. Link the console from Fleet, add your own rules, and invite your team.

Questions this page does not answer: ask us, and we will add them here.

How do the portals handle slow requests or malformed authentication input?

Each portal view owns its displayed content and actions, so delayed responses from another view cannot replace it. Browser Back and Forward work between views. Malformed authentication codes fail verification; invalid or oversized Content-Length headers are rejected before the body is read, and streamed request bodies remain independently size limited. These checks do not change what data is allowed to reach a model provider.