private alpha · macOS only

troopr.

Keep AI coding agents out of your secrets. Kernel-level blocks for .env, SSH keys, AWS creds — without boxing the whole machine.

install
troopr mascot

the problem

You hand an AI coding agent a terminal. It reads your project - and also ~/.aws/credentials, your shell history, the .env sitting next to your code. Anything the file system will hand it ends up in a prompt to a third-party model. There is no confirmation step.

troopr wraps the agent in macOS's built-in sandbox-exec. Reads of denied paths return Operation not permitted at the kernel level. The agent sees the same error your shell sees.

how it works

01

Write a config or use defaults

troopr starts from (allow default) and blocks only the paths you deny. A built-in universal denylist covers the usual suspects; add more in troopr.yaml.

# troopr.yaml
version: 1
deny:
  - "**/.env*"
  - "~/.ssh/**"
  - "config/secrets/**"
allow:
  - "**/.env.example"
02

Run your agent through troopr

troopr compiles the config into an Apple Sandbox Profile (.sb), launches your agent with sandbox-exec, and inherits stdio so the agent works exactly as before.

$ troopr run claude
$ troopr run agent --model auto
03

Watch denials in real time

When the agent tries to read something off-limits, the kernel denies it and troopr appends a JSON line to ~/.troopr/log.jsonl.

$ tail -f ~/.troopr/log.jsonl
{"timestamp":"2026-05-13T17:30:26Z","agent":"claude","path":"/Users/g/.aws/credentials","action":"deny"}

universal denylist

Always blocked on every troopr run. Add more in your troopr.yaml or ~/.troopr/config.yaml.

**/.env**/.env.***/*.pem**/id_rsa***/id_ed25519*~/.ssh/**~/.aws/credentials~/.aws/config~/.gnupg/**~/.kube/config~/.docker/config.json~/.netrc**/secrets/****/*.kdbx**/*.kdb

install

Requires Go 1.22+ and macOS 13 or newer. The binary is ~5MB with no runtime dependencies.

# clone (private alpha - request access)
$ git clone git@github.com:paanSinghCoder/troopr.git
$ cd troopr
$ go build -o /usr/local/bin/troopr ./cmd/troopr

# verify
$ troopr version
0.1.0

Try it on a sandbox directory before pointing it at a real project:

$ mkdir /tmp/demo && cd /tmp/demo
$ echo "SECRET=abc" > .env && echo "ok" > public.txt
$ troopr run /bin/cat public.txt
ok
$ troopr run /bin/cat .env
cat: .env: Operation not permitted

faq

Why not Docker or a VM?
Too much friction. troopr is a single exec wrapper - no daemon, no image, no port forwarding, no volume mounts. The agent reads and writes your real filesystem inside CWD as it always did, just with the secret-y paths walled off.
Why macOS only?
sandbox-exec is Apple's. A Linux build would need bubblewrap, firejail, or landlock - different code path. Not on the roadmap until the macOS version is stable.
Is sandbox-exec really deprecated?
Apple has marked it deprecated for years but still ships it on macOS 13–15. troopr tracks the deprecation and would migrate to a supported alternative when forced to. For now it's the most practical kernel-level isolation on the platform.
Path-based - not content scanning?
Right. The kernel only enforces paths. Content scanning would need a userspace proxy in front of every read, which adds latency and new failure modes. If your secrets live at an unusual path, add it to deny.
Is this a hard security boundary?
No. It's defense-in-depth against honest mistakes - the agent reaching for ~/.aws/credentials because the LLM suggested it. An adversarial binary actively trying to escape should be assumed to succeed; harden elsewhere.

Request access.

troopr is in private alpha. Leave your email and a quick line on what you'd use it for - I'll send an invite within a day or two.