Let your AI agents act on your cloud without ever holding a secret.
Your provider tokens (Cloudflare, GitHub, AWS, Postgres, any HTTP API) are sealed to a broker you run, so 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 credential, and returns only the result. Every request is logged.
Free for 3 agents and 10,000 operations a month. No card required.
POST /v1/actions Authorization: Bearer <workload-identity-token> { "provider": "cloudflare", "resource": "example.com", "action": "DNS_CREATE", "parameters": { "name": "api", "type": "A" } }
broker returns the result, never the key
{ "success": true,
"operation": "DNS_CREATE",
"data": { "record_id": "9f2c…" },
"request_id": "8a41d0c2" }
audit ▸ decision=ALLOW credential=short-lived 2m secret_in_record=none
One boundary between the agent and every provider.
The broker checks who the agent is and what it may do, uses a credential that never leaves the broker, and logs the result.
┌─────────┐
│ AGENT │ intent: "create A record api.example.com"
└────┬────┘
│ request (operation, never a secret)
▼
╔═════════════════════════════════════════════╗ ◄ trust boundary
║ CREDENTIAL BROKER ║
║ ┌──────┐ ┌────────┐ ┌────────────┐ ║
║ │ AUTH │──►│ POLICY │──►│ CREDENTIAL │ ║
║ └──────┘ └────────┘ └─────┬──────┘ ║
║ who? may it? sealed │ scoped ║
║ ┌────────┐ ▼ ║
║ │ AUDIT │◄────────────── executes ║
║ └────────┘ one event / request ║
╚════════════════════┬════════════════════════╝
│ short-lived · least-privilege
▼
┌───────────┐
│ PROVIDER │ cloudflare · github · aws · postgres · http
└───────────┘
agent ◄ RESULT only, never the key
Everything between an agent and your infrastructure.
Zero-access by construction
Tokens are sealed to a post-quantum hybrid key that only your broker holds. We store ciphertext and cannot decrypt it.
How it works → IdentityNo long-lived agent keys
Agents prove who they are with short-lived tokens from GitHub Actions, GitLab, Google Cloud, Kubernetes or SPIFFE.
Workload identity → CredentialsShort-lived and scoped
AWS STS sessions, GitHub installation tokens, Postgres temporary roles and Cloudflare per-call tokens, each set to expire.
Credentials → PolicyDefault-deny, with approvals
Allow exact operations per agent. Add parameter limits, time windows, rate limits, or human approval.
Policies → EmergencyEmergency controls
Freeze every agent in seconds, revoke all agent tokens, or grant one agent temporary access during an incident.
Emergency access → AuditTamper-evident trail
One hash-chained, optionally signed record per request. No secrets, ever.
Audit →Blast radius when the worst happens.
Assume the agent's runtime, context or logs leak. This is what an attacker can reach, as a share of the credential's full power.
A minted credential covers one operation and is already expiring. Policy denies everything else, and the attempt is already logged.
CASE: agent runtime / context leaked TRADITIONAL PASTKEYS ─────────── ──────── attacker ▶ API_TOKEN attacker ▶ spent session │ │ ┌──────────┼──────────┐ bound to one ▼ ▼ ▼ operation all zones all records acct policy denies the rest audit has the attempt reachable: EVERYTHING reachable: ~NOTHING
Try the default-deny engine.
Pick a request. The bench evaluates it like pastkeys policy test: allowed only on an explicit rule match.
- Unknown agents are always denied.
- The right resource with the wrong action is denied.
- Sensitive operations can require human approval.
- Every decision, allow or deny, is logged.
One interface, every provider.
Where a provider allows it, the broker mints a short-lived credential per operation. Otherwise a protected token stays in the broker and is never shown to the agent.
| Adapter | Operations | Credential | Status |
|---|---|---|---|
| aws (sts) | assume-role session · s3 list · caller identity | short-lived session | built |
| github | repo read · issues · pr read | scoped ~1h token | built |
| postgres | read-only query | temporary role | built |
| cloudflare | DNS read / create / update / delete | per-call scoped token (opt-in) | built |
| http (generic) | any REST endpoint | protected, broker-side | built |
| ssh (ca) | certificate issuance | short-lived cert | research |
Five steps, fail-closed.
authenticate
Verify the agent's workload identity.
authorize
Check policy for the agent, provider, resource and action. Default deny.
broker
Open the sealed credential, or mint a short-lived one.
execute
Run the operation. Return only the result.
audit
Write one secret-free record. Any error means deny.
Run a broker in two minutes.
Download the broker for your platform, generate a custody key, and connect it to your account. The private key never leaves your machine.
macOS, Windows and arm64 builds plus checksums are in the quickstart.
3 agents, 10k ops / month
25 agents, 1M ops / month
limits, SLA, support
Credential security for AI agents.
Secrets management for AI agents: a practical guide
AI agents break the assumptions secret managers were built on. A practical guide to keeping API keys, database passwords, and cloud credentials out of autonomous agents built with LangChain, CrewAI, MCP, and others.
AWSHow to give an AI agent AWS access without long-lived keys
Don't put AWS access keys in your agent. Use workload identity (OIDC) so the agent proves who it is and the broker assumes a role with short-lived STS credentials, scoped to one operation.
ThreatsHow prompt injection steals API keys, and how to stop it
Prompt injection turns untrusted content into instructions your agent follows. If a provider key is in the agent's reach, injection can exfiltrate or misuse it. The durable fix is to keep the key out of the agent entirely.
Stop handing agents long-lived secrets.Free for 3 agents. Your first brokered call takes minutes.
Start freeRead the docs