𝐈𝐧𝐬𝐩𝐢𝐫𝐚𝐭𝐢𝐨𝐧
I work a lot with AI coding agents like Claude Code, Codex, Cursor, and other CLI-based tools. They are really useful, but one thing always concerned me: 𝐡𝐨𝐰 𝐦𝐮𝐜𝐡 𝐚𝐜𝐜𝐞𝐬𝐬 𝐚𝐫𝐞 𝐰𝐞 𝐠𝐢𝐯𝐢𝐧𝐠 𝐭𝐡𝐞𝐬𝐞 𝐚𝐠𝐞𝐧𝐭𝐬 𝐭𝐨 𝐨𝐮𝐫 𝐜𝐫𝐞𝐝𝐞𝐧𝐭𝐢𝐚𝐥𝐬 𝐚𝐧𝐝 𝐬𝐞𝐧𝐬𝐢𝐭𝐢𝐯𝐞 𝐢𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧?
Most developers still keep API keys, database passwords, and production credentials in .env files. When an AI agent runs commands inside a project, those secrets can become accessible even when the agent doesn't actually need them.
I wanted to build something that gives developers more control over their secrets, especially when working with autonomous AI agents.
That's how 𝐊𝐚𝐯𝐫𝐢𝐱 started. My goal was to create an open-source, local-first secrets firewall where developers control which process or agent can use a credential, under what conditions, and for how long.
𝐖𝐡𝐚𝐭 𝐢𝐭 𝐝𝐨𝐞𝐬
Kavrix is more than a traditional secrets manager. It combines encrypted credential storage with a permission system for processes and AI agents.
Some of its main features include:
• 𝐄𝐧𝐜𝐫𝐲𝐩𝐭𝐞𝐝 𝐬𝐞𝐜𝐫𝐞𝐭 𝐯𝐚𝐮𝐥𝐭𝐬: Store API keys, tokens, and database credentials securely with support for multiple vaults and profiles. • 𝐀𝐈 𝐚𝐠𝐞𝐧𝐭 𝐜𝐫𝐞𝐝𝐞𝐧𝐭𝐢𝐚𝐥 𝐟𝐢𝐫𝐞𝐰𝐚𝐥𝐥: Agents request permission to perform specific operations instead of receiving direct access to stored secrets. • 𝐏𝐨𝐥𝐢𝐜𝐲-𝐛𝐚𝐬𝐞𝐝 𝐚𝐜𝐜𝐞𝐬𝐬 𝐜𝐨𝐧𝐭𝐫𝐨𝐥: Restrict credentials by command, executable hash, working directory, time limits, usage limits, and manual confirmation. • 𝐒𝐞𝐜𝐮𝐫𝐞 𝐩𝐫𝐨𝐜𝐞𝐬𝐬 𝐞𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧: Inject only the required secrets into an authorized child process without putting them in command arguments or plaintext temporary files. • 𝐓𝐞𝐦𝐩𝐨𝐫𝐚𝐫𝐲 𝐚𝐜𝐜𝐞𝐬𝐬 𝐠𝐫𝐚𝐧𝐭𝐬: Give limited permission to use a credential without permanently exposing it. • 𝐀𝐮𝐝𝐢𝐭 𝐥𝐨𝐠𝐬: Track credential usage and authorization decisions without logging the actual secret values. • 𝐈𝐧𝐭𝐞𝐫𝐚𝐜𝐭𝐢𝐯𝐞 𝐭𝐞𝐫𝐦𝐢𝐧𝐚𝐥 𝐔𝐈: Manage vaults, credentials, policies, grants, and sessions through a TUI. • 𝐄𝐚𝐬𝐲 𝐦𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧: Import existing .env credentials into encrypted vaults. • 𝐁𝐚𝐜𝐤𝐮𝐩 𝐚𝐧𝐝 𝐫𝐞𝐜𝐨𝐯𝐞𝐫𝐲: Create encrypted backups and restore protected data when needed.
Kavrix is designed to work locally, so developers don't need to depend on a hosted secrets management service for their everyday workflow.
𝐇𝐨𝐰 𝐈 𝐛𝐮𝐢𝐥𝐭 𝐢𝐭
I started by working on the core problem of securely storing credentials and making them accessible only when needed.
The initial version focused on encrypted local storage and basic credential management. After that, I started building the more advanced parts, including multiple vaults, process-level secret injection, access policies, and the agent credential broker.
One important part was keeping the developer experience simple. Security tools can become complicated very quickly, and I didn't want developers to spend hours configuring something just to run their applications.
That's why I built both a CLI and an interactive terminal interface. Developers can manage secrets manually or integrate Kavrix into their scripts, development workflows, and AI agent setups.
I also added support for different operating systems, recovery workflows, and importing existing environment files to make adoption easier.
Kavrix is published on npm and developed in public on GitHub.
𝐂𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞𝐬 𝐈 𝐟𝐚𝐜𝐞𝐝
The biggest challenge was finding the right balance between security and usability.
It is relatively easy to encrypt a secret and store it somewhere. The difficult part is controlling how that secret is used without breaking existing developer workflows.
Another challenge was handling AI agents. An agent might need to run a GitHub CLI command, but that doesn't mean it should have unrestricted access to the GitHub token.
I had to design a workflow where the agent can request an operation, Kavrix checks the permissions, and only the authorized process receives the credential.
I also spent a lot of time thinking about failure cases, concurrent access, credential recovery, cross-platform behavior, and preventing sensitive values from leaking through logs or command arguments.
There are still limitations. Kavrix is a credential firewall, not a complete process sandbox, and an authorized process can access the secrets it receives. Full agent isolation is another problem I want to explore.
𝐖𝐡𝐚𝐭 𝐈 𝐥𝐞𝐚𝐫𝐧𝐞𝐝
Building Kavrix taught me a lot about practical application security, encryption, access control, and designing tools for developers.
One of my biggest learnings is that security should be part of the development workflow rather than something developers need to work around.
I also learned how important it is to think about unexpected behavior, especially when AI agents are executing commands autonomously.
A feature might work perfectly in a normal situation, but security tools also need to handle incorrect configurations, interrupted operations, and malicious or unexpected requests.
𝐖𝐡𝐚𝐭'𝐬 𝐧𝐞𝐱𝐭
I want to continue developing Kavrix into a more complete credential-control platform for AI agents and developer tools.
Some things I want to explore include stronger agent isolation, safer execution environments, more flexible authorization policies, and better integrations with popular AI coding tools.
I'm building Kavrix as an open-source project because I want other developers to use it, review it, contribute to it, and help improve the security of AI-assisted development.
𝐆𝐢𝐭𝐇𝐮𝐛: https://github.com/d4rkNinja/kavrix
𝐖𝐞𝐛𝐬𝐢𝐭𝐞: https://kavrix.infynon.com
Built With
- ai-agents
- cli
- commander.js
- cryptography
- devsecops
- esbuild
- eslint
- ink
- javascript
- local-first
- mongodb
- node.js
- npm
- pnpm
- prettier
- react
- typescript
- vitest
- zod
Log in or sign up for Devpost to join the conversation.