Zabta Broker

A local credential-broker daemon that keeps API keys out of your AI agents' hands.

Instead of pasting secrets into agent configs and environment variables, you store them in an encrypted local vault. Agents request a credential at the moment of use; the Broker verifies the agent's identity, evaluates policy, checks budgets, and either issues a short-lived lease, denies the request, or escalates to a human for approval. Every decision is written to a local audit log.

Pre-release (0.1.0b5). This is an early beta: the wire protocol, CLI, and policy model may change without notice between releases. Evaluate it, but do not put production credentials behind it yet.

Install

pip install zabta-broker==0.1.0b5

While the Broker is in beta, install each release by explicit version — pip only resolves pre-releases when named exactly (and --pre would opt your whole dependency tree into pre-release versions).

Requires Python 3.10+ on macOS or Linux.

Quickstart

# 1. Store a secret in the encrypted local vault
zabta-broker vault add --provider stripe --scopes charges:create

# 2. Start the daemon (binds to 127.0.0.1:9477 — loopback only)
zabta-broker start

# 3. Connect to the Zabta control plane (policies, approvals, dashboards)
#    Requires a Starter plan or above — see https://zabta.ai/pricing
zabta-broker register --api-key <your-zabta-api-key>

Connecting a Broker to the Zabta cloud is a paid-plan capability; on Free, register returns a message pointing you to the pricing page rather than a bare error. A standalone local Broker (no cloud policies) runs on any plan.

On the agent side, use the zabta SDK. Set ZABTA_AGENT_ID to your agent's id (shown in the Zabta dashboard) — the SDK derives the agent's identity from it (did:zabta:<agent id>), and the Broker learns the same identities from cloud sync, so nothing else needs configuring:

export ZABTA_AGENT_ID=<your agent id>

import zabta

with zabta.credential("stripe", ["charges:create"]) as key:
    ...  # `key` is a fresh checkout; use it now, don't store it

To run the Broker as a background service (launchd on macOS, systemd on Linux):

zabta-broker install-daemon

How a request is decided

Each credential request runs through a seven-step pipeline:

1. Identity — unknown or unregistered agent DIDs are hard-denied.
2. Policy load — applicable policies are read from the local policy cache.
3. Evaluation — policies are evaluated locally (default deny when nothing matches).
4. Budget — an allowed request that would exceed a spend budget is downgraded to a denial.
5. Enforce or observe — policies in observe mode always issue the credential but record what would have happened, so you can trial a policy without breaking an agent.
6. Issue or refuse — an allowed request gets a short-lived lease on the secret; a denial gets a reason.
7. Audit — every path, including denials, writes an audit record. Redacted summaries (agent DID fingerprints, no secret material) sync to the Zabta cloud.

The Broker's local policy evaluation builds on Microsoft's agent governance toolkit (agent-os-kernel).

Scope — what the Broker does and does not do

We would rather you know exactly where the boundary is:

• Enforcement happens at credential checkout. Policy is evaluated when an agent requests a credential. Once a secret has been handed to the agent process, the Broker does not intercept or mediate what that process does with it.
• The lease TTL bounds the lease record, not the secret. When a lease expires, the agent must come back through policy to get the credential again — but expiry does not revoke, rotate, or invalidate the secret value already issued. Rotation remains your (or your provider's) responsibility.
• Policies are managed in the Zabta cloud control plane. The Broker pulls policies from your Zabta account and enforces a locally cached copy; approval verdicts are decided in the cloud (by your team, in the dashboard) and polled by the Broker. Offline, the Broker keeps enforcing the last-synced policies. An unregistered Broker has no policies, and no policy means deny by default.
• Loopback plus a session token, not a network service. The daemon refuses to bind to anything but 127.0.0.1, and requests must present a per-session token from a 0600 file. This protects against the network, not against other processes running as your own user — anything that can read your files can read that token.

Security model

• The vault is encrypted at rest; the master key lives in your OS keychain (macOS Keychain / Secret Service), not on disk next to the data.
• The session token file and vault database live in ~/.zabta-broker/, owner-readable only.
• Audit records synced to the cloud are redacted: agent DIDs are fingerprinted, secret values never leave the machine.

License

MIT © Zainova Labs LLC