SOC 2 bundle

SOC 2 is not a law and not a data type — it is an attestation framework. A licensed CPA firm examines a service organization's controls against the AICPA Trust Services Criteria: the Security Common Criteria (CC1–CC9, mandatory) plus the optional Availability, Processing Integrity, Confidentiality, and Privacy categories. The criteria are principles-based — the entity defines its own system, commitments, and controls, and the auditor tests whether they are suitably designed and operating effectively over a period. When an employee connects Salesforce, GitHub, or Snowflake to an AI agent over MCP, the agent inherits that user's credential and becomes a new, privileged access path into systems that sit inside the SOC 2 boundary. This bundle is a starting posture for that path: a DTwo policy can be the control an entity describes for the agent channel, and the gateway's per-decision log its evidence.

These policies support alignment with SOC 2 (Trust Services Criteria) on the MCP path only. They act on agent traffic that flows through the gateway; web-UI logins, native-API integrations, and in-app activity are outside their reach by design, and no policy or bundle makes an organization SOC 2 compliant. SOC 2 is an attestation over your whole control environment — the agent channel is one control among the many an auditor tests.

What this bundle covers

173 policies across 32 apps, grouped below by the Trust Services Criteria they support. Each policy appears once, under its primary theme. Every policy is single-purpose and composes with the others on the same pipeline direction. Policy bodies live under apps/; this page only links to them.

The per-decision audit log beneath the bundle — principal, action, resource, context, decision — is a property of the gateway, not a policy in it. That record is the Type II operating-effectiveness evidence for the CC6.x access criteria and the monitoring input for CC7.2 (anomaly detection) and CC7.3 (event evaluation). Every allow, deny, and transform below lands in it, attributed to an authenticated user.

1. Logical access & least privilege — the write floor (CC6.1, CC6.3)

The core CC6.3 pattern: reads stay open, writes require the matching IdP group, and specific high-impact writes are gated or denied outright. This is the per-app baseline that makes tool-level authorization keyed to identity — least privilege on the agent channel.

2. Boundary control — shut the escape hatches and standing side-channels (CC6.6, CC6.8, CC9.2)

CC6.6 makes the gateway the boundary control for the agent channel; CC6.8 and CC9.2 extend it to unauthorized tools and vendor risk. Default-deny allowlists fail closed on renamed or newly introduced upstream tools; escape-hatch denials shut the raw-API passthroughs that would bypass every other policy; and persistence guards deny the standing automations, filters, and webhooks that outlive a session.

3. Segregation of duties & change control — keep a human in the loop (CC6.3, CC8.1)

CC6.3 asks for segregation of duties; CC8.1 asks that changes to systems be authorized and approved. These policies keep the human authorization step intact: the agent may draft, propose, and read, but approval, dispatch, and identity-plane mutation stay with a named human or a gated group.

4. Restrict transmission, movement & removal (CC6.7, P6.1)

CC6.7 is the strongest DLP hook in SOC 2 — restrict the transmission, movement, and removal of information — and P6.1 limits disclosure of personal information to third parties. These policies cap bulk export and search fan-out, deny agent sends and share links to external destinations, block public exposure, keep customer-facing surfaces internal, and keep secrets from being written into governed content.

5. Confidentiality — fence sensitive scopes and redact on egress (C1.1, CC6.7, P4.1)

C1.1's "maintain and protect" half is enforceable on the MCP path, and P4.1 limits the use of personal information to identified purposes. These policies fence sensitive scopes — folders, channels, projects, schemas, boards, datasources — to the roles that own them, and redact or mask PII, PHI, and secrets from responses before they reach agent context.

6. Processing integrity — protect records from an agent (PI1.2, PI1.5)

PI1.5 asks that stored records keep their integrity, and PI1.2 that inputs are authorized. These policies deny agent-initiated deletion, overwrite, and history tampering, cap batch mutation blast radius, and block destructive SQL — so a stray plan or an injected instruction cannot erase a record of record or its audit trail. Break-glass admin groups keep legitimate cleanup possible.

How bundle membership works

Bundle membership is declared in each policy's policy.md frontmatter (the policy lists bundles: ["soc2"]). This page is a human-readable landing page; the generated manifest.json is the machine-readable source of truth. There is intentionally no separate bundle.json artifact — one source of metadata avoids drift.

The policies compose by direction. The egress redaction and masking policies (most of theme 5, plus the docusign directory cap) attach to the response pipeline and are transform-only where marked, so they never deny and never collide with the ingress controls. The ingress policies are each single-purpose — a role gate, a default-deny allowlist, a human-approval gate, an export cap, a scope fence, a destructive-op freeze — so several attach to the same app on the same direction without interfering. Where an app offers both a read-only posture and narrow write controls, pick one; combining them is redundant but harmless. Because SOC 2 scope is entity-defined, treat these themes as a menu: attach the controls that match the commitments in your own system description, not every policy by default.

What this bundle does NOT cover

These policies act only on agent traffic over MCP, and only some Trust Services Criteria reduce to a gateway decision. Out of scope by design:

• Web-UI, native-API, and in-app access. A user opening a record in the app's own UI, or a native integration writing to it, never passes through the gateway. Those paths stay governed by the app and your IdP — the gateway is one control among the many an auditor tests.
• The governance criteria (CC1–CC5). Control environment, communication, risk assessment, and the monitoring program are organizational. The gateway's audit log is an evidence input to CC4.1 monitoring, but the program itself is yours.
• Credential issuance and removal (CC6.2). Registering, authorizing, and de-provisioning users lives in the IdP (Okta/Entra) and each app. Gateway policies key on live IdP claims — so removing a user from a group cuts their agent access on the next call — but the provisioning and revocation workflows are IdP and app functions.
• Physical access and media disposal (CC6.4, CC6.5). No MCP-path surface; handled by the app vendor and the entity's facilities process.
• Encryption and protection in transit (CC6.7's in-motion half). TLS between agent, gateway, and apps is infrastructure, not policy. Encryption at rest and in transit rest with the deployment and the apps.
• Retention and disposal (C1.2, P4.2, P4.3). Retention schedules, purge, and destruction execute inside each app. A rule denying agent delete/purge tools prevents an agent from violating retention or legal hold, but it cannot execute or schedule disposal — that is adjacent support, not coverage.
• Availability (A-series) and the incident-response process (CC7.1, CC7.4, CC7.5). Capacity, disaster recovery, and backup have no MCP-path surface; the gateway emits deny events and telemetry, but triage, evaluation, and response are human and organizational.
• Data residency. SOC 2 has no residency criterion. Residency appears only if the entity writes it into its own commitments, and is enforced by app/vendor configuration, not the gateway.
• Tenant-specific inputs and identity placeholders. Sensitive project keys, schema names, folder and base IDs, channel lists, and domain allowlists are yours, not ours; supply them at import time. The IdP group names in these policies (for example finance, hr, infosec, sf-admins) are placeholders — map them to your directory's groups before relying on them.

---

Compliance note. This bundle supports alignment with the cited framework controls on the MCP path only. No policy or bundle makes an organization compliant with any framework; web-UI, native-API, and in-app access are outside the gateway's reach by design. Validate against your own compliance program before relying on it.