Privacy Policy

Effective 18 August 2026 · Last updated 18 August 2026

AIgentVault runs AI agents over the systems a firm already uses — email, documents, practice management. That means we handle material that is often confidential and sometimes privileged. This policy sets out exactly what we collect, why, where it goes, and how long we keep it.

This policy covers the AIgentVault application, this website, and the connected-service integrations offered through the product. It is written for the people who sign the contract as much as for the people who use the product, so it names specifics rather than categories.

1. Who we are

AIgentVault is the operator of the service described in this policy. References to “we”, “us” and “AIgentVault” mean the operator of aigentvault.com. The fastest way to reach us about anything in this policy is contact@aigentvault.com.

For personal data belonging to a customer’s own clients and staff that flows through the product, the customer is the data controller and we are a data processor, acting on their documented instructions. For account data about the customer themselves, we are the controller.

Where we provide consulting services — building and operating agents for an organisation under a signed agreement — personal data we handle in that work is processed on that organisation’s instructions, and this policy applies alongside the signed agreement and any data-processing terms in it; the signed agreement prevails where they differ.

2. What we collect

Account data

Your email address, display name, workspace membership, authentication state, and — if you enable two-factor authentication — a TOTP secret and single-use recovery codes. Sign-in is by emailed code, Google, or Microsoft; we never store a password.

Subscription and billing data

If you subscribe, we keep your plan, subscription status and invoice history. Card payments are collected by a payment processor acting as our subprocessor — your full card number never reaches our servers. The processor will be named in §6 when paid subscriptions launch.

Material your agents process

When you build a workflow that reads a mailbox, opens a document or calls a connected service, the content of that material passes through AIgentVault so an agent can act on it: email bodies and recipients, document text, file names, and whatever you write into a prompt. We handle this material to run the workflow you configured. We do not mine it, sell it, or use it to build products.

Credentials for connected services

OAuth refresh tokens and API keys for the services you connect. See §7 for how these are secured.

Files you share through the desktop app

The optional AIgentVault desktop app lets an agent read and write files on your own computer — but only inside folders you explicitly share in the app’s settings. With no shared folders, the agent has no file access at all. File content passes through the service only when a workflow you run uses it; sharing a folder does not upload it.

Voice sessions

If you use a voice chat session, your microphone audio is streamed to Google’s Gemini Live API for real-time processing and the model’s audio reply is streamed back. We do not keep audio recordings; a session’s transcript may appear in execution history, which follows the retention periods in §8.

Operational records

Execution history (the inputs and outputs of each workflow run), an audit log of consequential actions, and standard server logs including IP address and timestamps for security and debugging.

Site and browser storage

The application stores preferences in your browser’s local storage — active workspace, panel layout, view mode — and a session token so you stay signed in. We do not use advertising cookies or third-party tracking cookies.

3. Google user data

Because AIgentVault connects to Gmail, Google Drive and Google Docs, this section states in detail what we access from Google APIs and why. It governs over any more general statement elsewhere in this policy.

Scopes we request, and what each is for

You grant these at the Google consent screen, per connection, and can revoke them at any time from your Google Account permissions page or by deleting the credential inside AIgentVault. Revoking stops all future access immediately.

Limited Use

Concretely, that means:

• We use Google user data only to provide and improve the user-facing features that are visible in the AIgentVault interface — the triggers, nodes and agents you configured.
• We do not transfer Google user data to others except as necessary to provide those features, to comply with applicable law, or as part of a merger or acquisition after giving notice and obtaining consent.
• We never use Google user data for advertising, and we never sell it.
• We do not allow humans to read Google user data, unless you give explicit consent for specific messages, it is necessary for security purposes such as investigating abuse, it is required to comply with applicable law, or the data has been aggregated and anonymised for internal operations.

Google user data is not used to train, fine-tune or improve any machine-learning model. See §5.

4. How we use data

• To run what you built. Executing workflows, triggers, schedules and agents.
• To authenticate you and enforce workspace, ownership and role boundaries.
• To keep an audit trail of who did what, including refused attempts.
• To operate and secure the service — diagnosing failures, investigating abuse.
• To bill you — managing your subscription, renewals and invoices.
• To contact you about sign-in codes, support tickets and material service changes.

We do not profile you, make automated decisions with legal effect about you, or use your material for marketing.

5. AI models and training

Running an agent means sending prompt content — which may include email or document text — to a model provider. Depending on the model chosen in the workflow, that provider is Google (Gemini or Vertex AI) or Anthropic (Claude, via the direct API or Vertex AI).

We do not train models. AIgentVault builds no models of its own and performs no fine-tuning, so your material is never used to create or improve a model by us.

The model providers we offer do not train on your data. We use these providers' APIs under terms in which prompts and outputs are not used to train their models, and content is not retained beyond a limited abuse-monitoring window. This applies to every provider a workflow can select on the platform — Google, Anthropic, and, where enabled, OpenAI and xAI. If we ever add a provider whose terms differ, we will name it here and say so before it can be selected.

6. Where data goes and who processes it

Material is processed in three distinct places, and the difference matters:

Subprocessors always in the path

Subprocessors only if you connect them

Connecting an integration adds a subprocessor you chose, and your data then also travels under that provider’s own terms. Available integrations include Google Workspace, Microsoft 365, Clio, Filevine, Slack, Telegram, and a gallery of MCP connectors such as Asana, Atlassian, Canva, Figma, GitHub, HubSpot, Hugging Face, Intercom, Linear, Notion, PayPal, Sentry, Square, Stripe, Vercel, Zapier and monday.com. An MCP connector is scoped per tool: you can enable a subset of a server’s tools, and that subset is enforced for agents and for human-initiated calls alike.

AI applications you connect to AIgentVault

You can also connect an outside AI application — such as Claude Desktop — to your AIgentVault workspace, so that its assistant can use your workflows and data as tools. Each such connection is authorised by you on an explicit consent screen, is bound to the single workspace you choose, and can only do what your own role in that workspace allows. Data the connected application requests flows to that application and is then governed by its provider’s terms. You can see every connected application in Settings and disconnect one at any time, which cuts off its access immediately.

7. Security

• Workspace isolation. A workspace is a client. Workflows, credentials and files belong to exactly one, and cross-workspace access is refused at the point of use rather than hidden in the interface — an agent cannot reach another workspace’s credentials even if instructed to.
• Ownership within a workspace. A member sees only the workflows, execution history, generated files, skills, schedules and agent memory they created. Sharing is explicit and per item, and grants read access rather than control.
• Roles — viewer, editor, owner — with per-member adjustment. Credential management is owner-only, so one compromised editor account cannot substitute an API key.
• Two-factor authentication (TOTP), available on any account regardless of sign-in method, with single-use recovery codes.
• Encryption in transit: TLS to the application and to every subprocessor.
• Encryption at rest: Google Cloud encrypts all stored data by default. Third-party credentials are additionally encrypted by us with AES-256-GCM before storage, with the master key held in Google Secret Manager rather than on disk. Credential values are never returned to the browser after they are saved.
• Audit trail. Creation, modification and deletion; reads of customer material; permission changes; approvals; workflow execution; agent tool use attributed to the person the agent acted for; and refused attempts. Entries are append-only and hash-chained, so an altered or removed entry is detectable. The log never becomes a second copy of your material: configuration values are recorded in full, while free-text fields record only that they changed and by how much.

No system is perfectly secure, and we describe our current posture rather than promising invulnerability. Material weaknesses known to us are disclosed to customers on request.

8. How long we keep it

We keep each category of data only as long as it serves the purpose it was collected for, and the criteria differ by category. Execution history and generated files are working data — debugging aids and staging output — kept briefly and expired automatically on a configurable schedule. The audit log is compliance metadata (who did what, never document contents) and is kept substantially longer, because it is the record a later question about access is answered from. Account data is kept for the life of the account and deleted on closure; offboarding is described in §9.

Retention periods are configurable per deployment by an administrator, and where a customer requires specific contractual commitments, those are made in that customer's signed agreement. The currently configured periods for your deployment are available on request at contact@aigentvault.com.

9. Deletion and exit

You can delete individual credentials, workflows, files and workspaces at any time from within the product. Deleting a credential revokes our stored access to that service.

Each customer is deployed to a separate Google Cloud project and virtual machine, so offboarding is the deletion of that project — database, storage, secrets and machine together.

We retain nothing after offboarding — including the audit log. On exit you receive the complete audit log as an export; it is your access record, and you may keep it under your own retention rules. The export carries its integrity chain, so it remains independently verifiable as unaltered. The only thing we keep is a signed export receipt — a cryptographic fingerprint of the log, its entry count and the handover date, containing none of your data — which lets either party later prove that a produced copy of the log is the one that was handed over. Because the export contains identifiers such as file names and email recipients, it is transferred through an agreed secure channel.

10. Where data is stored

All processing and storage is currently in us-central1 (Iowa, USA). Model inference may be routed to Google’s global Vertex AI endpoint unless a specific region is configured for a workflow.

A customer requiring EU or UK residency can be accommodated, because each customer has their own project — but only if decided at provisioning. Moving a database between regions afterwards is a migration, not a setting.

We do not currently target customers requiring EEA or UK data residency. If we take on such a customer, the appropriate transfer mechanism (such as Standard Contractual Clauses) will be put in place as part of their agreement, and this policy updated to say so.

11. Your rights

Depending on where you live, you may have the right to access the personal data we hold about you, correct it, delete it, receive a portable copy, restrict or object to processing, and withdraw consent. Where we act as a processor for a customer, we will refer your request to that customer and support them in answering it.

Write to contact@aigentvault.com and we will respond within 30 days. If you are in the EEA or UK you may also complain to your local supervisory authority.

12. Children

AIgentVault is a business product, not intended for anyone under 16, and we do not knowingly collect their personal data.

13. Changes to this policy

We will update this page when our practices change and revise the “last updated” date above. If a change materially affects how we handle your data, we will notify account holders by email before it takes effect.

14. Contact

For any question, request or complaint about this policy or your data: contact@aigentvault.com.