Evidence of what your AI coding agents did.
SigDek records the commands, file edits and web requests that Claude Code and Cursor make on your team's machines, in a log that shows any later change, gap or deletion once SigDek has it. Block rules your team writes stop the worst actions before they run. When your auditor or a customer's security review asks what the agents did, you hand them the report.
The recorder is free on your own machine. Teams from $99 a month; no card for the trial. See a sample report (PDF).
Someone will ask what the agents did.
Your security team asks. So does a customer's security review and, increasingly, your auditor: what did the AI coding agents run and change on your team's machines, and what did your rules stop? A policy document says what should happen. SigDek's report shows what did.
SigDek collects the records behind the report without getting in anyone's way, chains them per machine so any change, gap or deletion after they reach SigDek shows up, and writes them up in the language auditors use.
What the report shows
A PDF for the reviewer and a CSV of every record for anyone who wants to check the numbers. Each report states its own limits, and anyone you send it to can confirm it hasn't been changed.
| Section | What it answers | SOC 2 |
|---|---|---|
| Inventory | Each person with the agents they used and how many machines; each machine with its owner, operating system and recorder version; the repositories seen, with record counts; and the MCP servers in use. | CC6.1 |
| Recorder coverage | Whether each connected machine's recorder sent records for each working day, per machine and per person. It measures the recorder, not the person. Two or more working days in a row with no records, outside marked leave, are listed by machine, and members with no machine are listed as not enrolled. | CC7.2 |
| Activity | How much the agents did, per person and per repository: sessions, commands, file edits, web requests and MCP calls. | CC7.2 |
| Sensitive actions | Counts per rule and outcome, with examples: force pushes, secrets files, infrastructure changes, destructive SQL, and what was blocked. Every matching action is in the CSV. | CC6.1, CC7.2, CC8.1 |
| Controls | The rules in force during the period, and every change to them, with who made it and when. | CC6.1, CC8.1 |
| Integrity | Every record's hash recomputed from the copy SigDek stored when it arrived, its stored fields compared with that copy, the chain checked across the period's edges, and any breaks listed. | CC7.2 |
See a sample report for an invented 13-person team over one quarter, or explore the same team live in the demo.
How it works
About two minutes per machine. Developers keep working as before; only your Block rules ever stop an action.
-
Add the recorder
Commit it to a repository so everyone who clones it is covered when they start an agent at its root, or install the Claude Code plugin for one person across every repository.
npx sigdek init
-
Connect each machine
Each developer approves their machine in the browser once. It gets a token that can only upload records and receive your team's rules. Machines no one connects, such as Cursor's cloud agents and CI runners, send nothing to SigDek, and your Block rules don't apply there.
npx sigdek login
-
Generate the report
Records arrive within a minute of each session. Pick a period, generate, and send the PDF.
Controls your auditor can read
A Block rule stops an action before it runs and tells the agent and the developer why, so the agent can take the approved route instead. A Flag rule lets it run and marks it for review. Either way, the attempt is in the record.
That's what turns a rule into evidence: the report shows the rules in force during the period, every change to them with who made it and when, and how often each one flagged or blocked an action, with every match in the CSV. One rule set covers Claude Code and Cursor on every connected machine, and each machine picks up a change on its next upload.
Rules match the command, file path or URL the agent sends. They catch an agent's mistakes; they aren't a sandbox, and a person set on getting around a rule can write a command it doesn't match.
Out of the box nothing is blocked: built-in Flag rules cover force pushes, recursive deletes, secrets files, infrastructure changes, destructive SQL, piping a download into a shell, publishing packages, privileged commands, history rewrites and edits to SigDek's own hook setup. Your team can change them or add its own.
Bash(terraform destroy -target=module.cache)
Blocked by your team's SigDek rule "No terraform destroy" (no-terraform-destroy). Run destroys from the release pipeline.
I can't run destroy from here. I've opened a pull request that removes the module so the pipeline applies it.
Recorded
- Who ran which agent, its model, and its version where the agent reports one (Cursor reports both; Claude Code reports only the model), the session and the repository, and Claude Code's permission mode
- For each action: its kind, the tool's name, the command, file path or URL, and whether it ran, failed, was blocked by a rule or was refused by the agent. Changes to SigDek's own setup are recorded as attempted before they run; any other action someone declines at the agent's permission prompt leaves no record.
- How long it took, and which of your rules it matched
- A SHA-256 hash of the full tool input, so an exact copy of an input can be matched later without SigDek storing it; like the prompt hash, it can confirm a guess. When a secret was stripped from the action, the hash covers the stored, stripped form instead.
Never recorded
- Prompt text: only its length and a SHA-256 hash. The hash can confirm a guessed prompt, so a short or common one like "yes" can be worked out; a long one can't be recovered.
- File contents or command output
- Anything outside agent sessions
Keys, tokens and passwords are stripped from commands, paths and URLs on the machine before anything is written. That's best effort: a secret in an unusual format could get through, so treat commands as sensitive.
The recorder is open source under Apache-2.0, written in Go with no third-party code, and typically adds well under 50 ms per action. How SigDek handles your data
Questions
- Claude Code already has permission rules. Why use SigDek's?
- Claude Code's permission rules are a good guardrail for one tool, and you can keep using them. SigDek adds what an audit needs on top: one rule set for Claude Code and Cursor, managed in one place instead of in each repository or on each machine; a history of every change to the rules, with who made it; and a record of every action a rule flagged or blocked, counted in the report with every match in its CSV. A block list on its own can't show an auditor that it was in force all quarter, or what it caught.
- Does it slow the agents down?
- Not noticeably. Recording typically adds well under 50 ms per action, and uploads happen in a separate background process. Two waits are longer: the first run of a new recorder version on each machine waits a few seconds while the launcher downloads it, and an action that changes SigDek's own setup waits up to a second for its record to upload. If anything inside the recorder fails, the action goes ahead and the error is written to a local log, so it never blocks your work by accident. The only thing that stops an action is a Block rule your team wrote.
- Can a developer turn it off?
- Yes. Anyone in control of a machine can: by removing the hooks or the plugin, turning hooks off in the agent's settings, pointing the launcher at another program with
SIGDEK_BIN, or running the agent in a repository without SigDek's hooks. The report's recorder coverage section catches a machine that goes quiet for two or more working days in a row outside marked leave, and lists it by name. A single working day without records counts as a silent day in its machine table but isn't listed, and looks the same as a day without agent use; switching off for one session or one repository won't show there. Built-in rules flag common agent edits to SigDek's own setup, includingSIGDEK_BIN. Once records reach SigDek, any later change, gap or deletion shows up under Integrity. SigDek makes long gaps visible; it can't stop someone who controls their own machine. - Is this a replacement for our SOC 2 tooling?
- No. It covers one thing those tools don't see: what AI coding agents did on developer machines. Hand the report to your auditor as evidence alongside the rest.
- Which agents does it support?
- Claude Code and Cursor today, on macOS, Linux and Windows. On Windows, Claude Code needs Git Bash, and Cursor needs a repository set up with
npx sigdek init --powershell. - Where is the data kept?
- Stored in the United States: the database with Neon in AWS US West (Oregon), files in Cloudflare R2's western North America location. Requests are handled at whichever Cloudflare location is nearest. Records are deleted after 13 months; reports you generate, including the records in their CSV, are kept while your team exists. Details are on the security page.