Compliance and Agent Decisions: SOC2, PCI, HIPAA Notes

Auditors will ask. The control mappings, the evidence to retain, and the architectures that make compliance straightforward instead of painful.

What auditors will ask

Four audit questions cover most ground. Who authorised this action? The audit trail must show agent identity, originating user/system, approval chain. How do you ensure unauthorised actions cannot occur? Tool allowlists, RBAC, two-person approval, all documented. How do you investigate agent errors? Reproducibility, audit logs, postmortem process. How do you protect data the agent processes? Redaction, encryption, access controls.

• Who authorised. Agent identity, originating user/system, approval chain.
• How prevent unauthorised. Tool allowlists, RBAC, two-person approval; documented.
• How investigate errors. Reproducibility, audit logs, postmortem process.
• How protect data. Redaction, encryption in transit and at rest, access controls.

SOC2 controls

Three SOC2 controls map directly to agent operation. CC7.2 system monitoring (the agent’s audit log satisfies this; document the retention and review process); CC8.1 change management (agent prompt and code changes follow standard change management with PR reviews, approvals, deploys); CC6.1 logical access (the agent’s access is RBAC-controlled; document who can grant the agent new permissions).

• CC7.2 system monitoring. Agent audit log satisfies; document retention and review.
• CC8.1 change management. Prompt and code changes follow standard PR/approval/deploy.
• CC6.1 logical access. RBAC-controlled; document who grants new permissions.
• Per-control evidence map. Each control has documented evidence; supports audit.

PCI considerations

Three PCI requirements deserve attention. Cardholder data (the agent must not process raw PAN; tokenise upstream so the agent sees tokens); audit trails (PCI requires retention for at least 1 year, match your agent’s audit log retention); access controls (cardholder data environment is a tighter control set, the agent runs outside or with extra restrictions).

• No raw PAN. Tokenise upstream; agent sees tokens, not card numbers.
• 1-year audit retention. Minimum; match your agent’s log retention.
• CDE control set. Tighter; agent runs outside or with extra restrictions.
• Per-environment scope. CDE separated; supports correct compliance boundary.

HIPAA considerations

Three HIPAA principles guide agent design. PHI (the agent must not retain PHI in prompts or logs without BAA-covered storage); encryption (AES-256 at rest, TLS 1.3 in transit, all standard requirements); minimum necessary (the agent’s tools are scoped to the minimum data needed, “just enough” is a HIPAA principle not just a security one).

• BAA-covered PHI storage. No PHI retained without BAA-covered storage.
• AES-256, TLS 1.3. Standard encryption requirements.
• Minimum necessary. Tools scoped to minimum data needed; HIPAA principle.
• Per-tool data scope. Each tool documents its data class; supports continued discipline.

Architectures that make compliance easy

Four architectural choices reduce compliance friction. Tools as the authorisation boundary (the agent calls tools, tools enforce permissions, the agent has no power outside tools); audit logs as immutable append-only (object storage with object locks, auditors verify in seconds); separate environments for handled data classes (the agent that touches PHI runs in a HIPAA-compliant environment, others run in standard environments); documentation describing the architecture in a one-page document the auditor reads first.

• Tools as auth boundary. Agent calls tools; tools enforce; no power outside.
• Append-only audit logs. Object storage with object locks; auditor verifies fast.
• Per-data-class environment. PHI in HIPAA environment; others standard.
• One-page architecture doc. Auditor reads first; reduces friction.