In March 2026, the European Data Protection Board issued guidance clarifying that AI agents processing personal data on behalf of a user are subject to the same GDPR obligations as any other automated data processing system. The message was explicit: "AI agent" is not a category that exists outside the regulation. If your agent touches personal data, every Article applies.
Most enterprise AI deployments are not ready for this. The tools their agents use have no access controls. The data flowing between agents and tools has no privacy filtering. The actions their agents take have no audit trail. Demonstrating compliance — proving to an auditor that personal data was handled correctly — is somewhere between difficult and impossible.
MPP does not make you compliant. No infrastructure does. But it provides the technical controls that make compliance an architectural property of your AI tool execution layer, rather than a policy aspiration that depends on every individual tool doing the right thing.
The Regulatory Landscape
Three regulatory frameworks dominate the enterprise AI compliance conversation. Each makes specific demands on how AI systems handle data, enforce controls, and maintain accountability.
GDPR (General Data Protection Regulation)
The EU's data protection framework. Applies to any organisation processing personal data of EU residents, regardless of where the organisation is based.
Key requirements for AI tool execution:
- Data minimisation (Article 5(1)(c)): Only process personal data that is necessary for the specific purpose.
- Purpose limitation (Article 5(1)(b)): Data collected for one purpose must not be used for another incompatible purpose.
- Accountability (Article 5(2)): The data controller must be able to demonstrate compliance with all GDPR principles.
- Data Protection Impact Assessment (Article 35): Required when processing is likely to result in high risk to individuals — which AI agent processing almost certainly qualifies as.
- Right to explanation (Article 22): Individuals have the right not to be subject to automated decisions without meaningful human involvement.
HIPAA (Health Insurance Portability and Accountability Act)
US federal law governing the handling of Protected Health Information (PHI). Applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates.
Key requirements for AI tool execution:
- Access controls (§164.312(a)): Technical controls to limit access to ePHI to authorised persons and processes.
- Audit controls (§164.312(b)): Hardware, software, and procedural mechanisms to record and examine activity in systems containing ePHI.
- Integrity controls (§164.312(c)): Mechanisms to authenticate ePHI and ensure it has not been improperly altered.
- Transmission security (§164.312(e)): Technical security measures to guard against unauthorised access to ePHI during transmission.
- Minimum necessary (§164.502(b)): Covered entities must limit the use and disclosure of PHI to the minimum necessary for the intended purpose.
EU AI Act
The EU's comprehensive AI regulation, which entered force in stages starting 2024. It classifies AI systems by risk level and imposes requirements proportional to that risk.
Key requirements for AI tool execution:
- Transparency (Article 13): High-risk AI systems must be designed to allow human oversight, including the ability to understand the system's capabilities and limitations.
- Human oversight (Article 14): High-risk systems must be designed to be effectively overseen by humans, including the ability to intervene and override.
- Logging (Article 12): High-risk systems must have automatic logging capabilities that record events relevant to identifying risks and monitoring operations.
- Data governance (Article 10): Training, validation, and testing datasets must be relevant, representative, and examined for biases.
- Risk management (Article 9): A risk management system must be established, implemented, documented, and maintained throughout the AI system's lifecycle.
How MPP Maps to Regulatory Requirements
MPP is not a compliance product. It is infrastructure — and like all infrastructure, its compliance value lies in the technical controls it provides. Here is how those controls map to specific regulatory requirements.
Privacy Filters → Data Minimisation and Minimum Necessary
The most direct mapping. MPP's privacy filter engine sits between every tool's output and the AI agent's input. It scans all response data against configurable patterns and replaces matches with redaction tokens before the data reaches the model.
Tool output: "Customer email: jane@example.com, SSN: 123-45-6789"
After filter: "Customer email: [EMAIL_REDACTED], SSN: [SSN_REDACTED]"
Agent receives: The filtered version. The raw PII never enters the model context.
This is protocol-level data minimisation. The agent receives only the information it needs (the structure and non-sensitive content of the response), not the information it doesn't (the raw PII). The tool author doesn't need to implement redaction — it happens at the infrastructure layer, enforced by the host runtime.
GDPR mapping: Article 5(1)(c) — data minimisation. The technical control ensures that personal data not necessary for the agent's task is redacted before the agent processes it.
HIPAA mapping: §164.502(b) — minimum necessary. PHI in tool responses is redacted to the minimum necessary for the agent to perform its function.
Built-in patterns: email, phone, ssn, credit_card, ip_address, ipv6_address. Credit card detection includes Luhn algorithm validation to reduce false positives.
Custom patterns: Organisations can define domain-specific patterns for internal identifiers, medical record numbers, account numbers, or any other sensitive data format:
{
"privacy_filters": {
"enabled": true,
"patterns": ["email", "phone", "ssn"],
"custom_patterns": [
{
"id": "medical_record",
"regex": "MRN-\\d{8}",
"description": "Medical record number"
},
{
"id": "employee_id",
"regex": "EMP[A-Z]\\d{6}",
"description": "Internal employee identifier"
}
]
}
}
Evidence generation: The audit log records which privacy filters matched for every invocation (privacy_filters_applied field). This provides documented evidence that data minimisation controls were applied — evidence that survives auditor scrutiny because it's in a hash-chained, tamper-evident log.
Capability-Based Permissions → Access Controls
GDPR and HIPAA both require that access to personal data be limited to what is necessary and authorised. MPP's capability-based permission system provides this at the tool execution level.
Every tool declares exactly what it needs in its manifest:
{
"capabilities": {
"network": ["api.internal-crm.com"],
"filesystem": {
"read": ["/data/reports"],
"write": []
},
"env_vars": ["CRM_API_KEY"]
}
}
The runtime enforces these declarations. A tool that declares network access to api.internal-crm.com cannot access api.payments.com. A tool that declares read access to /data/reports cannot read /data/patient-records. A tool with no declared env_vars cannot read DATABASE_PASSWORD.
This is the principle of least privilege, implemented as a technical control rather than a policy guideline.
HIPAA mapping: §164.312(a) — access controls. Each tool's access is restricted to the specific resources it declares, approved by the permission policy, and enforced by the WASM sandbox.
GDPR mapping: Article 25 — data protection by design and by default. The default state of an MPP tool is zero access. Capabilities must be explicitly declared, evaluated against policy, and approved before the tool receives any access at all.
Sensitivity Scoring + HITL → Human Oversight
The EU AI Act requires that high-risk AI systems be designed for effective human oversight. MPP's sensitivity scoring and human-in-the-loop (HITL) system provides this for tool execution.
Every tool invocation is assigned a sensitivity score (0–100) based on its capabilities, security level, and resource access. The score maps to four confirmation tiers:
| Score Range | Tier | Human Involvement | |-------------|------|-------------------| | 0–25 | None | Automated execution | | 26–50 | Notify | User is informed after execution | | 51–75 | Confirm | User must approve before execution | | 76–100 | Multi-Factor | Additional authentication required |
For operations that handle personal data, PII, or regulated information, the sensitivity score naturally trends toward the Confirm or Multi-Factor tier — ensuring a human reviews and approves the action before it executes.
EU AI Act mapping: Article 14 — human oversight. The HITL system ensures that high-sensitivity operations are reviewed by a human, with the ability to approve or deny. The scoring system is transparent and configurable, supporting the transparency requirements of Article 13.
GDPR mapping: Article 22 — automated individual decision-making. When an AI agent makes a decision that affects an individual (e.g., approving a loan, flagging a transaction), the HITL system ensures that the tool execution underlying the decision involves appropriate human involvement.
Hash-Chained Audit Logs → Accountability and Logging
Every regulatory framework requires records. GDPR requires demonstrable accountability. HIPAA requires audit controls. The EU AI Act requires automatic logging. MPP's audit log satisfies all three.
Every tool invocation produces a structured, hash-chained audit record containing:
- What ran: Package ID, version, content hash, publisher key
- What it could access: Capabilities requested and granted
- Who approved it: HITL decision, approver identity (if applicable)
- What happened: Input hash, output hash, execution time, errors
- What was protected: Privacy filters applied, patterns matched
The hash chain makes the log tamper-evident: modifying any entry breaks the chain, making alterations detectable.
GDPR mapping: Article 5(2) — accountability. The log provides documented evidence of every data processing operation performed by AI tools, including what controls were applied.
HIPAA mapping: §164.312(b) — audit controls. The log records every access to systems potentially containing ePHI, with enough detail to reconstruct what happened and who authorised it.
EU AI Act mapping: Article 12 — logging. The automatic logging captures events relevant to identifying risks and monitoring the AI system's operation — exactly what the regulation requires.
Cryptographic Signing → Integrity Controls
HIPAA requires integrity controls to ensure ePHI is not improperly altered. MPP's cryptographic signing provides this for the tools that process the data:
- Every tool package is signed with Ed25519. The signature covers a SHA-256 content hash of every file in the package.
- The Gatekeeper verifies the signature before execution. A modified package — even a single changed byte — fails verification and is refused.
- The audit log records the content hash and signature status for every invocation.
HIPAA mapping: §164.312(c) — integrity controls. The signed package format ensures that tools processing ePHI are authentic and unmodified. The audit log provides evidence of integrity verification for every invocation.
WASM Sandboxing → Transmission Security and Containment
The WASM sandbox provides the execution-level containment that supports multiple regulatory requirements:
- Network isolation. Tools can only access declared network domains. A tool that processes patient data cannot exfiltrate it to an undeclared endpoint.
- Filesystem isolation. Tools can only access declared paths. A tool that reads from
/data/reportscannot access/data/patient-records. - Memory isolation. Each tool invocation gets a fresh WASM instance with isolated linear memory. Data from one invocation cannot leak to another.
- Resource limits. Memory and time limits prevent denial-of-service — a tool cannot exhaust system resources to disrupt other processing.
HIPAA mapping: §164.312(e) — transmission security. Network isolation ensures PHI can only be transmitted to declared, authorised endpoints.
Building Compliance Evidence
The difference between "being compliant" and "demonstrating compliance" is evidence. Policy documents say what should happen. Technical controls ensure it happens. Audit logs prove it happened.
MPP's architecture produces compliance evidence as a byproduct of normal operation:
| Requirement | Evidence Source | MPP Control |
|-------------|----------------|-------------|
| Data minimisation | Privacy filter match records | Audit log: privacy_filters_applied |
| Access control | Capability grants | Audit log: capabilities_granted |
| Human oversight | Approval records | Audit log: hitl_approved, hitl_approver |
| Integrity | Signature verification | Audit log: signature_valid, content_hash |
| Logging | Tamper-evident records | Hash-chained audit log |
| Least privilege | Capability restrictions | Manifest: capabilities; Audit log: granted vs. requested |
When an auditor asks "Can you prove that PII was handled correctly in your AI agent workflows?", the answer is: here is the audit log. Every invocation records which privacy filters matched, what capabilities were granted, whether a human approved the action, and whether the tool was verified. The log is hash-chained and tamper-evident.
This is the difference between compliance as aspiration and compliance as architecture.
Data Protection Impact Assessments
GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) when processing is likely to result in high risk to individuals. AI agent processing — particularly agent workflows that access customer databases, generate communications, or make decisions — likely qualifies.
MPP doesn't perform the DPIA for you. But it provides the information the DPIA needs:
- What tools are used? The registry catalogs all tools available to agents, with their declared capabilities and privacy filters.
- What data is accessed? The manifest declares all resources the tool can access. The audit log records what was actually accessed.
- What safeguards are in place? The privacy filter configuration, capability restrictions, HITL requirements, and sandbox isolation are all documented in the manifest and policy configuration.
- What is the residual risk? The combination of capability restrictions + privacy filters + HITL + sandboxing provides a quantifiable risk reduction relative to unrestricted tool execution.
For organisations conducting DPIAs for their AI agent deployments, MPP's structured metadata and audit logs provide a level of documentation that ad-hoc tool execution cannot match.
A Note on What MPP Does Not Do
MPP provides technical controls at the tool execution layer. It does not:
- Replace privacy policies. You still need organisational policies governing what data AI agents can process and why.
- Perform legal analysis. MPP doesn't determine whether a specific processing activity is lawful under GDPR or whether data constitutes PHI under HIPAA. That requires legal expertise.
- Handle data subject requests. If an individual exercises their right to access or erasure under GDPR, MPP's audit logs can help identify what data was processed, but the response to the request is an organisational responsibility.
- Classify AI system risk. Under the EU AI Act, determining whether your AI system is high-risk is a regulatory and legal question, not a technical one.
MPP is infrastructure. It makes the right thing the easy thing and the wrong thing the hard thing. But it operates within a broader governance framework that includes legal, organisational, and procedural controls.
The Compliance Trajectory
Regulatory requirements for AI are increasing, not decreasing. The EU AI Act is the first comprehensive AI regulation, but it will not be the last. The US is developing sector-specific AI regulations. The UK, Canada, Japan, and others are following.
Organisations that adopt AI tool infrastructure with compliance controls built in — rather than bolted on after the first regulatory enforcement action — will have a structural advantage. They won't need to retrofit privacy filters into tools that were deployed without them. They won't need to reconstruct audit trails from application logs that weren't designed for the purpose. They won't need to implement human oversight for operations that were designed to run autonomously.
MPP provides these controls from day one. Not because compliance is the goal — security is the goal — but because good security and good compliance are, in practice, the same thing.
For the privacy filtering implementation, read PII Redaction at the Protocol Level. For the permission system that underlies access controls, read Capability-Based Permissions for AI Tools. For the audit logging system, read Audit Logs That Actually Work.