Hey HN,
We're launching the beta for Piper, a dashboard for managing credentials (API keys, tokens) for AI agents, LLM tools, and MCPs.
The problem: API keys end up scattered, hardcoded, or manually managed, which is insecure and doesn't scale, especially when users need to grant access to third-parties.
We provide a centralized vault where users store their credentials and a OAuth 2.0 based authorization layer:
Store - User stores their API key/token with us.
Authenticate - The agent authenticates using standard OAuth flows to request access to a specific user credential it needs for a task.
Grant - The user is prompted to explicitly grant or deny this specific agent access to that specific credential (optionally for a limited time).
Temporary credentials - If approved, Piper uses Google Cloud's STS to generate short-lived, temporary credentials.
The agent uses this temporary credential to access only the specifically approved secret/token for the duration of the credential's validity.
This flow keeps the agent from ever seeing the user's long-lived keys and enforces user consent + least privilege via STS. You can use the same key for multiple agents without ever sharing it and you can easily revoke an agent’s access to the key because you just have to stop issuing short-lived credentials to it.
We think this pattern offers significant security benefits, but we're keen on your feedback
Any better ways to handle the user consent step, especially integrating with LLM interactions or protocols like MCP?
eugenekaliisa•9mo ago
The problem: API keys end up scattered, hardcoded, or manually managed, which is insecure and doesn't scale, especially when users need to grant access to third-parties.
We provide a centralized vault where users store their credentials and a OAuth 2.0 based authorization layer: Store - User stores their API key/token with us. Authenticate - The agent authenticates using standard OAuth flows to request access to a specific user credential it needs for a task. Grant - The user is prompted to explicitly grant or deny this specific agent access to that specific credential (optionally for a limited time). Temporary credentials - If approved, Piper uses Google Cloud's STS to generate short-lived, temporary credentials. The agent uses this temporary credential to access only the specifically approved secret/token for the duration of the credential's validity.
This flow keeps the agent from ever seeing the user's long-lived keys and enforces user consent + least privilege via STS. You can use the same key for multiple agents without ever sharing it and you can easily revoke an agent’s access to the key because you just have to stop issuing short-lived credentials to it.
We think this pattern offers significant security benefits, but we're keen on your feedback
Any better ways to handle the user consent step, especially integrating with LLM interactions or protocols like MCP?