SCS + SCP: SOC 2 Alignment¶

Trust Services Criteria for AI Agent Deployments¶

Supervisory Control Plane — Ohana AI Strategy & Systems Architecture Contact: info@ohana-tech.com | supervisoryplane.com

Two Distinct Questions¶

SOC 2 comes up in two different contexts for SCP:

Does SCP itself meet SOC 2 criteria as a vendor? — Prospects may require their vendors to hold a SOC 2 Type II report. SCP is not yet SOC 2 certified. Certification is on the roadmap; see the gap section below.
Does SCP help an organization meet SOC 2 criteria for their AI agent deployments? — Organizations with AI agents in scope for SOC 2 audits need to demonstrate access controls, change management, and audit evidence for those systems. SCP provides the governance infrastructure to do this.

This document addresses both questions directly.

SCP Helping You Meet SOC 2 for AI Agent Deployments¶

As AI agents become part of production systems, they fall within the scope of SOC 2 audits. Auditors will ask: how are agent identities managed, how are behavior changes controlled, and what evidence exists that agents operated as intended?

CC6 — Logical and Physical Access Controls¶

Criterion	Requirement	SCS / SCP Coverage
CC6.1	Logical access restricted to authorized users	SCP Agent Registry assigns each agent a unique identity, role, and set of allowed intents. Agents cannot request context outside their registered permissions. Access is enforced at the control plane, not self-reported by the agent.
CC6.2	User (agent) lifecycle managed — provisioned, modified, revoked	SCP agent registration is explicit: agents are provisioned with defined roles, modified via the API, and can be deregistered. API keys are SHA-256 hashed and can be revoked immediately.
CC6.7	Restrict transmission of confidential information	SCP role-based context delivery ensures agents receive only the governance context relevant to their role and intent. An agent with a billing role does not receive PHI policies; an agent with a clinical role does not receive financial system credentials.

CC7 — System Operations¶

Criterion	Requirement	SCS / SCP Coverage
CC7.2	Monitor system components for anomalous activity	SCP audit log records every context request: agent identity, role, intent, SCDs delivered, timestamp, request ID. Anomalous patterns (unexpected intents, high-frequency requests, policy violations) are detectable from the audit stream.
CC7.3	Evaluate security events and determine their significance	SCP audit trails provide the raw event data for security evaluation. Every agent action that involves governance context is logged and attributable.

CC8 — Change Management¶

Criterion	Requirement	SCS / SCP Coverage
CC8.1	Authorize, design, develop, test, and approve system changes	SCS semantic versioning enforces a change management discipline for governance artifacts. Governance changes go through: author (provenance recorded) → version increment → validation → publish to Bundle Registry → delivery to agents. No governance change takes effect without a versioned, authored artifact.

The CC8 alignment is SCS's strongest SOC 2 contribution. SOC 2 auditors require evidence that changes to systems are controlled. SCS bundles provide that evidence for governance changes: who changed a policy, when, under which version, and when it was promoted to production. This is the audit trail auditors look for, applied to AI governance context.

C1 — Confidentiality¶

Criterion	Requirement	SCS / SCP Coverage
C1.1	Protect confidential information from unauthorized disclosure	SCS confidentiality SCDs define data classification levels and handling requirements as structured context delivered to agents at runtime. Agents operating under these SCDs cannot claim they didn't know the confidentiality requirements — those requirements were their operating context.
C1.2	Dispose of confidential information per retention policy	SCS data SCD encodes retention policies and disposal requirements for agent-handled data.

A1 — Availability¶

Criterion	Requirement	SCS / SCP Coverage
A1.1	Meet availability commitments	SCP deployment via Docker Compose or AWS CloudFormation with documented failover. When SCP is unavailable, the fail-safe behavior routes agent requests to human review — the system degrades gracefully rather than silently.
A1.2	Incident management and recovery	SCP backup and restore procedures are documented. Recovery point and time objectives are defined in the deployment runbooks.

Loading SOC 2 Requirements as Structured Context¶

For organizations using the scs-team Claude Code plugin:

/scs-team:use soc2

This loads the SOC 2 Trust Services Criteria as SCS SCDs — structured context covering security (CC6, CC7, CC8), availability (A1), and confidentiality (C1). Your AI agents operate under these requirements as explicit governance context, not implicit expectations.

SCP's Own SOC 2 Posture¶

SCP does not currently hold a SOC 2 Type II report.

Some prospects will require vendor SOC 2 certification as a procurement condition. The honest status:

Control Area	Current State
Logical access controls	API key authentication implemented. OAuth2/OIDC (required for enterprise SSO/MFA) on the roadmap.
Audit logging	Complete — all context requests logged with full attribution.
Change management	SCS versioning applies to governance artifacts. Standard software change management (code review, CI/CD) in place.
Encryption in transit	TLS for all external communications.
Encryption at rest	Depends on deployment infrastructure (customer-managed for self-hosted).
Availability monitoring	Basic health checks. Prometheus/Grafana observability on the roadmap.
Formal SOC 2 audit	Not yet initiated. Target: after first production pilot.

For pilot customers: SCP is deployed within your infrastructure. Your security team controls the environment, key management, and network access. The SCP system itself is within your security perimeter — your SOC 2 controls apply to it, not ours.

This is by design. The self-hosted deployment model means enterprise customers don't depend on SCP's vendor SOC 2 status for their own compliance — they control the environment.

Summary¶

Use Case	SOC 2 Coverage
Governing AI agents within a SOC 2-audited system	Strong — SCP provides access controls (CC6), audit evidence (CC7), and change management artifacts (CC8) for AI agent behavior.
SCS as the change management layer for governance	Strong — versioned bundles with provenance satisfy CC8.1 evidence requirements for governance changes.
Vendor SOC 2 certification	Not yet. Self-hosted deployment model reduces dependency on vendor certification for most pilot scenarios.