Ampbase - Data Processing Agreement

This Data Processing Agreement (“DPA”) has two parts: (1) the Key Terms and Annexes on this page, and (2) the Common Paper DPA Standard Terms Version 1.1 (“DPA Standard Terms”), which are incorporated by reference. It supplements the Ampbase Cloud Service Agreement and governs Ampbase’s processing of Personal Data on Customer’s behalf.

How to execute. This DPA is available to all business customers on any paid tier. To execute it, email legal@ampbase.io from your account’s primary contact address with your organization’s legal name; we will return a countersigned copy pinned to the version shown above. The DPA takes effect when executed by both parties.

Key Terms

Agreement	The Ampbase Cloud Service Agreement between Provider and Customer.
Parties	Provider (processor / data importer): Ampbase, LLC. Customer (controller / data exporter): the entity executing this DPA. Where Customer acts as a processor for its own controllers, Provider acts as Customer’s subprocessor.
Approved Subprocessors	The current list at ampbase.io/subprocessors, which states each subprocessor’s purpose and the categories of data it processes. Provider will give at least 30 days’ advance email notice before a new subprocessor processes Customer Content, with a right to object as described on that page.
Provider Security Contact	security@ampbase.io
Security Policy	The technical and organizational measures in Annex II below.
DPA Liability Cap	As set out in Section 8 (Limitation of Liability) of the Agreement, including its increased cap for breaches of the Agreement’s privacy and security obligations. This DPA does not add a separate cap.
Governing Law and Chosen Courts	As set out in Section 12.3 of the Agreement (State of Delaware), except where the Standard Contractual Clauses require the law of an EEA member state, the United Kingdom, or Switzerland for the clauses themselves.
Restricted Transfers	For transfers from the EEA, Module Two (Controller to Processor) of the EU Standard Contractual Clauses applies (Module Three where Customer is a processor), populated by the Annexes below. For UK transfers, the UK International Data Transfer Addendum applies; for Swiss transfers, the SCCs as adapted for the Swiss Federal Data Protection Act.

Annex I(A) — List of Parties

Data exporter: Customer, acting as controller (or as processor on behalf of its own controllers), contactable via the primary contact on its Ampbase account.
Data importer: Ampbase, LLC, acting as processor, contactable at privacy@ampbase.io.

Annex I(B) — Description of Processing

Subject matter and purpose. Provision of the Ampbase control plane for agents running on Customer’s computers: configuration management and delivery, fleet health and inventory, billing and account administration, and the telemetry-intelligence features Customer enables. Processing consists of receiving, storing, organizing, displaying, and deleting the data described below, on Customer’s instructions as expressed through the Agreement, this DPA, and Customer’s configuration of the Service.

Duration. The Subscription Period, plus the deletion windows in the retention table below.

Frequency. Continuous, for as long as Customer’s agents and users use the Service.

Categories of data subjects

Customer’s users and members — the individuals who sign in to Ampbase on Customer’s behalf.
Customer’s personnel — developers and operators whose workstations, CI jobs, or hosts run agents managed through the Service. This includes employees whose AI coding-agent activity Customer elects to monitor.
Individuals appearing in Customer telemetry — on the customer-controlled paths that can carry un-reduced content (described below), telemetry may incidentally contain personal data of any individual it references. Customer controls whether these paths are active and what they carry.

Categories of personal data, by plane

Account and control plane. Name, email address, and avatar URL from Customer’s OAuth provider; organization, channel, and membership records; role assignments; billing contact details; sealed (encrypted) OAuth tokens Provider cannot read in plaintext; audit events. This is the bulk of the personal data Provider holds.

Telemetry-agent plane. Operational telemetry from Customer’s observability agents is reduced on Customer’s own hosts before it egresses — logs to structural templates, metrics to cardinality sketches, traces to aggregates. For those reduced streams Provider stores structure and counts, not raw content. Four paths can carry un-reduced content, each customer-controlled:

Supervisor own-logs — the raw stdout/stderr of Customer’s agents and the supervisor itself. Customer controls this stream and can disable it.
Scrubbed exemplars — optional, default-off, PII-scrubbed and length-capped sample values that Customer may enable per policy.
Transport-debug passthrough — a local, default-off supervisor setting for telemetry agent types that forwards raw telemetry alongside the reduced stream while an operator investigates a transport problem. Documented as not for production use, and rejected outright — the supervisor will not start — when combined with the AI coding-agent type.
Cloud coding-agent intake — described under the AI coding-agent plane below.

AI coding-agent plane. For coding agents on workstations and CI runners managed by the supervisor, what leaves the device is governed by the redaction tier and forwarding gates Customer sets (default: most-restrictive tier, all forwarding off):

Usage metadata (to Provider, opt-in). Per-session token counts, tool-call counts, session and model identifiers, durations, and — unless Customer enables edge identity-drop — workstation hostname, the supervisor’s per-workstation instance identifier, and the developer, team, and region labels Customer configures. With edge identity-drop enabled, the supervisor omits all of these identity fields at the workstation and no per-developer or per-workstation attribution is retained. Prompts, code, diffs, and command output are structurally excluded from this stream regardless of tier.
Redacted events (to Customer’s own endpoint, opt-in). Customer may forward tier-redacted events from its workstations directly to its own SIEM. Provider is not in the path of this stream and does not receive or store it.
Cloud coding-agent intake (customer-directed). Where Customer points a cloud-hosted coding agent’s telemetry export at its Ampbase ingest endpoint, that telemetry arrives without device-side redaction and may include content (for example, prompt text) as determined by the exporting product’s configuration. Provider stores these records in Customer’s partition for 30 days. Records that arrive without a supervisor’s stream marker are stamped as having had no device-side redaction, so downstream systems can distinguish them; a record whose exporter supplies its own (mis)labeling is Customer Content and is stored as submitted.

Security-agent plane. Raw security events from Customer’s eBPF security agents — process arguments, file paths, container and user identifiers — are written to Customer’s own host logs and never transmitted to Provider. Provider receives per-policy match counts only, not event content. (If Customer configures the security agent to print events to its standard output and enables the supervisor own-logs stream, that printed content travels the own-logs path disclosed above — two independent opt-ins, neither a default.)

Special category data. The Service is not intended for special categories of data, and the Agreement’s Prohibited Data restriction applies. Customer is responsible for not directing such data into the customer-controlled un-reduced paths above.

Retention

Data	Retention
Account records	Deleted within 30 days of account deletion.
Customer Content	Deleted within 60 days of a request on termination (per the Agreement). Organization deletion permanently deletes the organization’s content and infrastructure promptly, with no recovery window; deleting an individual channel retains its stored data for 24 hours before purge.
Agent own-logs and cloud coding-agent records	30 days.
Coding-agent usage metadata	Retained for the life of the account to support long-range spend and adoption views; deleted with the account. Customer can prevent per-person attribution entirely via edge identity-drop.
IP address / user agent on security audit events	90 days; the remaining non-identifying event is retained for the audit trail.
Billing records	7 years, as required for tax and accounting.

Data subject rights and deletion

Provider will assist Customer in responding to data-subject requests as described in the DPA Standard Terms. The mechanics — access, rectification, erasure, restriction, objection, and portability, self-serve account deletion, and the 30-day response commitment via privacy@ampbase.io — are described in the Privacy Policy, which this Annex incorporates for those procedures.

Annex I(C) — Competent Supervisory Authority

The supervisory authority of the data exporter, determined in accordance with Clause 13 of the EU Standard Contractual Clauses.

Annex II — Technical and Organizational Measures

Encryption. TLS for all data in transit; encryption at rest for object storage; application-layer sealing of secrets (OAuth tokens are sealed before storage and are never held in plaintext; Vault data is encrypted before it reaches the storage backend, which holds no keys).
Tenant isolation. Each customer organization runs as its own isolated application with its own storage bucket and its own analytics partition — per-organization isolation is structural, not row-level.
Data minimization on the customer’s hosts. Telemetry is reduced to structure and counts on Customer’s own machines before egress; coding-agent telemetry defaults to the most-restrictive redaction tier with all forwarding off; content capture is disabled at the source under restrictive tiers; a credential denylist strips secrets at every tier including the most permissive; surviving metadata is PII-scrubbed and length-capped; edge identity-drop removes personal attribution before egress when enabled.
Transparency and provenance. Every coding-agent event record carries the policy version and redaction posture that governed it; monitored individuals can inspect, on their own device, exactly what the policy sends off the machine.
Change control. Configuration and policy changes are versioned, append-only, and auditable; changes that increase the data leaving Customer’s machines require explicit confirmation and can be rolled out gradually and rolled back.
Access control and audit. Role-based access within organizations; administrative and security events are logged to an append-only audit trail.
Incident response. Security incidents are handled per the DPA Standard Terms; report suspected incidents to security@ampbase.io.
Deletion. Deletion and retention behavior as stated in the retention table above.

Contact

Questions about this DPA or to execute it: legal@ampbase.io. Privacy questions: privacy@ampbase.io.