SOC 2 evidence for AI agents: CC6 and CC7

Where does SOC 2 evidence for AI agents come from?

SOC 2 evidence for AI agents comes from four records the endpoint already keeps. They show what each person's AI can reach (CC6.1), how access is granted and removed (CC6.2), which role each person holds (CC6.3), and each tool call that reaches execution (CC7.2). None of them is produced for the audit. Each is the operating record of the endpoint, which makes a sample cheap to pull and hard to argue with.

The criteria are the AICPA's Trust Services Criteria, the control criteria used to evaluate and report on controls over security, availability, processing integrity, confidentiality and privacy. In a Type II audit, AI access lands in logical access, next to the user access review. The auditor tests a period, not a moment, and asks for a population, the authorization behind it, and a log nobody can edit. The complication is that the population was assembled by a support lead and a finance analyst, in three different AI clients, on their own logins.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected SaaS account through one organization-wide MCP endpoint, POST /mcp, behind OAuth. Each person signs in and receives their own grant, rather than pasting a shared token into a client. One address is what makes the population countable in the first place.

The alternative is not an absence of AI. It is AI that leaves no record: a customer list pasted into a browser client, or a script carrying a long-lived token. Neither produces anything a tester can sample, which is why the first finding is usually about visibility rather than permissions.

A control plane produces evidence. It does not produce a certification. Whether Elaichi itself holds SOC 2, ISO 27001 or HIPAA attestations is a question for the Trust Center. Read the answer there rather than inferring it from a blog post.

Which artifact answers each criterion?

Each criterion has an artifact the auditor will ask for, and each artifact is a record Elaichi keeps for its own operation. This table pairs them.

Work them in the order an auditor tests: the population first, the authorization second, the record third.

CC6.1: what can an AI client reach, and on whose credential?

CC6.1 asks for logical access security software, infrastructure and architecture over protected information assets. For AI access, the artifact is the endpoint itself plus the rules that narrow it. Elaichi exposes one organization-wide MCP endpoint behind OAuth. No toolbox gets a URL of its own and no link carries an embedded token, so there is no second population of addresses to go hunting for.

The protocol supports that shape. The MCP authorization specification makes a protected MCP server an OAuth 2.1 resource server, and it requires authorization on every HTTP request from client to server.

What to pull:

• Scopes on the grant: mcp:read, mcp:write, mcp:destructive and mcp:tools. A tool classified forbidden is reachable under no scope at all.
• The permission gate. tool:execute gates the whole endpoint ahead of every scope. Without it, tools/list comes back empty and a call returns an in-band error naming the permission.
• Restriction rules, enforced at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file.
• Identity. SAML and OIDC SSO built in-house, SCIM v2 with group-to-role mapping, TOTP MFA with single-use recovery codes, passkeys, and API tokens hashed at rest and shown once.

One detail closes a bypass, so testers like it. A block rule matches the tool name or the underlying operation, and an allow rule matches the operation only. Whoever edits a connector's documentation controls the advertised name, so governance binds the operation instead of the label. The reasoning is in why a block matches the name and an allow does not.

Where do the app credentials actually sit?

Not in Elaichi. A separate credential service holds per-account secrets, encrypted with AES-256-GCM at rest, and it owns refresh. When a refresh fails, the connection is set to needs_reauth instead of breaking quietly, so a stale token shows up as a state instead of an intermittent error.

A connect URL is not a credential. It is a one-time session carrying no token, which is why it is safe to return over MCP. Read-back of an account's configuration returns public values plus secret_paths, the list of encrypted dot-paths, with none of their values.

An organization can also supply its own OAuth app per connector: a client ID, a client secret and scopes, with everything endpoint-shaped deliberately unrepresentable. That path is gated on connector:manage rather than connection:manage, so the people who can delete a connection do not silently gain the ability to repoint the organization's OAuth app.

Key custody sits on the next plan. In Elaichi, customer-managed keys in AWS KMS come with the Black plan, which is launching soon. Leave it out of a control description written for Gold.

CC6.2: how do people get access, and what happens when they leave?

CC6.2 asks that new internal and external users are registered and authorized before credentials are issued, and that their credentials are removed once access is no longer authorized. Removal is where the timing is exact. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant's revoked_at value is then re-read from the organization store on every call. For removal, suspension and grant revocation, "effective on the next call" is accurate.

Registration has four paths, and an auditor will want to know which ones you use. They are emailed single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a configurable default role, SCIM provisioning, and just-in-time SSO. SCIM is the provisioning protocol defined in RFC 7644, so users and groups can come straight from your identity provider. Verified domains are proved by a DNS TXT record.

The second half of a deprovisioning sample is usually the weak one, and the offboarding preflight covers it. A removal is refused while a private connection is still depended on by a shared toolbox. An admin has to transfer it to another member first. A transfer goes to one member, never to a team or the organization. A private connection that nothing beyond the person depends on cannot be transferred and is deleted with them. Delegated toolbox entries raise a non-blocking warning, and re-pinning is the fix.

Contractors are where removal goes wrong most often. Cutting contractor AI access on the day they leave covers that case on its own.

CC6.3: how is each person's access authorized and limited?

CC6.3 asks that access is authorized, modified and removed based on roles and responsibilities, with least privilege and segregation of duties in mind. The artifact is a member list where every member holds exactly one role. Elaichi enforces that with a unique index, so roles do not pile up over a tenure and an access review has nothing to reconcile.

The system roles form a strict subset chain: Guest, Member, Team Admin, People Admin, Org Admin, Org Owner. Billing Admin and Auditor sit off the chain. Two instances of segregation of duties belong in the control description. Org Admin holds every permission except billing:manage and org:delete, and org:delete is Owner-only, so an attacker who lands an admin account cannot delete the workspace and the evidence together. The connector:create permission is flagged high trust, because a custom connector can be pointed at any destination.

Sharing is a separate layer, and it answers the request to show that a given person cannot see a given resource. A grant of view, use or edit goes to a user, a team or the whole organization. A member sees only what they own or what was explicitly shared with them. No organization-level permission silently widens a listing, owners and admins included.

Two facts belong in the narrative before a tester finds them:

• In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks always beat allows. Note the trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
• A role change or a restriction change takes effect within about two minutes, because it waits out a 60-second cache before spreading across the edge. Grant revocation, member removal and suspension are effective on the next call.

Can the auditor get a seat without paying for one?

Yes. Elaichi has an Auditor role that is read-only and a free seat, alongside Guest and Billing Admin. Org Owner, Org Admin, People Admin, Team Admin and Member are the billable seats, so a compliance reviewer does not cost a license on either plan.

Put the reviewer inside the system rather than emailing exports. Exported files create a chain-of-custody argument you do not need, and they go stale the day after you send them.

Auditor lacks tool:execute, which gates the whole MCP endpoint. The reviewer reads the configuration state and the audit trail. The tools list comes back empty, and any call returns an in-band error naming the missing permission. Read access to the record does not come with the ability to act on a connected account.

CC7.2: how do you show that AI activity is monitored?

CC7.2 asks that system components are monitored for anomalies that point to malicious acts, natural disasters or errors, and that anomalies are analyzed to decide whether they are security events. The artifact is the audit log, meaning the append-only record of who did what. In Elaichi it holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The account it records is the one the call actually reached, taken from the execution rather than from the intent.

actor_kind is a field, not an inference. Its values include user, system, staff, scim, api_token and ai_assistant, which marks the Elaichi Agent. A call from Claude, ChatGPT or Cursor is recorded under the person who signed in, with surface mcp and the OAuth client named, and those three clients are marked verified. Both are recorded at the point of action, not guessed afterwards from a user agent string. That is the difference between a monitoring control a tester can sample and one you can only describe. The full field list, and why argument contents stay out of it, is in what an AI agent audit log must capture.

The protocol expects such a record. The MCP specification's tools page asks servers to implement proper access controls, and asks clients to log tool usage for audit purposes. A trail kept at the endpoint does not depend on which client a person happened to use.

Properties that come up in fieldwork:

• Each organization's audit history is scoped in the type system rather than by a WHERE clause. A dropped clause leaks; a wrong scope returns nothing.
• Staff impersonation is recorded and attributed to the staff member in your own audit log, rather than appearing as you.
• The trail is append-only, newest-first, and filterable by free text, category, actor, action kind and time. A departed member renders as "Former member" rather than being dropped.
• It is eventually consistent, so a row may take a moment to appear. Put that in the narrative, or a tester who makes a call and refreshes at once writes a finding.

Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. A Splunk HEC or Microsoft Sentinel destination is accepted but does not deliver events, so do not build a control description around either one. The audit trail inside Elaichi is on Gold.

Which criteria does a governed MCP endpoint not touch?

Most of them. A control plane is a logical access and monitoring control. It says nothing about CC1 through CC5: control environment, communication and information, risk assessment, monitoring activities and control activities. CC6.4 is physical access. CC8 is change management over your own infrastructure, data and software. CC9 is risk mitigation, including the vendor risk in CC9.2, and Elaichi is one of the vendors being managed.

It also stops at the boundary of the account it reaches. Native permissions inside your accounting system are still yours to configure, and the model itself is not audited by the endpoint in front of it.

Two limits are specific to this product and belong in the narrative rather than in a finding:

• Prompt injection. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint is role-based access control per operation, the forbidden classification, output redaction, OAuth scope limits and an audit row for each call that reaches execution. If prompt injection sits on your risk register, this endpoint is not the mitigating control for it.
• Data disposal. Deleting an organization deletes the credentials and tears down the workspace, but it leaves three stores behind: the audit history (each record ages out under the log server's 90-day retention, counted from when it was written), analytics events and the credential service's connector configuration rows. It returns that residue by name. Document the residue, and do not claim complete deletion.

How do you assemble the sample pack?

Work in the order the auditor tests, population first and detail second. Six steps, each producing one exhibit.

1. Export the member listing with role and seat class: exactly one role per member, with Guest, Billing Admin and Auditor marked as free seats.
2. Export the resource grants, showing which users and teams hold view, use or edit on each shared connection and toolbox.
3. Export the restriction rules per role and per user, recording the operations they bind rather than the advertised tool names.
4. Pull the audit log for the whole period. Filter by actor and time, then trace a sample of tool calls back to a member, a role, a connection and an outcome.
5. Take three removals and pair each with its offboarding preflight resolution and the grant revocation in the same transaction.
6. Attach the Trust Center for anything about certification status, and state in your own control description that role and restriction changes take effect within about two minutes.

If your AI footprint is one team and one client, the smaller answer may still be right. The case for not buying a gateway yet sets out when that holds. Past that, the population you will be asked to enumerate is the set of SaaS accounts people have already connected. The connector catalog runs to 600+, the team pages show which of the twelve teams tends to connect what, and the rest of the governance writing covers the rules underneath.