# Workpaper Vault

Vault is Workpaper's trusted credential store and request broker. It lets an operator choose which Vault-enabled computers can use each provider API key without giving those computers the raw key.

Last reviewed: 2026-10-15. [Open Vault](https://vault.workpaper.co/). Availability: early access; requires a protected, Vault-enabled computer.

## How access works

1. Sign in and save a named provider credential. Its value is encrypted in the hosted store and cannot be read back through the management UI.
2. Choose the computers allowed to reuse it: selected computers, or an explicit All setting for current and future eligible computers in your tenant.
3. On first use, a human operator approves the exact API host, port and supported authentication format. Saving a key or opening an approval link does not itself grant permission.
4. An approved computer receives a public placeholder. The trusted host broker inserts the real credential into outgoing API requests outside the computer.
5. Change access or revoke a grant when the computer should no longer use the key. Revocation blocks new requests and cancels active broker requests; it cannot undo provider actions already dispatched.

Current first-use approval is host-wide for the approved destination; it is not a separate human prompt for every endpoint or every computer. The initiating method and path are shown as context. Provider-side permissions and quotas still define what the key can do. Use least-privilege credentials.

## Security boundary

- The agent does not receive the raw provider credential from Vault and cannot approve its own request or change the approved destination binding.
- The broker, its host, operator authentication and encryption key are trusted parts of the system.
- Compatible runtime enforcement is mandatory. An existing unrestricted VM is not automatically made Vault-safe; startup refuses to proceed if required protection fails.
- Stop/start on a supported Vault computer preserves permissions and reinstalls protection before resume. Revocations made while paused remain effective.
- Rotation keeps the destination binding but clears computer access; access must be granted for the new revision. Key-level revocation is permanent. Per-request revocation blocks that computer for that credential revision until a new explicit approval.

## Important limits

- Supported HTTP requests and bounded UTF-8/ASCII JSON/plain-text responses only. No redirects, WebSockets, SSE, arbitrary binary protocols or certificate-verification bypass.
- Forking, raw snapshot copies and migration of Vault computers are blocked. Third-party browser-login brokering is not included.
- Provider responses remain untrusted. Exact-value response redaction cannot prevent every transformed disclosure by an approved upstream service.
- Activity history is bounded operational data, not an immutable compliance audit log.
- These controls are not an independent security certification or proof of being the most secure product on the market.

[Product overview](https://workpaper.co/index.md) · [Vault source and documentation](https://github.com/ujj-exe/workpaper/blob/main/docs/public/credential-vault.html) · [Contact](https://workpaper.co/contact)