blindpass. View on GitHub
SECURE SECRET HANDOFFS FOR AGENTS

Autonomy.
Under control.

Agents need API keys.
Give them a secure way to ask.

Request a secret from a person. Exchange it with another agent. BlindPass encrypts the handoff and applies policy to agent-to-agent requests.

Explore the workflow Read the docs
API keys. Access tokens. Credentials for the work.
Human-to-agent provisioning
Agent-to-agent exchange
Policy, approvals, and audit

IN MOTION

Fifteen seconds.
One encrypted handoff.

A request, a policy check, and a handoff the requester runtime decrypts.Motion illustration · sample metadata only

Agent A requests reports.api_key. Exchange policy allows it. Agent B encrypts the key for Agent A's runtime, which decrypts it.

01 / THE USE CASES

They need a secret.
You set the handoff.

A support agent needs an API token. A reporting agent needs a key held by an operations agent. Give each a way to request what it needs.

Explore the handoffs
01

An agent asks. A person provides.

Your agent requests an API key, token, or password. You enter it on the secure input page. Your browser encrypts it for the requesting runtime, which retrieves and decrypts it.

HUMAN → AGENT
02

One agent asks another.

A reporting agent requests a named key from an operations agent. Exchange policy checks the requester, fulfiller, secret, and purpose, then allows, denies, or requires approval.

AGENT → AGENT
03

Request here. Fulfill there.

An agent can request a secret in one exchange and supply a secret it holds in another. Reversing the roles creates a separate request, checked against its own policy.

BOTH DIRECTIONS · SEPARATE PERMISSIONS

02 / THE HANDOFF

Ask. Provide.
Keep work moving.

Explore a human-provided secret or an agent-to-agent exchange. Preview the browser pilot next.Interactive illustrations · no real credentials

Existing provisioning flow · A person supplies a secret requested by an agent.

HUMAN-TO-AGENT PROVISIONING

  1. 1
    RequestAn agent needs an API key.
  2. 2
    ProvideA person opens the input page.
  3. 3
    EncryptThe browser encrypts the secret.
  4. 4
    RetrieveThe agent runtime decrypts it.

The recipient runtime receives the secret. One-use delivery does not expire or revoke the API key at its provider.

secret-request / example-001SIMULATION
Ready to request

Your agent needs an API key.

A support agent needs your support API token. It asks you to provide it through a secure input page.

Requester
support-agent
Provided by
Human operator
Secret name
support.api_token
Delivery
One-use retrieval
A local illustration. No input link is sent and no secret is requested.

03 / BUILT WITH INTENT

A focused path forward.

Start with the security boundary.
Prove the workflow. Then expand.

THE FOUNDATIONIn the repository

Secrets for your agents.

Human-to-agent provisioning and agent-to-agent exchange, with encryption, exchange policy, approvals, and metadata audit.

HPKE · Policy · Audit
THE NEXT CHAPTERProposed pilot

Autonomous work.
Accountable access.

One controller. Two Linux hosts. An approved browser task and a native service job.

Identity → Workflow → Fleet
THE RELEASE BAREvidence required

Prove it in practice.

Real workload identity, session revocation, recovery, and stock-client tests before release.

Test · Verify · Repeat

The host broker, browser session handoff, and native/container fleet parity are planned work. Encrypted handoffs deliver secrets to recipient runtimes. Request expiry and one-use retrieval do not revoke credentials already delivered.

AUTONOMY, UNDER CONTROL.

Let them work.
Keep control.

Explore BlindPass

Start with a secret request. Build toward bounded access.