Varketa Privacy Policy

Last updated 24 September 2026

This policy describes what personal data the Varketa platform holds, why it holds it, who else it reaches, and how long it is kept. It describes how the platform actually behaves. Where something is not yet built or not yet decided, this policy says so rather than describing an intention as though it were a practice.

1. What Varketa is, and whose data this is about

Varketa is a multi-tenant platform for governed AI agents. A company adopts Varketa as a tenant, connects its own systems, and its people then ask Varketa to carry out work. What the agent did and what it touched is recorded, so an answer can be read back to the actions that produced it.

Two different relationships follow from that, and they matter for this policy:

Data belonging to an adopting company. Each company that adopts Varketa owns the data it brings to the platform and decides what happens to it: what enters, how long it is kept, who it is shared with, and when it is deleted or exported. Varketa processes that data on the company's behalf and under its instructions, and Varketa's responsibility is to provide the means for those decisions. Where a means is not built yet, section 9 says so and says what happens instead. If you are an employee, customer or contact of such a company, that company — not Varketa — determines why your data is there, and its own privacy notice governs that decision, except for the data listed next.
Data Varketa holds in its own right. Account identifiers, sign-in records and sessions, invitations, records of who at Varketa has operator access, request logs, the paying relationship with each adopting company, and messages sent to Varketa directly are held by Varketa in order to run the platform.

2. What the platform holds

Every table in the platform's database declares, in the schema itself, whether it holds personal information and which column identifies the person it is about. That declaration has exactly five categories for personal data — identity, contact, credential, activity and commercial — and the five headings below are those, in that vocabulary, so this section reflects what the system is actually built to store rather than a grouping chosen for the page.

Two things follow from describing it this way. The categories are meant to be complete for the database, so a kind of personal data the platform stores there should be findable here rather than discovered later. Request logs are held outside it, in Google Cloud's logging service; section 9 says what they contain and how long they are kept. And a record only exists where the feature that creates it is actually used — a tenant that sends no messages accumulates no message records, and a deployment that has not enabled a capability holds nothing for it.

Identity — who someone is: The account identifier your identity provider issues for you, as the pair (issuer, subject), together with the directory claim used to decide whether your account is admitted to a tenant. See section 3, which is specific about what this does and does not include.
This category also holds your standing in a tenant: that you are a member, the role you hold, what you are permitted to do there, and how you obtained that access — including whether it came from an invitation or from platform support access, which is recorded together with the reason given for it and the second person who approved it. Where the platform has recorded your handle at an identity provider, it keeps that handle together with the provider it came from, because the same spelling can exist at two providers and belong to different people.
And it holds who at Varketa has operator access and what that access permits. That is personal data about Varketa's own people rather than a customer's, and it is listed because the question this inventory answers is what the platform holds, not whose data it is.
Contact — how to reach someone: Email addresses on invitations, held as a delivery address so the invitation can be sent. An invitation that is never redeemed is personal data about somebody who may never become a user, and the platform treats it as such. Also the address and channel recorded for a tenant's security contact.
Where a tenant has the platform send messages on its behalf, this also covers the record of what was sent and to whom, any reply received and the address it came from, and the record of consent relied on for contacting someone.
Credential — authenticators: Browser session records, which hold the tenant, the session and grant identifiers, when the session was last seen and when it expires; and the access and refresh tokens issued when you connect a third-party account (section 5).
It also covers two things a reader would not otherwise expect here. Where the platform issues a credential of its own, it keeps a record of that credential — its kind and identifier, when it was created, when it expires, whether it has been revoked, when it was last used, and the scope it carries — rather than only the secret itself. And each connected account is stored with the account identifier the provider gave it, which for some providers is an email address.
Activity — what someone did: Records of actions taken through the platform: changes proposed and who staged them, approvals, deliveries, and metered usage. These are the records that let an action be audited afterwards, and this is the largest category of personal data the platform holds.
Your conversations are part of it, which is worth stating plainly because a reader would not look for them under this heading: what you ask the platform to do, and the material your requests draw on from systems your tenant has connected. It also includes what the platform generates in reply — an agent's answer, and any clarifying question it asks before running — retained as part of the conversation and marked as model-authored. Generated text can repeat personal information that was in the request or in the material it drew on, so it is held to the same standard as what you supplied. Section 4 covers where this content goes.
Conversations are not the only place content is kept. Where a deployment lets a tenant author its own skills, the stored skill is retained with its title, description and prompt; and where a run produces a result, that result is retained as the bytes the run produced. Either can contain personal information if what went into it did.
Commercial: The paying relationship with an adopting company.

3. Signing in

Signing in goes through an identity provider rather than a password held by Varketa. Varketa's own service uses Google; a tenant may be configured to admit a different provider, in which case you sign in there instead. At Google's consent screen you are asked to release the openid, email and profile scopes.

What the platform records from that is narrower than what the consent screen asks for. Varketa records the account identifier your provider issues (issuer and subject) and the directory claim that decides admission. It does not store your email address, your name or your profile picture as your identity.

Identity is deliberately never keyed on an email address: an email address can change hands, and resolving an account by one would let a directory that asserts an address take over an account that is not its own.

An email address you were invited with is held separately, as a delivery address for that invitation (section 2), and is not joined to your identity.

4. Where your content goes

To answer a request, Varketa sends the content of that request — the instruction and the material needed to act on it — to a third-party model provider, which generates the response. Varketa currently uses Anthropic for this. Varketa uses Anthropic's API under Anthropic's Commercial Terms, which do not permit Anthropic to train models on customer content from those services. Which model provider a deployment uses is a configuration choice recorded as an explicit, auditable act, so it can differ between deployments and can change; this policy will name the provider in use.

That material can include data from an account your tenant has connected — for example, calendar details an agent needs to find a free time — when an agent needs it to carry out what you or your company asked. This is the most significant way your content leaves Varketa's own infrastructure, which is why it is stated before the general list of recipients below.

5. Connected accounts

A tenant can connect third-party accounts so the platform can act in them. Which providers can be connected is part of how a deployment is configured. A connection is made only when someone authorises it at that provider's own consent screen, and it grants only the permissions shown there. Where the platform sends mail or acts in a calendar, it does so with the access that authorisation granted.

Google Workspace: Calendar and email permissions, described scope by scope in section 6.
Microsoft 365: A Microsoft 365 connection asks for the permissions Calendars.ReadBasic and Calendars.ReadWrite (to read your calendars and to create and change events), Mail.ReadWrite (to read and change mail in your mailbox), Mail.Send (to send mail as you), and offline_access (so the connection keeps working when you are not signed in). Microsoft shows each of these at its consent screen before you grant it.

Disconnecting an account in Varketa and revoking Varketa's access at the provider are two different things. Disconnecting is handled per account rather than for the whole tenant. Disconnecting stops Varketa starting any new work with that account's credential, apart from the revocation request described next; work already under way may finish, and the stored copy is deleted at a later scheduled clean-up. Deleted storage stays recoverable for seven days after that, and is then gone.

Google: when you disconnect, Varketa also asks Google to revoke Varketa's access. That request is made on a best-effort basis — if it does not go through, Varketa does not retry it, and Varketa's access remains authorised at Google until you remove it yourself. A revocation at Google ends every authorisation your Google account has given to the Google Cloud project behind Varketa's Google Workspace connection, so it can end more than the one connection you disconnected. To be sure access has ended, check Third-party apps with account access in your Google Account settings.

Microsoft: Microsoft does not offer a way for an app to revoke the access you gave it, so disconnecting in Varketa does not end that access at Microsoft. To withdraw it, remove Varketa's access in your Microsoft account or organisation settings.

6. Google user data

Varketa's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

What Varketa accesses

Signing in with Google uses the openid, email and profile scopes. Varketa uses what they release only to identify you and to decide whether your account is admitted to a tenant, and records only what section 3 describes.
Connecting Google Workspace, when your company uses it, can ask for at most the three permissions below. Google shows each one at its consent screen before you grant it.
- calendar.readonly lets Varketa see your calendars. Varketa uses it to find when you are available.
- calendar.events lets Varketa view and edit events on your calendars. Varketa uses it to create, change and cancel events you or your company ask it to handle, including adding a meeting link.
- gmail.send lets Varketa send email as you. Varketa uses it only to send messages you or your company ask it to send. This permission cannot read your mailbox, and Varketa's Google Workspace connection asks for no permission that can.

How Varketa uses it

Varketa uses Google user data only to provide the features your company uses Varketa for, carrying out what you or your company ask it to — for example, finding a free time, creating an event or sending a message.

What Varketa records from signing in with Google is only what section 3 describes — the account identifier and the claim that decides admission — and Varketa holds that in its own right (section 1). What Varketa retrieves through a Google Workspace connection is kept only as part of the records section 2 describes, such as a conversation that drew on your calendar or a record that a message was sent. Those records belong to your company and follow its retention (section 9).

Who it is shared with

Varketa shares Google user data only:

with its model provider (section 4), when an agent needs the data to carry out a request from you or your company, under terms that do not permit the provider to train models on it;
with Google Cloud, which hosts the platform (section 7);
where necessary for security, such as investigating abuse, or to comply with the law; and
as part of a merger, acquisition or sale of assets, only with your prior consent.

Varketa does not sell Google user data. It does not use it for advertising, to determine creditworthiness, or to develop, improve or train generalised artificial-intelligence or machine-learning models.

Who can read it

Varketa staff do not read your Google user data unless you have agreed to it for a specific purpose, it is necessary for security (such as investigating abuse), or the law requires it.

New uses

Varketa will not use Google user data in a way this policy does not describe until it has updated this policy and asked for your consent to the new use.

7. Who else your data reaches

Google Cloud — hosting, storage and databases. The platform runs in Google Cloud's us-central1 region.
Anthropic — model inference, as described in section 4.
Your identity provider — Google on Varketa's own service, or whichever provider your tenant is configured to admit.
Any provider your tenant connects — Google or Microsoft, as described in sections 5 and 6.
Whoever serves this page. Reading a web page sends a request to the host serving it, so that host sees the request. This page is served from Google Cloud, already listed above.

Varketa does not serve advertising, and does not share personal data with advertising networks or data brokers.

8. Cookies and tracking

Every cookie the platform sets is necessary for signing you in, for keeping you signed in, or for connecting a third-party account. None is used for analytics, advertising or profiling, and Varketa sets no third-party cookie of its own.

__Host-varketa-session identifies your signed-in session. It lasts as long as the session record it names, and no longer.
__Host-varketa-login-binding, __Host-varketa-login-pending and __Host-varketa-login-invite carry a sign-in across the round trip to your identity provider — binding the request to your browser so someone else cannot complete it, and remembering an invitation you followed. They expire after ten minutes, and a sign-in that completes clears them sooner.
__Host-varketa-oauth-binding does the same for connecting a third-party account, and is cleared on every outcome so it cannot be replayed.

All of them carry the __Host- prefix, which makes the browser refuse the cookie unless it is sent over HTTPS and bound to exactly one hostname, so no other host can set or read one. All are HttpOnly, meaning page scripts cannot read them.

The platform's pages load no third-party scripts, fonts or stylesheets, and it runs no analytics or tracking service. The only script the console loads is its own, from the same origin. This policy and Varketa's home page run no script at all and set no cookie.

There is one exception, and it is a deployment's own choice rather than something Varketa adds: a tenant may configure a logo hosted elsewhere, in which case your browser requests that image from the host the tenant chose, and that host can see the request and may set or receive its own cookies. Varketa sends no referrer with it. Varketa's own service does not use such a logo, and makes no such request.

9. How long data is kept, deleting it and exporting it

A company cannot yet set, from Varketa itself, how long its data is kept, and cannot yet delete or export its data itself. This section says so rather than implying otherwise.

Until those facilities exist, Varketa staff delete or export a company's data on that company's written instruction. Varketa does not promise a timeframe for this.

What is settled today:

Sessions carry an expiry and cease to be valid when it passes.
Request logs — which include your IP address, your browser's user agent, the address requested and the time — are kept in Google Cloud's logging service for 30 days.
Records of actions taken through the platform exist to make those actions auditable, so they are expected to outlive an individual account. Where such a record must survive, the intended approach is to remove the identification of the person from it rather than to destroy the record.
If your data is on Varketa because a company put it there, other than data section 1 lists as held in Varketa's own right, ask that company. It decides what happens to that data, and Varketa acts on the company's instruction rather than on requests made directly to Varketa about a company's data.
For data Varketa holds in its own right (section 1), write to the address in section 12. Varketa does not promise a timeframe for such a request.

10. How the platform protects data

The following are properties of how the platform is built:

Traffic to the platform is served over HTTPS.
Each tenant's data is separated in the database, and that separation is enforced by the database rather than left to application code to remember.
Session cookies are host-bound, as described in section 8.
Credentials for connected accounts are encrypted before they are stored — each with its own key, which is itself encrypted under a key held for that deployment — and are kept outside the database. The platform's own secrets are held in a managed secret store rather than in the application's configuration.
No third-party scripts run on the platform's pages; section 8 states the one third-party request a deployment can configure.

Varketa holds no security certification and this policy claims none. No statement here should be read as an audited assurance.

11. Children

Varketa is a platform sold to and used by companies. It is not directed at children and is not intended for use by them.

12. Contact

Questions about this policy, or requests concerning data Varketa holds in its own right, can be sent to privacy@varketa.ai.

This policy is published by Varketa, which is responsible for the data it holds in its own right.

13. Changes to this policy

When this policy changes, the date at the top of the page changes with it. Where a change materially affects what is collected or who it reaches, Varketa will say so rather than relying on the date alone. A new use of Google user data also needs your consent first (section 6).