What is an Agentic Control Plane?

An Agentic Control Plane is a governance layer that sits between AI coding agents and their tools. It logs every tool call, enforces permissions and policies, and provides audit trails — giving teams visibility and control over what their AI agents are doing.

How does ACP work with Claude Code?

ACP installs a PreToolUse hook in Claude Code that fires before every tool call (Bash, Read, Write, Edit, WebFetch). The hook sends the tool name and input to ACP's governance API for policy evaluation and audit logging. Round-trip is approximately 200ms.

How do I install ACP?

Run one command: curl -sf https://agenticcontrolplane.com/install.sh | bash. This auto-detects Claude Code and OpenClaw, installs the appropriate hooks, and opens your browser to set up your workspace.

Which SOC 2 Trust Services Criteria are most affected by AI agents?

The Common Criteria sections do most of the work: CC6.1 (logical access — addressed by per-user identity propagation), CC6.6 (restriction of data movement — addressed by output redaction and tool-call gating), CC7.1 (detection of changes — addressed by versioned policy bundles), CC7.2 (monitoring — addressed by an identity-attributed audit trail), and CC8.1 (change management — addressed by two-person review on policy changes). Confidentiality and Privacy categories add additional constraints depending on the data the agents touch.

Does HIPAA's audit-control rule (164.312(b)) require six-year retention?

Yes. HIPAA mandates that documentation required by the Security Rule — including audit logs — be retained for six years from the date of creation or last effective date, whichever is later. This applies to the audit trail itself, regardless of the retention schedule of the underlying clinical data. AI agent governance audit trails that touch ePHI must meet this retention or fail the audit.

How do you satisfy HIPAA 164.312(a)(2)(i) (unique user identification) for AI agents?

The agent must operate under the verified identity of the clinician (or other authorized user) who initiated the request — not under a shared API key or service account. Practically: the user's OAuth/OIDC JWT is verified at the control plane and propagated to every tool call the agent makes, including sub-agent calls. The audit row for each tool call must contain the verified user's subject claim, not just an agent identifier.

Can a single AI agent control plane satisfy SOC 2, HIPAA, GDPR, and the EU AI Act simultaneously?

Largely yes, because the underlying substrate — identity propagation, versioned policy, identity-attributed audit trail, redaction, retention — is shared across the frameworks. The differences are in retention windows (HIPAA 6 years, EU AI Act operating period plus 6 months), specific data classifications (PHI for HIPAA, personal data for GDPR), and additional reporting obligations (GDPR Article 30 records of processing). Implementing for the strictest framework you're subject to is the efficient path.

SOC 2 and HIPAA for AI agents: the compliance playbook

David Crowe · 13 min read

compliance soc2 hipaa governance ciso audit playbook

Your AI agents access protected data on behalf of users. Your compliance auditor doesn’t care that the technology is new — they care that the controls in your existing certification still hold when the calling identity is no longer a human pressing a button. Most don’t, by default. The shared API key, the missing identity attribution, the unstructured tool-call logs — these are exactly the gaps a SOC 2 or HIPAA auditor is going to find.

This is the practical playbook for closing them. A control-by-control mapping from the SOC 2 Trust Services Criteria and the HIPAA Security Rule to the specific AI agent governance controls that satisfy them, the evidence you’ll need to produce, and the failure modes that show up most often in audits.

It’s written for the role doing the work: the platform engineer or security lead who has to demonstrate the controls, not just describe them.

SOC 2: the controls that touch AI agents

SOC 2’s Trust Services Criteria (TSC) span Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). For AI agents, the tightest pressure is on the Common Criteria (CC) — particularly logical access (CC6), system operations (CC7), and change management (CC8) — and on the Confidentiality and Privacy categories.

CC6.1 — Logical access

“The entity implements logical access security software, infrastructure, and architectures over protected information assets.”

The AI agent gap: A shared API key gives every user of the agent the same access. There is no logical access boundary at the agent level.

The control that satisfies this:

Per-user identity propagation. The agent inherits the calling user’s verified identity (OAuth JWT subject, OIDC claims, IdP-attested role) and presents it to downstream tools.
Tier separation. Interactive sessions, subagents, background runners, and API callers are distinct identity contexts with distinct policies.
Tool-call authorization at the control plane, not the underlying API.

Evidence to collect:

Architecture diagram showing identity flow from user → agent → control plane → tool.
Sample audit log rows showing user.sub, agent.tier, and policy.decision populated.
Test case: invoke the agent as a low-privilege user; confirm a high-privilege tool call is denied with the user’s identity in the audit row.

Common audit failure: “We use API keys; the application enforces user authorization downstream.” This fails the boundary test — the auditor will ask what stops the agent from calling the API on behalf of a different user, and the answer is “the model decides not to,” which is a guarantee no one can attest to.

CC6.6 — Restriction of access to data

“The entity restricts the transmission, movement, and removal of information to authorized internal and external users.”

The AI agent gap: Agents read files, environment variables, and tool outputs that may contain confidential or restricted data, then reproduce that data into transcripts, commit messages, chat windows, and tool inputs of subsequent calls. The data crosses authorization boundaries inside the agent’s process.

The control that satisfies this:

Pre-call classification of file reads (.env, credentials, PHI directories) with policy that gates them.
Output redaction in the control plane: secrets, PII, or other patterns are replaced with [redacted:type] markers before the model sees them.
Egress monitoring: tool calls to external destinations are logged with destination and payload hashes.

Evidence to collect:

Policy showing which file paths and patterns trigger redaction.
Audit log rows showing redactions.count > 0 and redactions.types.
A regression test: agent prompted to read .env and quote it back; verify the response shows [redacted:secret].

CC7.1 — Detection of new, modified, or deleted data

“To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations…(2) the introduction of new vulnerabilities, and (3) susceptibilities to newly discovered vulnerabilities.”

The AI agent gap: Policy bundles change. Agent-runtime versions change. MCP servers come and go. Without versioning and change capture, you can’t answer “was the policy in force at the time the call was made?”

The control that satisfies this:

Versioned policy bundles. Every change produces a new bundle hash; every audit row pins the bundle hash that decided it.
Change log for the policy bundle (who changed what, when).
Inventory of agent runtimes and MCP servers with version capture in audit rows.

Evidence to collect:

Audit log row with policy.bundle_hash populated.
Policy bundle change log showing the audit-trail entries that correspond to bundle versions.
Inventory export of agent runtimes / MCP servers in production.

CC7.2 — Monitoring (the audit-trail core)

“The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.”

This is the criterion most-quoted in AI-related findings. The audit trail is the evidence.

The control that satisfies this:

A complete audit trail per the ten-question checklist.
A monitoring rule (in your SIEM, your dashboard, or both) that surfaces anomalies — high deny rates, identity-tier mismatches, novel tool calls, output redaction events.

Evidence to collect:

Sample audit row(s) populated with all required fields.
SIEM alert configuration tied to AI agent telemetry.
Recent alert volume report — is anyone actually watching this?

CC8.1 — Change management

“The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures.”

The AI agent gap: Policies, agent prompts, MCP server configurations, and tool definitions all change frequently — often via dashboard click rather than git commit. Audit risk: a change happens with no record of who approved it.

The control that satisfies this:

Policy bundles managed in git (or with a UI that produces signed, versioned, reviewable change records).
A two-person rule for production policy changes.
Diff capture between policy versions visible in the audit log near the change.

Evidence to collect:

Pull request history showing reviewed policy changes.
Audit log entries showing policy.bundle_hash shifting at known change times.
Documented procedure for emergency policy changes (and their post-hoc review).

HIPAA: the Security Rule mapped

HIPAA’s Security Rule has three sections: Administrative Safeguards (164.308), Physical Safeguards (164.310), and Technical Safeguards (164.312). For AI agents, the technical safeguards do most of the work.

164.312(a)(1) — Access control

“Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in 164.308(a)(4).”

Required implementation specifications:

Unique user identification (164.312(a)(2)(i)) — required.
Emergency access procedure — required.
Automatic logoff (164.312(a)(2)(iii)) — addressable.
Encryption and decryption — addressable.

The AI agent gap: “Unique user identification” is the headline failure. A shared API key is not a unique identifier; the agent presents itself as itself, not as the clinician who initiated the request.

The control that satisfies this:

The user’s verified identity (auth0 sub, Okta user ID, hospital SSO subject) reaches every PHI-touching tool call. The control plane carries it from the agent’s invocation through to the audit log.
Per-tier session boundaries: a clinician’s interactive session is distinct from any background agent running in the same environment.

Evidence to collect:

An audit row demonstrating user.sub populated with a verified clinician identifier on a PHI-tool call.
Configuration showing the IdP integration (Okta / Auth0 / hospital SSO) and the JWT verification keys in use.
Test case: an agent runs without an authenticated user; PHI tools are denied (not silently routed to a service account).

164.312(b) — Audit controls

“Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

This is HIPAA’s audit-trail clause, and it’s required, not addressable. Your audit trail must record activity in systems that touch ePHI.

The control that satisfies this:

Identity-attributed audit trail covering every tool call where ePHI may be involved.
Six-year retention (HIPAA’s audit-control records retention requirement).
Tamper-evidence (hash chain or external immutable sink).
Searchable, exportable to the SIEM the security team operates.

Evidence to collect:

Audit row from a PHI-relevant tool call with all required fields.
Retention policy showing six years (or longer) for tools that touch PHI.
Hash chain verification report or external sink configuration.

Common audit failure: “We rotate logs after 90 days.” HIPAA’s six-year requirement is not negotiable for audit logs themselves — even if the underlying clinical data has a different retention schedule.

164.312(c)(1) — Integrity

“Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.”

The AI agent gap: Agents have write access. An agent that hallucinates a record update, or that follows a prompt injection telling it to overwrite a chart, is exactly what this clause is worried about.

The control that satisfies this:

Pre-call policy that requires interactive-tier confirmation for write operations against ePHI tools.
Post-call audit captures the before-state and the proposed change for any mutation.
Multi-step confirmation for destructive operations (delete, batch update).

Evidence to collect:

Policy entries gating writes to ePHI tools.
Audit row showing a write attempt that was denied because it was not in interactive tier.
The two-step confirmation interaction in the agent’s UI.

164.312(d) — Person or entity authentication

“Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.”

This one is direct: the agent is not the entity seeking access. The clinician is. Your authentication has to verify the clinician, not the agent.

The control that satisfies this:

The agent operates under the clinician’s session token, not its own. The control plane verifies the JWT signature and refuses to act on stale or unsigned identities.
For agent-to-agent delegation, the chain is captured: clinician → primary agent → sub-agent → tool. Every hop carries the original identity attestation.

Evidence to collect:

Architecture documentation showing identity propagation through agent chains.
Audit row where user.sub and agent.delegation_chain are both populated.
Test case: invalidate a user’s session; confirm the agent’s next tool call is denied.

164.312(e)(1) — Transmission security

“Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”

The AI agent gap: Tool calls over HTTPS to the model provider, the MCP server, the underlying API. Each leg has its own TLS configuration, and the agent’s outputs may include ePHI in transit.

The control that satisfies this:

TLS everywhere, with certificate pinning for the highest-sensitivity destinations.
Output redaction before transmission to model providers (PHI never leaves your trust boundary embedded in a prompt or tool input).
Egress destination allow-listing.

Evidence to collect:

TLS configuration audit (cipher suites, TLS versions, certificate validity).
Policy entries that redact PHI patterns before they’re sent to model providers.
Egress allow-list policy and a recent denied-egress audit row.

Beyond SOC 2 and HIPAA

The same control surface satisfies the AI-relevant clauses of:

PCI DSS 10.2 — Logging of access to cardholder data; the audit-trail and identity controls map directly.
GDPR Article 30 — Records of processing activities; the audit trail is your processing record for AI-mediated access.
EU AI Act Article 12 — Logging requirements for high-risk AI systems; the same audit-trail substrate, with retention extended to the operating period of the system plus six months.
NIST AI RMF MEASURE 2.7 — Logged AI system events; identical evidence pattern.

If you build the controls right for SOC 2 and HIPAA, you’ve done most of the work for the others.

A one-page implementation checklist

Print this. Tape it to your monitor. Walk through it before your audit kickoff.

Identity

Every AI agent call carries a verified end-user JWT, not a shared API key.
JWTs are verified at the control plane (signature + issuer + expiration).
Identity propagates to every tool call the agent makes, including sub-agents.
Tier (interactive / subagent / background / API) is captured per call.

Policy

Tool-call policies are versioned and stored in git (or equivalent).
Policy bundles are pinned by hash on every audit row.
Two-person review for production policy changes.
Tier-aware rules for irreversible operations.

Audit trail

Identity, agent name, tier, tool, decision, policy version on every row.
Inputs and outputs captured (redacted) and tied to a single request ID.
Retention meets the strictest framework you’re subject to (HIPAA: 6 years).
Tamper-evidence (hash chain or external immutable sink).
SIEM export with documented schema.

Redaction & integrity

PII / PHI patterns redacted before they reach model providers.
Egress destinations allow-listed.
Write operations to sensitive systems require interactive-tier confirmation.

Operations

Failure mode (control plane unreachable) is fail-closed and tested.
Anomaly alerts (deny spikes, identity-tier mismatches) are wired into your SIEM.
Inventory of agent runtimes and MCP servers is current.

If every box checks, you have the substrate for both certifications. The audit then becomes a question of evidence-gathering, not architecture defense.

Where this fits

The control surface for AI agent compliance is mostly the same surface for SOC 2, HIPAA, PCI DSS, GDPR, and EU AI Act — built once at the governance layer, evidenced everywhere. An Agentic Control Plane is purpose-built to be that substrate.

Compliance-ready AI governance → · AI agent audit trails → · Reference architecture → · Get started →

Share: Twitter LinkedIn

← back to blog