Developer onboarding for a project that uses AI agents usually involves at least one of these: sending a .env file over Slack, having the new developer copy credentials from a shared Notion doc, screen-sharing while someone types in the values, or handing them access to a shared password manager entry.
Every one of those methods results in the new developer having a copy of the credential values. That copy persists after they leave the team, and there is no clean way to revoke it.
The actual problem
The inconvenience of credential sharing is not the real issue. The real issue is that sharing credential values creates copies that cannot be fully controlled once they leave your hands.
When you send a .env file over Slack, you do not control what happens to it. The developer might save it, they might forward it, they might commit it to a private repo that turns out to be less private than expected. When they eventually leave, you have to assume they still have it somewhere.
The same is true for every method that involves sharing the actual value. The credential leaves your control at the moment of sharing.
Shared access without shared values
With AgentSecrets, credentials are stored encrypted in the cloud. When you invite a teammate to a workspace, you are granting them encrypted access to the workspace key that decrypts the credentials on their machine, not sending them credential values.
agentsecrets workspace invite newdeveloper@company.com
The new developer runs:
agentsecrets login
agentsecrets workspace switch "Company Engineering"
agentsecrets project use payments-service
agentsecrets secrets pull
Their credentials are now in their OS keychain. They got there by downloading encrypted blobs and decrypting them locally with a workspace key provisioned specifically for them. You never sent them a credential value, and they cannot read the values out of the keychain — the keys go straight into storage.
When they leave
When a developer leaves, you revoke their workspace access and their workspace key copy is invalidated. They can no longer pull credentials or decrypt anything from the cloud.
Credentials they already had in their local keychain stop being relevant because the credentials themselves get rotated as part of offboarding. Critically, there is no Slack message or .env file or Notion doc that they still have access to from outside. The departure is structurally cleaner.
What day one looks like
# Install AgentSecrets
brew install The-17/tap/agentsecrets
# Set up account
agentsecrets init
# Join the workspace
agentsecrets workspace switch "Company Engineering"
# Pull credentials for the first project
agentsecrets project use payments-service
agentsecrets secrets pull
# Start working
agentsecrets proxy start
No credentials were shared. No .env file was created. No Slack message contains anything sensitive. The new developer has access to what they need, and that access was granted through the workspace system rather than through value sharing.
Why this matters more for AI agent projects
The credential sharing problem is more acute for AI agent projects than for traditional development. Agents need credentials to function and they create attack surfaces that traditional applications do not have.
When every developer on the team is running agents that call external APIs, credential hygiene is not just a best practice. If one developer's credentials are compromised and those credentials were shared values, the blast radius extends to everyone who had a copy. The workspace model isolates each developer's access so that a compromise is contained.
The standard onboarding pattern to establish
- New developer installs AgentSecrets
- They run
agentsecrets initfrom their project directory - They are invited to the workspace
- They pull credentials with
agentsecrets secrets pull
When a developer leaves, revoke their workspace access and rotate the credentials. The rotation is straightforward because you know exactly which credentials were in which workspace and no copy of the values was sent anywhere you would need to track down.
AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.
Top comments (1)
One surprising insight we've observed is that when onboarding developers to AI projects, focusing on token management early can prevent a lot of headaches later. In our experience with enterprise teams, most bottlenecks come from mismanaged tokens rather than complex API configurations. Adding robust token handling to the onboarding process not only secures your environment but also empowers new developers to experiment confidently within set boundaries. - Ali Muwwakkil (ali-muwwakkil on LinkedIn)