Giving someone access to a project usually means giving them secrets: database URLs, API keys, cloud credentials, the Stripe test key that somehow has live permissions.
With AI coding agents this happens more often than ever. An agent can fix a bug without ever seeing the production database password, but the easy path is to hand it the whole .env file.
The common options, roughly from fastest to safest:
- Paste the values into Slack or a password manager note, and rotate them when the person leaves
- Share a
.env.exampleand hand out the real values one by one - Give each person or agent its own scoped, short-lived tokens
- Use a secrets manager that injects values at runtime, so nobody reads them at all
Each one trades setup time against how much damage a leak can do.
What does your setup look like? How do you onboard a contractor, and what do you give an AI agent? Has a shared key ever come back to bite you?
Top comments (1)
Runtime injection is useful, but “so nobody reads them at all” only holds if agent-controlled code can't read the injected credential.
In MeshKore, we support keeping upstream credentials in a separately executing tool service rather than handing them to the calling agent. For an AI agent, I'd give it authorization to invoke that service, not the service's keys. Does your runtime injection put secrets into the coding agent's process, or into a separate service it calls?