Security & Data Residency

AFK keeps code execution close to your repositories while providing a hosted browser control plane for durable sessions, team coordination, and approvals. This page explains which data stays in the runner environment, which data reaches AFK, and which third parties may receive data.

How data moves through AFK

What AFK stores

• Account and organization data, including profile information, memberships, roles, and account settings.
• Session metadata and durable session history, which can include prompts, agent responses, tool calls and results, diffs, file paths, attachments, approvals, and usage information.
• Automation and integration configuration, run history, delivery state, and external conversation mappings when those features are enabled.
• Model connection credentials, OAuth credentials, and integration secrets needed to provide configured features.
• Billing, support, security, and operational records required to run the service.

AFK does not copy an entire local/shared-daemon repository into the hosted service merely because a daemon can access it. Data from that repository reaches the hosted service when it becomes part of session traffic or a user explicitly uploads, exports, or publishes it through an integration.

Security controls

• Hosted browser and daemon connections use encrypted HTTPS and secure WebSocket transport.
• Browser sessions are authenticated server-side. User and organization resources are scoped to their authenticated owner and active organization context.
• Organization roles restrict administrative settings. Session assignment and participant roles further restrict who may view or steer shared work.
• Daemon tokens are shown when issued and stored by AFK as one-way hashes. Tokens can be revoked from Account → API Keys.
• Values stored through Account → Secrets and supported chat-integration credentials are encrypted before database persistence. Secret values are not displayed again in normal lists.
• Permission modes, plan review, and tool approval cards provide human checkpoints before agent actions. Worktree and Docker options provide additional execution isolation when selected.

Data residency

Mooglest, Lda operates AFK from Coimbra, Portugal. The standard hosted AFK control plane and its primary application database are operated in the European Union. This EU residency applies to data controlled by the hosted AFK service; it does not automatically apply to data sent to a model provider or an integration selected by you.

Agents working through a local or shared daemon access repositories in the environment where that daemon runs. A company-managed shared daemon can therefore keep repository checkouts and command execution inside the company network. Enterprise customers with stricter residency or network requirements can discuss a dedicated or on-premises control-plane deployment with afk@mooglest.com.

Third parties and international transfers

Depending on the features you configure, data may be sent to:

• Your selected LLM provider, including Anthropic, OpenAI, Google, Azure, an OpenAI-compatible provider, or a local model endpoint.
• Authentication, payment, repository, chat, MCP, and automation services such as Google, Stripe, GitHub, Slack, or services you connect yourself.

These services may process data outside the EU. Their own terms, data processing agreements, retention settings, and transfer safeguards apply. Use local models, company-controlled MCP services, and enterprise deployment options when third-party processing is not acceptable.

Retention, export, and deletion

• Session-history availability follows the retention included with your plan. See Billing and limits for current periods.
• Sessions can be exported as Markdown or JSON. Archived sessions can be restored or permanently deleted from Account → History, subject to your organization permissions.
• Account data and legally required billing records follow the periods in the Privacy Policy.
• External providers and integrations can retain copies independently; deleting AFK data does not delete data already delivered to them.

Customer responsibilities

• Grant daemons access only to approved project roots.
• Select an execution isolation and permission mode appropriate for each task.
• Review model-provider and integration data terms before sending confidential or regulated data.
• Use least-privilege credentials, rotate them regularly, and revoke credentials for retired machines and integrations.
• Avoid placing secrets in prompts, repositories, hooks, or configuration files; use Account → Secrets where supported.

Compliance status and reporting concerns

AFK is designed with GDPR-oriented data controls. Mooglest, Lda is the data controller for personal data collected through the Service, and a Data Processing Agreement (DPA) is available for Team and Enterprise customers where AFK processes personal data on their behalf.

To report a suspected security issue or request security and privacy information, contact afk@mooglest.com. Do not include credentials or sensitive exploit details in an initial public message.

Subprocessors

AFK uses the following third-party subprocessors to provide the Service. Each subprocessor may process personal data as necessary to deliver their services to us.

Note: Model providers and customer-enabled integrations are selected and configured by the customer. Their own data processing terms, retention policies, and transfer safeguards apply. Customers should review provider terms before sending sensitive or regulated data.

This list is current as of May 2026. We will update this page and notify customers of material changes to our subprocessor list. For questions or to request a copy of our Data Processing Agreement, contact afk@mooglest.com.