Secrets vault for agents

Give credentials to your agents. Without ever exposing them.

Your AI agents need API keys, tokens and passwords to act. Pasting them into the prompt, the model context or a .env file exposes them — to the LLM, to logs, to history. Tramya reverses the flow: the agent requests the use of a secret, you approve locally, the agent receives the result — never the value.

The problem

A secret in a prompt is a compromised secret.

Anything that enters a model's context can be repeated, cached on the provider's side, or leaked through a prompt injection.

When an agent has to deploy, call a paid API or push code, it needs a credential. The common approaches make it visible far beyond that single use:

  • In the prompt: the value goes to the model provider, stays in the conversation history and can resurface in a response.
  • In the agent's context / memory: it gets re-injected on every turn, multiplying the leak points.
  • In a .env or config file: it sits in plaintext on disk, ends up in a commit or a screenshot.

The risk isn't theoretical: a single well-placed prompt injection can convince an agent to spit back everything it holds in context.

The flow

The agent asks, you approve, it receives the result.

Three MCP tools, one simple rule: the plaintext value stays between the local vault and the action.

1 — The agent requests the use

The agent calls request_secret_use with the secret's identifier and the intended action (e.g. "use STRIPE_KEY to create a refund"). It doesn't ask for the value: it asks for an execution.

2 — You approve locally

A local window shows who is requesting what, for which action. You approve or deny. Nothing goes over the network for this decision — the local engine (port 4317) orchestrates everything.

3 — The secret is injected at execution

On approval, the value is decrypted in memory and injected only into the actual command or call. It is never handed back to the agent as text.

4 — The agent gets the result

Via get_secret_use_result, the agent obtains the output of the action (status, API response, ephemeral token depending on policy) — enough to continue its task without ever having seen the credential.

And to store a secret? Symmetric: the agent calls request_secret_store to declare a need (name, purpose), but you are the one who types the value into the local window and confirms it. The agent gets a reference, never the value.

Local-first

Not a cloud broker. A vault on your machine.

The fundamental difference from enterprise credential brokers.

The key stays local

The vault's encryption key is derived and kept on your device. No third-party server can decrypt your secrets, because no third-party server holds the key.

No Business account

A cloud broker requires an enterprise plan, a team directory and trust in its infrastructure. Here, a single dev machine is enough: the approval flow runs locally.

Audit without exposure

Every use request is explicit, timestamped and logged locally. You know who requested what, and when — without the secret's value appearing anywhere.

Frequently asked questions

Does the agent see the secret's value?

No. The agent calls request_secret_use with a secret identifier and an action. The value is injected locally at the moment of the approved execution; the agent receives only a result (status, command output, or a short-lived token depending on policy). The plaintext value never enters the prompt, the LLM context or the conversation logs.

Do you need a Business account or a cloud to use the vault?

No. The Tramya vault is 100% local-first: the encryption key and the secrets stay on your machine. Unlike a cloud credential broker, no Business account or third-party server is required to approve an access. The local engine on port 4317 orchestrates the request, the approval and the injection with no network egress.

How does a secret get into the vault without the agent reading it?

Via request_secret_store: the agent declares that it needs a secret (name, purpose), but you are the one who types the value into a local window and approves it. The secret is encrypted at rest with AES-256-GCM. The agent gets a reference, never the value.

What happens if I deny an access request?

The action is blocked and the agent receives a denial status. Every request_secret_use request is explicit, timestamped and logged locally, which gives you an audit trail of accesses without ever exposing the values.