afka uses analytics cookies to see how visitors use the site, and a service that can identify the company a visitor works for. We do not sell your data. Decline and none of it loads.
afka runs agents that connect to your tools and act on your behalf, so security and control are built into the product. This page summarizes how we protect your data and how you stay in control of what your agents can do.
afka gives a company AI colleagues that receive work in a chat channel, plan it, act in its connected tools, and report back. The answer to the trust that requires is an architecture in which the dangerous thing is hard to do by construction. Three properties carry most of that weight.
The model never sees a credential. When an agent acts in a connected tool it never holds or sees the token that authorises the action. It calls the tool by name, and a backend gateway injects the credential at execution time, on the server, outside the model’s context. A credential the model has never seen cannot be leaked or redirected by it: the protection is structural, not behavioural.
Money and irreversible harm always ask a named human. Every agent has an autonomy setting the customer chooses, and above it sit two independent floors it cannot lower. Money leaving the customer’s account, and decisions that do a person irreversible harm, always stop and ask a named human being first, whatever the dial is set to.
Everything is written where it cannot be edited or deleted. Every action, by an agent or a person, is written to an append-only audit log in the customer’s workspace. The audit log cannot be altered or deleted, including by afka.
Compliant means the requirement is in force now and afka meets it. In progress means the work has begun and is not finished. Planned means the work is scheduled and has not begun.
| Standard | Status | What this means | Documentation available today |
|---|---|---|---|
| SOC 2 Type I | In progress | The work toward the examination is under way. No report exists yet, and afka claims none. | This page; Annex II of the DPA; a questionnaire on request. |
| SOC 2 Type II | In progress | A Type II report covers controls over an observation period. The work is under way, and no report exists yet. | None. |
| ISO/IEC 27001 | Planned | afka holds no certificate and no certification process is under way. | A control mapping against the requirements a buyer names. |
| ISO/IEC 42001 | Planned | afka holds no certificate for an AI management system and that work has not begun. | Sections 6 and 7; the matching Annex II entries. |
| GDPR (Regulation (EU) 2016/679) | Compliant | afka is processor, the customer controller. The DPA is published on standard terms, carries the Article 28 obligations in full, and incorporates the 2021 Standard Contractual Clauses. A legal position, not a certification. | The DPA and its Annexes; the Privacy Policy, which publishes the sub-processor list. |
| UK GDPR and the Data Protection Act 2018 | Compliant | The DPA covers the United Kingdom expressly and incorporates the International Data Transfer Addendum (version B1.0). | The DPA, including its Addendum elections. |
| CCPA and the United States state privacy laws | Compliant | afka acts as a service provider and does not sell or share personal information. Equivalent terms cover the Delaware, Virginia, Colorado, Connecticut, Texas and Oregon statutes. | The DPA (service provider terms); the Privacy Policy. |
| Google API Services User Data Policy, including Limited Use | Compliant | Sign-in scopes only for afka’s own Google client, plus the Google Chat application scope. No mailbox-reading scope is requested. | Section 2.6 of the DPA, stating the scopes and Limited Use commitments. |
afka does not today hold a SOC 2 report of any type, and does not hold an ISO/IEC 27001 or ISO/IEC 42001 certificate. There is no attestation and no report available under a non-disclosure agreement.
What a buyer can have today: the control descriptions on this page; Annex II of the DPA, which states where a measure is provided by an underlying platform provider; a mapping of those controls to the framework the buyer names; the DPA, signed; and a completed security questionnaire. Write to support@afka.ai.
Workspaces are isolated in the database, not in application code. Every tenant table carries row level security keyed on a business identifier claim that a custom access token hook injects into the access token at sign-in. A query made with one workspace’s token cannot return another’s rows, so an application bug does not become a cross-tenant exposure: the boundary is not enforced by the layer that has the bug.
On the core tables, row level security is set to FORCE, removing the exemption an ordinary policy gives the table owner. Those tables are tasks, runs, approvals, artefacts, the audit log, the credit ledger, connectors, workspace skills, agent watch data and proactive cards.
Tenant isolation is verified automatically before any change is released.
As defence in depth, server-side functions never trust a client-supplied workspace identifier: they re-resolve the tenant from the verified token.
Connection references for connected accounts are held in the managed database platform’s secret vault: never in environment files, never in the frontend bundle, never in a build variable that reaches the browser.
For a connector managed by the connector platform, the OAuth grant itself is held by that platform; afka holds only a reference to it. Disconnecting therefore revokes the account at the source, by an API call to the platform, and afka writes an audit row recording it.
API keys are stored as a SHA-256 hash, shown once at creation and never retrievable; only a prefix and the last four characters are kept, for display. Scopes are re-intersected with the creator’s live capabilities on every authenticate call, so a key cannot outlive its creator’s permissions, and the key management scope cannot be granted to a key.
The model never receives a raw credential; the backend tool gateway injects it at execution time. Where an agent delivers on behalf of the member who linked a tool, that member’s token is read from the vault per delivery and the connector posts under that member’s name.
Code written by a language model is untrusted from the moment it exists. It executes in an isolated microVM with one guest kernel per task, destroyed after the run and never reused across workspaces. Each run gets short-lived scoped tokens rather than long-lived secrets.
Network egress from the sandbox is denied by default.
Every run is bounded by CPU, memory, wall-clock and credit caps.
Each agent has an autonomy level the customer sets and may change. At Suggest it proposes work and does not act until told to. At Review it prepares an action and holds it for approval. At Auto it may execute actions in the risk classes the customer has released to it, subject to the floors below.
Ordinary work carries no risk classification and never asks: reading, researching, drafting, updating internal state. Above it sit the four risk classes the dial governs: money, spending or moving money; send, communicating outside the workspace; record, creating or altering records in a connected tool; account, changing account or workspace settings.
Above the dial sits a set of categories the dial cannot release. Money leaving the customer’s account, and decisions that do a person irreversible harm, always ask a named human being first. The gated categories are refunds, payments, payouts and adverse decisions about a person, with a named action list: processing a cancellation, changing a subscription, an offboarding action, an account change, spending money. A second, independent rule covers the same ground: a money set (refunds, credits, discounts, loyalty grants, spending, checkout, payment charge and capture, subscription changes, advertising reallocation) and a people set (offers sent or routed, hiring recommendations, offboarding, anything marked adverse).
The mechanism is a floor rather than a prohibition. A gated action is forced to the Review level, so a named person must approve it before it runs, and the approver, the action and the target are written to the audit log. If nobody approves, it does not run. An action the system cannot confidently classify is treated as gated.
Loosening autonomy is reserved to the workspace owner, so a change in risk posture is attributable to a named person. Pending approvals expire on a time to live and are swept. Spend caps are summed across an action broken into steps, so decomposition does not pass under a cap. Any running agent can be stopped from the application.
Every action taken by an agent or a person is written to an append-only audit log in the customer’s workspace. The log cannot be altered or deleted, including by afka: an attempt to alter or delete an entry is rejected.
A row carries the actor, the action, the target, the timestamp, the credit cost, the run identifier, a reference to the authorising approval where one was required, and whether the initiator was a human or an agent.
Customers export the log themselves. A server-side function verifies the caller’s token, resolves the tenant on the server, and checks a named export capability: owners and administrators always hold it, a member only if granted. Formats are CSV and NDJSON, the latter for a security information and event management system. The export writes its own row to the log.
The export is not cryptographically signed or notarised, and a customer should not represent an export to a court, a regulator or a counterparty as tamper-proof.
Where meeting functionality is enabled, a named assistant joins the call as a visible participant and announces itself on joining. afka does not join a call covertly and offers no mode in which it would.
afka transcribes; afka does not record video. There is no video recording and no recording library. What is kept is a transcript and derived outcomes: summaries, actions and follow-up work.
Meeting transcripts and the raw speech recognition samples are deleted on a rolling window of thirty (30) days by an automatic daily sweep. On the same window the stored prompt of a task and the stored context of an approval are emptied while the records themselves are kept. Speech samples sit in a table neither the anonymous nor the authenticated database role can read.
The audit log contains no speech or message content.
A scheduled join can be cancelled before the call; the assistant can be removed during a call, which ends transcription; and a call with its transcript can be deleted afterwards, a deletion the product refuses until the assistant has been removed. Consent is the customer’s responsibility: some jurisdictions require the consent of every participant. The self-announcing participant is not a substitute for that process, as the Terms of Service set out.
afka stores and routinely processes customer data in the United States. Application compute, meaning application hosting, the background worker and the voice ingress, runs in the United States, in the region declared as Oregon. The hot cache, rate limiting and product analytics also 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. For transfers out of the European Economic Area, the United Kingdom and Switzerland, the DPA incorporates the Standard Contractual Clauses and the United Kingdom Addendum.
All traffic to afka is carried over TLS. Encryption at rest is provided by the underlying managed database, storage and hosting providers. Browser-facing responses carry these headers:
A content security policy is enforced. Alongside it a stricter policy runs in report-only mode, reporting violations to a dedicated endpoint, so stricter rules are measured against real traffic before enforcement; those reports are swept at thirty (30) days. Public forms are protected by a managed bot detection challenge at the edge.
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: a member of afka staff does not read customer message content in the ordinary course of running the service. Support access is limited to what the matter raised requires. Every person authorised to process customer data is under a written confidentiality obligation surviving the end of their engagement.
The administrative database key is used server-side only and is never exposed to the browser or to a sandbox.
SAML 2.0 single sign-on is shipped, built on the managed authentication platform, and works with any SAML 2.0 identity provider. It is bound to a company domain that must be verified before use, one domain per workspace.
Enforcement, meaning turning password sign-in off for the verified domain, ships disabled and cannot be enabled until one successful single sign-on has completed, so enforcement cannot lock an administrator out of a workspace it has never worked in. Single sign-on is available on the highest self-serve plan and on enterprise plans, not on the lower plans.
SCIM directory sync is not built. There is no automated directory-driven provisioning or deprovisioning. Removing a person is done in the application or, where enforcement is enabled, at the identity provider.
afka does not use customer data to train general-purpose AI models. afka does not sell customer data or use it for advertising or cross-context behavioural profiling.
afka’s commitments about its AI providers’ behaviour reflect the contractual arrangements in effect with each of them, and a provider can change its terms unilaterally. If afka becomes aware that such a change would materially reduce the protection applicable to customer data, it will give advance notice through the sub-processor change process in the DPA, which carries a thirty (30) day notice period, an objection right and a route to terminate the affected part of the service. The DPA also binds afka to require that its AI providers do not use customer personal data to train general-purpose models.
afka uses a small number of AI model providers under contract: Anthropic for the primary language models, in use whenever an agent runs; Moonshot as a live fallback tier for those models; OpenAI for speech to text only; Voyage AI for the embeddings used to index and retrieve workspace knowledge; and Tavily for the web research step. These providers are named in the sub-processor list published in the Privacy Policy, which forms part of the DPA, and a change to that list is notified in advance through the process described above.
If you have found a security issue in afka, please tell us. Write to support@afka.ai with enough detail to reproduce it, and afka will acknowledge the report and keep you informed while it is investigated and fixed. afka will not pursue a researcher who reports in good faith, avoids accessing or destroying other people’s data, and gives afka a reasonable opportunity to fix the issue first.
afka does not run a paid bug bounty. What afka offers is a fast acknowledgement, a real fix, and public credit if you want it.
Write to support@afka.ai and afka will send, without a call and without a qualification process: the DPA on standard terms, ready to sign, with Annex II as the itemised control inventory; a mapping of afka’s controls to whichever framework you name; your own security questionnaire completed; and a direct answer about any control on this page.
See also the Terms of Service, which govern autonomy, approvals and responsibility for an agent’s actions, and the Privacy Policy. Where this page and the DPA differ, the DPA governs.