PASTKEYS · credential broker sheet 01 / 01 · scale 1:1 status: live Log in · Sign up

PASTKEYS

Let your AI agents act on your cloud — without ever holding a secret.

PastKeys is a credential broker for AI agents and automated workloads. You store your provider tokens (Cloudflare, GitHub, AWS, Postgres, any HTTP API) sealed to your own broker — we can't read them. Your agent asks the broker to perform an operation; the broker checks a default-deny policy, uses a short-lived scoped credential, runs it, and returns only the result. Every request is written to a tamper-evident audit log.

ZERO-ACCESS CUSTODY  ·  DEFAULT-DENY POLICY  ·  SHORT-LIVED CREDENTIALS  ·  COMPLETE AUDIT

Create an account →   Log in   Read the whitepaper →

FIG.1 general arrangement — request path

One boundary between the agent and every provider.

The broker authenticates the workload, evaluates a default-deny policy, uses a credential that never leaves the enclosure, and logs the result.

A · AUTHVerifies workload identity. Answers who — nothing else.
B · POLICYDefault-deny over (agent, resource, action). Fails closed.
C · CREDENTIALSealed in the enclosure; encrypted to a key only your binary holds.
D · AUDITExactly one secret-free record per request. Queryable.
FIG.2 field measurements

What the boundary actually changes.

Privilege reachable by a compromised agent, measured as a share of the underlying credential's power. To scale, 0–100%.

traditional 100% · full account
pastkeys ~0% · one scoped op
0255075100%
secrets exposed to agent
0
by construction — the key is never in the model
GitGuardian 2026 · public MCP configs
24,008
secrets found leaked — 2,117 live
policy default
DENY
allow only on an explicit rule match

CREDENTIAL LIFETIME — dimensioned, provider permitting:

├──────── 60 s TTL ────────┤   scoped to: 1 zone · 1 action · 1 request-id
FIG.3 failure analysis — agent compromised

Blast radius when the worst happens.

Assume the agent's runtime, context, or logs are fully exposed. What can the attacker actually reach?

FIG.4 policy bench — live

Try the default-deny engine.

Pick a request. The bench evaluates it exactly like pastkeys policy test: allow only on an explicit rule match, everything else denied, errors fail closed.

FIG.5 bill of materials — provider adapters

One interface, every provider.

Adapters implement a common contract. Where the provider supports it, the broker mints a short-lived, scoped credential per operation; where it can’t, a protected long-lived token stays broker-side and is never exposed to the agent.

ItemAdapterOperationsCredentialStatus
01aws (sts)assume-role session · s3 list · caller identityshort-livedbuilt
02githubrepo read · issue read/create · pr readscoped ~1h tokenbuilt
03postgresdynamic role · read-only queryshort-lived rolebuilt
04cloudflareDNS read / create / update / deletepass-throughbuilt
05http (generic)any REST endpointpass-throughbuilt
06ssh (ca)certificate issuanceshort-lived certresearch
FIG.6 assembly sequence — per request

Five steps, fail-closed.

01

authenticate

Verify the agent's workload identity.

02

authorize

Default-deny policy over agent, provider, resource, action.

03

broker

Fetch a sealed credential; scope + time-limit where the provider allows.

04

execute

Perform the operation; return only the result.

05

audit

Write one secret-free event. Any error resolves to DENY.

NOTE quickstart — self-host

Run the broker.

$docker compose up

Free and open source, self-hosted. Managed control plane, SSO, approvals, SIEM export and customer-managed keys (BYOK) come with the team tier.