Security

For IT and security reviewers. Last checked against the code: 31 October 2026.

Lockpin is a spend cap for AI agents. It is a program that runs on your own machines, between your agents and the AI provider. Before a call goes out, Lockpin prices it at its worst case and refuses it if that does not fit the budget. This page says how it is built, what it stores and sends, and what is not done yet.

Most of this page describes code that is not released yet. The latest release, v0.1.6 (21 October 2026), is what the installers give you today. It predates the hash-chained ledger, the team node and spend capabilities, the sealed key store, the signed policy, corporate proxy and private CA support, the audit export and lockpin ledger export, Azure OpenAI, Bedrock and Vertex AI, keys made in the dashboard, joining a team, phone pairing, questions about held calls in chat, Teams and ntfy alerts, lockpin upgrade and lockpin import. They ship in the next release. See What is not done yet.

How it works

• Lockpin is a local proxy. Your agent sends its calls to Lockpin on the same machine (127.0.0.1:8787 by default), and Lockpin sends them on to the provider you chose. Calls do not pass through our servers.
• The decision to allow or refuse a call is made on that machine, from its own ledger file. It never waits on our servers, and it works with the network to us cut off.
• There is no telemetry and no automatic update check. Lockpin contacts our servers only for features you turn on: reporting to the dashboard, joining a team, asking about held calls on your phone or in chat, and lockpin upgrade. Each is listed under Network and install.
• The hosted dashboard is optional. If you turn reporting on, a background reporter uploads spend totals once a minute. It runs off the call path: a slow or failed upload changes no decision.
• A team can run one Lockpin as a shared node that holds the provider keys (see Provider keys). The node also decides from its own ledger.

What leaves a machine

With reporting off (the default), no spend data that we can read goes to us. (A machine that joins a team sends its spend encrypted; see below.) Lockpin talks to your provider, and to the other hosts listed under Network and install only for the features you turn on.

With reporting on, it uploads a closed list of fields. An admin picks the detail level for the whole organization. This is a summary; the authority is the allowlist file in the code, which tests check every upload against.

What each reporting level uploads

Level	What is uploaded
totals	Hourly totals per key name, provider and model: request and token counts, costs, cache and timing sums, and a pseudonymous user id where a key counts spend per user. Alerts as fields (kind, limit, amount spent), never their message text. Key names and their dollar limits. Whether a team key or a spend capability paid. A random machine id and the Lockpin version.
tags (default)	Adds tag names and values, and a pseudonymous task id (an HMAC of the task name with your organization's salt). For spend capabilities, adds the issuer name an admin typed, the first 16 characters of each budget id and its parent's, each budget's dollar limit, expiry and first use on this machine, and for each issuer the time of its last heartbeat and whether it, or a budget this machine charged, is revoked.
tasks	Adds the real task names.

• Never uploaded, at any level: prompts, responses, tool calls and results, file contents, file names or paths, provider API keys, Lockpin key secrets or their hashes, spend capability tokens, webhook or Slack URLs, alert message text, operating-system user names, host names or environment variables.
• A machine's own -report-detail flag can only lower the level. The server rejects a batch with fields above the organization's level.
• The task and user ids are pseudonyms, not anonymous: we hold the salt they are made with.
• You can check it. lockpin report preview prints the exact next upload, and a copy of every upload is kept next to the ledger.
• Uploads go over HTTPS to ingest.lockpin.dev, each signed with an HMAC of the workspace credential.
• A machine that joins a team (lockpin enroll) also sends a status report once a minute, even with reporting off. It is encrypted on the machine to a key only the team's admins' browsers hold, so our server stores it but cannot read it, unless the dashboard's own page code were altered to send the decrypted report elsewhere.
• A signed policy can turn off reporting and team status for a whole machine (see Signed policy).

Provider keys

On a developer's own machine, the agent sends its API key to Lockpin, which passes it to the provider with the call. Lockpin does not write it to disk, the ledger or its logs.

With a team node and spend capabilities, the node holds the real provider keys and agents never see them. An agent holds a spend capability instead: a token starting lpc_ that names a task, a dollar limit, the models and tools allowed, and an expiry (24 hours by default). An agent can hand a smaller token to a sub-agent without the node, but can never widen it. The node refuses a call whose worst case does not fit the token or any budget above it.

The node keeps the keys in a protected store. How it is protected depends on the system:

How the node's key store is protected

System	Stored by hand (lockpin keys seal)	Node set up by lockpin node install
Windows	Encrypted with DPAPI for this machine	Encrypted with DPAPI for this machine; the file readable only by the node's account, SYSTEM and Administrators
macOS	Encrypted in the Keychain of the account that ran it	Not encrypted: a file readable only by the node's account and root (a service account has no Keychain)
Linux	Encrypted with systemd-creds, where it is installed and works	Not encrypted: a file readable only by the node's account and root

Where the system has no store, the keys go in an unencrypted file only its owner can read, and the command says so. For Amazon Bedrock and Google Vertex AI, the node signs each call or makes short-lived access tokens itself: the AWS secret access key and the Google service-account key never leave it.

Limits.

• Where the store is a plain file (a node on macOS or Linux, or a system with no store), the keys are in clear on disk, protected only by file permissions. Backups and disk images of that machine hold them in clear.
• On Windows, DPAPI encrypts for the machine, not for one account. Any process on that machine that can read the file can decrypt it, so the file's access list is the real protection. A copy is useless on another machine.
• While the node runs, the keys are in its memory. There is no hardware key store that keeps them out of reach of the node's own account.
• Anyone with administrator or root rights on the node can read the keys.
• On Windows the node runs as LocalService, a built-in account other Windows services share. Any service running as LocalService can read the node's keys.
• A node refuses to start as an account a person signs in with, unless you allow it for a one-person setup. Then capabilities are bookkeeping, not a boundary, and Lockpin says so.
• A capability is a bearer token: whoever holds it can spend what it allows until it expires or is revoked. Revoking applies within a second on the issuing node, within about a minute on nodes that follow it, and within the token's freshness window (10 minutes by default) anywhere.
• The revocation list beside the store is protected only by file permissions. Deleting it un-revokes every token at the next heartbeat.
• After a node restarts, a recent heartbeat can be replayed, so a token revoked shortly before the restart may work again for up to its freshness window.

The ledger and audit export

• Every charged call, every call refused at the cap, every budget change and alert, and every start and stop of Lockpin is appended to a ledger file on the machine.
• Every line carries the SHA-256 hash of the line before it. The hash has no key. It catches accidental damage and casual edits, but anyone who can write the file can recompute the chain, and lines cut from the end leave no trace.
• A team node also adds a checkpoint every 1,000 lines and when it stops, signed with its Ed25519 node key. Lines up to the last checkpoint cannot then be edited without breaking a signature. Lines after it are covered only by the unkeyed chain. Only a team node writes checkpoints.
• lockpin ledger verify checks the chain, and with -key and the node's public key, the checkpoint signatures.
• If Lockpin crashes or is killed, the cap can only get stricter: nothing it reported as written is lost. A power cut is different: it can lose about the last second of lines, and with them the spend of a call made in that second.
• lockpin ledger export writes the ledger as JSON Lines or CSV. CSV cells that a spreadsheet would run as formulas are escaped.
• For a SIEM, -audit-export DIR (or the signed policy) keeps writing the ledger to a folder your log agent collects. Each record carries its hash and the previous one's, so a gap shows. Lockpin sends the export nowhere itself.
• Exports hold no prompt, response, key or alert message text. A full or unwritable export folder stops the export, never the cap.

Signed policy for a fleet

• IT can push one policy file to every machine with the tool it already uses (Intune, Jamf, Ansible). Lockpin reads it at start and within five seconds of a change.
• The file is signed with an Ed25519 key that IT holds. Each machine pins IT's public key. A file that is unsigned, signed by another key, edited after signing or damaged is refused and logged, and the last good policy stays in force.
• It can set task budgets, a hard ceiling per task, dollar limits per machine, key, user and tag, allowed and denied providers and models, the reporting level (or no reporting), a private root CA and the audit export folder.
• It is a floor for every Lockpin on the machine: flags, local settings, the dashboard and an agent's headers can only make it stricter.
• A team node can be set to refuse every call while no signed policy is in force.
• The file has no field for a key, a token or a URL, and nothing in it is uploaded.
• What it does not stop. It binds Lockpin, not the user. A user with their own provider key can call the provider another way, or run their own copy of Lockpin, and can delete the per-user policy file in their own folder. The policy is a hard wall only where the provider keys sit in a team node the user cannot read. It also does not protect against local administrators, who can replace the pinned key.

The hosted dashboard

• Optional. The cap works the same without it.
• Sign-in. With a code sent by email, a password, or Google or GitHub. An organization can turn on company sign-in with Microsoft Entra ID or Google Workspace, after proving its email domains with a DNS record, and can then require it for admins and viewers. Lockpin asks the identity provider only for name, email address and a stable ID. A company sign-in lasts at most 12 hours.
• Owners never act through company sign-in. A company sign-in acts as an admin at most, and owner actions need the owner's own Lockpin sign-in. So owner powers never come through company sign-in, and a problem at your identity provider cannot lock owners out. Whoever controls an owner's mailbox, or the Google or GitHub account they sign in with, can still sign in as that owner. To remove an owner, remove them on the Members page: disabling them at your identity provider does not.
• Audit log. Changes to members, roles, keys, sign-in, billing and export tokens are logged. Owners and admins can download the log as CSV or JSON Lines.
• Read-only SIEM tokens. Owners and admins can make a token that reads the audit log, spend, or both. It is shown once and only its SHA-256 hash is kept. It cannot change anything and is not a sign-in. Revoking it stops it at once.
• Honest numbers. Every number says when it was read ("as of"). Each machine enforces its own cap, so a budget or total across several machines is soft: the machines together can pass it, and the dashboard labels it soft.
• A dashboard budget can only lower a machine's own limit, never raise it. Keys made in the dashboard are accepted only by a machine started with -managed-keys, and each is still held to that machine's own monthly ceiling ($100 unless changed).
• Data and retention. Hourly spend is kept 35 days and daily spend 90 days or 13 months, depending on the plan. Who processes it and for how long is in the privacy policy.

Network and install

Every host the program calls, and when

Host	When
Your AI provider (the base URL your agent uses)	Every call. For Meta, OpenAI and Anthropic, also their token-count endpoint when a call is near its budget.
Your Azure OpenAI resource; Amazon Bedrock; Google Vertex AI and oauth2.googleapis.com	Only if your agents use them.
Slack, Microsoft Teams, ntfy or a webhook URL	Only if you set one, for alerts, and with -ask-remote for questions about held calls.
app.lockpin.dev and your phone's push service	Only with -ask-remote or a paired phone (lockpin phone pair): Lockpin polls our relay for answers, which carries only question ids and signed answers, and sends questions, alerts and the weekly digest to a paired phone, encrypted so only the phone can read them.
ingest.lockpin.dev	With reporting on, once a minute. After lockpin enroll, once a minute for the encrypted status report and the team's policy, even with reporting off.
lockpin.dev and GitHub	Only when you run lockpin upgrade, to fetch the installer and the release.
api.openai.com, api.anthropic.com, api.cursor.com	Only when you run lockpin import, with admin keys you give it, to read what those services billed.
A price-catalog URL	Only if you set one.
Your own capability issuer node	Only on a team with several nodes, every 60 seconds.

• Corporate proxy. Every outbound request honours HTTPS_PROXY, HTTP_PROXY and NO_PROXY. Lockpin's own connections to localhost are always direct.
• Private root CA. -ca-file, LOCKPIN_CA_FILE or the signed policy adds your roots to the system's. No setting turns certificate checks off. lockpin doctor shows the settings in effect, with any proxy password hidden.
• Install. The one-line installers install for one user without admin rights, and refuse a download that does not match the release's SHA256SUMS. For fleets, a per-machine MSI (for Intune or msiexec), .deb and .rpm packages, a macOS pkg, and winget, Scoop and Homebrew manifests are built but not yet published.

How the code is built and checked

• The proxy uses only Go's standard library, and CI fails if it gains a dependency. The hosted service has one direct dependency: pgx, the Postgres driver.
• CI is set up to run, on every change, the tests with the race detector, go vet, and govulncheck, which flags known vulnerabilities only where the code reaches them; govulncheck also runs weekly. The proxy's parsers of untrusted input (request bodies, event streams, price catalogs, keys files, hook payloads, transcripts) have fuzz targets that CI runs too.
• The repository's GitHub Actions minutes are used up until November 2026. Until then, the same jobs run on our own machine with scripts/ci-local.sh while each change is reviewed, and the weekly govulncheck run does not happen.
• Dependabot opens weekly update requests for Go modules, npm packages, GitHub Actions and Docker images.
• The release process builds each version twice on two machines and publishes only if the results match byte for byte. Each archive is then signed with Sigstore (keyless), described by a signed CycloneDX SBOM, and covered by SLSA build provenance.
• Lockpin is licensed under Apache 2.0.

Certifications and what is not done yet

• Most of this page is not released. The latest release is v0.1.6 (21 October 2026). The features listed at the top of this page ship in the next release.
• No certifications. Lockpin holds no SOC 2 report, ISO 27001 certificate or similar, and has had no independent audit or third-party penetration test. This page will say so when that changes.
• No signed release yet. The signing, SBOM and reproducible-build steps were added after v0.1.6, which carries SHA256SUMS only. The next release is the first to be signed.
• No code signing. The programs and packages are not yet Authenticode-signed or notarized by Apple, so Windows SmartScreen and macOS may warn.
• Packages built, not yet published. The MSI, .deb, .rpm and package-manager manifests are built and checked on our build machine but not published. The macOS pkg has not yet been built on a Mac.
• Dashboard features not yet live. Company sign-in, the audit-log and spend downloads, and the SIEM tokens are built but not yet deployed to app.lockpin.dev.
• Source not public yet. The repository is private for now, so you cannot yet rebuild a release yourself, and CodeQL scanning starts when it is public.
• Dashboard sign-in. No SAML, no Okta, OneLogin or Ping, no SCIM, and no instant sign-out when an account is disabled at your identity provider.
• Audit export. No Windows Event Log or syslog output. The export files are not signed themselves; the hash chain and checkpoint signatures inside them are the proof. The Splunk, Sentinel, Elastic and Datadog examples in our docs have not been tested against those products.

Reporting a vulnerability

Email security@lockpin.dev. Please don't describe the problem in a public issue. You'll hear back within 3 business days. Once the problem is confirmed you'll get a plan for the fix. Once the fix is released, we email you, and describe it in a GitHub security advisory once the repository is public, crediting you if you'd like. Until then the repository and its release notes are private, so a fix that customers need to act on is also announced on this page.

Please include the version (lockpin version), how to reproduce it, and what an attacker gains. We especially want to hear about a way to spend past a cap, to read or use a key you were not given, to reach the local meter from another machine or a web page, or to read another account's data on the dashboard. Only the latest release gets fixes.

The same contact is in /.well-known/security.txt (RFC 9116), where security tools look for it.