Cross-border identity for AI agents
Four major regimes — GDPR, CCPA, DPDPA, PIPL — converge on the same primitive: cryptographic, portable, consent-based identity. One architecture, four certifications.
The shared primitives across regimes
Each major data protection law differs in detail and converges in shape:
- GDPR (EU) — lawful basis, purpose limitation, data subject rights, cross-border transfer mechanisms.
- CCPA / CPRA (California) — right to know, delete, correct; opt-out of sale and sharing.
- DPDPA (India) — purpose-bound consent, withdrawal, data principal rights.
- PIPL (China) — consent for cross-border transfer, data localization, certification mechanisms.
All four require: identifiable data principal, recorded consent (or other lawful basis), purpose limitation, retention limits, and cross-border transfer documentation. HATI primitives map directly.
The architecture that satisfies all four
| Primitive | HATI layer | Satisfies |
|---|---|---|
| Verified data principal | L1 (identity) | All four |
| Consent as delegation token | L2 (delegation) | GDPR, DPDPA, PIPL especially |
| Purpose / scope enforcement | L2 + L5 enforcement | All four |
| Withdrawal / revocation | L2 revocation | All four |
| Tamper-evident audit | Audit anchor | All four |
Cross-border transfer specifically
Each regime restricts data flow across borders. GDPR requires SCCs or adequacy decisions; PIPL demands government-approved mechanisms; DPDPA permits notified-country transfer; CCPA emphasizes opt-out. The portable, cryptographic consent token in HATI Layer 2 is verifiable in any jurisdiction without phoning the issuer — which means the audit story holds across borders even when the relationships do not.
The agentic complication
Agents acting on data principals' behalf cross borders constantly. An EU citizen's email read by an AI assistant whose model is hosted in the US, with data backed up to a Singapore region, processed via Indian engineering ops. Each hop has compliance implications. Without a portable consent chain, each hop requires bespoke legal infrastructure. With HATI delegations, the chain travels with the data.
The right pattern
- Issue consent at collection as a Manav delegation token.
- Bind the token to the data principal's verified identity.
- Enforce purpose / scope at every agent action.
- Honor withdrawal as token revocation, propagated to every relying party.
- Export the audit log in each jurisdiction's preferred format from a single source of truth.
Where the regimes still diverge
Four important divergences HATI does not paper over:
- Data localization (PIPL stricter than others).
- Retention limits (regime-specific).
- Categories of sensitive data (each defines differently).
- Cross-border transfer mechanisms (require specific legal instruments, not just technical primitives).
The HATI architecture handles the technical layer; the legal layer requires per-jurisdiction work. They are separate problems; treating them as one is the most common mistake.
Common objections
Compliance teams push back with two reasonable concerns. Vendor lock-in — answered by the open-source protocol and forkable reference implementation. Audit acceptance — answered by the major auditors that have already approved the audit-trail format for SOC 2 evidence and the regulators who have reviewed the Article 14 mapping.
Frequently asked questions
What is the penalty exposure if we ignore this? Material. EU AI Act Article 14 caps fines at 7% of global revenue or €35M, whichever is higher. SOC 2 audit failures jeopardize enterprise procurement. The cost of the audit-trail layer is small relative to either.
Do we need to be in the EU for this to matter? No. Article 14 applies to any AI system placed on the EU market, including non-EU vendors selling into the EU. Most US enterprises with European customers are in scope. The same controls satisfy emerging US sectoral rules and India's DPDPA.
How long does compliance take to set up? Two weeks for an instrumented stack. Most of the work is auditing the existing agent surface — what agents run, what they touch, who authorized them — not deploying the identity layer. The protocol integrates in twelve lines; the policy work takes longer.
Where to start
Pair this with dpdpa ai agents for the cross-jurisdictional view and eidas 2 and manav for the audit artifact your auditors expect to see. Most compliance projects we have seen succeed by reading those three together before scoping anything.
The treaty problem nobody is talking about
The EU AI Act, the US AI Bill of Rights, India's DPDPA, China's Generative AI Measures, and the UK's pro-innovation framework all converge on the same demand for accountability and diverge on every implementation detail. A multinational deploying agents has to satisfy all five. Today, the satisfaction strategy is bespoke per jurisdiction — separate documentation packages, separate audit trails, separate counsel. That strategy is unsustainable beyond a small number of regimes. The treaty problem nobody is yet discussing is the eventual harmonization layer: the cross-border instrument that lets a single signed delegation chain satisfy multiple regulators. Versions of this exist for tax (BEPS), data protection (Schrems frameworks), and trade (mutual recognition). The AI version will arrive in the next several years. The protocol that the harmonization treaty references will be the protocol that won the prior decade of single-jurisdiction integrations. We are working on every one of those integrations now, on purpose.
Different regimes. Same primitives. One architecture earns four certifications.