Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
Where agent changes break a SOC 2 sample
CC8.1 expects changes to be authorized, tested, approved, and documented. An agent that applies Terraform with a cloud role it inherited from a developer leaves a change with no request, no separate approver, and a cloud log that names the role instead of the agent. Even if the change was correct, the sample has no evidence that it was controlled.
SOC 2 criteria mapped to Massdriver controls
Each row names a Trust Services Criterion, what it requires, what Massdriver does for changes that run through it, and the evidence your auditor can request.
| Criterion | What it requires | What Massdriver does | Evidence produced |
|---|---|---|---|
| CC8.1 | Changes to infrastructure, data, and software are authorized, designed, configured, documented, tested, approved, and implemented. | Every change, from a person, a pipeline, or an agent, is configured from the approved catalog, planned, and checked against policy. Where your policies separate the steps, it is proposed and a person with deploy permission approves it. The deploy runs in a deterministic pipeline. | A per-change record with the proposer, the approver, the plan diff, and the policy results; deployment history |
| CC6.1 | Logical access security software, infrastructure, and architectures protect information assets. | AWS, Azure, and GCP credentials stay in Massdriver. People and agents act through Massdriver with tokens that attribute-based policies limit by environment, project, and team. | Policy definitions; service accounts and their token expiry |
| CC6.2 | Users are registered and authorized before the entity issues credentials or grants access. | People sign in through your identity provider with SSO, and SCIM adds and removes them. Each agent gets its own service account and a token with an expiry you set. | SCIM and access events in the audit log; service account list |
| CC6.3 | Access is authorized, changed, or removed based on roles, with least privilege and segregation of duties. | Proposing a change and deploying it are separate permissions, given to separate groups. An agent group can propose a production change that only an approver group can deploy. | Group policies; the proposer and approver of each production change |
| CC7.1 | Detection procedures identify configuration changes that introduce new vulnerabilities. | Policy checks, including SOC 2, HIPAA, and CIS rules, run before every deploy. Massdriver integrates with Checkov, Snyk, OPA, and Wiz. | Policy results attached to each change |
| CC7.2 | System components are monitored for anomalies that indicate malicious acts or errors. | A live inventory lists every resource Massdriver provisioned, with its owner and its dependencies, so an unexpected resource or owner is visible. | Queryable inventory export |
Massdriver records the changes that go through it. Your auditor or assessor decides whether these records meet a control, and changes made outside Massdriver, in a cloud console or with a cloud key, do not appear in them.
What Massdriver does not cover
A SOC 2 report covers far more than infrastructure changes. These parts stay with your other controls.
- Runtime monitoring and incident response. CC7.3 through CC7.5 need your monitoring, alerting, and incident process. Massdriver records what changed, which helps the investigation, but does not detect attacks.
- Changes made outside Massdriver. A change made in a cloud console or with a cloud key does not appear in the Massdriver record. Limit those paths with cloud IAM.
- Application code review and testing. Massdriver governs the infrastructure an application runs on. Review and tests for the application code stay in your software delivery process.
- The rest of the Common Criteria. Control environment, risk assessment, vendor management, and HR controls (CC1 through CC5, CC9) are outside the infrastructure path.
SOC 2 questions about AI-built infrastructure
Does Massdriver make us SOC 2 compliant?
No tool does. Massdriver produces records for the changes that run through it: who proposed each change, who approved it, the plan diff, and the policy results. Your auditor decides whether those records satisfy CC8.1 and the access criteria in your system description.
Do infrastructure changes from AI coding agents fall under CC8.1?
CC8.1 applies to changes to infrastructure and software, whoever or whatever makes them. If an agent can change production, your auditor will expect those changes to be authorized and approved like any other. In Massdriver the agent proposes, and a person deploys.
How does an auditor tell an agent change from a person change?
Each agent has its own Massdriver service account. Every audit log entry names the actor, so an auditor can filter for changes an agent proposed and see who approved each one.
Other framework mappings
HIPAA
Security Rule access, audit, and integrity standards for the infrastructure that holds ePHI.
See the mapping →NIST AI RMF
Govern, Map, and Manage subcategories for the coding agents your teams already use.
See the mapping →EU DORA / Digital Operational Resilience Act
ICT change management, access, and asset inventory duties under Regulation (EU) 2022/2554.
See the mapping →One governed path, for agents and every other change.
Give us an hour with your platform and security leads, and within a day you have a governed path running on your own infrastructure, ready to prove for 30 days.