You ask an AI coding agent to fix a config bug.
It opens .env.
There it is. Database URL. API keys. Stripe secrets. Maybe a private token you forgot was sitting there from three months ago.
The agent did not mean to leak anything. You did not mean to paste secrets into a model context. But now those values may be in tool traces, shell logs, debugging output, or just sitting in a conversation where they never needed to be.
This is one of those problems that feels small until you notice how often it happens.
So I started building ReadSafe.
The problem is not that agents read files
Agents need to read files. That is the whole point.
If an agent is fixing a missing environment variable, checking whether a JSONL file has the right shape, or updating a config key, it needs structure. It needs to know that DATABASE_URL exists, that SUPPORT_EMAIL looks like an email, that a value is required, or that a file has three event types.
But it usually does not need the actual secret.
That distinction matters. We have got very comfortable with the idea that an agent should just open whatever file helps it complete the task. Most of the time that works. Sometimes it means your local secrets become accidental prompt material.
I do not like that tradeoff.
What I want ReadSafe to do
ReadSafe is a local-first CLI for inspecting and narrowly updating sensitive structured files.
The idea is simple:
sensitive file
-> local parser
-> redaction and classification
-> stable structure manifest
-> agent
The file is still read on your machine by the ReadSafe process. The important part is that raw values are not emitted to the agent, stdout, stderr, generated manifests, or dry-run output by default.
For example, instead of showing an agent this:
DATABASE_URL=postgres://user:password@host:5432/app
STRIPE_SECRET_KEY=sk_live_please_do_not_put_this_in_chat
SUPPORT_EMAIL=support@example.com
ReadSafe should give it structure closer to this:
{
"schemaVersion": "0.1",
"files": [
{
"path": ".env",
"kind": "dotenv",
"variables": [
{
"name": "DATABASE_URL",
"type": "url",
"required": true,
"sensitive": true,
"valueExposed": false
},
{
"name": "STRIPE_SECRET_KEY",
"type": "token",
"required": true,
"sensitive": true,
"valueExposed": false
},
{
"name": "SUPPORT_EMAIL",
"type": "email",
"required": true,
"sensitive": false,
"valueExposed": false
}
]
}
]
}
Now the agent can reason about the file without seeing the values. That is the whole trick.
What exists today
ReadSafe is pre-alpha. Very pre-alpha.
The core dotenv workflow exists in the repository: inspect, env set, env remove, env rename, and env test. There is also experimental JSON and JSONL inference with infer, plus manifest and schema validation with validate.
There are no release artifacts yet. No Homebrew formula. No npm wrapper. No Cargo release. If you want to try it today, you build from source:
git clone https://github.com/bnap00/readsafe.git
cd readsafe
cargo build --release
That is intentional for now. I would rather keep the surface area small while the security model, CLI contract, and MVP boundary are still settling.
What it is not
ReadSafe is not a secret manager.
It does not rotate credentials. It does not encrypt your .env. It does not stop an agent from ignoring instructions and opening the raw file directly. It is not a sandbox, an access-control system, or a magical compliance blanket you can throw over a messy repo.
It is much narrower than that.
It is a tool for reducing accidental value exposure through its own outputs. If ReadSafe is unsure whether something is sensitive, I want it to fail closed. That means less convenience sometimes, but I think that is the right default for this category of tool.
Why build this in public?
Because the annoying part is not writing a parser.
The hard part is deciding the boundary. What should be considered sensitive? How much structure is safe to reveal? Are comments safe? Are value lengths safe? Are hashes safe? What should a dry run show? How should agents be instructed to use the tool without turning every file access into security theatre?
These are not questions I want to answer alone in a corner and then pretend the first release is perfect.
I am building ReadSafe in public because the threat model needs pressure from other people who actually use coding agents every day. If you have seen agents leak secrets into logs, mangle .env files, or over-read private config because the tool interface made it too easy, I want those stories.
Where I want it to go
The first useful version should focus on agent-safe dotenv workflows:
- ›inspect key names, comments, types, required state, and sensitivity
- ›add, update, remove, rename, and test keys without returning existing values
- ›preserve ordering, comments, quoting, and newline style where practical
- ›return redacted dry-run output
- ›use atomic writes
- ›keep the dependency tree small enough to audit without crying
JSON and JSONL inspection are secondary for now. Generic JSON editing is not part of the first safe-update scope. I am trying very hard not to accidentally build a general configuration-management platform because that way lies madness and probably YAML.
If you want to help
The repository is here: github.com/bnap00/readsafe.
If this problem matters to you, you can help by:
- ›starring the repo so you can follow the release
- ›opening issues with real workflows you want ReadSafe to support
- ›reviewing the security model and CLI contract
- ›contributing tests for accidental disclosure cases
- ›trying it from source if you are comfortable with pre-alpha tools that may still change under your feet
Please do not treat it like a finished product yet. Treat it like a workshop with sharp tools on the table.
The more I use AI agents, the more I think the next layer of tooling is not about making them louder or more autonomous. It is about giving them narrower, safer interfaces to the parts of our systems they should not casually inhale.
ReadSafe is one small attempt at that.
Feel free to connect or reach out if you have questions, scary .env stories, or ideas for making this safer before the first release.