SOC 2 evidence for AI agents: CC6 and CC7

Where the AI question lands in a Type II audit

It lands in logical access, next to the user access review. The auditor is testing a period, not a moment. The request is for a population, the authorization behind it, and a log nobody can edit. SOC 2 evidence for AI agents has that same shape. 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. OAuth here means each person signs in and receives their own grant, rather than a shared token pasted 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. Someone pastes a customer list into a browser client. Someone else writes a script with a long-lived token in it. Neither produces anything a tester can sample, which is why the first finding is usually about visibility rather than about permissions.

Settle one thing before fieldwork starts. 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, and the answer should be read there rather than inferred from a blog post.

Where does SOC 2 evidence for AI agents come from?

From four artifacts, each tied to a different criterion. None of them is generated for the audit. Each is the operating record of the endpoint, which is what makes a sample cheap to pull and hard to argue with.

Work them in that order. The population comes first, the authorization second, the record third.

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

CC6.1 is about the access architecture over protected assets. The artifact is the endpoint itself, plus what the resolver allows through it. Elaichi exposes one organization-wide MCP endpoint behind OAuth. There are no per-toolbox URLs and no embedded tokens, so there is no second population of addresses for a tester to go hunting.

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. Guest, Auditor and Billing Admin do not hold it.
• Restriction rules. A restriction says which connectors and which individual tools a target may reach. Enforcement happens at four points against the same resolver: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.
• 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 testers like, because it closes a bypass. A block rule matches the tool name or the pinned operation. An allow rule matches the pinned operation only. Whoever edits a connector's documentation controls the advertised name, so governance binds the operation instead of the label. The reasoning is worked through in why a block matches the name and an allow does not.

Where do connector 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. A failed refresh marks the connection needs_reauth rather than failing quietly, so a stale token shows up as a state rather than as 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 dot-paths that were encrypted. That list carries none of the values, and it is the only thing that decides whether a variable is a secret. Editing one is refused, and the refusal text is identical whichever side produced it, so a caller cannot tell which side refused.

Two further artifacts are worth naming in a control description. An organization can supply its own OAuth app per connector, accepting a client ID, a client secret and scopes. Everything endpoint-shaped is deliberately unrepresentable. That path is gated on connector:manage rather than connection:manage, so everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app. For key custody, Elaichi supports per-organization envelope encryption with a customer-managed key in AWS KMS.

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

CC6.2 covers registration before credentials are issued and removal once access is no longer required. On the removal side the timing is exact. removing or suspending a member revokes every live grant in the same transaction as the membership change, and revoked_at is re-read from the organization store on every single 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 actually use: 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. Verified domains are proved by DNS TXT record.

The second half of a deprovisioning sample is usually the weak one, and the offboarding preflight earns its place there. A removal is refused while a personal connection is still referenced by a toolbox entry. The connection has to be transferred to the organization, a team or another member, or deleted. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become someone else's when that owner leaves. Delegated toolbox entries raise a non-blocking warning, and re-pinning is the fix.

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

CC6.3: one role per member, and a least privilege you can screenshot

CC6.3 is about authorizing and modifying access with least privilege and segregation of duties in mind. The artifact is a member listing where every member holds exactly one role. Elaichi enforces that with a unique index. Roles do not accumulate over a tenure, so 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. connector:create is flagged high trust, because a custom connector can be pointed at any destination.

Sharing is a separate layer. It answers the request to show that a given person cannot see a given resource. A grant of view, use or edit is made 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 to write into the narrative before a tester finds them:

• Restrictions target a role or a user. restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. The organization default is the absence of any rule, which means allow all. A rule on a user replaces the role rules for that user rather than adding to them Within the winning layer, allow rules union, block rules union, and blocks always beat allows. An allow rule that names nothing denies everything, because the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything rather than its contents.
• A role change or a restriction change takes effect within about two minutes, through a 60 second cache plus edge propagation. Do not write that it applies on the next request. Only grant revocation, member removal and suspension are effective on the next call.

Giving the compliance reviewer a seat of their own

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

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

Auditor lacks tool:execute, which gates the whole MCP endpoint. The reviewer can read the configuration state and the audit trail. The tools list comes back empty for them, 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: one audit row per tool call, with actor_kind

CC7.2 is about monitoring components for anomalies, and the artifact is the audit log, meaning the append-only record of who did what. Elaichi writes one entry per tool-call attempt, succeeded or failed. Both name the account actually reached, taken from the execution rather than from the intent. That is the first question after an unexpected change in one of two connected workspaces.

Recorded per call: the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code. Argument names and counts are logged. Argument values never are.

actor_kind is a field, not an inference. Its values include user, system, staff, scim, api_token and ai_assistant. Whether an action was taken by an AI is 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.

Four more properties come up in fieldwork:

• One record shape covers audit events and application logs, so a single query answers what happened instead of correlating two systems by eye.
• One log tenant per organization, enforced in the type system rather than by a WHERE clause. A dropped clause leaks; a wrong tenant returns nothing.
• An error-text firewall. The error returned to the caller is derived from the third party's response body and is never written to the audit trail, because audit records are organization-visible and are fanned out to whatever SIEM you configure.
• Staff impersonation is recorded and attributed to the staff member in your own audit log, rather than appearing as you.

On export, Datadog is implemented. Splunk HEC and Microsoft Sentinel are accepted but not yet delivering, so do not build a control description around either one today. The trail is append-only, newest-first, cursor-paginated, and filterable by free text, category, actor, action kind and time. Actor names resolve server-side, and a departed member renders as "Former member" rather than being dropped. It is also eventually consistent, so a row may take a moment to appear. Put that sentence in the narrative, or a tester who makes a call and refreshes at once writes a finding.

Which criteria a governed MCP endpoint does not touch

Most of them. A control plane is a logical access and monitoring control. It says nothing about CC1 through CC5: board oversight, communication of policy, risk assessment, evaluation of your own controls, or your control activities as a whole. CC6.4 is physical access. CC8 change management covers your code and your release process. CC9 covers vendor management, 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.

Three 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 RBAC per operation, meaning role-based access control, the forbidden classification, output redaction, OAuth scope limits and full audit logging. If prompt injection sits on your risk register, this endpoint is not the mitigating control for it.
• Data disposal. Deleting an organization tears down the workspace but has no path to purge that organization's log tenant, and it returns the residue by name. Document the residue. Do not claim complete deletion.
• Residency. The eu and us regions are hard residency, a jurisdiction that keeps compute and storage in place. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Region also decides which regional log instance the audit trail lands in.

How to assemble the sample pack

Work in the order the auditor tests, which is 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. Show 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 pinned operations 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 deprovisioning events and pair each with the offboarding preflight resolution and the grant revocation in the same transaction.
6. Attach the Trust Center for anything concerning certification status, and state the two-minute figure for role and restriction changes in your own control description.

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