This page is for security engineers, GRC leads, and the person who owns the SOC 2 evidence request list at a company that runs AI agents in production. It maps the controls Praesidia provides to the SOC 2 Trust Services Criteria (the 2017 criteria with 2022 points of focus) most affected by autonomous agents, and it lists the evidence you can export for each.
SOC 2 does not mention AI agents. It asks whether your organization designs and operates controls that meet the criteria in scope: Security (the Common Criteria, CC1 through CC9) plus any of Availability, Processing Integrity, Confidentiality, and Privacy you include. Agents change the facts on the ground under those criteria. An agent is a principal that authenticates, reads data, calls tools, and produces output at machine speed. If it shares a service account with four other agents, CC6.1 attribution fails. If its tool calls land in a log an administrator can edit, the auditor's reliance on that log under CC7 weakens. If nobody can say who changed the agent's permissions last Tuesday, CC8.1 has a gap.
The mapping below focuses on CC6 (logical and physical access), CC7 (system operations), CC8 (change management), and CC9 (risk mitigation, including vendors). The broader background on what auditors look for in AI platforms is in SOC 2 for AI platforms; the worked example of an agent audit trail built for a SOC 2 audit is in the SOC 2 audit trail use case.
Control mapping
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| CC6.1 — Logical access security software, infrastructure, and architectures are implemented to protect against security events | A distinct non-human identity for every agent, MCP server, and application, with no shared service accounts; role-based access control and scoped API keys for the humans and integrations that manage them; strict tenant isolation. | Inventory export of registered entities and their credentials; role and API-key scope listing; the identity guide at /guides/identity-access-for-ai as design documentation. |
| CC6.2 — New users are registered and authorized before credentials are issued; access is removed when no longer needed | Entities are registered before they receive credentials, with just-in-time ephemeral credentials as the default for new agents; SCIM lifecycle for human operators; single-agent revocation that takes effect on the next request. | Registration, credential issuance, rotation, and revocation events in the audit trail; SCIM deprovisioning records. |
| CC6.3 — Access is granted, modified, and removed based on roles and least privilege | Per-connection authorization (an agent can only reach what it is explicitly connected to), per-tool authorization on MCP servers, RBAC for the control plane, and access-review workflows. | Connection and tool-authorization configuration; completed access-review records; the audit entries for each permission change. |
| CC6.6 — Logical access from outside system boundaries is restricted | IP allowlists, geographic restrictions, and time-based access policies per connection; SAML/OIDC single sign-on, MFA, and passkeys for administrators. | Policy configuration per connection; denied-request records; SSO and MFA enforcement settings. |
| CC6.7 — Transmission, movement, and removal of information is restricted to authorized users and processes | Bidirectional guardrails that redact or block sensitive data in agent inputs and outputs; vaulted provider keys and credentials that are shown once and never read back in plaintext. | Guardrail configuration and per-request decision records (block, redact, warn); audit records of credential issuance, rotation, and revocation. |
| CC6.8 — Unauthorized or malicious software is prevented or detected | Customer control; Praesidia contributes prompt-injection detection on inbound content, tool-name restrictions on MCP servers, and discovery of agents operating outside governance. | Guardrail hit records; list of discovered-but-not-adopted agents; tool-restriction rules. |
| CC7.1 — Configuration changes and vulnerabilities are detected and monitored | Every control-plane change (guardrail, policy, connection, credential) is recorded as an attributable audit event; alert rules can watch the audit stream. | Audit records filtered to configuration changes; alert-rule definitions. |
| CC7.2 — System components are monitored for anomalies indicative of malicious acts or errors | OpenTelemetry metrics and traces, SIEM forwarding of security events, alerting to Slack and email, and hard spend caps that stop runaway agents. | Forwarded SIEM events; alert history; budget and rate-limit configuration with triggered-cap records. |
| CC7.3 — Security events are evaluated to determine whether they are incidents | Forensic search over the audit corpus; hop-by-hop attribution of agent-to-agent chains so an event can be traced to its originating request. | Forensic query exports; chain views for the incident period. |
| CC7.4 — Identified incidents are responded to through defined procedures | Customer control; Praesidia contributes single-agent revocation with contained blast radius, fail-closed block verdicts, and immediate budget caps as response actions, each recorded in the trail. | Revocation and cap events with timestamps and acting operator; incident-period audit export. |
| CC8.1 — Changes to infrastructure, data, software, and procedures are authorized, designed, tested, approved, and implemented | Customer control; Praesidia contributes an API-first surface so configuration changes can flow through your CI/CD and approval process, and every change lands in the audit trail attributed to the operator or API key that made it. | Change history for a connection over the audit period; API-key scope showing which automation may change what. |
| CC9.2 — Risks from vendors and business partners are assessed and managed | Customer control; Praesidia contributes bring-your-own-key model-provider access (you hold the provider relationship), bring-your-own-key custody for audit-record signing, and a published subprocessor list on the security page. | Provider configuration; BYOK custody settings; your vendor-review file for Praesidia itself. |
| Evidence integrity (supports reliance on logs across CC4, CC6, CC7) | An append-only audit trail with optional cryptographic tamper-evidence; signed compliance-bundle export by organization owners and compliance officers; an open-source, offline verifier; optional anchoring to the public Sigstore Rekor transparency log. | The exported bundle plus the verifier's pass or fail result, reproducible by the auditor on their own machine. |
What this mapping is not
This is a control mapping, not an attestation. SOC 2 reports are issued by independent CPA firms after examining your organization's controls over a period; a vendor cannot issue one for you, and a vendor's own report does not transfer to your environment. These mappings support your assessment and do not constitute certification.
Several criteria remain substantially yours. Praesidia records who changed what; your change-management policy decides who is allowed to. Praesidia detects and blocks; your incident-response runbook decides what happens next and who is told. Praesidia gives every agent its own identity; your onboarding process decides which agents exist and what business purpose justifies each connection. CC1 (control environment), CC2 (communication), CC3 (risk assessment), and CC5 (control activities) are organizational criteria that no platform satisfies on your behalf.
Two scope notes matter for honesty with your auditor. First, the audit trail records activity that flows through connections you route through Praesidia; traffic that bypasses the platform is not visible to it, and your system description should say so. Second, if you enable cryptographic signing, the verifier confirms that what is in an exported bundle was not altered after signing. It does not prove that every action was captured in the first place. The verification page states these limits plainly, and a good auditor will appreciate seeing them written down before asking.
Getting started
- Create a workspace and register your in-scope agents at /start, giving each one its own identity so attribution is settled before the audit period begins. The getting-started guide walks through the first entity, connection, and controls.
- Attach controls to every connection that touches in-scope systems: guardrails for content, policies for rate, geography, and time windows, and a budget cap. Exercise one allowed and one denied request and confirm both appear in the trail.
- Run an export before the auditor asks. Follow from agent action to audit evidence to trace one controlled action to its signed export, then have someone outside the engineering team run the verifier as described at /security/verify-your-audit-trail.
- Schedule access reviews for agent permissions on the same cadence as your human access reviews, so CC6.3 evidence accumulates during the period rather than being assembled at the end. The access review guide covers the procedure.
Common questions
No single tool does. SOC 2 is an attestation over your organization's controls, performed by an independent CPA firm against the criteria you scope in. Praesidia supplies runtime controls and exportable evidence for the criteria most affected by agents, chiefly logical access (CC6), monitoring (CC7), and change management (CC8). Your policies, your people processes, and your auditor decide the outcome.
CC6.1 through CC6.3 (who and what can access systems, and with what privileges), CC6.7 (controlling data leaving the boundary), CC7.1 through CC7.4 (detecting, evaluating, and responding to events), and CC8.1 (authorized, documented change). Agents strain these because they act autonomously, often under shared credentials, and generate activity that traditional logs attribute poorly.
An inventory of registered agents, MCP servers, and applications with their credentials and roles; the access-review records; the guardrail and policy configuration attached to each connection; and an exported audit bundle covering the sample period. If cryptographic signing is enabled, the auditor can verify that bundle offline with the open-source verifier without contacting Praesidia.
Yes. CC8.1 asks whether changes are authorized, tested, approved, and documented, which is an organizational process. Praesidia contributes attributable, logged configuration changes made through the dashboard or the API, so the record of who changed a guardrail or policy, and when, is available as evidence rather than reconstructed from memory.
SOC 2 attests to controls over security, availability, processing integrity, confidentiality, and privacy for a service organization. ISO/IEC 42001 is a management-system standard specific to AI. Many teams run both; the audit trail, identity, and guardrail evidence described here serves either program. See the SOC 2 versus ISO 42001 comparison linked below.