Privacy Policy

1. Who this applies to

This policy covers the hosted agensis service at agensis.io — the web app, the backend that serves it, and the agent daemon when it connects to that backend.

agensis is also open source, published under the MIT licence. If you run your own copy, this policy does not describe your deployment: your database, your servers, your logs, your choice of AI provider. Section 9 covers what changes in that case.

2. What we collect

Account information

When you create an account with an email address and password, we store:

• your email address;
• a hash of your password (scrypt, with a random per-user salt) — never the password itself;
• optionally, a display name and an accent colour, if you set them;
• the date the account was created.

That is the whole of it. We do not ask for your real name, postal address, phone number, job title, company, or date of birth, and there is nowhere in the product to enter them.

If you sign in with Google or GitHub instead, that is handled through Netlify Identity. We receive the email address the provider asserts and use it to find or create your agensis account. We do not receive or store your Google or GitHub password.

Workspace content

Everything you and your agents create inside a workspace is stored in our database, as you wrote it:

• Messages in channels, threads and direct messages, including messages your agents write;
• Channels, threads and their titles;
• Documents, their version history, and comments on them;
• Tasks and task comments;
• Memory — the facts and notes your workspace and your agents keep;
• Files you upload, stored as the original bytes;
• Canvas objects and the layers and groups they sit in;
• Agent configuration — an agent's name, handle, character description, system prompt and instructions;
• Huddle transcripts. A voice huddle writes what was said into a conversation in the workspace, and separately records join/leave/speaking events;
• Activity events — an audit trail of what happened in the workspace, including a record of each call an agent made to an external provider (which provider, which operation, the resolved URL, the HTTP status and the duration — never a request body, a header or a credential).

Files mirrored from a connected machine

When you connect an agent daemon running on your own computer, that daemon pushes copies of certain local files into your workspace so the rest of the team — and other agents — can read them while your machine is offline. Specifically:

• Agent memory files: path, a summary, and the file's content;
• Agent skill documents: the skill name, its path on your machine, and the body of the skill file (stored up to 64 KiB; longer files are marked as truncated).

This is a real transfer of local file content into our database. It happens because you connected a daemon, and it is how a teammate can read your agent's skill without your laptop being on.

Connection metadata

A connected daemon reports, and we store:

• the hostname of the machine it runs on;
• the working directory path it was started in;
• its online/busy/offline status and the capabilities it advertises (which tools, models and skills it has available).

Usage metering

We record how much of each metered resource a workspace consumes, in a table called usage_events. A row holds: the workspace, the provider (anthropic, deepgram, cartesia, livekit or sandbox), the resource (a model name, a voice model, a room), which part of the product spent it, and counts of tokens, characters or seconds. There is no message content in a usage row, and no price — money is calculated at display time from a separate rate card.

Feedback reports

If you send in-app feedback, we receive your description, the page and elements you selected, and a diagnostics snapshot: the build id, your browser's user-agent string, the page URL, viewport size, language, the last few hundred console lines (each truncated) and the last few unhandled errors. Console text is passed through a secret-redactor on the way out.

The snapshot deliberately excludes localStorage, sessionStorage, cookies, form values and network request bodies — your session token lives in localStorage, and the surest way to keep it out of a bug report is never to read it.

IP addresses

Your IP address is used as a rate-limiting key — to slow down repeated sign-up attempts, failed sign-ins, browser security reports and device-authorisation requests. It is held in the server's memory for that purpose. We do not write it to the database as an IP address and it is not written to our application logs.

Link previews

When a URL is pasted into a message, our server fetches that URL to build the preview card — the reader's browser does not fetch it. The site you linked to therefore sees a request from our server's IP address, identifying itself as agensis-linkpreview/1.0, not from you or from anyone who reads the message. We cache the resulting title, description, site name and image URL.

3. What we do not collect

There is no analytics or tracking of any kind in agensis. We checked the shipped code for it. There is no Google Analytics, no PostHog, no Sentry, no Segment, Mixpanel, Plausible, Hotjar, FullStory or Datadog, no advertising pixel, and no session-recording tool. Nothing measures which buttons you press or how long you stay.

We set no cookies. Your sign-in session is an HMAC-signed token kept in your browser's localStorage, sent as an Authorization header. It expires after 14 days by default, and signing out or changing your password invalidates every outstanding token for your account.

We do not sell personal data, and we do not share it for advertising.

4. Where your data is stored

Uploaded files are subject to a 25 MB per-file limit and a per-workspace storage quota (2 GB by default). They are served back only to authenticated members of the workspace that owns them, and they are not copied to any object store or third party.

5. Third parties that receive data

Below is every external service that receives data from the hosted agensis service, what reaches it, and when. Each entry was verified against the source code rather than assumed.

DECISION NEEDED: a data processing agreement (DPA) with each of Neon, Fly.io, Netlify, Anthropic, Deepgram, Cartesia, LiveKit and ascii.dev, and a statement of whether each provider trains on the data it receives. Their retention and training practices are contractual and cannot be determined from our source code. This policy should not claim anything about them until those terms are checked.

Services that receive nothing

For the avoidance of doubt: there is no payment processor connected (see the Terms — billing is not yet implemented), no email provider, no SMS provider, no CRM, no error-tracking service and no analytics vendor.

6. Destinations you choose yourself

Several features send your data somewhere you nominated. We cannot list those destinations, because you pick them:

• Inference gateways. If you configure an OpenAI-compatible endpoint in Settings and select it for a conversation, the full system prompt and the full message history for that turn are sent to whatever host you pointed it at, with the API key you supplied. That host is your subprocessor, not ours.
• Flow webhooks. If you configure a webhook URL, events are POSTed to it — and for message events that payload includes the message content and sender fields, signed with an HMAC so the receiver can verify it came from us.
• Provider skills. An agent carrying a provider skill can call that provider's API through us. The destination comes from the skill definition, and the request body is whatever the agent wrote.
• MCP clients. agensis exposes an MCP server. Any MCP client you connect to it — and grant a workspace token — can read the workspace content that token permits.
• Link previews. Any URL pasted into a workspace is fetched by our server, as described above.

Requests to all of these are restricted to public HTTPS addresses. Internal and private network addresses are blocked, redirects are refused rather than followed, and an agent cannot supply a URL, host or header of its own — a fact we consider part of the privacy story rather than only a security one.

7. Credentials and the workspace vault

Every credential a workspace holds — model API keys, provider keys, webhook signing secrets, shared secrets — lives in the workspace vault. Three properties of it are worth stating plainly, because they are unusual:

• The vault is write-only. No route in the product returns a stored secret, in full or masked, to anyone — not to you, not to an admin, not to an agent. The route that lists your vault entries does not even ask the database for the secret columns; it asks only whether each entry is configured. There is nothing to redact, because nothing is read.
• Secrets are encrypted at rest with AES-256-GCM, using a key held by the application, not by the database.
• An agent can use a credential without ever seeing it. When an agent needs to call a provider, it names a skill and an operation — never a URL, a host or a header. Our server resolves the address from the skill definition, attaches the credential itself, makes the request, and hands the agent back only the response. The credential is never in the agent's context, so it cannot be repeated into a chat message, written to a file, or leaked by a prompt injection.

The trade-off is the honest one: if you lose a secret, we cannot give it back to you. You can only replace it.

8. Your own API keys, and agents on your machine

agensis is designed so that, if you want, your conversations need never reach our AI account.

Bring your own key

If you put your own Anthropic API key in your workspace vault, turns that run on our server use your key. The request still leaves from our server, so we are still transmitting the content — but the relationship with Anthropic, including their retention and any enterprise terms you hold, is yours. If you set no key, the turn uses our platform key and falls under our account with Anthropic instead.

Agents running on your own machine

An agent in daemon mode runs on your computer, not ours. For those agents:

• We assemble the conversation context and send it over our connection to your machine.
• Your machine calls the AI provider under your own credentials. The prompt goes to the model from your machine, not from our server. We never see that request and it is not billed to us.
• The agent's reply comes back to us and is stored in your workspace like any other message — that part is unchanged.
• The daemon can be given access to folders on your machine. Anything it reads from them may end up quoted in a message, and therefore in our database. That is a decision you make when you grant the folder.

9. Self-hosting

agensis is MIT-licensed and can be run entirely by you: your own Postgres, your own server, your own AI keys.

In that configuration, none of your data comes to us. There is no licence check, no telemetry, no usage reporting, no update ping. The app's version check reads a file from your own deployment's origin. Sections 4 and 5 of this policy describe our hosted service and simply do not apply — you become the operator, and you decide which third parties your deployment talks to.

Two outbound calls still happen from a self-hosted server, and both are to services that are not us:

• openpets.dev — a public catalogue file is fetched when the pet picker is opened. No user data is sent.
• Link previews — your server fetches URLs your users paste, exactly as described in section 2.

Everything else — Anthropic, Deepgram, Cartesia, LiveKit, sandbox providers — is off unless you configure a key for it.

10. Who can see your workspace

Inside your workspace

Workspace membership carries a role — owner, admin, editor, commenter or viewer — which controls what a member can change. You should understand that it does not narrow what a member can read:

Roles are inherited downward from a parent workspace to its children, never upward. Only manage — owner and admin — can add or remove members, write vault secrets, configure agent host folders, or delete the workspace.

By us, as the operator

There is exactly one cross-workspace surface in the product, reserved for the service operator. It exposes account records and aggregate counts only — email, display name, sign-up date, workspace names, and counts of messages, huddles, agents, documents and members. It cannot return message bodies or document text; those columns are not in the query. The operator can also send an in-app announcement to a segment of accounts.

Separately, and unavoidably, whoever operates the service holds the database credentials and access to the file volume. Message and document content is not encrypted at rest (vault secrets are), so an operator with infrastructure access could read it. We are telling you this because it is true of essentially every hosted product and is rarely said out loud. DECISION NEEDED: what internal policy governs operator access to customer content, who is permitted it, and whether such access is logged. This paragraph should describe a real control, not just an admission.

11. Retention and deletion

What deletion currently means

• Deleting a conversation or a message hides it; it does not erase it. The app marks the row with a deletion timestamp and stops showing it. The content stays in the database indefinitely.
• Deleting a workspace does remove its content from the database — sessions, messages, documents, tasks, agents, huddles, activity and file records all cascade away with it. However, the bytes of uploaded files are left on disk: only deleting a file individually removes the actual file. This is a known gap.
• There is no way to delete your account from within the product. No such button and no such API route exists. Removing an account today requires the service operator to run a database script by hand.

What expires automatically

Very little. Offline agent connection records are cleared after about two minutes; huddle presence rows are removed when a huddle ends; device-authorisation codes are purged after 24 hours; rate-limit rows are swept opportunistically. Everything else is kept indefinitely — messages, documents, memory, tasks, uploads, huddle events, usage rows, activity events, invitations and cached link previews all persist until something explicitly deletes them.

DECISION NEEDED — and this is the largest gap in this document:

• A retention period for workspace content, and for content in a deleted or dormant account.
• Whether to build self-service account deletion. A privacy policy that promises erasure while the product has no delete route would be a false statement, so either the feature or the promise has to change.
• Whether "delete" in the UI should become a real erasure, and after how long.
• Backup retention at Neon and Fly — how long a deleted row survives in backups.

12. Security

• Passwords are hashed with scrypt and a per-user random salt. A minimum length and character-class policy is enforced on the server.
• Sessions are HMAC-signed tokens with a 14-day default lifetime, revocable in bulk by signing out or changing your password.
• Sign-up and failed sign-ins are rate-limited by both email and IP address.
• Vault secrets are encrypted at rest with AES-256-GCM and are never returned by any route.
• All outbound requests made on your behalf are checked against private and internal network addresses, re-checked after DNS resolution, and refuse redirects rather than following them.
• Content written by agents or fetched from external providers is passed to a model inside an explicit untrusted-data fence, so it is treated as data rather than as instructions.
• User-generated rich text is sanitised at every render and paste boundary.
• The service sets X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a referrer policy, a permissions policy that allows the microphone only for the app's own pages and blocks camera and geolocation outright, and a Content-Security-Policy.

No system is perfectly secure, and we make no guarantee that ours is. DECISION NEEDED: a breach-notification commitment — who we tell, and within what period.

13. Your rights

DECISION NEEDED — this entire section depends on facts not present in the code. Which privacy regimes apply turns on where the operating entity is established and where its users are, and the answers determine what must be offered here: access, rectification, erasure, portability, restriction, objection, the lawful basis for each kind of processing, whether a Data Protection Officer or an EU/UK representative is required, and the mechanism relied on for transfers of personal data outside the UK/EEA to our providers.

Two things are true today regardless of which regime applies, and are stated here so the gap is visible rather than papered over:

• Access and portability — you can read everything in your workspace through the app, but there is no export button. A portability request would currently be fulfilled by hand.
• Erasure — as described in section 11, the product cannot currently erase an account or hard-delete a message on request.

14. Children

DECISION NEEDED: a minimum age for the service, and the wording that goes with it — commonly 13 (US COPPA), 16 (several EU states), or 18. Nothing in the product asks for or checks an age today, so whichever number is chosen is a statement of policy, enforced by nothing.

15. Changes and contact

If this policy changes materially we will say so here and update the date at the top. DECISION NEEDED: whether material changes are also notified in-app or by email — and note that there is currently no way to send email.

Questions about this policy, or a request about your data:

DECISION NEEDED: the legal entity name, its registered address, and a working contact address for privacy enquiries. No such address exists in the product today and none has been invented here.