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. How identity, policy, guardrails and the audit trail fit together around your agents is covered in the AI agent control plane guide.
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 (Advanced tier and Enterprise) 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 (Enterprise); single-agent revocation. Once an agent is revoked, Praesidia refuses its next A2A call and issues it no new tokens; its MCP tool calls through Praesidia are refused from the next call when the organization's agent governance mode is enforce, while in observe mode they still run and are recorded as would-deny decisions. An identity token issued to the agent before its revocation stays valid until it expires, by default minutes after issuance, for a service that checks it offline. Model calls made through the gateway with the agent's application key continue to be accepted for up to a minute, until the gateway's next policy refresh refuses the key; requests already running then finish, and a streamed response can last up to 10 minutes. | Audit events for registration (agent, MCP server, application, and service-account creation, with the agent's credential mode); for API-key, application-key, and service-account key creation, rotation, and revocation; and for agent revocation, with the reason given and, when a user revoked the agent, that user; SCIM deprovisioning records. Token issuance is only partly in the trail: not every token issued to an agent is recorded there. |
| CC6.3 — Access is granted, modified, and removed based on roles and least privilege | Per-connection authorization for the calls that pass through Praesidia (an agent's MCP tool call is refused unless exactly one active connection binds the agent to that server; a call an agent makes straight to a server or API does not pass through Praesidia and needs no connection), per-tool authorization on MCP servers, RBAC for the control plane (Advanced tier and Enterprise), and access-review workflows (Enterprise). | Connection and tool-authorization configuration; completed access-review records; the audit entries for connection, tool-policy, and member-role changes (a change to a connection's minimum trust level is not always audited; see CC7.1). |
| CC6.6 — Logical access from outside system boundaries is restricted | IP allowlists on the Praesidia API (Advanced tier and Enterprise), organization-wide or narrowed to particular routes or roles, and per service-account key (service accounts are on the Enterprise plan); a time window (UTC hours and days of the week) on a connection between two agents, outside which the tasks sent over it are refused, while an MCP tool call is checked against no time window; SAML/OIDC single sign-on (Enterprise), MFA, and passkeys for administrators. Praesidia does not restrict access by the geographic origin of a request. | IP-allowlist configuration, with its changes recorded in the audit trail; connection time-window configuration, with decision records for the agent tasks a time window refused; SSO and MFA enforcement settings. A request an IP allowlist rejects is not recorded in the audit trail. |
| 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; guardrail log entries for content the Praesidia API checks, one for each evaluated rule with the action taken when it triggered (block, redact, warn), kept separately from the audit trail; blocks enforced at the gateway as decision records in the audit trail (the gateway's redactions and warnings are recorded in neither); audit records of API-key, application-key, and service-account key creation, 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 | These control-plane changes are recorded as audit events attributed to the operator or API key that made them: guardrail create, update, delete, and rollout; agent policy create, update, delete, and assignment; tool policy create, update, and delete; connection create, status, policy, configuration, attached guardrails, and disconnect; the creation, rotation, and revocation of API keys and application keys; and service-account creation, key rotation, and deletion. Not every change is: a change to a connection's minimum trust level may not be recorded, and for most changes recording is not guaranteed, so a change can stay in place without its record. On the Advanced tier and Enterprise, 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 traces your instrumented agents send to your Praesidia workspace, a per-organization metrics export, SIEM forwarding of security events (Advanced tier and Enterprise), alert rules that notify by email or signed webhook (Advanced tier and Enterprise), and budget policies, on the Team and Enterprise plans, that can pause or block new agent tasks once spend reaches a threshold you set, and refuse a model call through the gateway that would exceed an agent's or the organization's budget; no budget is checked on an MCP tool call. | Forwarded SIEM events; alert history; budget and rate-limit configuration with the refusals recorded under them. |
| CC7.3 — Security events are evaluated to determine whether they are incidents | Forensic search over the audit corpus (Advanced tier and Enterprise); a chain view that traces an agent-to-agent chain hop by hop (Enterprise), so an event can be traced to the request that started the chain. | 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, guardrail blocks, tool-policy refusals, and budget policies that pause or block new agent tasks as response actions; a tool policy refuses an MCP tool call only under the enforce governance mode, while in observe mode the call runs and the refusal is recorded as a decision. An agent revocation is written to the audit trail after the change, with the acting operator and the reason given; an agent revoked with an organization API key names neither a user nor the key. Blocks are recorded where they are enforced: a guardrail block on an agent task as an audit event next to its guardrail log entries, and a block at the gateway as a decision record; recording is not guaranteed, so a block can go unrecorded. | Agent revocation events with timestamp and reason, naming the acting operator when a user revoked the agent; guardrail-block audit events, gateway decision records, and guardrail log entries for the incident period; 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 the changes listed under CC7.1 land in the audit trail attributed to the operator or API key that made them, with the gaps noted there. | Change history for a connection over the audit period (a change to its minimum trust level may be missing from it); 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 cryptographic tamper-evidence under the default configuration; signed compliance-bundle export by organization owners and compliance officers; the offline verifier, distributed under Apache-2.0 to customers and their auditors; 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, calls that do not pass through Praesidia are not recorded, and your system description should say which paths are covered. Second, Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A signed record shows it was not changed afterwards. It does not show that every action was captured. 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 and time windows, and, on a connection between two agents, a monthly spend cap. No spend cap or time window is checked on an MCP tool call; an agent's connection to an MCP server can cap each tool's calls per hour instead. Send one agent task over the connection that its policy allows and one that it denies, then look for both in the trail: the allowed task recorded as created, the denied one as a policy-violation decision record with its reason, such as a rate limit or a time window. Neither record is guaranteed to be written. A model call through the gateway reaches the trail only when the gateway blocks it or requires a step-up; an allowed gateway call is not written there. A signed record shows it was not changed afterwards. It does not show that every action was captured.
- 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; access-review workflows in Praesidia are on the Enterprise plan.
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, on the Enterprise plan; the guardrail and policy configuration attached to each connection; and an exported audit bundle covering the sample period. Signing is on in the default configuration, so the auditor can verify that bundle with the offline verifier, distributed under Apache-2.0 to customers and their auditors, 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.