Hi HN — I’m a heavy OpenClaw user and, like many others, I’ve been thinking about how to give these new “unleashed” agents secure access to my accounts.
Agents need API access to be useful.
But API keys are long-lived secrets.
And agents are not secure environments.
So I built something for myself that quickly turned into a product: keychains.dev.
The idea is simple: agents never see raw credentials.
With Keychains.dev:
• Agents make API calls via a drop-in replacement for curl or JavaScript’s fetch()
• They use template variable names instead of embedding credentials
• The request is proxied through keychains.dev
• The proxy analyzes the target endpoint and determines the minimal OAuth scopes required
• It attempts to fulfill the request using credentials stored server-side
• If credentials are missing — or the agent isn’t approved for that action — it returns an approval link
• The agent forwards that link to its human for authorization
This creates a user-in-the-loop escalation model instead of blind credential injection.
Security-wise:
• Agents can make requests without ever touching credentials (protects against prompt-injection exfiltration)
• Credentials cannot be replayed to arbitrary endpoints — they’re bound to the issuing provider
• Each agent machine is authenticated via SSH keypair + stateful fingerprinting (keys can’t be reused elsewhere, instant revocation)
• Agents can delegate scoped credentials to sandboxed sub-agents if needed
• Users approve new permissions via FaceID/TouchID in the browser
• Full audit trail of every request, with granular revocation at the agent, sub-agent, or scope level
Even if a private key is stolen, permissions can be revoked immediately and tokens are short-lived.
I currently support delegation across 6,754 APIs, but the core idea isn’t the number — it’s controlled delegation with human approval on escalation (+ any API you can reach with curl is compatible).
WDYT?
I’d really appreciate feedback on:
– Whether this matches your threat model for agents
– If user-in-the-loop escalation feels practical
– How you're handling credential security today
Agents need API access to be useful. But API keys are long-lived secrets. And agents are not secure environments.
So I built something for myself that quickly turned into a product: keychains.dev.
The idea is simple: agents never see raw credentials.
With Keychains.dev:
• Agents make API calls via a drop-in replacement for curl or JavaScript’s fetch() • They use template variable names instead of embedding credentials • The request is proxied through keychains.dev • The proxy analyzes the target endpoint and determines the minimal OAuth scopes required • It attempts to fulfill the request using credentials stored server-side • If credentials are missing — or the agent isn’t approved for that action — it returns an approval link • The agent forwards that link to its human for authorization
This creates a user-in-the-loop escalation model instead of blind credential injection.
Security-wise:
• Agents can make requests without ever touching credentials (protects against prompt-injection exfiltration) • Credentials cannot be replayed to arbitrary endpoints — they’re bound to the issuing provider • Each agent machine is authenticated via SSH keypair + stateful fingerprinting (keys can’t be reused elsewhere, instant revocation) • Agents can delegate scoped credentials to sandboxed sub-agents if needed • Users approve new permissions via FaceID/TouchID in the browser • Full audit trail of every request, with granular revocation at the agent, sub-agent, or scope level
Even if a private key is stolen, permissions can be revoked immediately and tokens are short-lived.
I currently support delegation across 6,754 APIs, but the core idea isn’t the number — it’s controlled delegation with human approval on escalation (+ any API you can reach with curl is compatible).
WDYT?
I’d really appreciate feedback on: – Whether this matches your threat model for agents – If user-in-the-loop escalation feels practical – How you're handling credential security today
Happy to answer technical questions.