Discussion

Search code, repositories, users, issues, pull requests...

atonse: IronClaw seems to do this natively, I like the idea in general, so it's good too see this pulled out.I have few questions:- How can a proxy inject stuff if it's TLS encrypted? (same for IronClaw and others)- Any adapters for existing secret stores? like maybe my fake credential can be a 1Password entry path (like 1Password:vault-name/entry/field and it would pull from 1P instead of having to have yet another place for me to store secrets?

anthonyskipper: The fake key for real key thing seems like a problem. A lot of enterprise scanning tools look for keys in repos and other locations and you will get a lot of false positives.Otherwise this is cool, we need more competition here.

guyb3: It's a good point, I don't think the placeholders we use will trigger a secret scanner, but we can adjust if it's an issue.https://github.com/onecli/onecli/blob/942cfc6c6fd6e184504e01...

empath75: Don't see any reason to use this over vault.

Olshansky: tl;dr "scrt [set|get|list|....]" is also a great option---If this is of interest, I also recommend looking into: https://github.com/loderunner/scrt.To me, it's a compliment to 1password.I use it to save every new secret/api key I get via the CLI.It's intentionally very feature limited.Haven't tried it with agents, but wouldn't be surprised if the CLI (as is) would be enough.

hardsnow: This is the right approach. I built a similar system to https://github.com/airutorg/airut - couple of learnings to share:1) Not all systems respect HTTP_PROXY. Node in particular is very uncooperative in this regard.2) AWS access keys can’t be handled by simple credential swap; the requests need to be resigned with the real keys. Replicating the SigV4 and SigV4A exactly was bit of a pain.3) To be secure, this system needs to run outside of the execution sandbox so that the agent can’t just read the keys from the proxy process.For Airut I settled on a transparent (mitm)proxy, running in a separate container, and injecting proxy cert to the cert store in the container where the agent runs. This solved 1 and 3.

lancetipton: Im literally working on the exact same solution. Difference is I'm running the system in a Kubernetes cluster.I essentially run a sidecar container that sets up ip tables that redirect all requests through my mitm proxy. This was specifically required because of Node not respecting HTTP_PROXY.Also had to inject a self signed cert to ensure SSL could be proxied and terminated by the mitm proxy, which then injects the secrets, and forwards the request on.Have you run into any issues with this setup? I'm trying to figure out if there's anything I'm missing that might come back to bite me?

jpbryan: Why not just use AWS Secrets Manager?

stevekemp: A program making a call to github.com needs an authentication token.What are you suggesting? The program makes a call to retrieve the secret from AWS? Then has full access to do with it what they want? That's exactly the risk and the problem this, and related solutions mentioned in this thread, is trying to solve.

inssein: You use a forward proxy that can MITM.

paxys: You don't want to give the agent a raw key, so you give it a dummy one which will automatically be converted into the real key in the proxy.So how does that help exactly? The agent can still do exactly what it could have done if it had the real key.

inssein: This is basically what https://www.verygoodsecurity.com/ (their main product), but it's heavily focused on credit card data.

brabel: For one thing, it cannot leak secrets between services.

paxys: Is that really a problem? All the examples on the repo page themselves show LLMs running unintended operations and messing up your data. And that is very much still going to happen with this wrapper. If anything it is going to provide a false sense of security.

miki_ships: wuweiaxin's short-lived-tokens-per-task is the right model, but it hits a ceiling: AWS IAM makes it native; most SaaS APIs don't. GitHub hands you a bearer token, Stripe too, Notion too. The proxy fills that gap. You get per-request scope enforcement without depending on the upstream service supporting fine-grained auth. That's the actual answer to paxys's question -- it's not about preventing the agent from making the same calls, it's about enforcing which calls it's allowed to make when the credential issuer won't.

sathish316: This can also be done using existing Vaults or Secrets manager. Hashicorp Vault can do this and agents can be instructed to get secrets, which are set without the agent's knowledge. I use these 2 simple scripts with OpenClaw to achieve this, along with time-scoped expiration. The call to vault_get.sh is inside the agent's skill script so that the secrets are not leaked to LLMs or in any trace logs:vault_get.sh: https://gist.github.com/sathish316/1ca3fe1b124577d1354ee254a...vault_set.sh: https://gist.github.com/sathish316/1f4e6549a8f85ac5c5ac8a088...Blog about the full setup for OpenClaw: https://x.com/sathish316/status/2019496552419717390

rgbrgb: It seems that the architecture you describe still gives the key to the agent (who could email it to red team or perform nefarious actions with it). The advantage of OP's architecture is that the agent never sees the key and you could inspect the request before proxying it. Is that right or do I misunderstand something?

nonameiguess: Sort of. The point of Vault is you're supposed to actually use RBAC and least privilege and store NPE credentials that are properly scoped to the actions you're comfortable automating, which your NPE then gets a certificate to fetch on demand, rather than just giving it your own personal root credentials that can do anything.We're going to see this reinvented thousands of times in the next few months by people whose understanding of security is far poorer than HashiCorp's, via implementations that are nowhere near as well-tested, if tested at all.

morphology: I don't get the benefit. Yes, agents should not have access to API keys because they can easily be fooled into giving up those API keys. But what's to prevent a malicious agent from re-using the honest agent's fake API key that it exfiltrates via prompt injection? The gateway can't tell that the request is coming from the malicious agent. If the honest agent can read its own proxy authorization token, it can give that up as well.It seems the only sound solution is to have a sidecar attached to the agent and have the sidecar authenticate with the gateway using mTLS. The sidecar manages its own TLS key - the agent never has access to it.

sethcronin: Oops, i read vault and thought obsidian vault haha - but yeah, one of the issues is if your agent can _execute_ on the secret at all, it can be potentially convinced to use it in a way that does not benefit you, even if it doesn't have access to the secret itself.