Secrets for Machines, Integrations and AI Agents

This guide teaches you to give a secret to something that is not a person, a build machine, an on-demand container, a connected integration, a Virtual Worker, or an AI agent, without scattering plaintext or handing over a value that gets echoed into logs. By the end you will be able to get credentials out of your .env files, scope a secret to exactly one machine or task with an expiry, and understand why an AI agent can use a secret it can never read.

One Vault for People and Machines

After this section you will see the shape of the problem this solves. The consensus fix for leaked credentials is well known: stop embedding long-lived secrets in code and configuration, and instead hand a short-lived, narrowly scoped secret to exactly the thing that needs it, at the moment it needs it. Backbuild Secrets does this from the same zero-knowledge vault that holds your human logins, with one property that holds across every case below: for a credential in a zero-knowledge vault, the platform never holds the plaintext, and the recipient uses the value without it being echoed back to your code, a model, or the logs.

Authorize a Machine or Container

After this section you will let a machine read a vault without a human unlocking each run. A machine grant authorizes one specific registered device or on-demand container to read the secrets in a designated vault, unattended. Enrollment is a deliberate consent, not a silent token handoff: the machine presents a code, and you, in an unlocked and step-up-confirmed session, confirm it. The grant is bound to that machine's own key, to the specific vault, to the vault's current key generation, and to an expiry, so it is never a blanket, permanent credential.

Machine grants are revocable and fail closed. You revoke one from the vault's sharing panel, and a torn-down session's grant stops working; access is re-checked on the server within a short window, so a revocation takes effect quickly rather than lingering. The primary use is giving an on-demand container, or a coding-agent command-line tool you have linked, exactly the credential a run needs, released from the zero-knowledge vault rather than copied into the environment by hand.

For the developer workflow end to end, replacing a .env file with a launch-time injection, authorizing a workstation or a CI runner, and managing grants across a team, see Secrets from the CLI. It walks the machine authorization ceremony, the secrets run command that projects secrets into a process for its lifetime only, and the grant lifecycle.

A four-stage flow of a machine grant. Stage 1, request: a machine or container presents a code. Stage 2, consent: a person in an unlocked, step-up-confirmed session confirms it, and the grant is bound to that machine's key, the specific vault, the vault's current key generation, and an expiry. Stage 3, use: the machine reads only the granted vault, unattended, until expiry. Stage 4, revoke: the owner revokes from the sharing panel and access fails closed, re-checked on the server within a short window. A note reads: bound, scoped, expiring, revocable.
A machine grant is requested by code, confirmed by a person, bound to one machine, one vault, and an expiry, and revocable at any time with access failing closed.

Release Your Own Keys to a Connected Integration

After this section you will let an integration act with your credential without exposing the value. When you connect an integration that must act with a credential, for example letting the AI assistant call a model provider with your own provider API keys (bring your own key), you knowingly release exactly the needed vault credential to that named service. The release is scoped to that recipient, gated by a fresh step-up, short-lived by default, audited, and revocable, and only a service that is eligible for that kind of credential can receive one.

The boundary is the point. The platform uses the released credential at use-time on your behalf, substituting the real value in at the execution boundary, so your own application code and the model never touch the raw secret and it is never echoed back into a response or a log. You are releasing to a named recipient for a scoped, revocable purpose, not handing out a copy of the key.

A diagram of a secret used but never revealed. On the left, an AI model or your application code issues a request that references a secret by name, not by value. In the middle, a trusted execution boundary substitutes the real secret value into the outbound call to an external service. On the right, the external service receives the call. A return arrow shows the response coming back with the secret value scrubbed out, so the model, the code, and the logs never see it. A caption reads: the value lives only at the boundary, for the duration of the call.
A released secret is substituted at the execution boundary and scrubbed from anything returned, so your code, the model, and the logs never see the value.

Give a Virtual Worker Its Own Vault

After this section you will understand how an autonomous worker uses secrets safely. A Virtual Worker is a non-human identity that runs tasks on its own. Each Virtual Worker gets its own vault, and that vault is auto-shared to the organization administrators who consent to oversee it, so a human can always view and manage it in the app.

A worker's access to secrets is task-scoped. A running task can reach only the secrets bound to that task's scope, checked at the moment of use, and it can never reach a human's vault or another customer's secrets. Administrator consent is required per organization, removing or demoting an administrator re-keys the worker's vault, and every autonomous use of a secret is audited. The wider Virtual Worker model is covered in Virtual Workers.

Why an AI Agent Can Use a Secret It Cannot Read

After this section you will be able to explain the AI boundary precisely. Backbuild is AI-native, and the vault is built so an assistant or worker can be genuinely useful with secrets without ever seeing one. The tools available to an AI agent let it check whether a vault is set up, ask the user to initialize one, generate a new password into a named slot, and list the names, descriptions, and allowed connection targets of entries, and soft-delete entries it created. Generating a password returns a reference to the new secret, never the value, its length, or its character set.

There is deliberately no tool that returns a plaintext value, because none exists. When a secret is actually needed to run a command or make a call, the real value is substituted only in trusted code at the execution boundary and is scrubbed from anything returned to the model, its results, and the logs. An agent can therefore create, organize, and use credentials on your behalf, and still never be a place a secret can leak from.

Drive It Over the API and Native Tools

After this section you will know the programmable surfaces. The whole vault is drivable over the public REST API: status and initialization, unlock and lock, the master password, vaults and members, items, history and restore, attachments, the generator, trash, and the tree, plus device and grant management. Native tools for AI agents expose a safe subset over the Model Context Protocol: reading is available under a plain secrets scope, writing requires an explicit write scope, and no tool ever returns a secret value or even its shape.

How do I get secrets out of my .env files and CI?
Store them in a vault, authorize the machine or CI runner once, and launch your process with the secrets injected at runtime instead of read from a file. There is one authoritative copy, nothing is written to disk, and revoking a machine is a single action. See Secrets from the CLI.

Can I scope a credential to one machine or task with an expiry, and revoke it without affecting others?
Yes. A machine grant is bound to one machine's key, one vault, and an expiry, and each machine has its own grant, so revoking one never disturbs the rest. A Virtual Worker's access is scoped to the running task and checked at use.

Can I rotate a secret without redeploying?
Yes. Update the value in the vault, and the next run of an authorized machine or task picks up the new value at launch. There is nothing baked into an image or a config file to rebuild.

Does the platform ever hold plaintext for a zero-knowledge vault secret, even to deliver it to a machine?
No. The value is released from the zero-knowledge vault and substituted at the execution boundary; it is not stored server-side in the clear and is not echoed back into your code, a model's context, or the logs.

If I let the AI assistant use my model-provider key, does the key get exposed?
No. The key is released to the named integration and used at the moment of the call, substituted at the boundary and scrubbed from the response, so your application code and the model never touch the raw value.

Next Steps