Answers · AI evidence
How do I answer a SOC 2 or ISO 27001 auditor's request for evidence of AI agent change control and access reviews?
Last updated
TL;DR: Treat each AI agent as two things auditors already test: a non-human account with access, and a piece of software that changes. For access, SOC 2's CC6.2 and CC6.3 and ISO/IEC 27001:2022 control 5.18 expect access to be authorized before it is granted, reviewed, changed when needs change and removed when no longer needed. For change, SOC 2's CC8.1 and ISO 27001 control 8.32 expect changes to be authorized, tested, approved and recorded. So the evidence is: a complete list of agents with an owner each; for each agent, a dated record of what it may reach, who authorized it, and its limits and expiry; a periodic review where a named person kept or removed each grant, with removals carried out; and a change record for every model, prompt, tool, permission or spend-limit change, approved before it went live. An auditor will sample from your lists, so they must be complete, and the records must have existed at the time, not been written for the audit. On Rightshold, record_access_grant signs and ledger-commits each agent's grant, revoke_access_grant records the revocation that names it, check_access_grant answers whether a grant was in force on a sample date, and POST /v1/me/compliance-export returns a signed bundle of your account's keys, mandates, revocations and receipts.
What should I check, step by step?
1. Build the population first: every AI agent, MCP client and automation that holds a credential, with an owner, the systems it reaches, the credential it uses and when it was created. Pull it from your identity provider, secret store and cloud accounts, not from memory. An auditor samples from this list, so a missing agent is an exception.
- For each agent, keep a dated access record: resource, scope, limits, who authorized it and when it expires. Write it when access is granted, before the agent uses it.
- Run access reviews on a fixed schedule (quarterly is common) and keep the output: the list as it stood, the reviewer's name, the keep/remove decision for each grant and the date. Then show each removal was actually carried out, with the provider's reference.
- Define what counts as a change to an agent: model or model version, system prompt, tools or MCP servers added or removed, scopes and permissions, spend limits, and the code that runs it. Route each one through your normal change ticket with a test and an approver who isn't the requester.
- Pin versions so changes are visible: model ids with dates, MCP server versions, and a fingerprint of each tool's definition, so an upstream change that nobody approved shows up as a change.
- Collect evidence as it happens and store it where the agent and the change author can't edit it. Records written after the auditor asked are weak evidence.
- Prepare for sampling: for any sampled date, show which grants were in force; for any sampled change, show the ticket, the test, the approval and the deploy, in that order.
- Record exceptions honestly: emergency changes approved after the fact, grants that outlived their expiry, reviews done late. Auditors expect some exceptions. Missing or reconstructed records are worse.
What do SOC 2 and ISO 27001 ask for on AI agent access and change control?
The AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) are what SOC 2 reports test against. CC6.2 covers registering and authorizing users before credentials are issued and removing credentials when access is no longer authorized. CC6.3 covers authorizing, changing and removing access based on roles, with least privilege and segregation of duties. CC8.1 covers changes to infrastructure, data, software and procedures being authorized, designed, configured, documented, tested, approved and implemented.
- ISO/IEC 27001:2022 Annex A has matching controls: 5.15 access control, 5.16 identity management (the full life cycle of identities), 5.18 access rights (provisioned, reviewed, modified and removed according to your access policy), 8.2 privileged access rights, 8.15 logging and 8.32 change management.
- Neither standard has a separate rule for AI agents. That is the point: an agent that holds a credential is in scope of the access controls, and a change to its model, prompt or tools is a change to a system in scope.
What AI agent evidence can a SOC 2 or ISO 27001 auditor sample?
A SOC 2 Type II report covers how controls worked over a period, so the auditor picks samples: some agents, some review cycles, some changes. Each sample needs a record that existed at the time and shows the control step, such as an approval dated before the deploy or a revocation dated soon after the review.
- Auditors also test that your lists are complete and accurate before sampling from them. An agent inventory built from the identity provider and the secret store holds up better than a spreadsheet kept by hand.
- Agents change in ways a code review misses: a new tool on an MCP server, a model alias that now points at a newer model, a prompt edited in a dashboard. Fingerprint what you depend on so those show up as changes and go through approval.
How do Rightshold access grant records support an AI agent access review?
record_access_grant returns a signed grant record (resource, grantor, scope, limits, valid_from, expires_at) and a receipt committed to the public ledger. revoke_access_grant records the revocation once, with your reason and the provider's reference. It does not end access at the provider, so do that too. check_access_grant says whether a grant was in force at a given moment and why: not yet valid, expired, revoked or in force.
- verify_access_record lets the auditor check a grant or revocation record without an account: its digest, its Ed25519 signature, and that a revocation names the grant it ends.
- POST /v1/me/compliance-export assembles your Rightshold account's receipts, mandates, revocations, API keys with their creation and revocation times and activity by operation into one signed bundle, maps it to SOC 2 CC6.1, CC7.2 and CC8.1, and records the export on the ledger. For outside MCP servers, check_tool_integrity re-probes the server and reports whether its tool definitions changed since they were recorded.
How do I ask Rightshold about this (free, no key)?
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “Record the access our AP agent has before the quarterly access review: it may pay approved vendor invoices from the operating account, up to 2,500 USD a day, authorized by the Controller, until the end of January. Then tell me how to show the auditor it was in force on a sample date.”
{
"tool": "record_access_grant",
"arguments": {
"workspace_id": "<your operations workspace id>",
"agent_label": "AP invoice agent",
"resource": "Operating account ending 4410",
"grantor": "Controller",
"scope": "Pay approved vendor invoices; read balances.",
"limits": {
"max_amount": 2500,
"currency": "USD",
"per": "day"
},
"expires_at": "2027-01-31T00:00:00Z"
}
}- Needs your account key. It's in the operations toolset (connect to /mcp?toolset=operations) with revoke_access_grant, check_access_grant and verify_access_record.
- check_access_grant with at set to the sample date answers in force, not yet valid, expired or revoked. verify_access_record is free and needs no account, so the auditor can check the records themselves.
- request_human_approval binds a change, such as raising a limit or adding a tool, to a named human decision on the hash of the exact change, and verify_human_approval checks it.
- POST /v1/me/compliance-export (REST, account key) returns the signed evidence bundle, and GET /v1/me/compliance-exports lists every earlier export, so the evidence trail has its own trail.
Rightshold records grants, revocations, approvals and exports you send it, signs them and commits them to a hash-chained public ledger. It doesn't connect to your identity provider, grant or remove access at any provider, run your change process or perform an audit, and a Rightshold record isn't a SOC 2 report or an ISO 27001 certificate. Your auditor decides what evidence is enough. Not legal, audit or compliance advice.
What are the sources?
- AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
- ISO/IEC 27001:2022: Information security management systems
- NIST SP 800-53 Rev. 5: AC-2 (account management) and CM-3 (configuration change control)
- OWASP Logging Cheat Sheet
- Agent access grants on Rightshold
Related
- How to build an agent audit trail tied to grant, spend cap and revocation
- How to export a period-locked signed agent spend pack for an external auditor
- How to pin MCP server versions and review changes before upgrading
- How to give an AI agent a scoped, expiring credential instead of a long-lived API key
Not legal advice. JSON · Markdown · All answers
Get a free API key in one call
No card and no email needed. 100 free credits; the license and policy checks stay free without a key.
curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_... # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
-H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'