Trust & Data

Ablo is a business service for organizations. Users must be at least 18 years old and authorized to act for their organization.

The exact content depends on how an organization configures its projects, Coworkers and integrations.

Ablo processes customer data only to provide, secure, support and administer the service, to follow customer instructions, and to meet legal obligations.

Authorized platform administrators can sign in as a user for support. This provides the user's actual access and permits real actions, including changes to workspace content and paid agent work. Ablo records the administrator and target when support access is requested; this does not confirm completed sign-in. Individual workspace actions are attributed to the signed-in user rather than separately identifying the administrator. Support access uses a normal user session and ordinary sign-out; already-issued access tokens may remain valid until they expire.

• Customer data is not sold.
• Customer prompts, responses or workspace content is never used by Ablo or its subprocessors to train AI models.
• New subprocessors, integrations, data types and processing locations require review before production use.

Ablo's production Convex deployments use the EU region. Agent execution, Browserless and the checkpoint registry run on EU-based Hetzner infrastructure. Gogs repositories and Redis run in Railway's EU region. Deliverable object storage uses Backblaze's EU Central region.

These EU locations do not make the complete service EU-only. Authentication, application delivery, analytics, billing, email, integrations, AI routing and provider support may involve processing outside the EEA.

See the complete provider-by-provider disclosure in the subprocessor register.

Ablo sends AI completion requests through OpenRouter. The default OpenRouter workspace guardrail applies to every workspace key by default. Zero Data Retention is enabled separately for All other models, Anthropic, OpenAI, Google and SpaceXAI. Requests that would require provider data retention are rejected.

The same guardrail disallows paid endpoints that train on request data, free endpoints that retain or train on prompts and completions, and free endpoints that publish prompts. Data-region restriction is not enabled, so a compliant endpoint may process outside the EEA. The access policy is “Only Allow” with exactly three providers: Azure, Amazon Bedrock and DeepInfra. All other providers, including newly added providers, are blocked. There is no separate model allowlist: models served by an allowed provider remain subject to the privacy rules.

Additional per-request enforcement in AgentContainer is pending: the request client must include provider.zdr = true and provider.data_collection = "deny" on every request and fail rather than silently route to a non-compliant endpoint. The workspace guardrail is already enabled. Zero Data Retention applies to prompt and response content. OpenRouter may still retain operational metadata such as model, provider, token counts, latency and cost.

The provider allowlist covers the model families in Ablo's current model picker: Azure and Amazon Bedrock serve proprietary models, and DeepInfra serves open models. Availability depends on OpenRouter's current endpoint classifications and a compliant endpoint being available at request time. Adding another inference provider requires an explicit allowlist and register update.

Integrations are project-scoped. Ablo uses Composio to connect customer-selected services and execute approved tools. Composio holds and refreshes the connected-account credential; Ablo stores the connection identifiers needed to use and remove it.

Ablo limits integrations to the actions it exposes. The current Gmail product flow creates editable drafts inside Ablo and sends mail through Composio; Ablo does not currently expose a mailbox-reading tool. The production Composio-managed Gmail grant is broader: it includes the full Gmail scope, which permits reading, sending, modifying and deleting mailbox content, together with profile, email, contacts, language, address, birthday and phone-number scopes.

When Tripletex MCP Beta is configured and a project Manager connects an account, Ablo can send requested tool inputs to Composio and receive Tripletex results that may include accounting records, invoices, customers, suppliers, employee details and payslips. The Manager can select read or admin access until changed or disconnected; admin permits all synced MCP tools available to the connected Tripletex account without a separate approval for each call. Tripletex's own permissions still apply, and its MCP tools do not cover its full REST API.

The production Composio project uses the “Don't store data” log-storage setting. Composio does not retain request or response payloads for new tool calls, but keeps a metadata-only audit record including the tool, time, result, application user ID, connected-account ID and auth-config ID. Payloads stored before this setting was enabled are not deleted retroactively and may remain for Composio's default retention period of up to one year.

Disconnect and organization-deletion flows attempt to revoke upstream access before deleting the Composio connected account. When a provider does not support programmatic revocation, Ablo deletes the Composio record and tells the customer to remove Ablo’s access in the connected service’s account settings. No confirmation or support approval is required to continue or reconnect. Organization deletion schedules background cleanup of its workspace and project connections, including pending authorizations and accounts awaiting replacement cleanup. Transient revocation failures and failed deletions remain in a durable cleanup job and are retried. Unsupported revocation does not block deletion. If authorization has settled but revocation is unsupported or cannot be confirmed, Ablo removes the Composio record and keeps a notice asking the customer to check the connected service and remove unwanted access. Record deletion or a revoked account status alone is not confirmation of upstream revocation. Partial or unknown token revocation keeps the manual follow-up notice, which remains visible during pending setup. Notices remain after reconnecting; removing shared authorization in the external service may also disconnect a current connection. No further automatic revocation is scheduled for a removed account. Reconnecting replaces the old Composio record without revoking the upstream grant, preserving the newly authorized connection. Failed or superseded setup attempts also preserve upstream grants that a new connection may share, including when the first setup has not completed. Rejecting a replacement request while an account is still connected also preserves that account. These retired provider records may temporarily coexist with the new attempt; Ablo does not use them for integration operations. Their records are deleted after provider authorization completes, fails, expires, or is revoked. In-progress authorizations and cleanup failures are retried in the background without blocking a new setup. Rejecting a request while the connection is awaiting authorization, including a first-time setup, disables the connection and follows disconnect cleanup, including attempted upstream revocation. New authorization can start while this cleanup waits or retries. When a new authorization starts, cleanup of older accounts skips upstream revocation to protect access that the new connection may share, and deletes only the retired provider records. New authorization waits while Ablo awaits a revocation response. A timeout, failed request, or recovery of an interrupted worker releases this wait and immediately shows a persistent warning. An accepted provider request may still finish later and interrupt the new connection, requiring another sign-in. Organization deletion continues to attempt revocation because new connections are not permitted in a deleted organization.

Opening HTML deliverables may contact external services chosen by you or your agents. Those services may receive browser information and document data sent by scripts; their own privacy and retention terms apply.

PostHog analytics runs only with the appropriate consent. Session replay is disabled in authenticated product areas. Ablo does not intentionally include workspace content, prompts, responses, integration payloads, credentials or other customer secrets in analytics, error telemetry or routine logs.

Reddit advertising measurement requires separate opt-in and sends only public-page visits and completed signup or confirmed booking signals with browser and advertising identifiers. Reddit may use these signals for personalized ads. No contact details, workspace content or private dashboard URLs are passed to Reddit. Backend-verified signup and booking events also use the Conversions API with shared opaque conversion IDs. Withdrawal stops further pixel activity and cancels pending backend delivery once received; already received signals remain subject to Reddit’s retention and deletion rules.

Error telemetry is limited to stable event and error-class names plus operational identifiers, status codes, timing and counts. Error messages, stack traces, request and response payloads, and raw error objects are excluded. Necessary security and delivery logs are kept separately from product analytics where practical, with access limited to people who operate, secure or support the service.

Booking buttons open an embedded Cal.com calendar only after a visitor clicks to arrange a call. Ablo does not preload the calendar. Visitors choose what information to submit in the booking form.

Deleting an organization removes access immediately. Ablo's policy is to complete deletion from active systems within 30 days, including Ablo data, agent tasks and files, integrations, repositories, analytics identities and object storage.

Data may be retained longer only when law requires it. Norwegian primary accounting records may be isolated and retained for five years, or longer where a specific legal obligation applies. Legally retained records are separated from deleted product content and are not reused to provide the product.

Backups are retained only for a documented, time-bounded recovery window. Deleted customer content is not restored to active service except when necessary for disaster recovery, after which the deletion process resumes.

Questions or privacy requests can be sent to privacy@ablo.no. General product support is available at support@ablo.no.