Every call to /v1/check, /v1/check/page, /v1/check/screen and MCP check_action is logged in the workspace’s check log, allowed or not.

​
What a row holds

The log records the rule’s text at check time, so later edits to the map don’t rewrite history. Each row also carries the rule version’s hash and confirm record, the agent and the person it acted for, near-miss fields and, once the guard reports it, whether the action ran: see Evidence, which also covers the hash chain over the log and its exports.

​
Read it

In the web app: Checks. Filter by map, result and actor. Or the API (a capture credential, not an agent key: agents can’t read the log):
The CSV has up to 10,000 rows, newest first. Cells that start with =, +, - or @ are escaped so a spreadsheet doesn’t run them.

​
As audit evidence

The log shows that a control ran on every action, what it decided and why. With the walkthrough workpaper (how the control is performed, in the owner’s words) it covers inquiry, observation and operation of the control. It doesn’t replace the auditor’s inspection and re-performance.

​
Personal data in the record

The record is stored PII-redacted by default: names, emails, phones, IBANs, cards and IDs become placeholders such as [EMAIL] (how). Amounts, dates, codes and record ids stay, so the row still shows why a rule fired. A workspace that must keep records exactly as sent (an auditor needs the original values) can be switched to raw storage on the server: CLAROS_CHECK_LOG_RAW=<workspace id>,<workspace id> (or * for all). Model calls are redacted either way.
The log covers agents today. People are checked through Claros for Mac, logged as their own checks (source mac).