Privacy Policy

1. Who we are and what this policy covers

afka is a product of Afka, Inc., a Delaware corporation at 2810 N Church St STE 89857, Wilmington, DE 19802, United States. afka gives a company AI colleagues that receive work in a chat channel, plan it, act in its connected tools within the autonomy that company sets, and report back. Every action an agent takes is written to an append-only audit record.

It covers the website at afka.ai, the application at app.afka.ai, the voice surface at talk.afka.ai, the agents in a customer’s connected channels, the meeting assistant, and the public application programming interface (together, the Services).

Two roles run through it. For content flowing through a customer’s workspace, the customer is the controller and afka the processor, acting on that customer’s documented instructions under the Data Processing Agreement: if your data is there because you work at that company or dealt with it, your request goes to them and afka assists. For account administration, billing, security telemetry, product analytics and afka’s own website, afka is the controller.

Definitions used in this policy

• Customer: the organisation holding an afka workspace under the afka Terms of Service.
• Customer Data: content submitted to, generated in or retrieved by the Services on a Customer’s instructions: channel messages in conversations an agent is part of, meeting transcripts, voice text, tasks, runs, artefacts, approvals, workspace knowledge, and connected-account data.
• Connected Channel: a surface a Customer binds to its workspace: Slack, Microsoft Teams, Google Chat, Zoom Team Chat, Discord, ClickUp, the web application, email, the voice surface and the public application programming interface.
• Customer-Enabled Integration: a third-party platform or account a Customer connects, or to which it directs an agent.
• Sub-processor: a third party afka engages to process Customer Data on afka’s behalf.
• Autonomy: the per-agent setting deciding how much an agent may do before asking a named human.

2. The information afka collects

• Account and workspace information: user identifier, name, email address, workspace and organisation identifiers, role and capabilities, identity provider identifiers where single sign-on is used, and session and device metadata.
• Connection references: the platform, the account, the scopes granted, the member who connected it and its status. For a connector reached through the connector platform the OAuth grant is held there and afka holds only a reference to it, in the platform secret vault.
• Workspace content: tasks and their prompts, plans, runs, artefacts, approvals and their context, agent outputs, workspace knowledge and its embeddings.
• Channel messages: an agent reads the conversations it has been added to and direct messages addressed to it, not the whole of a workspace. Within those, afka receives message content and metadata: sender and recipient identifiers, display names and timestamps.
• Meeting and voice data: where the afka meeting assistant is invited to a call it joins as a named, visible participant and announces itself. afka transcribes; it does not record video and keeps no recording library. Stored: the transcript, the associated speech recognition samples, participant identifiers and display names, meeting title, times and outcomes. For the voice surface, speech converted to text, with session metadata.
• Service, usage and billing data: audit entries, application and infrastructure logs, error and security telemetry including content security policy reports, credit consumption in an append-only ledger, and billing and transaction metadata. Card details are handled by afka’s payment provider, never stored by afka.
• Analytics and communications: usage events, website measurement and visitor-identification data after consent (Section 5), and support and sales correspondence.

Data afka asks you not to send. The Services are not designed, certified or intended for protected health information, payment card data, non-public financial information, special categories of personal data under Article 9 of the GDPR, criminal conviction data, personal data of children under sixteen (16), or export-controlled data. Submitting it is prohibited by the DPA.

3. How afka uses information

• To provide the Services: receive work in a Connected Channel, plan it, carry it out in connected tools within the configured autonomy, seek approval where required, and report back.
• To run the AI processing behind the output: content is sent to the AI providers described in Section 4 for inference, and model-written code runs in an isolated sandbox. Outputs are probabilistic and the Customer remains responsible for reviewing them.
• To secure, support and bill: authentication, tenant isolation, abuse and fraud prevention, bot detection, rate limiting, metering, payment and service notices.
• To improve the Services through aggregated or de-identified measurement. afka does not use Customer Data to train general-purpose AI models, and requires the same of its providers.
• To market afka’s own products to business contacts, subject to Sections 5 and 8, and to comply with law and defend claims.

afka does not sell personal data for monetary consideration and does not use Customer Data for advertising or cross-context behavioural profiling. Depending on your jurisdiction, some website analytics described in Section 5 may count as a sale, a sharing or targeted advertising; the consent control there is how to stop it.

4. Sub-processors and how afka shares information

A. Current sub-processors

Each is engaged under a written contract imposing obligations in substance no less protective than those afka owes its Customers, and afka remains liable for its performance. afka gives at least thirty (30) days notice before a new one processes Customer Data, and a Customer may object under Section 7.3 of the DPA.

Current sub-processors:

Sub-processor	Purpose	Data it may process
Supabase	Managed Postgres database, authentication including SAML single sign-on, realtime, server-side function execution, object storage and the secret vault.	Workspace and account records, user identifiers and authentication events, tasks, runs, approvals, artifacts, the audit record, meeting transcripts, the credit ledger, and the connection references held in the vault.
Render	Application hosting for the web application, the public application programming interface, the background worker, the static sites and the voice ingress.	Request metadata and application logs, and Customer Data in transit through the application while a request is served.
Cloudflare	The managed challenge used to distinguish humans from automated traffic, and custom hostname termination for Customer-facing pages.	Network metadata, the address a request comes from, and the result of the challenge. No workspace content.
Upstash	Managed key value store used as a hot cache and for per-tenant rate limits.	Short-lived cached values keyed to a workspace, and rate limit counters.
Temporal Cloud	Durable orchestration of long-running agent work.	Workflow state, and the inputs and results passed between the steps of a run.
E2B	Isolated microVM execution of model-written code.	The code an agent writes and the data that run is given to work on, for the life of the run. The guest is destroyed when the run ends.
Pipedream	The connector platform through which a Customer connects third-party accounts and through which connected-account actions are carried out.	The authorisation grant for a connector it manages, and the data passing to and from the connected account within the scopes the Customer granted.
Recall.ai	The meeting assistant that joins a scheduled call as a named participant and returns the transcript.	Meeting audio during the call, the resulting transcript, participant names and call metadata. There is no video recording.
Retell AI	The live voice agent that conducts a spoken conversation on the voice surface.	Call audio, the transcribed turns of the conversation, and call metadata.
Cartesia	Text to speech for the voice surface.	The text an agent speaks, and the audio generated from it.
Telnyx	Telephony transport carrying voice calls to and from the voice surface.	Call audio in transit, and call routing and duration metadata.
Postmark	Transactional email sent by the Services, and inbound mail reception for the email channel.	Sender and recipient addresses, subject and body of the messages sent and received, and delivery results.
Resend	Internal notification and follow-up email sent by the Services.	Recipient addresses, and the content of the messages sent.
Loops	Lifecycle email.	The name and business email address of an account contact, and lifecycle events.
PostHog	Product analytics for the application, on United States infrastructure, served through a first-party proxy at e.afka.ai.	Usage events, page views, and user and workspace identifiers. No message, transcript, email or task content is sent to it.
Stripe	Payment processing and subscription billing.	Billing contact details, and transaction and subscription metadata. Card details are handled by Stripe and are not stored by afka.

Each processes only what its function requires, under contract, and each is bound by confidentiality and data protection terms.

The table above is the current list. It forms part of the Data Processing Agreement and is the list Section 7 of the DPA refers to. A Customer is given notice of an addition or a replacement in advance of that sub-processor processing Customer Data, and may object to it, by the mechanism Section 7 of the DPA sets out. To have a copy sent to you, or to subscribe a further address for change notices, write to privacy@afka.ai.

The providers measuring the marketing website are named in Section 5: they process visitor data, not workspace content.

B. AI providers

afka uses a small number of AI model providers under contract:

• Anthropic: the primary language models, in use whenever an agent runs.
• Moonshot: a live fallback tier for the language models, reached when the primary provider is unavailable or degraded.
• OpenAI: speech to text only, reached when a voice or meeting feature is invoked.
• Voyage AI: embeddings, used to index the workspace knowledge base and to run a retrieval step over it.
• Tavily: the web research step, reached when a task requires research on the public web.

afka names a provider here only where that provider is in use.

• Current list: the providers named above are the providers in use, and they also appear in the sub-processor table in Section 4.A on this page. That list is maintained under Section 7.3 of the DPA, and a change to it is notified in advance.
• Data residency: inference runs on United States infrastructure. afka does not offer European Union data residency and does not claim it.
• Provider retention: providers may retain data temporarily under their own policies for security and abuse monitoring. Each request is processed in isolation, invisible to another Customer.
• No training: Customer Data is not used to train general-purpose AI models, by afka or its providers. This reflects the contracts in effect with each; if afka learns of a change materially reducing that protection it gives notice through the sub-processor change process, which carries thirty (30) days notice, an objection right and a route to terminate.

C. Customer-Enabled Integrations are not afka sub-processors

The provider of a platform a Customer connects is not a sub-processor of afka solely because the Customer connected it, unless it appears on the sub-processor list described in Section 4.A. Data is transmitted there at the Customer’s instruction and within the scopes granted, and what that provider does with it is governed by the Customer’s own agreement with it. The Customer is responsible for the scopes it grants, the notices and consents required, and compliance with that platform’s terms. Where a provider appears in both roles, its status as an afka sub-processor covers only afka’s use of it.

D. Tools afka uses to run its own business

afka also uses ordinary business tools of its own. They hold afka’s own records, including the contact details of people who enquire, and they are not processors of Customer Data. They are HubSpot, afka’s customer relationship system; Dub, for creator and affiliate links; Notion, for internal task tracking; GitHub, for source control; and Instantly, for afka’s own outbound sales.

E. Other disclosures

afka may disclose personal data where required by law or lawful request, or where necessary to protect rights, property or safety, or to defend legal claims; where permitted, afka informs the Customer first. On a merger, acquisition or sale of assets, data may transfer to the successor under this policy or one no less protective.

5. Cookies, analytics and the afka website

A. Strictly necessary cookies. The application sets cookies and browser storage needed to sign you in, keep your session, remember your workspace and protect against automated abuse. These load without consent because the Services cannot function without them.

B. The marketing website: two providers, both behind a consent gate. On afka.ai and www.afka.ai two analytics providers load, neither until you consent in the cookie banner.

• Google Analytics 4 measures visits, pages viewed, referral source and campaign performance, showing which pages and campaigns work.
• RB2B performs reverse-IP visitor identification. Stated plainly: it takes a visitor’s network address and attempts to identify the company that visitor works for, so afka’s sales team can see which companies have visited. afka names it because a visitor should know it is running before consenting.

If you decline, neither script loads at all. You can change or withdraw your choice at any time through the cookie control on the website. afka loads no advertising or social-media tracking pixels.

C. Product analytics inside the application. The application uses PostHog, on United States infrastructure, behind a first-party proxy at e.afka.ai so requests go to an afka domain rather than a third-party one. It records usage events, page views and user and workspace identifiers, showing which parts of the product are used and where they fail. It is not used for advertising, and message, transcript and task content is never sent to it.

D. Your controls. Browser controls can block or delete cookies, though blocking strictly necessary ones stops the application working. Every marketing email carries an unsubscribe link; unsubscribing leaves service and security notices in place.

6. Where data is stored and how it is protected

A. Location

afka stores and routinely processes personal data in the United States: application hosting, the background worker, the voice ingress, caching, rate limiting and product analytics run in United States regions.

The primary managed database is located in the United States, in the East US (North Virginia) region.

afka does not offer European Union data residency.

B. The controls that carry the most weight

Tenant isolation is enforced in the database, by row level security on every tenant table with FORCE on the core tables, and the model never holds a credential: a backend gateway injects it at execution time. The security page covers these, the approval floors and the transport controls. Three points bear directly on personal data.

• Model-written code runs in an isolated microVM, one guest per task, destroyed after the run and never reused across workspaces, with short-lived scoped tokens rather than long-lived secrets, and CPU, memory, wall-clock and credit caps. Network egress from the sandbox is denied by default.
• The audit record cannot be edited or deleted. Every action an agent takes is written to it, not only the actions that required an approval, and append-only is enforced by a database trigger that rejects any update or delete of a row: application code cannot rewrite history and neither can afka. A row carries the actor, action, target, timestamp, credit cost, run identifier, the authorising approval where one was required, and whether a human or an agent initiated it. It carries no meeting speech, message or email bodies, document contents or task prompts, and Customers can export it in CSV and NDJSON.
• Secrets and tokens. Application programming interface keys, directory bearer tokens and mobile link tokens are stored as a SHA-256 hash, shown once and never retrievable. Connection references are held in the platform secret vault; for a connector managed by the connector platform the OAuth grant is held there and afka holds only a reference.

C. Encryption at rest

Encryption at rest is a property of the underlying managed database, storage and hosting providers, provided by them rather than implemented by afka.

D. Access by afka personnel

Access to production platforms is granted on the principle of least privilege, authenticated at each provider, and revoked when no longer required. There is no routine access to Customer content: afka staff do not read Customer messages in the ordinary course, and support access is limited to what the matter requires. Everyone authorised to process Customer Data is under a written confidentiality obligation surviving their engagement.

7. How long data is kept

A. The one automatic window afka operates

Speech captured from meetings is deleted on a rolling thirty (30) day window: meeting transcripts and the associated speech recognition samples are deleted, and on the same window the stored prompt of a task and the stored context of an approval are emptied while the record itself is kept. The window is a scheduled job running daily. Content security policy reports are swept at thirty (30) days; voice session records and expired approvals are swept on a rolling basis.

afka operates no other general automatic deletion sweep. Other than this, deletion occurs on the Customer’s request.

B. Deletion during the term

A Customer can delete data through the Services: a task and its content; a single call and its transcript, which the Services refuse until the meeting assistant has been removed from that call; and a connected account, by disconnecting it. On disconnection of a connector managed by the connector platform, afka revokes the connection there by an application programming interface call and records it in the audit record; because the OAuth grant is held by that platform, no afka-side token record exists to delete. Any further written deletion request is actioned within sixty (60) days, subject to Section 7.E.

C. After termination

On termination or expiry, on deletion of the account, or otherwise after the end of the Services, a Customer has thirty (30) days to export or request the return of its data, with self-service export of the audit record in CSV and NDJSON and assistance for anything further. If it does not, that is a deemed instruction to delete the data including existing copies, and afka does so within sixty (60) days after that thirty (30) day period ends. After the export window the data may not be recoverable. On written request within sixty (60) days of completion, afka confirms the deletion and identifies anything retained.

D. Backups

afka operates no backup infrastructure of its own. Backup and point-in-time restoration are functions of the managed database and hosting platforms, and backup media are overwritten in the ordinary course of those providers’ rotation. afka publishes no backup retention period and does not represent that deletion from active systems is at once reflected in backups.

E. Legal hold

afka may retain personal data where required by law, or under a reasonable legal hold for actual or anticipated litigation, investigation or dispute, retaining only what is required and only so long as required. Billing and tax records are kept for the periods the law requires.

F. What is not deleted: the audit record

The audit record described in Section 6 is not deleted and cannot be deleted: append-only is enforced by a database trigger, so it survives deletion of the underlying working data. The audit record contains no speech or message content. A row may still contain identifiers that are personal data, such as the name of the person who acted; where a Customer needs those erased to answer a data subject, afka will discuss in good faith what can be done consistently with the record’s integrity, whose retention it considers necessary to defend legal claims and to secure processing.

8. Your rights and choices

Depending on where you live, you may have the right to access the personal data held about you, to have it corrected or deleted, to receive a portable copy, to object to or restrict processing, to withdraw a consent, and not to be discriminated against for exercising these rights.

Which door to knock on depends on the roles in Section 1. If your data is in a Customer’s workspace, that Customer is the controller: write to them. If afka is the controller (your account, your billing records, your visit to the website), write to privacy@afka.ai.

• Response times: afka responds within forty-five (45) days, extendable once by a further forty-five (45) days where the request is complex, with notice of the extension and its reason. Identity may need to be verified first.
• Appeals: if afka declines a request you may appeal, by replying to the decision or writing to privacy@afka.ai with the words Privacy Appeal in the subject line. Where your state allows, you may also complain to its attorney general.
• Authorised agents: where the law allows, an agent may submit a request on your behalf with proof of authority.
• Withdrawing consent and disconnecting: a Customer can disconnect any connected account from the application, revoking the connection at the connector platform; a member can remove an agent from a channel; the meeting assistant can be cancelled or removed; and analytics consent can be withdrawn through the cookie control in Section 5.
• Complaints: in the EEA, the United Kingdom and Switzerland you may complain to your local supervisory authority; afka asks that you raise it first.

9. International transfers

Where personal data is transferred to afka out of the European Economic Area, the United Kingdom or Switzerland, the transfer is made under the European Commission Standard Contractual Clauses, and under the United Kingdom International Data Transfer Addendum where the UK GDPR applies, each as incorporated by Section 8 of the DPA. The measures relied on are in Annex II of that document.

EU representative under Article 27 of the GDPR. Afka, Inc. has designated Dmitry Melnik, established in Poland, as its representative in the Union for the purposes of Article 27 of the GDPR. Data subjects and supervisory authorities in the European Economic Area may contact the representative at privacy@afka.ai, and afka asks that correspondence be marked for the attention of the EU representative.

10. Google user data and Limited Use

Where a Customer connects a Google account, afka’s use and transfer of information received from Google application programming interfaces to any other application adheres to the Google API Services User Data Policy, including its Limited Use requirements. afka’s application requests these scopes and no others.

All four are sensitive scopes under the Google API Services User Data Policy. afka requests no restricted scope.

Scope	What it permits	Why afka requests it	Data afka receives
gmail.send	Sending mail as the signed-in user. It grants no ability to read a mailbox.	So afka can send only a message the user approved inside afka, from the user’s own Gmail account. afka never reads, lists, searches or stores the mailbox through this client, and no narrower scope can send a message.	The message afka sends, and the delivery result. This scope returns no mailbox contents.
calendar.events	Creating, editing and deleting events on the user’s calendar.	So afka can create or update an event when the user asks to schedule one. calendar.events.readonly alone cannot schedule, and the broader calendar scope is unnecessary because afka never changes calendar settings or other users’ calendars.	Titles, times, descriptions, locations, organiser and attendee identifiers for events changed.
calendar.events.readonly	Reading calendar events without changing them.	So afka can read upcoming events, to brief the user and to join the meetings it was asked to join.	Titles, times, descriptions, locations, organiser and attendee identifiers.
chat.bot	Operating the afka application inside a Google Chat space.	So afka receives and answers messages addressed to the afka Chat app in a space a user has added it to. No narrower scope exists for a Chat app.	Messages addressed to the application in spaces it was added to, with sender identifiers, names and timestamps.

Limited Use commitments

• afka uses data from these scopes only to provide and improve user-facing features prominent in the afka interface: sending mail, reading and scheduling calendar events, and operating an agent in a Google Chat space at the user’s instruction.
• afka does not transfer it to others except as necessary to provide or improve those features, to comply with law, or in a merger, acquisition or sale of assets with the notice and consent the law requires. Sub-processor transfers fall under Section 4.
• afka does not use that data for serving advertisements and does not sell it.
• afka does not use that data to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models, whether afka’s own or a model provider’s.
• No person at afka reads it. afka does not allow humans to read data obtained through these scopes, with four exceptions: the affirmative agreement of the relevant user for specifically identified data; necessity for security purposes, such as investigating abuse; a requirement of law; or data that has been aggregated and de-identified.
• A user may revoke access at any time by disconnecting the account in the afka application, or at myaccount.google.com/permissions. Disconnecting revokes the grant at the connector platform and records it in the audit record.

11. Platform and marketplace compliance

Each block states what afka receives on that platform, what it commits to, and how to revoke access. Across all of them an agent reads only the conversations it was added to and direct messages addressed to it, never a whole workspace; platform data is used only to operate that Customer’s agents, write the audit record and support the Customer; and it is never sold or used for advertising.

A. Slack

What afka receives. Workspace and team identifiers, user identifiers and display names, and message content and metadata in channels the app was added to and direct messages with it.

Commitments. afka does not use data obtained from the Slack application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models. afka requests the narrowest scopes its features need.

Revoking access. A workspace owner or administrator can remove the app in the Slack administration settings, revoking the grant; removing it from one channel stops the agent reading it.

B. Microsoft Teams

What afka receives. Tenant, team and channel identifiers, user identifiers and display names, and message content and metadata in conversations the app is part of. Where the meeting assistant is invited to a call, the transcript and participant identifiers.

Commitments. afka does not use data obtained from the Microsoft application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models. Access is limited to the permissions the administrator consents to.

Revoking access. A tenant administrator can remove the app from Teams, or revoke its consent in the Microsoft Entra administration console.

C. Google Chat

What afka receives. Space identifiers, user identifiers and display names, and messages addressed to the application in spaces it was added to, with metadata. The scope is chat.bot, described in Section 10.

Commitments. The Limited Use commitments in Section 10 apply in full here: afka does not use data obtained from the Google application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models, and does not allow humans to read it save for the four exceptions listed there.

Revoking access. Remove the application from the space, disconnect the Google account in afka, or revoke at myaccount.google.com/permissions.

D. Zoom

What afka receives. In Zoom Team Chat: account and channel identifiers, user identifiers and display names, and message content and metadata in conversations the agent is part of. Where the meeting assistant is invited to a call: the transcript, participant identifiers and display names, and meeting metadata. It joins as a named, visible participant and announces itself; afka transcribes and does not record video.

Commitments. afka does not use data obtained from the Zoom application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models. Transcripts and speech recognition samples are deleted on the rolling thirty (30) day window in Section 7.

Revoking access. An account owner or administrator can uninstall afka from the Zoom App Marketplace management page. A Customer can cancel the assistant before it joins, or remove it mid-call.

E. Discord

What afka receives. Guild and channel identifiers, user identifiers and display names, and message content and metadata in channels the application was added to and direct messages with it.

Commitments. afka does not use data obtained from the Discord application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models.

Revoking access. A server administrator can remove the application from the server at any time.

F. ClickUp

What afka receives. Workspace, space, list and task identifiers, member identifiers and display names, and the tasks and comments an agent is asked to work with.

An important disclosure. Delivery into ClickUp uses the credentials of the member who linked the account, read from the secret vault for each delivery. Comments and updates the agent makes therefore appear under that member’s own name, not a separate application identity. A Customer should tell that member first.

Commitments. afka does not use data obtained from the ClickUp application programming interfaces to develop, improve or train generalised or general-purpose artificial intelligence or machine learning models.

Revoking access. Disconnect the ClickUp account in the afka application, revoking the connection at the connector platform, or revoke afka in the ClickUp integrations settings.

12. Children

The Services are business software, sold to organisations for use by their personnel. They are not directed to children and afka does not knowingly collect a child’s personal data. Submitting the personal data of a child under sixteen (16) is prohibited by the DPA. If afka learns it holds such data it deletes it; write to privacy@afka.ai if you believe this has happened.

13. Changes to this policy

afka reviews this policy at least annually and updates it when the product or the law changes; the current version is the one at afka.ai/legal/privacy. Where a change materially reduces the protection afforded to personal data, afka gives notice by email to the account administrator of record and by posting to afka.ai/legal before it takes effect. Sub-processor changes follow Section 7.3 of the DPA.

14. How to contact afka

Data protection matters go to privacy@afka.ai: questions about this policy, requests to exercise the rights in Section 8, requests under the GDPR and the United States state privacy laws, correspondence for the EU representative named in Section 9, privacy appeals and questions about a personal data breach.

Everything else goes to support@afka.ai: support, billing, sales and general questions and contract notices. Where formal service by post is required, write to Afka, Inc., 2810 N Church St STE 89857, Wilmington, DE 19802, United States.

See also the Terms of Service, the Data Processing Agreement and the security page.