Kindgi Cloud: data processing addendum

Version 1.1; effective November 4, 2026

This addendum is part of the Kindgi Cloud terms between your organization (“you”) and Kindgi Inc., a Delaware corporation (“Kindgi”, “we”). It covers the personal data we process for you when we run Kindgi Cloud. When you accept the Kindgi Cloud terms at sign-up, you accept this addendum too. We record which version you accepted, and when. If you want a copy signed by both of us, write to contact@kindgi.com.

If this addendum and the Kindgi Cloud terms disagree about personal data, this addendum wins. If the standard contractual clauses apply (section 11) and disagree with this addendum, the clauses win.

1. Who does what

• You decide what Kindgi Cloud processes, and why. You build the packs (your agents, tools and flows), choose what data they handle, and add the people who use your workspace.

• We process that data only to run Kindgi Cloud for you. Under the GDPR we’re your processor. Under the CCPA we’re your service provider, and under the other US state laws your processor.

• If you build for clients (an agency, for example):

  • your clients are usually the controllers of their customers’ data;
  • you’re their processor, and we’re your sub-processor.

  You confirm that your clients have authorized you to use us, on terms at least as protective as these. You pass on to us what they instruct, and we treat it as your instruction.

• Your Kindgi account itself is different. We’re the controller for:

  • your organization’s sign-up, its billing contact, tax details and subscription;
  • the usage counts behind your limits and your usage page;
  • the records we keep to secure sign-in to Kindgi Cloud and to prevent abuse (for example, the bot check and sign-in limits).

  Privacy at Kindgi explains how we handle those, not this addendum. What’s in your workspace, including the people you add and their sessions, keys and sign-in history there, is your data under this addendum.

  One exception: we read your workspace admins’ names and email addresses to send you service notices (incidents and breaches, maintenance, changes to sub-processors or terms). For that use, we’re the controller of those contacts. We read nothing else of your workspace’s for our own purposes.

2. What we process

Annex I describes the processing:

• whose data it is: your people, your clients’ people, the people who talk to your agents, and anyone your agents’ data names;
• what kinds: account details, runs, conversations, memory facts, approvals, secrets, the audit trail, logs;
• why: to run your packs and keep their records.

We don’t choose or inspect the content. It’s whatever your agents and tools handle.

Sensitive information: don’t use Kindgi Cloud for the kinds below unless we’ve agreed in writing:

• health records covered by HIPAA or a provincial health privacy law;
• payment card numbers;
• government identity numbers;
• the GDPR’s special categories (health, religion, sexual orientation and the others in its Article 9).

If your agents handle some anyway, the same protections apply (Annex II), and you’re responsible for having a legal basis.

3. Your instructions

We process personal data only on your documented instructions, and those are:

• these terms: the Kindgi Cloud terms and this addendum;
• how you configure Kindgi Cloud, through the console, the API and the CLI: what your packs do, which model provider and systems they call, your retention settings, your erasure requests;
• anything else you ask in writing that we agree to.

We don’t process it for any other purpose, unless a law we’re subject to requires us to. If one does, we’ll tell you before we do it, unless that law forbids telling you.

If we think an instruction breaks the GDPR or another data protection law, we’ll tell you straight away. We don’t have to follow it until it’s resolved.

When your packs call other services, that’s your instruction:

• your model provider, under your own key (“bring your own key”);
• your client’s store or site;
• an MCP server you registered;
• a webhook receiver.

We send them what your packs send. Those services aren’t our sub-processors: your agreement with each of them applies.

We never use your data to train AI models, ours or anyone else’s. We don’t have models of our own.

4. Our people

• Confidentiality: everyone at Kindgi who can reach your data is bound to keep it confidential, by their employment or contract terms.
• When our people look at your data: only in these cases.
  • You ask us to, for support. We tell you what we looked at.
  • To investigate or fix an incident, or abuse of the service.
  • When the law requires it.
• How it’s controlled:
  • Who: Kindgi’s founder. Anyone else only once Kindgi names them in its access procedure, and only after they’re bound to confidentiality.
  • For support: you add the named person to your workspace as a member, with the role the task needs, and remove them afterwards. We have no other way into your workspace’s data through the product. You see the membership, and your audit trail records every access.
  • For an incident or the law: access to production goes through Google Cloud’s identity and access management only, with a credential that lasts at most one hour and isn’t kept on the computer. No shared accounts, and no standing credentials on laptops.
  • How long: support access ends when the request does, and incident access ends with the incident. Each is removed the same day.
  • How it’s logged: in your workspace’s audit trail (support access), in Google’s admin-activity logs (every change to access), and in Kindgi’s access record: who, which customer, why, when, and what was looked at.
  • Review: we review who has access every three months, and whenever someone joins or leaves.
• AI assistants never read your content. We use AI assistants to help us build and operate Kindgi. They work under an identity of their own, which can’t read your data: not the database’s contents, not your secrets, not your exports. So no AI provider receives your content from us, and none is on our sub-processor list.

5. Security

We protect your data with the measures in Annex II. They include:

• each workspace’s data kept apart in the database;
• each workspace’s code run in its own sandboxed service;
• encryption in transit and at rest;
• the secrets you store encrypted again by us;
• an audit trail.

We can change a measure, but never in a way that lowers the protection overall.

What v1 doesn’t have yet, said plainly: one encryption key wraps every workspace’s stored secrets in Kindgi Cloud. A separate key per workspace is planned.

• What that means for deletion: deleting your secrets deletes them one by one. Copies in backups stay encrypted until those backups age out (section 9).
• When the separate keys arrive: we’ll update Annex II and tell you. Deleting an organization’s workspace will then also destroy its key, which makes its secrets unreadable everywhere, backups included.

6. Sub-processors

You authorize us to use the sub-processors on our list. Each is bound by a written contract that protects your data at least as well as this addendum. We stay responsible to you for what they do.

New sub-processors:

• Notice: we tell you at least 30 days before a new one starts processing your data. The notice goes by email to your workspace’s admins and billing contact, and on the list’s page.
• Objecting: you can object, on reasonable data protection grounds, within that period. We’ll talk it through.
• If we can’t resolve it, you can stop using the affected part of Kindgi Cloud, or close your account, without penalty. You pay only for what you used up to then.
• Urgent replacements: if we have to replace a sub-processor urgently, for security or because it stopped serving us, we tell you as soon as we can and the same objection right applies.

7. Helping you

• People’s requests (to see, correct, delete or move their data). Kindgi Cloud includes tools for them:

  • erasing a person’s data across memory, conversations, runs, approvals and the audit text;
  • exports and reads through the API.

  If you can’t do something with the tools, ask us, and we’ll help within 10 business days. If a person asks us directly, we send them to you and don’t answer for you.

• Your assessments: we give you the information about Kindgi Cloud that you reasonably need for:

  • data protection impact assessments, and consultations with an authority;
  • transfer impact assessments;
  • the CCPA’s risk assessments, cybersecurity audits and its rules on automated decisions;
  • Quebec’s privacy impact assessment for information leaving Quebec.

• Records: we keep the records of processing a processor must keep (GDPR Article 30(2)).

8. Breaches

If we learn of a breach that affects your personal data, we tell you by email without undue delay, and within 72 hours of knowing about it. Where a law requires it sooner, we tell you sooner.

• What we tell you, as far as we know it:
  • what happened, and when;
  • which data and roughly how many people;
  • the likely consequences;
  • what we’ve done and will do;
  • who to talk to at Kindgi.
• As we learn more, we tell you more.

“Breach” covers the GDPR’s personal data breach, PIPEDA’s breach of security safeguards, Quebec’s confidentiality incident, and a breach of security under US state laws.

Then:

• We help you meet your own duties: notifying authorities and people, and keeping PIPEDA’s breach records for 24 months.
• We don’t notify your clients, their customers or an authority for you, unless you ask or a law requires us to.
• Telling you isn’t an admission of fault.

For data subject to Quebec’s private-sector act, we also tell you of any attempt to breach the confidentiality of your data that we confirm was aimed at it.

9. How long we keep data, and deleting it

This section is Kindgi Cloud’s retention policy. It follows Kindgi’s decision of 2026-10-02: one retention and encryption policy, the same for self-hosted and Kindgi Cloud customers.

What you control

• Deleting something (an agent, a run, a conversation, a secret, an API key, a memory fact) takes it out of every list and read straight away. It stays stored, marked deleted, until a retention policy purges it.

• Retention policies, set per kind of record in your workspace:

  • each says how long a deleted record waits before it’s purged: at once, after a number of days, or never;
  • a sweep then purges what’s due, on a schedule or when you ask;
  • a purged record is gone for good, and each purge is recorded in your audit trail.

• Conversations and memory facts are purged only by a policy that names them.

• A finished run is purged together with its journal, under the run policy, counted from when it finished.

• Erasing a person works in two steps (Kindgi’s guide, “Erase a person’s data”).

  • From the moment it starts:

    • no memory read returns the facts it names, even before they’re cleared;
    • a new turn for that person (their conversation, or their participant id) is refused;
    • writing a new fact about them is refused.

    A turn of theirs that’s already running or waiting isn’t refused. The erasure cancels the waiting ones, and waits for one that’s executing, before it clears anything.

  • Then, in the background, it clears their data. That’s usually within minutes; it waits only for a turn of theirs that’s still executing. You can follow its progress. It clears:

    • their memory facts;
    • their conversations;
    • their runs’ inputs, outputs and journals;
    • the text of approvals, ratings, audit records and error messages that held their words.

  Ids, statuses, times and costs stay. Audit records under a legal hold keep their text, and the erasure counts them. A completed erasure keeps no readable record of whom it erased. So that a restored backup can be erased again, an erasure ledger keeps a keyed hash of whom each erasure named: only Kindgi Cloud’s own key can match it, and it reveals nothing without that key.

  Erasing a person covers the people your agents serve and talk about. It doesn’t remove a reviewer’s name from the approval decisions they made (below).

Kindgi Cloud’s defaults

• Finished runs and their journals: kept 90 days, then purged.
• Conversations and memory facts: kept until you delete them, or set a policy.
• The audit trail:
  • access decisions 90 days, refused ones 365;
  • run outcomes 730 days;
  • approval decisions and secret changes for as long as your account exists.
• Expired sign-in sessions, sign-in state and stored request answers: deleted every hour.

You can set shorter periods.

What deletion can’t reach

• Backups, until they age out after 30 days. If we ever restore one, we replay every erasure made since, so an erased person stays erased.
• Logs already written: kept 30 days, Cloud Logging’s default. At the default levels they don’t hold your runs’ inputs or outputs.
• The erasure ledger’s copies: keyed hashes only (above), kept 30 days, as long as the backups they serve, so a restore can replay erasures.
• A reviewer’s name on the decisions they made. Each approval decision keeps the name of the person who made it, as it was at that moment, in records that are never edited: the decision and its audit record.
  • Why: it’s your record of who approved each action, payments and refunds included. Erasure law allows keeping it for that (GDPR Article 17(3)(b) and (e)).
  • How long: for as long as your audit trail keeps approval decisions (the defaults above, or a shorter period you set). Then it goes with the decision.
  • So: if a reviewer asks to be erased, their account and anything else about them goes, but their name stays on past decisions until then.
• Copies outside Kindgi Cloud:
  • what your packs already sent elsewhere (your model provider, a webhook receiver, a client’s store);
  • signed exports you made.

When your account ends

• Nothing runs from the moment it ends: runs in progress are cancelled, and schedules, webhooks and deploys stop. Your workspace stays readable, so you can export it.
• For 30 days after it ends, you can export your workspace’s records, as files, through the API. The export covers the data stored in your workspace: its projects, agents, flows, tools and guardrails, runs, conversations, approvals, memory facts, artifacts, settings and the audit trail. Not in it: secret values, which can’t be read back, by design; your packs’ images, whose sources you hold; and your packs’ operational logs, which are kept for 30 days for operations (as above) and aren’t exported.
• Within 7 days after those 30 days, we delete your workspace: its records, its secrets, its packs’ services and images.
• Backups age out within 30 more days (as above). If we restore one before then, we delete your workspace from it again.
• What we keep: your account and billing records (see the privacy page), and nothing of your workspace’s content.

We confirm the deletion in writing.

10. Audits

What we make available, so you can check we meet this addendum:

• this addendum;
• its security annex;
• the sub-processor list;
• answers to one security questionnaire a year, plus more after a breach;
• Google Cloud’s certifications for the infrastructure Kindgi Cloud runs on (for example ISO/IEC 27001 and SOC 2, which are Google’s, not ours).

Kindgi itself has no certification yet. SOC 2 work is planned, and we’ll say so when it starts. We won’t claim a certification before we have it.

If that isn’t enough, you, or an independent auditor you choose who is bound to confidentiality, can audit our compliance:

• Notice: 30 days, at a time we agree.
• How often: once a year, unless there’s been a breach, or an authority requires it.
• Cost: yours.
• Scope: an audit doesn’t extend to other customers’ data, or to our sub-processors’ facilities; their own audit reports cover those.

11. Data outside your country

Where your data is stored: in the USA, in Google Cloud’s us-central1 region (Iowa), by Kindgi Inc., a US company.

• Its logs are stored in the USA too, in us-central1.
• Its database backups are stored in the USA too, in Google Cloud’s us multi-region.
• Sub-processors may process data where the list says.

From the EU, the EEA and Switzerland

Where the GDPR applies to your data and Kindgi Cloud receives it in the USA, the EU standard contractual clauses (Commission Implementing Decision (EU) 2021/914) apply between you and us, and are made part of this addendum:

• Module Two (controller to processor) if you’re a controller;
• Module Three (processor to processor) if you’re a processor for your clients.

The choices in the clauses:

• Clause 7 (the docking clause) applies.
• Clause 9(a): Option 2, general written authorization, with the notice in section 6 of this addendum.
• Clause 11(a): the optional redress wording doesn’t apply.
• Clause 13: the competent supervisory authority is the one Annex I.C names.
• Clause 17: Option 1, the law of Ireland.
• Clause 18(b): the courts of Ireland.
• Annexes I.A, I.B, I.C and II of the clauses are Annexes I and II of this addendum. Annex III of the clauses is the sub-processor list.

Switzerland: for transfers under Switzerland’s data protection act, the same clauses apply with these changes:

• the Swiss Federal Data Protection and Information Commissioner is the competent authority;
• references to the GDPR mean the Swiss act;
• people in Switzerland can bring claims there.

Government requests: if a public authority asks us for your data, we:

• check that the request is lawful, and challenge it where there are grounds to;
• tell you, unless the law forbids it;
• give only the minimum the request requires.

That’s what the clauses’ Clause 15 requires. We’ll give you the information you need to assess US law for your transfer impact assessment.

From the UK

Where the UK GDPR applies, the UK Information Commissioner’s International Data Transfer Addendum to the EU standard contractual clauses (version B1.0) applies too.

• Its Tables 1 to 3 are filled in from the clauses above and the annexes of this addendum.
• Table 4: neither party may end the Addendum when the Commissioner changes it.

From Canada

PIPEDA lets you transfer personal data to a service provider in another country. You stay accountable for it, and must protect it by contract, as principle 4.1.3 says. This addendum is that contract.

Canada’s privacy commissioner expects you to tell people their information may be processed in another country. There it can be reached by that country’s courts, law enforcement and national security authorities. Privacy at Kindgi gives wording you can reuse.

Quebec: if your data is subject to Quebec’s private-sector act:

• Before sending it outside Quebec, you do the privacy impact assessment its section 17 requires. Section 7 says how we help.
• Section 18.3’s written contract is this addendum:
  • confidentiality (section 4);
  • use only for your mandate (section 3);
  • nothing kept after the contract (section 9);
  • notice of breaches and attempts (section 8);
  • your right to check (section 10).

12. US state privacy laws

Where the CCPA or another US state privacy law applies to personal data we process for you:

• What we use it for: we’re your service provider or processor, and we use the data only for these business purposes:
  • hosting and running your packs, and the data they handle;
  • storing your workspace’s records: runs, conversations, memory, approvals and the audit trail;
  • sending your packs’ requests to the model provider and systems you configure;
  • emailing sign-in links and approval requests to the people you add;
  • keeping the service secure, finding and fixing errors, and preventing abuse;
  • meeting our legal obligations.
• What we don’t do with it:
  • we don’t sell it or share it, as the CCPA defines those words (including for cross-context behavioral advertising);
  • we don’t keep, use or disclose it for any other purpose, any other commercial purpose, or outside our direct business relationship with you;
  • we don’t combine it with personal information from other sources or other customers, except where the CCPA’s rules allow (for example, to detect security incidents).
• Our commitments:
  • The same protection the law requires of you: we comply with the law that applies, and protect the data as that law requires.
  • If we can no longer meet these obligations, we tell you within 5 business days.
  • Your right to check and to stop misuse: you can take reasonable steps to check we use the data as this section says (section 10). If you find unauthorized use, you can tell us to stop and to put it right, and we’ll work with you to do so.
  • Consumers’ requests: we help you respond to them (section 7).
  • Subcontractors: we pass equivalent obligations on to them, after the notice and objection in section 6.
• We certify that we understand these restrictions and will comply with them.

13. Liability

Each party’s liability under this addendum is subject to the limits in the Kindgi Cloud terms. Those limits don’t reduce anything the standard contractual clauses give the people whose data it is.

14. Contact

Privacy questions and notices: contact@kindgi.com (subject: “Privacy”), or Kindgi Inc., 500 Westover Dr #38104, Sanford, NC 27330, USA.

---

Annex I: the parties and the processing

A. The parties

	You	Kindgi
Name, address	As given at sign-up	Kindgi Inc., a Delaware corporation, 500 Westover Dr #38104, Sanford, NC 27330, USA
Contact	Your workspace’s admins and billing contact	contact@kindgi.com (subject: “Privacy”)
Role	Controller, or processor for your clients	Processor, or your sub-processor
Activities	Building and running agents, tools and flows	Running Kindgi Cloud
Accepted	At sign-up, with the version and time recorded	—

B. The processing

Whose data:

• your people, and your clients’ people, whom you add to your workspace;
• the people your agents talk to: on a shop’s website, for example, or by email;
• people named in what your agents handle: a shop’s customers in an order, or someone a memory fact is about.

What data:

• Your workspace’s people:

  • name and email;
  • the sign-in account they’re linked to;
  • roles and grants;
  • sessions (stored as a hash, with the IP address and browser they were opened from);
  • API keys (stored only as a hash);
  • sign-in history.

• What your agents process:

  • runs, with their inputs, outputs and step-by-step journal;
  • conversations and their messages;
  • memory facts;
  • approvals (a proposed action and a reviewer’s reason);
  • evaluation copies of runs.

  The content is whatever your agents and tools handle.

• Your secrets: credentials for the systems your tools call, encrypted (Annex II).

• Model-call records: cost and token counts. What a model was sent is in the run’s journal.

• The audit trail:

  • access decisions;
  • approval decisions;
  • run outcomes;
  • secret changes, never a secret’s value.

• Logs: request records (method, path, status, timing, and the request’s and the workspace’s ids). At the default levels they don’t include runs’ inputs or outputs, and values that look like secrets are redacted.

Sensitive data: none intended (section 2). If your agents handle some, Annex II applies to it as to everything else.

What we do with it:

• Storing it, and running your packs on it.
• Sending it on your instruction (section 3):
  • your packs’ calls to the services they name;
  • prompts to the model provider you configure;
  • emails to the people you add.
• Purging and erasing it as section 9 says.

Why: to provide Kindgi Cloud under the Kindgi Cloud terms.

How long: while your account exists, then as section 9 says.

How often: continuously, while your packs run.

Sub-processors: for hosting and email, as the list says.

C. The competent supervisory authority (for the standard contractual clauses)

• If you’re established in the EU: your lead supervisory authority.
• If you’re not, but have an EU representative: the authority where your representative is.
• Otherwise: Ireland’s Data Protection Commission.

Annex II: security measures

Keeping workspaces apart

• Every stored record carries its workspace’s id. PostgreSQL row-level security limits each query to the workspace it runs for.
• Requests run as a database role that can’t bypass those rules, so a query that forgot its workspace finds nothing.
• One server serves many workspaces, and a test suite of attacks between two workspaces runs against the real service before launch and with each release.
• Each workspace’s code (its packs) runs in its own Cloud Run service, inside Google’s sandbox.
  • Its identity holds no permissions, and only Kindgi Cloud’s server may call it.
  • It reaches the public internet only. Private networks, Google’s internal ranges and Kindgi Cloud itself are blocked.
• Each deploy is built in its own isolated build:
  • the build can push only to its workspace’s own image repository;
  • no Kindgi secrets go into it, and no build cache is shared between workspaces;
  • the image’s digest is recorded and signed with the deployment.
• What a workspace’s configuration can’t make the server do: run commands on it, reach its own address, the cloud’s metadata service or private networks, or sign in to anything with Kindgi’s own credentials.

Access to the API and the console

• Every call needs a token or a personal API key.
  • Keys are stored only as hashes and compared in constant time.
  • A revoked key is refused from its next request.
  • A key acts with its holder’s permissions and no more.
• Sign-in is by an emailed link, or by Google, Microsoft or GitHub, or by your own identity provider for a domain verified for your workspace.
  • Only people added to the workspace get in, by an email their provider has verified.
  • The first sign-in links the account, so a reassigned address can’t take a person over.
• Sessions:
  • cookies the page’s scripts can’t read, stored only as hashes;
  • they end after 12 hours, or 1 hour without use;
  • a change made through a session must come from the console’s own origin.
• Permissions: an authorization service, run by Kindgi inside Kindgi Cloud, decides each action. It accepts calls only from Kindgi Cloud’s server.
• Abuse: a bot check on the sign-up and sign-in pages, and limits per organization on runs, concurrency and each pack’s resources.

Encryption

• In transit:
  • HTTPS at the public edge, behind Google’s load balancer and its web application firewall;
  • the server’s direct address is closed, so every request passes through them;
  • encrypted connections only to the database;
  • HTTPS with a Google-signed identity token and a per-deployment token on each call to a workspace’s code;
  • webhooks only to public https addresses, checked again at each delivery.
• At rest:
  • Google encrypts everything it stores, by default: the database, backups, logs, images and secrets.
  • Your secrets are encrypted again by Kindgi, each version with its own key, wrapped by a Cloud KMS key that rotates every 90 days.
  • A tool receives only the secrets it declares, per call. Nothing goes into your code’s environment.
  • You set your secrets yourself, from your own terminal. No Kindgi person sees them or places them.
• One key, for now: the Cloud KMS key is the same for every workspace until keys per workspace arrive (section 5).

Audit trail

• What’s recorded:

  • each access decision, allowed or refused;
  • each approval decision;
  • each run’s outcome;
  • each secret change, never its value.

  Each record carries its request’s id.

• How long it’s kept: section 9.

• Infrastructure changes: Google’s admin-activity logs record every change to Kindgi Cloud’s cloud resources.

Kindgi’s own people

• Production runs under Google Cloud’s identity and access management, with no shared credentials.
• Kindgi’s people don’t keep machine-wide cloud credentials on their computers.
• Access to your data: section 4.

Availability and recovery

• Daily database backups with point-in-time recovery, stored in the USA. A restore is rehearsed before launch and regularly after.
• Erasures are replayed after a restore.
• More than one server instance.
• Alerts reach a person at Kindgi, by email, for:
  • server errors;
  • crashes;
  • unusual sign-in activity;
  • the uptime check;
  • the budget.

Software integrity

• Each deployment of your code is signed with your key. Kindgi Cloud refuses one signed by a key you haven’t trusted, or have revoked.
• Images are pulled by digest from repositories with immutable tags, so what runs is exactly what was signed.

Incidents: a written runbook covers a suspected breach: contain, assess which organizations and data are affected, notify (section 8), review.

Annex III: sub-processors

The list.