Credential vault

Save encrypted keys once, approve their first-use destination, and choose which computers can reuse them.

Add API credentials at vault.workpaper.co. Keys stay in Workpaper's hosted trusted broker, outside your computers. Your laptop does not need to stay online after approval.

Save once, approve first use

1. The initial vault request redirects to existing Workpaper sign-in/sign-up unless you have a current browser session; the form is served only after that check. Save a Name, API key, optional Note and computer Scope. Select individual vault-enabled computers, or explicitly select All for current and future vault-enabled computers in your tenant.
2. Save encrypts the key but leaves it unbound and unusable for injection. No destination/auth form is required to save. Keep secrets out of names and notes.
3. Create a restricted computer and request the exact destination on first use:

workpaper run api-agent --vault hosted
# Inside the computer; SERVICE_KEY matches the saved Name:
workpaper vault request SERVICE_KEY api.example.com bearer GET /v1/account

The request is an untrusted suggestion. Workpaper hands its approval link to the operator's laptop browser through the attached terminal; it never launches a browser inside the computer. A detached session prints a clickable fallback link. Sign-in preserves only an opaque pending-request ID. Opening the page does not approve anything. If the key is not saved yet, choose Add a key, save it, and return to review.

The dialog says which computer is asking to use which saved key, with the matching key already selected. Allow approves API requests to that exact host once—not each endpoint or each computer. The initiating request appears under Connection details. Supported formats are Bearer, X-Api-Key and Api-Key. No Basic auth, wildcard hosts or provider-specific connectors. An agent cannot self-approve, read the value or change the approved host/port/auth binding. Saved computer Scope controls reuse; All includes future tenant vault-enabled computers. A different destination requires a separate credential and approval. The provider's own key permissions still apply.

workpaper vault status
workpaper vault call REQUEST_ID GET /v1/account
# Machine-readable output; no automatic browser handoff:
workpaper --json vault request SERVICE_KEY api.example.com bearer GET /v1/account

Status exposes waiting, approved, denied, expired or revoked state and public placeholders for approved access. The call command picks up the placeholder, header and proxy automatically. For POST/PUT/PATCH, provide JSON on stdin. Other compatible clients can use the same public configuration. Requests and status use a narrow host-bound control path, so no general internet or guest management access is needed before approval. No provider key or browser session callback enters the guest.

SDKs and external agents

// JavaScript
const c = await wp.create("api-agent", { vault: { policies: [] } });
await wp.requestVaultAccess(c.id, "SERVICE_KEY", {
  host: "api.example.com", port: 443, auth: "bearer",
  methods: ["GET"], paths: ["/v1/account"]
});
const requests = await wp.vaultRequests(c.id);

# Python
c = wp.create("api-agent", vault={"policies": []})
wp.request_vault_access(c.id, "SERVICE_KEY", {
    "host": "api.example.com", "port": 443, "auth": "bearer",
    "methods": ["GET"], "paths": ["/v1/account"]
})
requests = wp.vault_requests(c.id)

SDK responses include the hosted approval URL for an operator-browser handoff; they never implicitly approve or launch a VM browser. Both SDKs also accept an optional credential ID to select a specific saved key.

Activity, access and rotation

Saved keys swaps only the form area into a searchable, server-paginated metadata table showing Name, computer Scope, binding/revocation status and last recorded use. Last use comes from retained successful broker activity; an empty value does not mean the key was never used. Change access, revoke, rotate and delete use centered dialogs. Requests and sanitized activity are available on the same page. Values cannot be read back. Rotation keeps the destination binding but clears computer access and revokes old requests; use Change access to grant the new revision. Revoking a key is permanent; create a new key to restore access. A per-request revocation blocks that computer for the current credential revision, including All reuse. Revocation cancels active broker requests but cannot undo provider actions already dispatched. Encryption uses a separately provisioned hosted server key.

Limits

• Unknown hosts are denied. HTTP/1.1, bounded UTF-8/ASCII JSON/plain text and identity/gzip responses only. No redirects, WebSockets, SSE or arbitrary binary protocols.
• Proxy and public CA trust are installed by the host/template. Certificate-pinned, non-HTTP and proxy-unaware clients may fail; never disable TLS verification.
• Stop/start preserves your files, processes and saved key permissions. Workpaper reinstalls protection before each resume, without another approval for unchanged All or selected-computer access. Revocations made while paused stay revoked. Vault computers use normal runtime and idle limits, not a one-hour vault lease. Raw unprepared restores, snapshot copies, forks and migration remain blocked.
• Allowed methods/routes do not constrain actions embedded in bodies or queries. Use least-privilege provider credentials and quotas.
• Activity is a bounded operational ring, not immutable compliance storage. No bodies, auth values or URL queries are recorded. Exact-value response redaction cannot prevent arbitrary transformations by an upstream.
• Third-party browser-login brokering is phase 2 and excluded. Workpaper's own hosted sign-in is supported.

Terms · Privacy · Contact