GDPR compliance mapping¶

The General Data Protection Regulation (GDPR) applies to AI agents that process personal data of EU residents. This page is for data protection officers and privacy teams. It maps the GDPR duties most relevant to AI agents (showing what you did, building in protection, keeping records, security) to the evidence an Agent Manifest can provide. It is a reference map, not a statement that any system complies.

Article 5(2) - Accountability principle¶

The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (the principles).

What agent-manifest provides

A signed manifest is a checkable record of accountability for an AI agent. It proves who issued the agent (issuer SPIFFE URI, a standard workload identity), what configuration it was authorised to run, and whether human approval was required (the HITL, or human-in-the-loop, record). The issuer's signature covers that requirement; each approval is signed separately by the approver's key and verified on its own. Because both are signed, the controller can demonstrate these facts without relying on self-reported agent state.

A manifest store (database, .well-known endpoint, or immutable log) provides an auditable history of every agent version that processed personal data, which supports the controller's duty to demonstrate compliance on request.

Article 25 - Data protection by design and by default¶

The controller shall implement appropriate technical and organisational measures designed to implement the data-protection principles in an effective manner.

What agent-manifest provides

Attestation level as a design control: The manifest's conformance level is a measurable design control. An organisation can define a policy that agents processing personal data must be Level 2+ (SEV-SNP or TDX). Manifests at Level 0 or 1 are rejected by the verifier in personal-data contexts.

Scope-limited delegation: When one agent hands work to another (delegation), each step (hop) can only narrow what is allowed, never widen it. An orchestrator agent can delegate to a sub-agent with an explicit data_classifications scope grant, ensuring the sub-agent can only access data classes it was explicitly authorised for.

{
  "scope_grant": {
    "tools": ["org.example.research.search_anonymised_records"],
    "data_classifications": ["internal"],
    "max_delegation_depth": 0
  }
}

(The spec's data_classifications values are public, internal, confidential, and restricted; map anonymised datasets to the lowest classification your policy allows.)

The verifier rejects any manifest where the effective scope exceeds what the delegation chain granted.

Article 30 - Records of processing activities¶

Each controller shall maintain a record of processing activities under its responsibility.

What agent-manifest provides

The manifest is a record of processing intent: it documents what the agent was configured to do at the time of issuance. Fields that are relevant to Article 30 records:

The manifest's issued_at / expires_at pair documents the period during which the agent was authorised to process. A manifest that has expired and been re-issued creates a timestamped version history suitable for Article 30 records.

Article 32 - Security of processing¶

The controller and processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

What agent-manifest provides

Summary table¶

This mapping is provided as reference material. It does not constitute legal advice. Consult your legal and compliance teams before making compliance claims.