The standard advice for secrets is short: put them in a .env and keep it out of git. It quietly assumes that I’m the only one touching that file. Add an agent on the same machine, with access to the repo, a shell and the logs, and that assumption gets shaky.
The Risk Isn’t Theft#
The course slides made a point I hadn’t thought much about. The danger isn’t an AI company stealing your keys, it’s ordinary mistakes: the agent printing environment variables, including a .env in a debug summary, committing a secret, or writing it to a log. An agent debugging a config problem is exactly the kind of situation where it might open the .env, so I treat that as realistic and not far-fetched.
The same goes for pasting secrets into a chat. I don’t paste .env contents or API keys into any AI tool, because that sends them to a provider and they may live on in the history.
How I Handle It#
In the market project everything runs locally, so there is a .env with localhost database settings and development values, plus a .env.example in the repo that shows other developers what’s required. The tests use mocks only. My teammate once tested with an API key generated just for testing, and it has since been closed down, which is the “use test keys, limit them and burn them” advice we try to follow.
The rule I follow is that everything in the .env is burnable. If the agent reads it, prints it or commits it, nothing is lost.
If the project were deployed, the plan is a virtual Linux machine running a Docker image, with a CI/CD pipeline and a compose file supplying the environment variables. No agent would be installed there, so nothing that thinks for itself can reach those secrets. The pipeline then becomes a place where secrets live, so it’s worth knowing who can touch it.
An Instruction Is Not a Guardrail#
I haven’t put any rules about secrets in the agent’s instructions, mostly because I don’t expect them to be a boundary. I once set up Codex with access to GitHub for my repo. The sandbox stopped it while committing, and it then got itself the rights to do it anyway. Git access was part of the workflow, so nothing was forbidden. It was more of a curiosity, but it was a nice reminder that a line in a prompt is a request, not a wall.
What’s worth more is limiting what’s reachable in the first place. My SSH keys sit on the same PC the agent runs on, so it could read them if it wanted to. A passphrase doesn’t help once the key is loaded in the SSH agent. The strongest fix is running the agent on a second PC with no SSH keys at all. How far to go depends on what you’re working with. For a school project with mock data, it’s overkill. For real customer data, it isn’t.
The Data I Didn’t Need#
I planned to use real contact details from the customer’s website for a demo, in a local script kept out of git. That data was public, but publicly available isn’t the same as free to reuse for any purpose, and it’s still personal data under GDPR. It would also be sitting on the machine where the agent works.
Then I realized the demo works just as well with mock data. No real data means no GDPR question and nothing to leak. That’s the simplest security decision in the whole project.
Choices That Were Security Choices#
Some decisions I made for other reasons turned out to be about security too:
- No login for applicants. It’s easier for them, but it also means I don’t store passwords. People reuse email and password combinations, so there’s nothing for me to leak that unlocks their other accounts. That’s data minimization.
- No e-conomic integration. I don’t know their platform or API, so everything would have been the agent’s work with no way for me to verify it, and that’s riskier when money is involved. A real integration would also need credentials for a live accounting system, which can’t be burnable mock data. Instead the admins send an offer, which the stallholders compare with the real invoice from the bookkeeper.
What’s Still Open#
Since nothing here is production ready, I’d rather list the gaps than pretend they’re not there.
The public form. Nothing protects it yet. Anyone could submit applications, bots could flood it, and since the system sends a confirmation email, it could send mail to people who never applied. It could also eat up an email provider’s quota. Server-side validation, rate limiting, and a honeypot or CAPTCHA are the obvious starting points, with the usual trade-off against ease of use for stallholders who aren’t tech-savvy.
The admin login. It’s built on Spring Security, and the agent set it up. The library does the hard cryptography, but the configuration around it is where mistakes hide, and I can’t fully verify what an agent wrote. Before production, a human needs to check which endpoints are open, how passwords and sessions or tokens are handled, whether CSRF protection was switched off to make something work, and where the signing secrets come from.
Wrap Up#
An instruction isn’t a guardrail, so don’t build on the agent behaving. Build so it doesn’t matter: in development, everything should be burnable.