Security for AI coding agents: here's how we earn your trust
Security for AI coding agents starts with a tool you can trust more than the agents. Cotterpin runs AI agents against your codebase, so it has to be more trustworthy than they are. This page is our full account of what we protect, how, and what we will never do.
Signed releasesRelease key held in AWS KMS · verify offline
Signed licencesKMS licence key · pinned in every build
SBOM every releaseCycloneDX
GDPRYour code is never our data
security.txtResponsible disclosure
EU Cyber Resilience ActVulnerability reporting process published
SOC 2 Type IIPlanned · not yet audited
ISO/IEC 42001Planned · not yet certified
SLSA build provenancePlanned
Data flow
Exactly what leaves your machine — and what never does.
cotterpin privacy prints the equivalent statement on your machine. Every item that reaches us is asked about first — what, and why — and declining always leaves you a working default.
What leaves your machine
To your model provider, under your own account: what your agent sends it, exactly as it already does. When a Cotterpin task calls a model, the files that task selected, its prompt and its instructions go to the provider you chose — only after you approve it, with .env and credential files removed and recognisable secrets redacted. It goes straight from your machine to your provider, never through us.
To Cotterpin, for licensing — and only after you approve it: licence id, plan, machine fingerprint (a keyed hash computed on your machine, never the hardware id itself) and Cotterpin version.
Email addresses, as a hash only: for every paid customer, our licence service keeps only a SHA-256 hash of the email address Paddle gives us (and, if you claim a purchase, of the address you type, to which we send a one-time code).
From Cotterpin, for updates: a signed release download — nothing uploaded beyond the licensing items above.
Telemetry: off. This release contains no telemetry sender; it could only ever be switched on by you.
Bug reports: sent by you after you read them; from the next release, also automatically, only for a repository and kind you turn that on for, confirmed by your operating system, and never where your organisation forbids it. What a report holds.
There is no Team or Enterprise dashboard in this release, so nothing is sent to one. If we ever build one, it will be opt-in and this statement will change first.
What Cotterpin never receives
Your source code, diffs or file contents
Your prompts, agent transcripts or test output
File paths or repository names
Your provider API keys or logins
Secrets found by the secret scanner
Session reports and receipts — they stay in your repository
The results of machine measurements (cores, memory, disk, load) — used only on your machine
Your model provider receives what your agent sends it, as it would without Cotterpin. Its own terms govern that.
Payments are processed by Paddle, the merchant of record, in Paddle's own checkout in your browser. Paddle sells the licence to you and handles sales tax, VAT, invoices and refunds. Cotterpin never sees your card details — not from the website, and not from cotterpin subscribe.
Control & reversibility
Nothing happens to your code that you can't see, stop or undo.
⎇
Isolated when it should be
Checks run in place and read-only. New work — a task, an audit — gets its own branch and worktree, so your checkout is never touched.
◉
You decide what lands
Fixes wait for your approval. Tasks end in a pull request, not a merge. Any run can be paused or stopped at any moment.
↺
Every step reversible
Every change is a commit; every task, a branch you can delete. Updates roll back with one command.
$ cotterpin update --rollback
Integrity
The rules can't be quietly bent — by agents or by anyone.
☝
Approvals an agent can't fake
A destructive action waits for cotterpin approve <id> at your own terminal. A root-owned signer shows you the exact action — control characters made visible, so nothing can hide in it — and signs it with an ECDSA P-256 key only root can read, after the operating system has checked it's you: your account password, or Touch ID (your fingerprint) on a Mac where Touch ID is enabled for sudo, asked afresh every time.
$ cotterpin approvals setup⚑
Every action has a risk tier
Each agent tool call is read, low-risk write, sensitive write or destructive, and the tier alone decides what happens. A sensitive write is confirmed in your agent's prompt; a destructive one — git reset --hard, --no-verify, removing Cotterpin — needs a signed approval.
#
An audit log agents can't rewrite
Every decision — allowed, asked, refused, approved — is appended to the action audit log in your repository's git folder. An agent's attempt to edit, move or delete it, the approvals store or the records cotterpin report reads is itself refused.
⛨
Agents can't switch off the gates
Lowering a protective rule needs a person's signed approval bound to that rule, checked on every hook call — so a settings file written by any other route lowers nothing. Uninstalling Cotterpin or its adapters needs one too.
⚷
Credentials never reach the agent
Reading .env, cloud credential files, Cotterpin's own licence or the environment into an agent's context is refused — judged by effect, whatever program or tool tries it — and everything Cotterpin prints or keeps passes through one redactor first.
@
Every override has a name
People can turn a rule down or mark a refusal as a false positive. Never anonymously: each takes a person's signed approval and a reason, recorded with the change.
◎
Memory can't be promoted by an agent
A fact moves from your own memory to the team's repository only with a person's signed approval — never a flag, a file or a setting an agent could produce.
⚿
We never hold your keys
Cotterpin uses the logins your agent CLIs already have. We store no provider credentials anywhere.
⌂
No vendor cloud in the path
No agent cloud, no build farm. Builds, tests and attacks run on your machine or your own infrastructure.
Illustration: an agent tries a destructive git reset; Cotterpin refuses it and records an approval request; the developer runs cotterpin approve in their own terminal, sees the exact action, confirms with Touch ID or their password, and the root-owned signer approves that action once.
~/payments-service
Illustration · example output
Two installs
A guardrail on your laptop. A boundary when an administrator installs it.
Cotterpin's threat model is published with the product. It is honest about what each install defends against.
Developer mode
pipx install cotterpin in your own account. The adversary is an AI agent acting through its tools — the shell, file edits, reads and searches — every call of which passes through Cotterpin's hook. Every route through those tools to approving itself, forging an approval, weakening a rule, dropping to Watch, removing the guard, editing Cotterpin's own code, rewriting the audit log or reading a credential is refused.
Developer mode is a guardrail for agents, not a sandbox. A process that never goes through the agent's tools — malware already running as you, your own shell — can do anything your user can. What stays out of its reach is what is root-owned: the approval key and signer, so it still can't make an approval.
Hardened mode
An administrator installs Cotterpin root-owned, with an approved-release lock and a root-owned security policy. The adversary is everything above, plus any process that can write your files. The approval trust, the signer and the policy are root-owned; on a hardened machine no user file — licence, consent, or a hooks.json — can lower enforcement or drop it to Watch.
Still being built: registering the agent hook through each tool's administrator-managed settings, and binding approvals to a hardware key or your SSO. Until then hardened mode protects the licence, trust, signer, policy and settings, but not the hook's own registration.
Identity & access
Your password — or Touch ID, where it is enabled for sudo — for every approval. Your identity provider on Team and up.
Sign-in and access features by plan
Feature
Watch
Pro
Team
Enterprise
Approvals confirmed with your account password, or Touch ID (fingerprint) where it is enabled for sudo, signed by a root-owned key
✓
✓
✓
✓
Approvals bound to a hardware key (YubiKey) or your SSO — hardened mode, being built
–
Being built
Being built
Being built
AWS IAM sign-in with MFA — hardened mode, being built
–
Being built
Being built
Being built
OIDC single sign-on — Okta, Entra ID, Google Workspace, GitHub
–
–
✓
✓
Admin-owned gate policy
–
–
✓
✓
SAML single sign-on & SCIM provisioning
–
–
–
✓
Confined agent OS identity
–
–
–
✓
SIEM export · air-gapped updates · MDM
–
–
–
✓
Approvals with your password — or Touch ID, on a Mac where Touch ID is enabled for sudo — work on every plan once you run cotterpin approvals setup (it says what and why first; declining installs nothing, and destructive agent actions simply stay refused). To turn Touch ID on for sudo on macOS 14 or later, copy /etc/pam.d/sudo_local.template to /etc/pam.d/sudo_local and remove the # before its auth sufficient pam_tid.so line; without it, macOS asks for your password. Team single sign-on — cotterpin login through your Team's one identity provider (Okta, Entra ID or Google Workspace over OpenID Connect, or GitHub with an organization) — is in the 0.3.0 release candidate; the sign-in data it handles is described in our Privacy Policy. Hardware-key or SSO-bound approvals and AWS IAM sign-in with MFA belong to hardened mode and are not yet available on any plan.
Supply chain
Don't trust our releases. Verify them.
Signed releases — every release manifest is signed with a release key held in AWS KMS, in Cotterpin's own AWS account; the private key never exists on a laptop, and signing needs MFA.
Keys pinned in the build — each build carries the public halves of the release and licence keys. A release or licence signed by any other key does not verify.
Signed licences — your licence is signed by Cotterpin's KMS licence key and checked on your machine; a clock wound back can't extend it.
Every file pinned — the signed manifest lists each published file by SHA-256.
SBOM in CycloneDX with every release, so your scanners see every dependency.
Verified on every update — cotterpin update --fetch refuses an unsigned or altered release. Check a downloaded release yourself, offline, with cotterpin verify --release: nothing is sent.
Planned: SLSA build provenance and Sigstore attestations for the public package.
Team and Enterprise customers can request our SBOMs, this page's data-flow statement in writing, our Data Processing Addendum and sub-processor list, and answers to your security questionnaire (CAIQ, SIG Lite). A SOC 2 Type II audit and an independent penetration test are planned; we have not completed either yet.
Registered with the UK Information Commissioner's Office (registration ZC266082), with a named Data Protection Officer — check the public register.
Email security@cotterpin.io. Please don't report a vulnerability in a public issue or through support. Include what you found, how to reproduce it, the Cotterpin version (cotterpin --version) and the impact you expect, and give us a reasonable chance to fix the issue before disclosing it publicly.
We will not pursue legal action against good-faith research that respects our users' privacy and data, avoids degrading the service, and gives us a reasonable chance to fix the issue first. We publish an advisory for every fixed vulnerability and credit reporters who want to be credited. Full terms: our Security and Responsible Disclosure Policy.
https://cotterpin.io/.well-known/security.txt
Our response times for vulnerability reports
Stage
Target
Acknowledge your report
2 business days
Initial assessment
5 business days
Fix — critical
7 days
Fix — high
30 days
Notify the authorities of an actively exploited vulnerability (EU CRA)
within 24 hours
Questions people ask
Does Cotterpin send my code anywhere?
No. Your source, diffs and prompts never go to Cotterpin. Only your own model provider sees your code, under your own account.
Who decides on a destructive action by an AI agent?
Only you. A destructive action waits for you to allow it, confirmed by your operating system, so the agent cannot allow it for itself.
Can an AI agent read my credentials through Cotterpin?
No. Cotterpin refuses an agent reading .env files, cloud credentials or the environment into its context, and everything it prints passes through one redactor.