DEV Community

Cover image for Bitwarden Agent Access: How to Share Vault Credentials with AI Coding Agents Securely
Hassann
Hassann

Posted on • Originally published at apidog.com

Bitwarden Agent Access: How to Share Vault Credentials with AI Coding Agents Securely

If you use Claude Code, Codex, or Cursor with real APIs, you need a safer way to pass credentials into agent-run workflows. Pasting API keys into a chat puts them in model context. Storing them in .env files makes them readable by any shell command the agent can run. Bitwarden’s open-source Agent Access project gives you a better pattern: fetch scoped credentials at runtime and inject them only into the process that needs them.

Try Apidog today

Agent Access includes a credential-sharing protocol, a CLI called aac, and Rust/Python SDKs. It creates an encrypted tunnel between a credential provider, such as your Bitwarden vault, and a consumer, such as an agent, CI runner, or script. The consumer requests credentials by domain or vault item ID. It does not get access to your full vault.

This guide shows how to install Agent Access, fetch credentials with aac connect, inject secrets into subprocesses with aac run, and use the pattern with Claude Code, Codex, Cursor, CI, and API testing workflows. It pairs well with the credential-hygiene patterns covered in How to Secure AI Agent API Credentials.

What Agent Access does

Agent Access is an open protocol and reference implementation from Bitwarden. It is designed so other password managers can implement the same provider/consumer model.

The CLI, aac, creates an end-to-end encrypted tunnel using the Noise protocol.

There are two sides:

  • Provider: the side that owns access to the vault.
  • Consumer: the process that needs a credential, such as an agent, script, or CI job.

The consumer requests one credential by:

  • domain, for example github.com
  • vault item ID

The provider decides what to return. The consumer cannot enumerate the whole vault.

Agent Access architecture

Agent Access is currently in early preview. The project README says APIs and protocols may change, and it explicitly warns against inputting sensitive credentials directly into LLMs or AI agents.

The safer pattern is to use aac run, which injects secrets into a child process as environment variables instead of exposing them in the agent transcript.

Why this matters for AI coding agents

AI coding agents now do more than edit files. Claude Code, Codex, Cursor, and similar tools can:

  • read your repository
  • run tests
  • call APIs
  • open PRs
  • trigger deployments
  • interact with CI scripts

Each step may require credentials.

The wrong solution is to trust the agent with broader access. The better approach is to reduce what the agent can see and use.

Agent Access helps by making credentials:

  • scoped to one domain or item
  • encrypted in transit
  • fetched at runtime
  • available only to the subprocess that needs them
  • removed when that process exits

This matters because credential hygiene already fails at human scale, as shown by incidents like exposed API keys in shared tooling. The Postman exposed-API-keys incident is a good example of how quickly secrets can spread when processes are loose. Add agents to the workflow, and the blast radius grows.

For broader API key tooling context, see API Key Management Tools.

Install Agent Access

Install the aac CLI for your platform.

macOS Apple Silicon 

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
Enter fullscreen mode Exit fullscreen mode

macOS Intel 

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
Enter fullscreen mode Exit fullscreen mode

Linux x86_64 

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
Enter fullscreen mode Exit fullscreen mode

Windows x86_64

Download aac-windows-x86_64.zip from the latest release page, then extract it to a directory on your PATH.

Verify the install:

aac --help
Enter fullscreen mode Exit fullscreen mode

If the Bitwarden CLI, bw, is available on your PATH, aac uses it as the default credential provider.

If you only want to test the flow, use the example provider:

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

Quick start: pair and fetch a credential

Start the provider listener on the machine that can access your vault, usually your laptop:

aac listen
Enter fullscreen mode Exit fullscreen mode

The listener prints a pairing token.

On the consumer side, use that token to request a credential:

aac connect --token <pairing-token> --domain github.com --output json
Enter fullscreen mode Exit fullscreen mode

The response looks like this:

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}
Enter fullscreen mode Exit fullscreen mode

You can parse this JSON in your script.

To request by vault item ID instead of domain:

aac connect --id <vault-item-id> --output json
Enter fullscreen mode Exit fullscreen mode

--id and --domain are mutually exclusive. Use one or the other.

If the vault item has TOTP configured, the TOTP value is returned in the same payload.

Use aac run to inject secrets into a subprocess

aac connect is useful when your script wants JSON.

For AI-agent workflows, aac run is usually safer.

aac run fetches a credential and starts a child process with selected credential fields injected as environment variables. The secret does not go to stdout, disk, shell history, or the model context window.

Inject selected fields 

aac run \
  --domain example.com \
  --env DB_PASSWORD=password \
  --env DB_USER=username \
  -- psql
Enter fullscreen mode Exit fullscreen mode

This starts psql with:

DB_PASSWORD=<credential.password>
DB_USER=<credential.username>
Enter fullscreen mode Exit fullscreen mode

Inject all fields with the default prefix 

aac run --domain example.com --env-all -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

This injects available fields with the AAC_ prefix.

Combine defaults with overrides 

aac run \
  --domain example.com \
  --env-all \
  --env CUSTOM_PW=password \
  -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

Available fields are:

  • username
  • password
  • totp
  • uri
  • notes
  • domain
  • credential_id

This is the key pattern for AI coding agents.

Instead of asking the agent to handle a secret, give it a script that runs:

aac run --domain api.stripe.com --env-all -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

The model sees the command. It does not see the secret value.

If the agent later tries to inspect the value, the credential is scoped to the child process and is not available in the agent transcript.

This is the same isolation principle covered in How to Secure AI Agent API Credentials, implemented with a real tool.

Use the Python SDK

If you need to embed Agent Access into your own app, use the Python bindings:

from agent_access import RemoteClient

client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")

cred = client.request_credential("example.com")
print(cred.username, cred.password)

client.close()
Enter fullscreen mode Exit fullscreen mode

The Python module is backed by PyO3, so the protocol implementation remains in Rust.

Use the Rust SDK

The Rust SDK exposes the same RemoteClient interface as a first-class library.

Use it when your consumer is written in Rust, for example:

  • CLI tools
  • build runners
  • internal developer tools
  • compiled deployment utilities

Reference implementations are available under examples/rust-remote/ in the Agent Access repo.

For teams already using enterprise secrets tooling, this pattern can sit alongside HashiCorp Vault or Azure Key Vault. Agent Access is not a full enterprise vault replacement, but it fits developer-laptop and CI-runner workflows well.

Integrate Agent Access with AI coding agents

Claude Code

Wrap the sensitive operation in a script.

Example:

# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh
Enter fullscreen mode Exit fullscreen mode

Make it executable:

chmod +x deploy.sh
Enter fullscreen mode Exit fullscreen mode

Then point Claude Code at:

./deploy.sh
Enter fullscreen mode Exit fullscreen mode

Claude Code can trigger the deploy, but the credentials stay inside the subprocess launched by aac run.

The same pattern applies in CI. The Claude Code GitHub Actions workflow can install aac in the runner, pair with a provider, and inject scoped credentials during the job.

OpenAI Codex

For Codex CLI workflows, keep the same boundary:

# run-tests-with-secrets.sh
#!/usr/bin/env bash
aac run --domain staging.example.com --env-all -- npm test
Enter fullscreen mode Exit fullscreen mode

The agent calls:

./run-tests-with-secrets.sh
Enter fullscreen mode Exit fullscreen mode

Codex can see the command and test output. It does not need to see the secret.

For a broader view of Codex workflows, see Codex from your phone.

Cursor

Cursor terminal commands and Composer workflows can use the same wrapped scripts.

For local development, the listener will usually run on the same machine:

aac listen
Enter fullscreen mode Exit fullscreen mode

Then your Cursor-triggered script can use:

aac run --domain local.example.com --env-all -- ./dev-task.sh
Enter fullscreen mode Exit fullscreen mode

OpenClaw

Agent Access ships an official OpenClaw skill. The repo includes a SKILL.md.

If your team uses OpenClaw-style skills, this gives you a cleaner integration point: the skill understands the Agent Access protocol and can fetch credentials for downstream tools.

For more context, see the OpenClaw API keys guide.

Security model

Agent Access gives you three useful guarantees.

1. End-to-end encryption

Traffic between the consumer and provider is encrypted with the Noise protocol framework, the same protocol family used by systems like WireGuard and Signal.

2. Scoped credential access

The consumer requests one domain or one vault item ID.

It cannot enumerate the full vault.

3. No secrets on disk by default

With aac run, secrets are injected into the child process environment.

They are not written to a file, printed to stdout, or stored in shell history by default.

What Agent Access does not solve

Agent Access reduces exposure, but it does not make unsafe workflows safe.

It does not protect against:

  • A compromised consumer process: if the child process is malicious, it can still leak the scoped credential.
  • A compromised provider: if your vault or provider host is compromised, Agent Access cannot fix that.
  • Secrets pasted into prompts: if you copy a credential into an LLM chat, the protocol is bypassed.

Use Agent Access to reduce the blast radius, not as a reason to give agents broad trust.

Practical CI pattern: agent writes code, Apidog tests the API

A common implementation workflow looks like this:

  1. Agent writes the code

    Claude Code, Codex, or Cursor modifies an endpoint and opens a PR.

  2. CI runs implementation tests

    The test job calls aac run to fetch a staging API key and run the test suite.

  3. Apidog verifies the API contract

    Apidog runs OpenAPI contract tests as a separate CI step, also through aac run.

Example CI script:

#!/usr/bin/env bash
set -euo pipefail

aac run \
  --domain staging.example.com \
  --env API_KEY=password \
  -- ./run-api-tests.sh
Enter fullscreen mode Exit fullscreen mode

The result:

  • the agent can ship code
  • CI can call the API
  • Apidog can verify the contract
  • the secret does not enter the agent prompt

For more API-agent testing patterns, see How to test AI agents that call your APIs.

Limitations and warnings

Before you build on Agent Access, account for these constraints:

  • Early preview: APIs and protocols may change.
  • Bitwarden CLI required by default: install the Bitwarden CLI or use --provider example for testing.
  • No config file yet: current usage is flag-driven, so repeated workflows should be scripted.
  • Do not paste secrets into LLM prompts: Agent Access only helps if you keep credentials out of the model context.

FAQ

Is Agent Access free?

Yes. The CLI, SDKs, and protocol are open source under the Bitwarden GitHub organization.

If you use Bitwarden as your vault, your Bitwarden plan still applies.

Does it work with password managers other than Bitwarden?

The protocol is designed to be vendor-neutral.

The current reference implementation supports Bitwarden and includes an example provider. Other providers can implement the protocol over time.

Can I use it without a password manager?

For testing, yes:

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

For production, use a real credential provider.

Does the consumer process need network access?

Yes. The consumer must reach the provider listener.

Local-only setups work when both sides run on the same host.

How is this different from a .env file?

A .env file sits on disk. It can be accidentally committed, copied, or read by commands the agent runs.

aac run keeps the secret in the child process environment and removes access when the process exits.

Does it replace HashiCorp Vault or AWS Secrets Manager?

No.

Enterprise vaults are still better for large-scale service-to-service secret management. Agent Access is aimed at developer machines, agent workflows, and CI runners where direct password-manager-backed access is more practical.

Will Anthropic, OpenAI, or other agent vendors integrate this directly?

No direct first-class integrations have been announced.

For now, the integration model is to wrap sensitive commands in scripts that call aac run.

Where do I report bugs or contribute?

Use the GitHub repo for issues, pull requests, and protocol discussions.

Try it now

Start with the smallest working loop.

Install aac, then run the listener:

aac listen
Enter fullscreen mode Exit fullscreen mode

In another terminal, test with the example provider:

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

Once that works, replace the example provider with Bitwarden-backed access, then wrap a real command:

aac run --domain staging.example.com --env-all -- ./run-tests.sh
Enter fullscreen mode Exit fullscreen mode

Pair Agent Access with Apidog for API testing, and you get a clean workflow: the vault stores the secret, the agent ships the code, Apidog verifies the contract, and credentials stay out of the prompt.

Top comments (0)