Vault (Secrets Store)

Overview

The Vault is a secure, on-device secrets manager built into Yukkai. It stores your API keys, access tokens, passwords, and other sensitive credentials so that the AI agent can use them when needed — without ever exposing the actual secret values to the large language model (LLM).

Every time the agent needs to authenticate against an external service (for example, calling the OpenRouter API, pushing to GitHub, or querying a search engine), it goes through the Vault. The LLM only sees opaque placeholders, never the real credentials. This design ensures that even if a conversation is logged, cached, or reviewed, your secrets remain safe.

How It Works

The Vault operates on a simple but powerful principle: secrets are injected client-side, at the moment a request is made.

Here is the flow:

1. Storage — Your credentials are saved securely on your device, associated with a service label (e.g., openrouter, github).
2. Reference — When the agent needs a secret, it retrieves a placeholder token in the format {{VAULT:service}} — for example, {{VAULT:openrouter}}. This string carries no actual secret data.
3. Injection — When an authenticated HTTP request is executed via the Vault's api_call action, the real secret value is substituted in at the system level, completely outside the LLM's view.
4. Result — The LLM receives only the HTTP response from the service — it never sees the raw API key, token, or password.

This means you can confidently let Yukkai interact with external services on your behalf without worrying about credential leakage in prompts, tool outputs, or conversation logs.

Predefined Services

The Vault ships with built-in support for several commonly used services:

Service	Typical Use
openrouter	LLM inference via OpenRouter
github	Repository operations via GitHub API
openai	Direct calls to OpenAI APIs
anthropic	Direct calls to Anthropic APIs
parse	Symbyoz Cloud Code backend
brave	Web search via Brave Search API
apify	Web scraping via Apify

Additional custom services can be configured as needed.

How to Use It

The Vault exposes four actions. Each is designed for a specific stage of the secret lifecycle — from discovery to authenticated execution.

Actions and Parameters

Action	Purpose	Required Parameters	Optional Parameters
list	See all stored services and their labels (no values shown)	—	—
get	Retrieve a secure placeholder for a service	service	—
get_field	Retrieve an additional field (e.g., a custom URL or app ID)	service, field	—
api_call	Execute an authenticated HTTP request with automatic secret injection	service, url	method (default GET), body (JSON string), headers (JSON string)

Key Behaviors

• Secret values are never returned in clear text. No matter which action you use, the actual credential value is always masked.
• api_call is the recommended way to make authenticated requests. It handles secret injection, header construction, and response parsing for you.
• get returns a placeholder, not the secret itself. This placeholder can be safely embedded in commands or templates that the LLM constructs — the real value is substituted only at execution time.
• get_field is useful when a service requires supplementary information beyond a single key (for example, a custom endpoint URL, an app ID, or a client key).

Examples

Example 1: Discovering Available Services

Before making any authenticated call, you can check which services are already configured in your Vault. The agent calls the list action and receives the names of all available services — but no actual credentials. This is a great first step when you are setting up a new integration or verifying that a key has been stored.

Example 2: Making an Authenticated API Call

Suppose the agent needs to fetch your current usage from OpenRouter. It uses the api_call action with the openrouter service, the OpenRouter usage endpoint URL, and the GET method. The Vault automatically injects your real API key into the request headers. The LLM never sees the key — it only receives the JSON response with your usage data, which it can then summarize or display for you.

Example 3: Retrieving a Custom Endpoint URL

Some services require more than just an API key. For example, a Parse Server instance may have a custom base URL. The agent can use the get_field action with the parse service and a field name like url to retrieve that endpoint — again, as a placeholder if needed, or as a direct value for non-sensitive configuration data. The actual API key remains securely stored and is only injected when an authenticated call is made.

Example 4: Building a Multi-Step Workflow

In a complex workflow — say, scraping data from a website via Apify, then posting the results to a GitHub repository — the agent can chain multiple api_call invocations. Each call uses the appropriate service (apify, then github), and the Vault handles credential injection for each one independently. The LLM orchestrates the logic and sees only the responses, while all secrets stay locked away.

Tips & Best Practices

• Prefer api_call over manual retrieval. Whenever you need to hit an authenticated endpoint, use api_call directly. It handles everything securely in one step. Avoid trying to retrieve a raw secret and then manually construct a request — that approach risks leaking the credential into the conversation.
• Review your stored services periodically. Use the list action from time to time to audit which services are configured. Remove any that you no longer use to keep your attack surface minimal.
• Understand what the LLM can and cannot see. The LLM can see service names, placeholder strings, and HTTP responses. It cannot see raw secret values, request headers containing secrets, or the substitution process itself. This is by design.
• Use get_field for non-sensitive configuration. If a service requires a custom URL or app ID that is not itself a secret, get_field is the right tool. Keep secrets in the primary credential slot and use fields for supporting metadata.
• Store secrets once, reference everywhere. Once a credential is stored under a service label, the agent can use it across any number of tasks, workflows, and conversations. You never need to re-enter or paste the key again.
• Trust the placeholder pattern. When you see {{VAULT:openrouter}} in a command or template, that is the system working as intended. The real value is injected only when the command executes — not when the LLM writes it.

---

The Vault is your first line of defense in keeping credentials safe while still allowing Yukkai to act autonomously on your behalf. By centralizing secret storage and enforcing client-side injection, it lets the agent do powerful things with your accounts — without ever putting your keys at risk.