Compliance Frameworks for AI Agent Deployments

You built an agent chain that works. It automates a workflow, saves your team hours, and the output quality is solid. Now legal wants to know if it's compliant. Your CISO wants a risk assessment. The enterprise prospect on the call wants to see your SOC2 report. And you're staring at a framework document wondering how "AI agent orchestration" maps to "control objective CC6.1."

Compliance frameworks weren't written for AI agent pipelines. They were written for traditional software systems where humans initiate every action and data flows through well-understood paths. Agent chains are different: they make decisions, call external APIs autonomously, process data through multiple intermediate steps, and run on schedules without human involvement. Mapping these behaviors to compliance controls requires thinking about what the frameworks actually care about, not just checking boxes.

What Compliance Frameworks Actually Want

Strip away the jargon and every compliance framework asks the same four questions:

1. Who can access what? (Access control)
2. What happened and when? (Audit trail)
3. Is the data protected? (Encryption and privacy)
4. Can you prove it? (Evidence and monitoring)

If your agent deployment can answer these four questions definitively, you can satisfy any framework. The specific controls differ, but the intent is the same.

SOC2: The Trust Services Criteria

SOC2 is organized around five trust services criteria: security, availability, processing integrity, confidentiality, and privacy. Here's how agent chains map to each.

Security (CC6): Who can create, modify, and execute chains? Mentiko uses RBAC (role-based access control) to restrict chain management. Define roles -- chain-admin, chain-operator, chain-viewer -- and assign them based on job function. Every chain modification goes through version control, so you have a commit history of who changed what.

{
  "name": "sensitive-data-pipeline",
  "rbac": {
    "create": ["chain-admin"],
    "modify": ["chain-admin"],
    "execute": ["chain-admin", "chain-operator"],
    "view_runs": ["chain-admin", "chain-operator", "chain-viewer"],
    "view_logs": ["chain-admin", "chain-operator"]
  }
}

Availability (A1): Can you demonstrate that your chains run when they're supposed to? This means monitoring, alerting, and documented recovery procedures. Every scheduled chain should have an alert for missed executions. If a chain is supposed to run at 6am and doesn't, someone should know by 6:15am.

Processing integrity (PI1): Does the chain produce correct, complete output? This is where testing and validation agents earn their keep. Add a validation agent at the end of every chain that checks output against expected schema, value ranges, and completeness criteria. Log the validation result with every run.

Confidentiality (C1): Are secrets, API keys, and sensitive configuration protected? Use Mentiko's secrets vault -- not environment variables, not config files, not hardcoded values in prompts. The vault encrypts at rest, provides access only to chains that need specific secrets, and logs every access.

Privacy (P1): If your chains process personal data, you need consent tracking, data minimization, and deletion capability. More on this in the GDPR section.

HIPAA: Protected Health Information

If your agents touch PHI (protected health information), HIPAA applies. The key requirements that affect agent chains:

Access controls (164.312(a)): Every agent that accesses PHI must be authenticated and authorized. This means your chain's workspace execution environment -- whether it's local, Docker, or SSH -- needs to enforce access controls. No shared credentials. No wide-open Docker volumes.

Audit controls (164.312(b)): You need a complete log of every access to PHI. Every agent that reads, processes, or writes PHI must log that access with: who (which chain and agent), what (which data elements), when (timestamp), and why (the chain's purpose).

{
  "name": "patient-record-processor",
  "compliance": {
    "framework": "hipaa",
    "phi_handling": true,
    "audit_level": "detailed",
    "data_elements_accessed": ["patient_name", "dob", "diagnosis_code", "medication_list"]
  },
  "agents": [
    {
      "name": "record-fetcher",
      "prompt": "Retrieve the patient record from the EHR API. Log all accessed fields.",
      "triggers": ["chain:start"],
      "emits": ["record:fetched"],
      "audit": {
        "log_input": false,
        "log_output_schema": true,
        "log_output_values": false
      }
    }
  ]
}

Notice the audit configuration on the agent. log_output_schema: true means the audit log records that the agent output a patient name and diagnosis code. log_output_values: false means the actual values aren't in the log -- because the audit log itself would then contain PHI and require its own protections. Log the shape of the data, not the data itself.

Transmission security (164.312(e)): All data in transit between agents must be encrypted. If your chain runs in a single workspace, this is handled by the OS. If agents communicate across network boundaries, TLS is mandatory. Mentiko's SSH workspace execution uses encrypted channels by default.

The Business Associate Agreement (BAA) question: if you're using a cloud-hosted model provider (OpenAI, Anthropic, etc.) as part of your agent chain, you need a BAA with that provider before sending them PHI. Some providers offer BAAs, some don't. This is a vendor selection issue, not a technical one, but it's the most common HIPAA blocker for agent deployments.

GDPR: Data Subject Rights

GDPR applies when your agents process data of EU residents, regardless of where your infrastructure is. The requirements that most affect agent chains:

Lawful basis (Article 6): You need a legal basis for each processing activity. For most B2B agent chains, this is "legitimate interest" or "performance of a contract." Document the lawful basis in your chain definition.

Data minimization (Article 5(1)(c)): Your agents should only access the data they need. If an agent's job is to check whether an email address is valid, it shouldn't also receive the user's name, address, and purchase history. Design your chain's data flow so each agent gets the minimum required input.

{
  "name": "customer-outreach",
  "agents": [
    {
      "name": "segmenter",
      "prompt": "Segment customers by purchase frequency. Use only customer_id and purchase_count fields.",
      "triggers": ["chain:start"],
      "emits": ["segments:ready"],
      "data_filter": {
        "input_fields": ["customer_id", "purchase_count"],
        "exclude_fields": ["email", "name", "address", "phone"]
      }
    }
  ]
}

The data_filter block explicitly restricts what data the agent receives. Even if the upstream data source includes email and name, the segmenter only sees customer_id and purchase_count. This is data minimization enforced at the chain level, not just policy.

Right to erasure (Article 17): When a data subject requests deletion, you need to delete their data from everywhere -- including chain run histories, event files, shared state directories, and any cached outputs. Build an erasure chain:

{
  "name": "gdpr-erasure",
  "agents": [
    {
      "name": "finder",
      "prompt": "Search all chain run directories for files containing the subject's identifier. List all file paths.",
      "triggers": ["chain:start"],
      "emits": ["files:found"]
    },
    {
      "name": "eraser",
      "prompt": "Delete or redact the identified files. Log each deletion for the compliance record.",
      "triggers": ["files:found"],
      "emits": ["erasure:complete"]
    },
    {
      "name": "verifier",
      "prompt": "Re-scan all directories to confirm no instances of the subject's data remain. Produce the compliance certificate.",
      "triggers": ["erasure:complete"],
      "emits": ["chain:complete"]
    }
  ]
}

Data processing records (Article 30): Maintain a record of all processing activities performed by your agent chains. This isn't just "we have a chain that processes customer data." It's: what data categories, what processing purposes, what retention periods, what security measures, and what third parties receive the data (including model providers).

ISO 27001: Information Security Management

ISO 27001 is a management system standard, not a technical checklist. It wants to see that you have a systematic approach to managing information security risks. For agent chains, this means:

Risk assessment (Clause 6.1.2): Identify the risks specific to AI agent processing. What happens if an agent makes a wrong decision? What if it accesses data it shouldn't? What if a model provider has a data breach? Document these risks with likelihood and impact scores.

Asset inventory (Annex A.8): Your agent chains are information assets. Maintain an inventory: chain name, data classification of inputs and outputs, execution environment, external dependencies, and owner. This is straightforward to automate -- export your chain definitions to a compliance dashboard.

Access control (Annex A.9): Implement the principle of least privilege. Each agent should have access only to the resources it needs. Each team member should have access only to the chains relevant to their role. Review access quarterly.

Logging and monitoring (Annex A.12.4): Centralize your chain execution logs. Every run, every event, every error should flow to a monitoring system where you can set alerts, build dashboards, and investigate incidents. Mentiko's run history provides this natively, but pipe it to your SIEM for ISO purposes.

Practical Implementation

Start with these five controls regardless of which framework you're targeting:

1. RBAC on all chain operations. Who can create, modify, execute, and view chains. Map to your organizational roles.

2. Immutable audit logs for every chain run. Timestamp, chain version, inputs (or input schema for sensitive data), outputs (or output schema), duration, and outcome. Store these separately from the chain's working directory.

3. Secrets management through a vault, not environment variables or config files. Rotate credentials on a schedule. Log every access.

4. Data classification on every chain. Mark each chain with the highest sensitivity level of data it processes. Apply security controls proportional to the classification.

5. Retention policies. How long do run histories persist? When are event files cleaned up? When are shared state directories purged? Define policies per data classification level and enforce them automatically.

These five controls satisfy the core requirements of SOC2, HIPAA, GDPR, and ISO 27001 simultaneously. The framework-specific additions are mostly documentation and process: risk assessments for ISO, BAAs for HIPAA, processing records for GDPR, and formal policies for SOC2.

Compliance isn't a feature you ship once. It's an operational discipline that your agent infrastructure either supports or fights against. Build the controls into your chain definitions from the start, and the audit is a documentation exercise. Bolt them on after the fact, and the audit is a painful retrofit.

See the security architecture page for Mentiko's built-in compliance features, or explore securing agent workflows for the technical implementation details.