DCP: Give Your AI Agents Encrypted Permission and Keys

Give your AI agents encrypted permission and keys - DCP | Product Hunt

DCP

Launching today

Give your AI agents encrypted permission and keys

95 followers

Give your AI agents encrypted permission and keys

95 followers

Visit website

Security software

Today, many agents read keys and sensitive info from dotenv files, configs, or memory. One bad prompt or compromised tool can drain your wallet, API bill, or private data. DCP makes agents safe for real work: your wallets and API keys stay encrypted on your own machine. Give each agent only the scopes it needs; it asks, you approve from Telegram or App. Daily budgets, logs, and instant revoke keep you in control. Open source, non-custodial, and works with Claude, Cursor, OpenClaw, and Hermes.

Overview

Reviews

Alternatives

Built with

Forum

Team

More

Free

Launch tags:Developer Tools•Artificial Intelligence•Alpha

Launch Team / Built With

Subscribe

Forum Threads

p/dcp•

1d ago

Should AI agents ever be allowed to hold private keys?

I m launching DCP for Alpha Day and wanted to ask the community something real:

Should AI agents ever be allowed to hold private keys, API keys, or sensitive credentials directly?

A lot of agent workflows today still depend on keys sitting in .env files, configs, local memory, or tool settings.

That works for demos.

View all

The ultimate founder launchpad: Cap tables, equity & 409As

Promoted

Maker

📌

Hey PH! I’m Iftakhar, building DCP.

AI agents are moving from answering questions to executing real work: signing transactions, using API keys, making payments, and calling tools across apps.

But there’s a problem: agents should not hold private keys, raw credentials, or sensitive information.

DCP is my attempt to solve that. It is a local permission vault for AI agents.

The flow is simple:

agent asks

you approve on Telegram or in the app

DCP signs locally

secret never enters the model context

What works today:

• desktop app

• local encrypted vault

• Telegram approvals

• Solana wallet signing

• API credential storage

• budgets and approval limits

• MCP-compatible agent flow

• open source repo

I built this because I think the next bottleneck for agents is not intelligence. It is permission.

If agents are going to act for us, they need a safe way to use wallets, credentials, and sensitive tools without taking custody.

Would love feedback from people building agents, wallets, MCP tools, x402 apps, or anything around agent commerce.

Website: https://dcpagent.com

Docs: https://dcpagent.com/docs

Download: https://dcpagent.com/#download

GitHub: https://github.com/1lystore/dcp

Report

1d ago

@iftakhar_rahmany Congrats on the launch Iftakhar 🎉 Permission as the next bottleneck rather than intelligence is the right framing.

Question on the deployment model: the vault is a local desktop app and signs locally, which is clean for an agent running on my own machine. But a lot of agents now run server-side or in hosted environments, not next to a desktop. How does DCP work when the agent lives on a remote host? Does the vault need to run on the same machine, is there a daemon/relay pattern, or is the local-desktop model an intentional scope choice for now? Asking because "non-custodial + local" and "my agent runs in the cloud" are in tension, and that gap is where permission tools usually have to make a hard architectural call.

Report

15h ago

Maker

@artem_fedorovich Thanks Artem, I’m glad you asked this.

The vault does not need to run on the same machine as the agent.

For remote/server-side agents, DCP uses a sidecar + encrypted relay model.

DCP Desktop lets you connect both local and remote agents. For a remote agent, the user creates a remote invite in DCP Desktop and runs one install command on the server. That installs dcp-agent as a service, pairs it with the user’s vault, and exposes a private HTTP MCP endpoint locally on the server, usually:

http://127.0.0.1:8420/mcp

Then the cloud agent, OpenClaw, Hermes, or any MCP-capable runtime talks to that local MCP endpoint.

The request path is:

remote agent → local dcp-agent sidecar → encrypted relay → user’s DCP Desktop vault → policy / approval / signing → result back to agent

The relay is transport only. It routes encrypted envelopes. It does not hold wallet keys, approve requests, or sign.

So yes, DCP is designed to work with any agent that uses MCP, remote or local. The remote machine gets a permissioned interface to the vault, not custody of the vault itself.

Report

14h ago

@iftakhar_rahmany That's a clean design, the sidecar plus transport-only relay keeps the trust model tight without forcing the vault onto every host. Makes sense.

Thanks for the detailed breakdown Iftakhar, this is one of the clearer takes on agent permission I've seen ship. Good luck with the launch 🤝

Report

13h ago

Maker

@artem_fedorovich Thanks Artem, really appreciate that.

That trust model is the part I care about most: agents can ask, but the user keeps custody and final control.

Glad the design came through clearly.

Report

13h ago

A lot of teams try to solve this with a secrets manager (Vault/Infisical/Doppler) or by giving each agent its own wallet (Privy/Coinbase AgentKit/Sponge). What’s the crisp technical difference in DCP’s model of authority—i.e., what does DCP prevent that those approaches still can’t, and where are the tradeoffs?

Report

11h ago

Maker

@curiouskitty Great question. The difference is custody and authority.

Secrets managers are great at storing and rotating secrets. But in most agent setups, the dangerous moment is when the secret leaves the manager and enters the agent runtime.

At that point, the agent can leak it, misuse it, log it, pass it to a tool, or keep using it until you rotate/revoke.

Per-agent wallets reduce blast radius, but they still make the agent the custodian of that wallet.

DCP takes a different path: the agent does not get the wallet key; it asks for the outcome.

Example:

agent: “sign this Solana transaction”

DCP: checks scope, budget, session, and approval policy

vault: signs locally

agent receives: signed tx / signature

agent never receives: private key

DCP decides whether that action is allowed, under which policy, for which agent, and at what limit.

You also get one permission layer across multiple agents: Claude, Cursor, OpenClaw, Hermes, VPS agents, etc. Set DCP once, then grant each agent its own permissions, budgets, approvals, and audit trail.

That means the permission boundary stays with the user, not the model, prompt, toolchain, server, or relay.

Tradeoff: there is an extra permission layer. But for sensitive actions, that is the point.

Secrets managers protect secrets at rest.

DCP protects authority at the moment an agent tries to act.

Report

9h ago

Scoped permissions for agents feel important. Can teams issue temporary task-level keys that expire or revoke automatically after an agent run, instead of giving the agent broad credentials?

Report

5h ago

Maker

@cyrus_elmtalabDCP supports per-agent permissions, budgets/limits, approvals, logs, and instant revoke.

We don’t yet support automatic time-based revoke after a run, but it’s on the roadmap. The direction is exactly what you described: temporary/task-level scopes that can expire automatically.

For now, teams can revoke access instantly when an agent should no longer have that permission.

Report

5h ago

FYI, I REALLY want to try DCP, but downloading the installer (made sure it's the right version for my Apple silicon Macbook Air 15") it does install, but then gives me a "DCP is damaged; you should move it to trash" which I cannot get around - tried re-downloading and reinstalling, tried a few different things (running as admin, etc.) - nothing works.

This is exactly and precisely the solution I need, so, I hope I can figure it out... congrats on the launch, regardless!

Report

9h ago

Maker

@grey_seymour thank you for flagging this — and sorry you hit it.

This is the macOS unsigned beta/Gatekeeper issue. We added a note on the site for it, but clearly it needs to be more visible.

Please try this in Terminal:

xattr -cr /Applications/DCP.app

Then right-click DCP in Applications and choose Open.

We’re working on notarization so this step goes away. Really appreciate you wanting to try it — and please let me know if that command doesn’t fix it for your Mac.

Report

8h ago

the harder question underneath this product is whether detecting AI use in a technical interview is actually the right goal. a senior engineer who knows how to use AI tools effectively might be more valuable than one who can whiteboard without them. curious if there's a way to configure what counts as unauthorized versus what's just how people actually work now

Report

18h ago

Maker

@ansari_adin Thanks Ansari, I think this may have been meant for another launch today, but I agree with the broader point that AI tools are becoming part of real workflows.

For DCP, we’re focused on the permission layer: how agents can safely use wallets, keys, and sensitive tools without directly holding secrets.

Report

16h ago

Would you give your private keys to your AI agents?

What if an agent makes the wrong decision?

Report

17h ago

Maker

@lakshminath_dondeti Exactly, that’s the core problem DCP is built around.

I don’t think agents should directly hold private keys. They should request an action, show the scope/amount/destination, and let the user approve or reject it.

If the agent makes the wrong decision, DCP gives you guardrails: budgets, approval limits, logs, and instant revoke. The agent can ask, but it should not have custody.

Report

16h ago

@iftakharrahmany agreed. Agents can ask for permission to use private keys and humans can approve on a case by case basis.

Report

6h ago

Congrats on the launch! One question, if we hit the daily cap does it pause and wait for next day or does it notify you?

Report

17h ago

Maker

@prateek_kumar28 Thanks Prateek, good question.

If the daily cap is reached, agent can’t continue under that budget. The user gets notified, and they can either raise the limit manually or wait for the next budget window.

The goal is that agents can automate work, but they should never silently exceed the permission you gave them.

Report

16h ago

12

Next

Last