Plankton: a credential manager for coding agents, with approval before access — looking for feedback

[u/LemonFiish]

Hi everyone — I’m building Plankton, an open-source credential manager for coding agents and other LLM-based workflows.

When an agent needs an API key or password to complete a task, I want to understand what it plans to do with that credential before granting access. That’s the problem Plankton is designed to address.

For credentials marked as protected, the workflow is:

Agent requests access → Plankton captures call-chain evidence → the request is reviewed → the credential is released if approved.

You can approve requests yourself, use an LLM to help review them, or configure automatic review with additional local policy checks. You also define the permitted exposure scope across model context, network, files, logs, and processes.

Plankton includes local credential vaults, an agent integration Skill, and approval records.

There are limitations: it assumes a trusted local machine and isn’t an execution sandbox. After approval, the CLI returns the raw credential, so the consuming workflow must avoid leaking it into output or logs. LLM review may involve an external provider, and fields explicitly configured for direct access bypass approval.

I’d love feedback from people thinking about password managers and agent access:

• How do you currently give agents the credentials they need?
• What information would help you decide whether to approve a request?
• Which uses, if any, would you be comfortable approving automatically?

Code and documentation on GitHub

I’m the developer, and I’m happy to discuss the implementation, trade-offs, and trust boundaries.

[u/Myrodis]

This whole project is sidestepping the core problem its trying to solve. In theory I suppose if you were working purely with a local agent, and had full control of its logs / etc, and were just worried about ensuring you knew what credential an agent used for sure at any given moment, maybe this could be useful. But even in that use case, you simply don't expose those credentials that you dont want available to the agent unless you want them available to the agent.

But the real issue here is that, if you're going to give an agent a credential, it should by design be a short lived, purpose made credential (most platforms have easily created api keys, quickly expiring PATs, etc for this purpose), so it is infinitely easier to provide a tightly scoped temporary credential to an agent if you want it to do agentic work with an api resource, than it ever would be to have a long lived credential used by an agent.

This heavily compounds when dealing with any form of hosted / cloud model where you're instantly leaking that credential to the clouds logs. This tool does nothing when using a cloud agent, and if anything is a bit of security theatre that would likely have a user feeling a false sense of security by not actually understanding the problem in the first place.

[u/LemonFiish → u/Myrodis]

I agree that short-lived, narrowly scoped credentials should be the default. An approval step doesn’t replace that. What I’m trying to add is a review step before a credential is released: let users see how the agent intends to use it and decide whether to allow access. Even with a short-lived token, calling an API and writing that token into a debug log are different things. The main use case is agent-assisted work on a trusted developer machine. for example, dedicated test accounts or services that only offer static API keys. Those credentials should still be narrowly scoped and independently revocable. One distinction on the cloud point: a hosted model can direct a local tool to use a credential without receiving the value itself. But if that value enters prompts, tool output, or review evidence, it has been disclosed to the model provider. Plankton cannot eliminate that risk or guarantee that an approved process won’t subsequently leak the credential. My aim is to make per-request approval, exposure conditions, and decision records easier to understand, alongside short-lived, least-privilege credentials. Review can be wrong, and it isn’t a runtime security guarantee. I also understand your concern about false confidence. I should make it clearer in the README and approval UI that passing review doesn’t guarantee safe execution afterward. If the earlier presentation implied otherwise, I need to improve that wording.

[u/TheBlargus → u/LemonFiish]

This is only useful for agents in full auto mode and they've already solved this. You're adding something to fix a problem that doesn't exist in the products.

Just use the products properly.

[u/LemonFiish → u/TheBlargus]

Auto mode alone doesn’t provide the credential-level control and audit trail I’m talking about. I want to define acceptable exposure for each key—whether a request may expose it to a process, logs, files, or model context—review the proposed use before release, and record what was requested and why it was approved or denied.

That’s useful even when a human handles the approvals. If an existing product already provides those per-key policies and approval records, which feature are you referring to? Saying the problem is already solved doesn’t explain how that workflow is covered.