Security & privacy

This page is the reference for IT-security review. It describes how credentials, customer data, and access controls work end to end across DPP Agent.

Vault {#vault}

Every credential stored on DPP Agent — Akeneo OAuth secrets, Centra API tokens, Shopify storefront tokens, SMTP passwords, LLM provider keys — is encrypted at rest using AES-256-GCM under a master key held only in our hosting platform's encrypted environment-variable store. Plaintext never persists to disk and never appears in our application logs. The specific environment variable name is treated as confidential and is not published here.

Encryption is at the row level (per credential), not at the database level, so a database backup leaking does not constitute a credential leak. The master key has a target quarterly rotation cadence; re-encryption is automated via a maintenance script and is run on rotation events or on customer request.

Credentials are displayed in the admin UI as a fingerprint (first-4 + last-4) only — never as plaintext. The original is write-only: once saved, the operator cannot retrieve it. To rotate a credential, paste the new one over the old (which clears the row).

OAuth scopes per integration

We request the minimum read scope per provider. We never request a write scope unless the adapter genuinely needs to push data back (none of the current adapters do).

If a customer's compliance team requires a written attestation, we can issue one per integration on request.

Network egress and IP allowlisting

DPP Agent runs on Vercel. Outbound calls to your PIM or commerce backend originate from Vercel's edge regions. Per-region IP ranges are published at https://vercel.com/docs/edge-network/regions.

Brands operating Akeneo, Centra, or any other connected system behind a WAF or IP allowlist can restrict inbound traffic to those ranges so no other tenant of Vercel — and no actor outside it — can reach the brand's system through our network path.

Roles and permissions {#roles}

Per-tenant role model. Roles are assigned by tenant owners or DPP Agent staff during onboarding:

Role transitions are audited via role_access_audit. Ownership transfer requires two-party confirmation: the current owner initiates from the tenant settings, a 24-hour token is generated, and the prospective new owner confirms by signing in and accepting at /accept-ownership/<token>. The previous owner is demoted to admin on confirm. Audit row + before/after state are kept indefinitely in tenant_ownership_transfers.

A finer-grained section-audience role model (per-section visibility and edit rights, default-deny) is in design — see the internal ROLES-ACCESS-DESIGN document. Available on request for enterprise tenants.

Data residency

Customer data (tenants, dpp_runtime, tenant_integrations) lives in a Supabase Postgres instance hosted in the eu-central-1 AWS region (Frankfurt). Backups are retained for 30 days, also in the EU. No data crosses the EEA boundary at rest.

Logs and analytics live in a separate Postgres instance, same region, same retention.

Deletion {#deletion}

Three deletion modes apply at three different levels:

• Draft DPP — can be hard-deleted from the admin (single or bulk). Drafts have never been publicly resolved, so no record retention requirement applies.
• Active / withdrawn / archived DPP — cannot be hard-deleted. EN 18223 §4.1.2 requires retention of any DPP that has ever been publicly resolved. The pragmatic equivalent of "delete" is to transition the row to archived; the public URL returns 410 Gone with a branded notice.
• Tenant — full tenant deletion is a manual two-party operation handled by DPP Agent ops. Customer data is wiped, integrations revoked, credentials shredded, audit log retained for 6 months per our contractual SLA.

GDPR right-to-erasure requests from consumers are not directly applicable to DPPs, since DPPs describe products, not people. Where a DPP accidentally references PII (e.g., a brand-side comment with an employee name) the field can be cleared via the admin and the change audited.

Indexing {#indexing}

Default policy: no search-engine and no LLM-crawler indexing.

Every active DPP response carries two indicators that the major crawlers honour:

<meta name="robots" content="noindex,nofollow,noarchive">

X-Robots-Tag: noindex, nofollow, noarchive

This blocks Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot, and the bulk of well-behaved AI crawlers. The brand opts in to indexing per-tenant via tenants.allow_search_indexing = true — only relevant if the brand wants the DPP to appear in search results (e.g., for marketing reasons).

Brands operating consumer-DPPs for sensitive product categories (infant care, regulated chemicals, defence-adjacent goods) should leave indexing off.

Audit log

Meaningful actions are recorded across four append-only sources:

• dpp_runtime_versions — per-DPP value diffs and status transitions (full before/after snapshot per change).
• tenant_theme_versions — theme palette and logo changes.
• integration_sync_log — every integration sync run, success or failure, with row counts and provider response codes.
• role_access_audit — access-control changes (member added, removed, role changed). Available with the section-roles rollout — see roadmap below.

Logs are accessible via the admin UI on the relevant tenant detail and via the audit-log export API:

GET /api/admin/audit-export.csv?tenant=<tenantId>&since=<ISO>

This endpoint requires staff authentication and unions the four sources above into one CSV for SOC review. Default retention is 90 days for the UI surface; underlying tables retain longer (see the table-by-table retention statement in our DPA on request).

Incident response

We follow a 1-2-4 playbook — 1 hour to customer notification, 2 hours to initial scope statement, 4 hours to public post on status.dppagent.com. Full process, severity definitions, roles, and post-mortem cadence are described in the Incident response chapter.

Internal tabletop exercises run on a target quarterly cadence. Post-mortems are shared with affected customers under NDA on request.

Penetration testing

External penetration test scheduled annually — next engagement planned for Q3 2026. Internal review and dependency scanning is continuous via the build pipeline. We participate in coordinated disclosure for vulnerabilities found in our open-source dependencies and contribute fixes upstream where possible.

Prior or current test reports, when available, are shareable under NDA.

Subprocessors

A complete subprocessor list — with purpose, region, and DPA link per provider — is shareable on request as part of the procurement review. Material changes are announced via email to tenant owners; the notice period is governed by the customer's Data Processing Agreement (default 30 days for enterprise tenants).