Dembri DPO Agent Draft outputs. A named human approves.
04 · Data handling

How the DPO Agent handles your data

This page describes the running configuration of this instance. It is generated from the settings in force, not from marketing text.

Read from the configuration in force on this server

01What the tool reads

  • Website: public pages only. No login. Public addresses only. Redirects are re-checked at each hop. Response bodies are capped at 2 MB and 12 pages.
  • Git repository: a shallow, read-only clone over https only from github.com, gitlab.com, bitbucket.org, codeberg.org (no tags, no LFS, a 2 MB blob filter requested from the server as best effort, and a watchdog that aborts a clone that grows past the size limit; it measures the clone directory in a loop, so a fast transfer can overshoot by the amount received during one measurement before the abort), or a local path inside an allowed root. A local path is never scanned in place: its scannable files are first copied, one by one through directory descriptors (no symlink followed, regular files only, size caps), into the tool's own data directory, and the commit id is read from the .git/HEAD file as text. Git is never executed inside a directory the tool does not own, so a crafted local checkout's configuration (hooks, filter and diff drivers) can never run a program. On the clones the tool makes itself, every git command still runs with the checkout's executable configuration overridden; if that configuration cannot be read, the scan is refused. Git connects by itself, so the address check used for websites cannot pin it; the host allowlist and the public-address check apply instead, redirects are refused. Private GitHub repositories are read through the Dembri DPO Agent GitHub App: the organisation installs the app on the repositories it chooses, with one permission (Contents, read only), and can remove it in GitHub at any time. For each clone the tool obtains a token limited to that one repository and that permission; it lives one hour, is sent as an HTTP header to github.com only, and is never written to a file or a log. If the administrator configures a GitHub token for private repositories, it is sent as an HTTP header to github.com only, never placed in a URL or a log; the administrator must issue it as read-only (the tool cannot verify its scope), and it is visible to processes of the service user on this server.
  • OpenAPI specification: a URL or an uploaded file, parsed in an isolated child process.
  • MCP server: only servers the administrator declared. Only tools on the allowlist that the server itself marks read-only. Every call has a timeout and a budget. The server runs in its own process group behind a transport guard.
  • Documents: PDF, DOCX, Markdown, text, JSON, YAML, CSV that you upload. Parsed in an isolated child process with a memory limit.

02What leaves this server

  • A redacted digest of each evidence item: id, source, kind, locator, summary, an excerpt of the redacted text, metadata. "Collect evidence only" on the engagement page shows a snapshot of that digest before any model is called. A full run collects again, so the material sent can differ if a target changed; for MCP targets the collector model can also call the allowed read-only tools during assessment and receives their results.
  • Your organisation context text, redacted.
  • Model vendors in force: Anthropic (claude-sonnet-5-5) for collection and the data map; OpenAI (gpt-5.6-terra) for the DPO and ASO findings and the narrative.
  • OpenAI requests carry store=false. The vendor terms in force (training, retention) are the organisation's to confirm; the engagement records who confirmed them.
  • Not sent by design: original artefacts, uploaded files, repository contents beyond the stored excerpts, cookie values, lines that carry a secret-keyed value. Redaction is pattern-based; free text that names a person in other words is not detected.

03Redaction before storage

  • Emails, phone numbers, Emirates IDs, IBANs, card numbers, IP addresses, JWTs, API keys, passwords and private keys are replaced by markers before text enters the evidence store. Two things are stored unredacted on this server's disk until the retention period or deletion: the files you upload and the repository clones. They are never sent anywhere.
  • JSON is redacted by structure: any value under a secret-looking key is removed whole.
  • In repositories, a line that carries a secret-keyed value is never excerpted. The finding keeps the file and line only.
  • A keyed digest (HMAC-SHA256 under a server-side key, stored as hmac-sha256:<key id>:<hex>) of the original artefact is kept so the operator can prove provenance without the tool holding the data. A plain hash is not used, because a reader of the database or a report could test candidate secrets against it; plain hashes written by an earlier version are removed at startup.

04Retention

  • Evidence text, summary, locator and metadata are blanked after 90 days (the kind and the hash stay for the audit trail); uploads and clones older than that are deleted. The "what leaves" view reads the evidence rows, so it is blanked with them.
  • An engagement that was never approved is erased after 365 days.
  • An approved DPIA is kept 1095 days (accountability record), then erased.
  • The Delete engagement button erases all rows and files at once.
  • Every state change is written to an audit log that you can export per engagement.

05Isolation and review

  • Parsers and scanners run in child processes with a memory limit and a hard timeout.
  • Website and OpenAPI fetches pass a public-address check and are pinned against DNS rebinding. Git clones use a host allowlist instead (see above). MCP servers are separate programs the administrator declared; they make their own connections.
  • The service runs as an unprivileged user under a hardened systemd unit; only its data directory is writable.
  • Two independent model reviewers (gpt-6-astra and gpt-5.6-sol) review each code change before deployment. The repository holds the record (0 review transcripts so far); each transcript names the commit it reviewed and its verdict.
  • Host: https://dpo.trydembri.com.

06What the output is

  • A DPIA in the structure of the DIFC Commissioner's Article 20 worksheet and ISO/IEC 29134, with every finding tied to stored evidence and to a citation that exists in the bundled law corpus.
  • A ROPA and an AI systems register drafted from the same data map.
  • Everything is a DRAFT until a named person records a decision on each finding and approves the report version. A reviewer can override a blocker (open findings, incomplete coverage, unverified citations); the report records that override. The final step has no AI in it.