Enforcement Boundary
We would rather you know exactly where the Broker's authority starts and stops than have you find the edge in production. This page states the boundary plainly — no section below is a limitation we're hiding; it's the shape of what “enforcement” honestly means here.
Enforcement happens at checkout
Policy is evaluated when an agent requests a credential — identity check, policy match, budget check, then issue or refuse. Once a secret has been handed to the agent process, the Broker does not intercept or mediate what that process does with it. The Broker is a gate at checkout, not a proxy sitting between your agent and the provider API on every call.
The lease TTL bounds the record, not the secret
A lease has a TTL (300 seconds by default). When it expires, the agent must come back through policy to get the credential again — but expiry does not revoke, rotate, or invalidate the secret value that was already issued. If your agent is still holding that Stripe key after the lease record expires, the key still works; nothing calls Stripe to rotate it. The TTL bounds how long the audit record considers the checkout current, not how long the underlying credential remains valid at the provider.
Rotation of the actual secret remains your (or your provider's) responsibility.
The cloud is the policy brain; the Broker enforces
- Policies are authored and managed in the Zabta cloud control plane. The Broker pulls them and enforces a locally cached copy — it does not decide policy on its own.
- Approval verdicts (for escalated requests) are decided in the cloud, by your team, in the dashboard, and polled by the Broker. See Human approval in the Credential Leasing Guide.
- Offline, the Broker keeps enforcing the most recently synced policies. It does not fail open when it loses connectivity to the cloud — it keeps using the last policy set it has.
- An unregistered Broker (never connected to the cloud) has no policies at all. No policy means deny by default.
The Broker's local policy evaluation builds on Microsoft's agent governance toolkit (agent-os-kernel).
Loopback plus a session token, not a network service
The daemon refuses to bind to anything but 127.0.0.1, and every credential request must present a per-session token read from a 0600 file that rotates on every Broker restart.
This protects against the network — nothing off-box can reach the Broker. It does not protect against another process running as your own user: anything that can read your files can read that token. The boundary is the network, not the local user account.
Frequently asked
Can Zabta revoke a credential an agent already holds?
No. Once a lease is issued, the agent process holds a real, usable secret, and the Broker has no channel back into that process to take it away. Releasing a lease (or letting its TTL expire) closes the audit record — it does not revoke the credential at the provider. True mid-block revocation would require the Broker to sit as a proxy on every provider call, which is a different and much larger product than a local vault-and-lease daemon. Roadmap note: an egress-proxy mode that could support real revocation is a candidate for a future major version, not a near-term commitment — treat “lease” as “checkout,” not “remote control,” until that changes.
What happens if my agent loses its network connection mid-lease?
Nothing happens to the credential it's already holding — see the lease TTL section above. The Broker has no way to reach out and reclaim a secret mid-use, connected or not.
Is the Broker fail-open or fail-closed?
Neither label is accurate as a blanket claim — behavior is per-component. The Broker itself is deny-by-default: no synced policy means deny, and it never invents a permissive default when it can't reach the cloud. The SDK's credential() context manager only ever yields a real secret or raises — see the Credential Leasing Guide. “Fail-open” is not a claim we make about this product.
Related