Security

What's collected

For each agent action: who ran it, on which machine, with which agent and model, in which repository, Claude Code's permission mode, the command, file path or URL, the result, how long it took and which rule matched. Never prompt text (only its length and a SHA-256 hash, which can confirm a guessed prompt, so a short or common one can be worked out), file contents or command output. The full tool input is kept only as a SHA-256 hash, which can likewise confirm a guess; when a secret was stripped from the action, the hash covers the stored, stripped form instead. Secrets are stripped from commands, paths and URLs on the developer's machine, before the record is written; the patterns are tested in the open-source recorder. This is best effort, and a secret in an unusual format could get through, so treat commands as sensitive.

For people who sign in: name, email address, the sign-in provider's account ID, and the IP address and browser user agent stored with each sign-in session. To limit requests, SigDek's database also counts them by client IP address, and sign-in link requests by email address; a daily job deletes each count once a day has passed since its last use. Card numbers go to Stripe and never reach SigDek. The Billing page shows the card's brand and last four digits and the invoice amounts, which SigDek's server reads from Stripe when the page asks and doesn't store. The dashboard loads no scripts from other sites, except on its checkout page, which loads Stripe's script from js.stripe.com to show Stripe's payment form inside Stripe's frame.

Where it goes

• The recorder writes records to ~/.sigdek on the machine, then uploads them over TLS to ingest.sigdek.com, a Cloudflare Worker.
• Records are stored in a Postgres database run by Neon in AWS's US West (Oregon) region. Each upload that holds at least one valid record is also kept exactly as received in Cloudflare R2 (western North America), so SigDek can re-check any stored record against its original bytes on request.
• Reports are generated inside Cloudflare and stored in R2. Downloads require a signed-in team member. Requests are handled at whichever Cloudflare location is nearest.
• Data is encrypted in transit with TLS and at rest by Neon and Cloudflare.

Tamper evidence

Each record includes the SHA-256 hash of the record before it on the same machine, computed over a canonical form of the record (RFC 8785). Records are tamper-evident once SigDek has received them. The server checks every upload against the chain and never rejects a batch for a break: it records the break, so a gap, an edited record or a fork shows up in the next report's Integrity section instead of disappearing. Each report recomputes every record's hash from the copy stored when it arrived, compares the stored fields with that copy, and checks the chain across the period's edges, and anyone can check a report file's SHA-256 against SigDek's record of it.

What this does and doesn't cover:

• On the developer's machine. The local chain has no secret key, so someone with access to the machine could rewrite its log consistently before upload. Uploads normally happen within minutes of an action; from then on SigDek's copy is the one that counts.
• After upload. A changed, missing or extra record, or a second history for the same machine, shows up in the next report. Each report also checks the chain heads saved by earlier reports, so a record removed or changed after an earlier report shows up even at the end of a chain.
• Inside SigDek. These checks compare against SigDek's own copy. Someone with write access to SigDek's database and storage (our operators, or an attacker who got that access) could in principle rewrite records and SigDek's saved chain heads consistently, and a later report alone wouldn't show it. A report you keep would: it lists each machine's last record in the period with that record's hash, which depends on every record before it, so generating a report for the same period later and comparing the two tables shows whether any of those records changed. Keep the reports you hand to auditors. The verify page checks SigDek's own record of each file, so it shows that SigDek generated a file, with the same reliance on SigDek's database.

Access

• People sign in with GitHub, Google, or a one-time link emailed to them, which works once, for 15 minutes, and is stored only as a hash. Sessions end after 30 days without use.
• A connected machine holds a token that can only upload records and receive the team's rules. It can't read data or act as a person. Tokens are stored only as SHA-256 hashes and can be revoked from the dashboard, or with sigdek logout when the machine can reach SigDek.
• Team data is visible only to members of that team. Owners and admins manage rules, invitations, reports and billing.
• Only Tekton Software's operators can reach production systems, through provider accounts protected by two-factor sign-in. Deploys run from GitHub Actions, which holds the deploy credentials and runs only when an operator starts it. We look at a team's data only to answer that team's support request or to keep the service running.

The recorder

The code on developer machines is open source under Apache-2.0, so you can read exactly what it records. It's written in Go using only the standard library, with no third-party code. Launchers download the version pinned in .sigdek/recorder.lock (or in the plugin's own lock file) and check its SHA-256 before keeping it. It never stops an action by accident: any internal error lets the action go ahead. The only actions it blocks are ones matching a Block rule your team wrote.

It records only where its hooks run. Claude Code and Cursor read a repository's hooks only where a session starts, so a session started in a subfolder of a repository set up with sigdek init is recorded only if that person has the plugin. And a machine sends records and receives your team's rules only after someone signs it in with sigdek login: agents on machines no one has signed in, such as Cursor's cloud agents, CI runners and hosted sandboxes, record only on that machine, send nothing to SigDek and get only the built-in rules, which block nothing.

Retention and deletion

Records are kept for 13 months, then deleted automatically, along with the original uploads and any notes of breaks in a machine's chain. Generated reports are kept while your team exists, so their copies outlast the 13 months: a report's CSV holds every record in its period, its PDF and HTML hold names, counts and example commands, and a findings CSV lists any integrity problems. Neon also keeps a point-in-time history of the database for recovery; deleted data leaves that history within 30 days. To delete your team and all its data, write to support@sigdek.com from an owner's address; deletion completes within 30 days.

Service providers

What we haven't done yet

SigDek hasn't completed its own SOC 2 audit or an independent penetration test. If your review needs either, tell us at hello@sigdek.com; we'll answer security questionnaires directly.

Reporting a vulnerability

Email security@sigdek.com. We'll acknowledge within two business days and keep you updated until it's fixed. Please give us a reasonable time to fix an issue before disclosing it, and don't access other teams' data or degrade the service while testing. We won't pursue good-faith research that follows these terms.