This has been needed long before agents were a thing - and now with agents, even more so! Excited to try it out. But I would like to understand more about the security posture. What documentation do you have for how Capy keeps secrets safe?
Capy uses a split-key encryption model, meaning secrets are encrypted client-side before reaching our servers—so the backend never sees or stores raw plaintext keys. The design is also pretty unique in that it can be used to cryptographically revoke local secrets remotely.
I love this question, because it's something I've been thinking about a lot for the next evolution of this product. My solution, currently, is that the CLI provides all the guardrails.
All the security and logical primitives are enforced via the CLI's command layout, similar to how it is done with git, and the human is still in the loop for the most critical stuff like initial onboarding, saving secrets, resolving conflicts, running deployments, and performing rotations.
I do eventually want to find safe ways for agents to take over those tasks, and there is a lot to learn from how software factory agents currently work with git. The thing is, even with software factories, the VERSION CONTROL gates are also usually still defined by humans (when to commit, merge, deploy, etc.). Whatever it is, the same level of automation ought to exist for secrets and configuration.
To that end, I have an upcoming MCP that acts as a wrapper for orchestrating sequences of Capy CLI commands (but never the contents of them). In the preliminary MCP implementation there's nothing the agent is actually able to interpret, besides maybe identifying variable names, what the stack looks like, and what services the application likely uses.
On the crypto side, the values are encrypted client-side before they’re sent. This means the service stores ciphertext it has no ability to decrypt. So the worst case for a backend compromise is someone getting encrypted blobs plus some metadata.
On the controls side, SAST scanning in CI, and minimizing deps as much as possible in the client and the service.
Do I need another “C” in my workflow?
You can read more about it here: https://www.capy.sc/docs/internals/zero-trust
In addition, the company is right around the corner on our SOC2 Type I audit. It should be available within the next week!
https://trust.capy.sc/
All the security and logical primitives are enforced via the CLI's command layout, similar to how it is done with git, and the human is still in the loop for the most critical stuff like initial onboarding, saving secrets, resolving conflicts, running deployments, and performing rotations.
I do eventually want to find safe ways for agents to take over those tasks, and there is a lot to learn from how software factory agents currently work with git. The thing is, even with software factories, the VERSION CONTROL gates are also usually still defined by humans (when to commit, merge, deploy, etc.). Whatever it is, the same level of automation ought to exist for secrets and configuration.
To that end, I have an upcoming MCP that acts as a wrapper for orchestrating sequences of Capy CLI commands (but never the contents of them). In the preliminary MCP implementation there's nothing the agent is actually able to interpret, besides maybe identifying variable names, what the stack looks like, and what services the application likely uses.
On the controls side, SAST scanning in CI, and minimizing deps as much as possible in the client and the service.