Agent VaultDEV

A vault for your agents

Give tools access.
Keep secrets private.

Add credentials, choose which harnesses can use them, and manage access from one place.

01 Save a secret securely

02 Connect a scoped harness

03 See usage and revoke access

How connecting a harness works

Your vault starts here

Sign in with your agentleFS account, or create an account.

Loading secure sign-in…

WHY KEEP SECRETS OUT OF CONTEXT?

Your agent needs a capability.
Its prompt doesn’t need the credential.

Paste an API key into a conversation and the model can repeat it. Copies may also remain in chat history, shared transcripts, or traces. Agent Vault lets your agent ask for a tool to use a credential while keeping the value in the trusted execution path.

Sharing a value in chat

The credential becomes part of the conversation

The secret travels with the prompt. A misleading instruction, an accidental quotation, or a copied transcript can expose it to someone who should not have it.

Using Agent Vault

The conversation carries a reference

secret://workspace/staging/database

The reference identifies a secret; it does not grant access. The vault releases the value only to an authenticated harness with permission to use it.

HOW IT WORKS

From a reference to a tool result

A database test is one example. The same flow works for API keys and other tool credentials.

  1. 01

    You save and scope access

    Add a secret in the app, then connect a harness with selected secrets and an expiry. The service encrypts the stored value and manages its access grants.

  2. 02

    The agent requests a tool

    The agent uses the secret reference in its tool request. Its trusted harness authenticates to the vault over HTTPS; the vault checks current permissions and delegated scopes.

  3. 03

    The harness injects the value

    Imagine the agent needs to run a database check. Its request names secret://workspace/staging/database. The trusted harness adapter—the code that connects your runtime to the vault—resolves that reference after the vault checks its access.

    The adapter launches the check with the real credential in the process’s DATABASE_URL environment variable. The database client reads it normally. The value stays out of the prompt and command arguments, and the vault’s raw response is never returned to the model.

    For tools that read a credential file, the adapter can instead create a temporary file with owner-only permissions and supply its path to the process. It removes the file during execution cleanup. The tool still receives plaintext credentials, so the harness and tool must be trusted.

  4. 04

    The agent gets filtered output

    Tools can accidentally print credentials in diagnostics or errors. The adapter captures both standard output and error output, then replaces known secret values with [REDACTED] before returning either stream to the model. It also checks common JSON-escaped, URL-encoded and base64 forms.

    Database check passed
DATABASE_URL=[REDACTED]

    Output is buffered before filtering, so splitting a value across output chunks does not evade an exact-value match. If execution times out, is cancelled, or exceeds the output limit, the adapter suppresses captured output rather than returning a potentially sensitive fragment.

    Separately, the vault records who requested which reference, its version, the time and the access decision. It does not put the credential value in that audit record. Filtering is best effort and covers output returned through this adapter; it cannot prevent a malicious tool from leaking credentials through other channels.

Limit each worker’s reach

Give a test harness staging credentials. A delegated worker can receive narrower access, with every ancestor’s scope still enforced.

Change access centrally

Expire harness credentials, remove a grant, or retire a harness to block future resolutions. Rotate the underlying secret when its value needs to change.

Inspect usage without values

See which harness requested a reference, when it did so, and whether access was allowed. Saved secret values are write-only in the web app.

See the harness connection guide

Add a secret

Agent Vault encrypts the value and manages access.

Write-only. Saved values are never displayed here.

Connect a harness

Choose its access. We’ll create the identity and grants.

Allowed secrets Choose up to 16

Harness connected

Save this token in your harness’s protected runtime settings. It is shown once.

The endpoint is . Your agent uses secret references, while your trusted harness handles this credential.

Manage harness access