Privacy Policy

Dibbla AB (“Dibbla,” “we,” “us,” or “our”), registered in Sweden, operates the Dibbla platform — including the web application at app.dibbla.com, the Dibbla CLI, the Dibbla Desktop App, and related APIs (collectively, the “Service”). This Privacy Policy (“Policy”) explains what personal data we collect, why we collect it, how we use and protect it, and what rights you have.

By using the Service you acknowledge and agree to this Policy. If you do not agree, please discontinue your use of the Service.

1. Definitions

• “Personal Data” means any information relating to an identified or identifiable natural person, as defined in the EU General Data Protection Regulation (GDPR).
• “Customer Data” means the workflows, configurations, and content you create or upload within the Service. Customer Data is processed solely to provide the Service.
• “Customer Personal Data” means Personal Data contained in Customer Data — including Personal Data belonging to your own end users — which Dibbla processes on your behalf as a processor under our Data Processing Agreement.
• “Service Data” means operational data such as error logs, uptime metrics, and aggregate usage statistics. Service Data is used for security, reliability, and product improvement and is not Personal Data.

2. Our Roles: Controller and Processor

Dibbla processes Personal Data in two different roles. Which role applies decides which document governs the processing and who you turn to with a request.

Dibbla is the controller for the Personal Data we need in order to run Dibbla as a service: your account and authentication data, organisation membership and roles, billing details, support correspondence, security and operational telemetry, and visits to our marketing website. We decide the purposes and means of that processing, and this Policy describes it in full.

Dibbla is a processor for the Customer Personal Data your organisation brings to the Service — whatever lives inside the applications you deploy and their databases, storage buckets, files, workflows and application logs. We process that data only on your organisation’s documented instructions, to provide the Service. Your organisation is the controller for it (or is itself a processor, where it acts on someone else’s behalf) and is responsible for the lawfulness of the data it brings to the Service and for informing the data subjects concerned. Those terms are set out in our Data Processing Agreement (DPA), which forms part of the Terms of Service and becomes binding when your organisation accepts them — no signature required. Where the DPA and this Policy say different things about Customer Personal Data, the DPA prevails.

Two practical consequences. If you are an end user of an application someone else built on Dibbla, your access, correction or erasure request goes to that organisation and not to us; if we receive it, we forward it to them without undue delay and do not act on it ourselves except on their instruction. And if you are a Dibbla customer, the third parties we engage to process Customer Personal Data on your behalf are named, in tiers with the condition under which each one applies, in the Sub-processor List, which is incorporated into the DPA by reference and which you can subscribe to for advance notice of changes.

You can reach us in either role at [email protected].

3. Personal Data We Collect

Authentication data

When you sign in with Google or Microsoft, we receive and store:

Data	Purpose
Email address	Account identification, login, and communication
Display name	Shown in the application UI
Provider user ID	Linking your identity to your Dibbla account
OAuth refresh token	Maintaining your session and accessing APIs you have authorised (encrypted at rest)

Your profile picture URL is retrieved during sign-in for display purposes but is not stored in our database.

Automatically collected data

• Account activity — last login timestamp, organisation membership, and assigned roles.
• Session data — a secure, HTTP-only authentication cookie.
• Log data — operational telemetry such as error codes, request timestamps, and performance metrics, used for debugging and security monitoring. Personally identifiable information is not written to logs by default.

Contact forms

If you submit a contact or demo request form on our marketing website, we collect your name and email address. This data is forwarded by email only and is not stored in a database.

Sensitive data

We do not intentionally collect special-category or sensitive Personal Data, and we instruct users not to upload such information to the Service.

4. Google API Scopes and Limited Use

When you sign in with Google, we request only the permissions necessary to verify your identity and retrieve your basic profile information (email address and display name). If you connect Google Workspace integrations within a workflow, additional permissions may be requested at that time. You can revoke access at any time from your Google Account permissions page.

Google API Services User Data Policy: Dibbla's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• We only use Google user data to provide and improve the features you have explicitly authorised.
• We do not use Google user data for serving advertisements.
• We do not sell Google user data to third parties.
• We do not use Google user data for purposes unrelated to the Service.
• We do not allow humans to read Google user data unless we have your affirmative agreement, it is necessary for security purposes, to comply with applicable law, or the data is aggregated and anonymised for internal operations.

5. AI Connectors (MCP)

Dibbla can be connected to an AI agent — Claude, ChatGPT, Codex, the Dibbla CLI or any other client that speaks the Model Context Protocol — through the Dibbla connector at mcp.dibbla.com/platform. This section describes what a connected agent can reach, on what terms, and how you disconnect it. It applies in addition to, not instead of, the rest of this Policy.

What a connector can reach

A connector acts as you, in one organisation. It never gets its own standing account and never sees anything you could not see yourself. Within that boundary, and only for the permissions you approved, it can reach:

• Your identity and the granted organisation — your email address, display name and the organisation the grant was issued for.
• Applications and deployments — application inventory and configuration, deployment history, and deployment pre-checks.
• Logs — bounded windows of your applications' runtime logs, which may contain whatever your own application writes to them.
• Application checks — their definitions, results and history.
• Secret names, never secret values. A connector can list which secrets exist and set or rotate them; there is no permission that reads a secret value back, and the pattern is structurally excluded from the permission registry.
• Databases and storage — inventory and status, provisioning, and, where separately approved, reading rows through a server-owned structured query surface. Raw SQL is structurally excluded.
• Files, workflows and long-running operations — file metadata and download tickets bound to the requesting principal, workflow definitions and executions, and the status, events and logs of operations already under way.

The connector does not reach your Google or Microsoft account. Those are separate authorisations, described in Section 4.

Access is limited to the permissions you approve

Every connector permission is a named scope, and no scope implies another. Consent defaults to read-only: write permissions are unticked on the consent screen and only granted if you tick them, and destructive permissions (deleting an application, database, bucket, file or workflow, or restoring a database over its current contents) additionally require a separate, bound confirmation at the moment the action is taken — the permission alone is not enough.

Each access token is bound to the exact resource, client, user, organisation and set of scopes it was issued for, and every call is checked against all of them. A token cannot be re-used against a different organisation, a different client or a wider set of permissions; a refreshed token can only ever narrow its scopes, never widen them.

How long connector tokens live

Credential	Lifetime
Authorisation code (issued at consent, exchanged once)	60 seconds, single use
Access token (what the agent presents on each call)	1 hour
Refresh token (used to obtain a new access token)	30 days, rotated on every use
Client registration for a dynamically registered agent	30 days

Because the refresh token is rotated on every use, an agent you keep using stays connected indefinitely without you re-approving it — and an agent you stop using falls out of access on its own within 30 days. If a refresh token is ever presented twice, the whole token family and the underlying grant are revoked immediately: the legitimate holder and a thief are indistinguishable at that moment, so both lose access and you re-authorise.

Disconnecting an agent

You can disconnect a connected agent yourself, at any time, without contacting us. The current instructions are in the platform connector guide.

Revocation takes effect on the next call, not when the access token expires. Although an access token is valid for up to an hour, its validity is resolved against our database on every single request, so a grant revoked a second ago is refused a second later. Revoking a grant also invalidates every refresh token issued under it, and signals work already running on your behalf to stop. Nothing you have to wait out.

Records of what a connector did — audit entries and operational logs — are retained under Section 11 (Data Retention and Deletion) after the grant is gone. Revoking access stops future activity; it does not erase the record of past activity.

Questions and abuse reports

For anything about connector access — including reporting an agent, client or grant you believe is being misused — write to [email protected]. We act on connector abuse reports within one business day, and can revoke an individual grant, an individual client, or a whole registered client immediately.

6. How We Use Your Data

We process Personal Data for the following purposes:

• Providing and operating the Service — authentication, account management, and workflow execution.
• Organisation management — associating you with the correct organisation and enforcing access control.
• Third-party integrations — accessing connected services on your behalf when you have authorised them.
• Security — detecting unauthorised access, validating sessions, and preventing fraud or abuse.
• Service improvement — understanding usage patterns to improve reliability and features.
• Communication — responding to support requests and sending essential service notifications.
• Legal compliance — meeting regulatory and record-keeping obligations.

We do not use your Personal Data or Customer Data to train general-purpose AI models. We do not engage in automated decision-making that produces legal or similarly significant effects on individuals.

7. Legal Basis for Processing (GDPR)

• Contract performance (Art. 6(1)(b)) — processing necessary to provide the Service.
• Legitimate interest (Art. 6(1)(f)) — security monitoring, fraud prevention, and service improvement, where not outweighed by your privacy rights.
• Consent (Art. 6(1)(a)) — for optional integrations and non-essential cookies. You may withdraw consent at any time without affecting the lawfulness of prior processing.
• Legal obligations (Art. 6(1)(c)) — where required by applicable law.

8. Data Storage and Security

All user data is stored on servers located in the European Union. We implement industry-standard security measures including:

• Encryption of sensitive data at rest and all data in transit (TLS).
• Secure, HTTP-only authentication cookies with CSRF protections.
• Short-lived access tokens cached in memory only — never persisted to disk.
• Role-based access control with organisation-level data isolation.
• Immediate session invalidation on logout.

In the event of a data breach that poses a risk to your rights, we will notify affected users and the relevant supervisory authority within 72 hours, as required by the GDPR.

9. Data Sharing

We do not sell, rent, or share your Personal Data for marketing or advertising purposes. Data is shared only in these limited circumstances:

• Infrastructure and service providers — we use third-party providers for hosting, network security, and email delivery. These providers act as data processors under appropriate contractual safeguards. The ones that process Customer Personal Data on your behalf are our sub-processors: each is named, with its purpose, location, transfer safeguard and the condition under which it applies, in the Sub-processor List. Providers that only process data outside a customer’s applications — for example Stripe for billing — are listed there too, so the list is the single place to see who touches data because of Dibbla. Sub-processors that apply only when you enable an optional feature, such as an AI provider, are marked as such and process nothing until you do.
• Third-party APIs — when you authorise an integration (e.g. Google Workspace), your tokens are used to communicate with that provider's APIs on your behalf.
• Legal obligations — we may disclose data if required by applicable law, regulation, or court order.

We do not use third-party analytics or tracking within the application. Our marketing website uses cookies for B2B visitor identification — see our Cookie Policy for details.

10. International Data Transfers

Your Personal Data is stored within the EU. Where data is transferred to providers outside the EU/EEA, we rely on EU Standard Contractual Clauses (SCCs) or equivalent safeguards recognised under the GDPR. We do not transfer Google user data outside the frameworks permitted by the Google API Services User Data Policy. The Sub-processor List states the location of processing and the transfer mechanism for each sub-processor.

11. Data Retention and Deletion

We keep Personal Data only as long as we need it for the purposes described in this Policy, or as long as the law requires. The table below is the authoritative statement of how long each kind of data lives on the managed Dibbla platform, and it is the retention schedule the Data Processing Agreement refers to. Periods are the ones that apply to production, where customer data lives.

What	How long we keep it	What ends it
Account data — your user record, organisation memberships, roles, invitations, per-application access, connected Google/Microsoft accounts	While your account and organisation exist	Deleting your account or your organisation. All of it is removed within 30 days of the request, in most cases immediately
Browser session	24 hours per issued cookie	Expiry, logging out, or any change of role or organisation — each invalidates every cookie already issued to you
CLI session	30 days of inactivity, 90 days maximum	Expiry, dibbla logout, or account deletion
API tokens	The expiry you choose when you create one	Revoking the token, or account or organisation deletion. An expired token is refused immediately
AI connector tokens and grants	Access token 1 hour, refresh token 30 days (rotated on every use), the grant itself until you revoke it	Disconnecting the agent; organisation deletion. See Section 5
Platform logs — operational logs from our services and from the applications you deploy, including whatever your own application writes to its output	180 days, then deleted automatically. Logs carry pseudonymous identifiers (user and organisation ids), not e-mail addresses	Age-out. Deleting an application also requests deletion of its logs. We keep logs longer than everything else deliberately, to be able to investigate security incidents that surface late
Connector audit records — one entry per change a connected AI agent makes, and per secret operation: what happened, by which client and user, with what outcome. Never a value	180 days, as above, pseudonymous	Age-out. Revoking a grant stops future activity; it does not erase the record of past activity
AI request and response content — prompts, responses and attached media passing through the Dibbla AI gateway, if you use AI features	30 days, erased by an automatic hourly sweep	The sweep. What remains afterwards is a usage record (model, token counts, timing, user and organisation id) with no content, kept for billing while the organisation exists
Deployment records — which version was deployed, by whom, from which source and with what outcome	While the organisation exists	Organisation deletion
Your source code and deployed applications — the repository an application deploys from, its deployed files and uploaded archives	While the application exists. Offsite copies: the last 30 nightly backups	Deleting the application removes it at once; backup copies age out within 30 days
Files in object storage	While the organisation exists	Deleting the object or the bucket. Offsite copies of deleted or overwritten objects age out within 30 dated backup generations
Support tickets — tickets raised from your applications, their comments and attachments, including the reporter’s name and e-mail	Open: while the application and organisation exist. Closed: 24 months after the ticket is closed	Automatic daily sweep, or deletion on request
Notifications — what was sent, to which address, and whether it arrived	Subscriptions and their delivery addresses while the organisation exists; delivery records are kept as operational records. Unsubscribe tokens: 90 days	Removing the subscription; organisation deletion. Notifications never carry your code, prompts, log excerpts, database rows or secrets
Database backups — of platform databases and of the databases you run on Dibbla	A deleted row is gone from every backup after 30 days (a 7-day point-in-time recovery window plus 30 nightly copies)	Age-out only. Backups are never edited to remove individual records — this is the 30-day figure the DPA refers to
Billing records — customer, subscription and invoices, held by Stripe; we store only the identifiers	Invoices are accounting records and are kept for 7 years under Swedish law	Legal obligation. Nothing shortens it
Contact and demo forms on our marketing website	Not stored in a database	Forwarded by e-mail only

What deletion actually removes

Deleting an application removes its workload and addresses, its volumes and everything on them, its secrets, its container images, its database records, the repository it deploys from, and requests deletion of its logs. Managed databases and storage buckets are deliberately not removed with the application — they belong to your organisation, can be shared between applications, and are named in the output with the command that deletes them.

Deleting your organisation removes, in one operation, the organisation and its memberships, invitations, access lists, custom domains, connected accounts, API tokens and connector grants, and then propagates to the platform: applications, deployment records, databases, buckets and AI-gateway records keyed to that organisation are removed as well. Deleting your account removes your user record, your connected accounts and tokens, and your personal organisation the same way.

What survives a deletion, for as long as the periods in the table allow, is the operational record: logs, connector audit entries and backup copies. They are not edited on request, they age out. That is what lets us investigate a security incident after the fact, and it is the one place where erasure is bounded by a period rather than by an action.

To request deletion, or to ask us to confirm one, contact us at [email protected]. If the data you are asking about lives inside an application built by a Dibbla customer, see Section 2 — the request belongs with that organisation, and we will forward it.

12. Your Rights

Under the GDPR you have the right to: access, rectify, erase, restrict, or port your Personal Data; object to processing based on legitimate interest; and withdraw consent for optional processing at any time without affecting the lawfulness of prior processing.

To exercise any of these rights, contact us at [email protected]. We will verify your identity and respond within 30 days. If you believe your request has not been satisfactorily resolved, you may lodge a complaint with the Swedish Authority for Privacy Protection (IMY) or your local supervisory authority.

13. Cookies

The application uses a single, essential authentication cookie to keep you signed in. It is HTTP-only, Secure, and SameSite. We do not use tracking, advertising, or non-essential cookies within the application. For cookies on our marketing website, see our Cookie Policy.

14. Third-Party Services

The Service may link to or integrate with third-party services not controlled by Dibbla. Your interactions with those services are governed by their own privacy policies. We encourage you to review them before sharing Personal Data.

15. Children's Privacy

The Service is not directed at individuals under the age of 16. We do not knowingly collect Personal Data from children. If you believe a child has provided us with Personal Data, please contact us and we will delete it promptly.

16. Changes to This Policy

We may update this Policy from time to time. For material changes that reduce your rights or expand our processing, we will provide advance notice via email or through the Service. The “Last updated” date at the top reflects the most recent revision.

17. Severability

If any provision of this Policy is found to be unlawful or unenforceable, it will be severed and the remaining provisions will remain in full force and effect.

18. Contact Us

Dibbla AB
Email: [email protected]
Website: dibbla.com

© 2026 Dibbla AB. All rights reserved.