A local credential broker for AI agents, and the boundary it cannot enforce

When we began building Blackvault Corporate, we had two requirements that seemed to pull against each other. The application needed to hold sensitive company records and credentials, but an AI agent also needed a practical way to use one approved credential for one real task. Giving every agent the administrator password would make the vault little more than a folder with a login screen. Requiring the founder to copy a secret into each chat would create another trail of secrets.

A request is not permission

We built a local credential broker with a narrow request, approval and read sequence. It is part of a Windows desktop application. Its HTTPS server binds to loopback, and its sessions and agent grants live in memory rather than in the durable corporate store.

An agent begins by naming an exact list of credential IDs and a purpose. The request returns an opaque bearer token in pending state. It releases no credential. The founder sees the request in the approval interface and can approve a subset of those IDs, set an expiry and choose a total number of reads. The approved scope cannot silently grow beyond the original request. A credential read is then permitted only while the grant is current, within its approved ID set, and below its remaining disclosure count.

A label is not an identity

The distinction between a request label and identity matters. The agent supplies its own agentId. That string helps us understand the request, but it does not cryptographically prove which model, vendor or process sent it. The random bearer token proves only possession of the capability. We therefore treat the token as a secret and avoid putting it in a URL, log or chat transcript.

For this application, “read access” is too coarse for a credential vault. A colleague may need to know that an account exists without seeing its password. Corporate separates record metadata from the reveal operation: a permitted metadata read can show a credential's label and field names, while revealing the actual fields requires explicit reveal permission. The founder's own signed-in interface can reveal without asking for the password again on every click, but an ordinary read grant does not inherit that power.

When a response goes missing

The most interesting failure case is a broken response. Suppose a credential read reaches the server, the server records the disclosure and consumes the final permitted use, but the network drops before the client receives the value. A naive client retries, effectively asking for a second disclosure. Our rule is to audit the read before returning the secret and to treat an interrupted response as uncertain. The client checks the grant status, rather than assuming a timeout means no use occurred. If another read is genuinely needed, it requires a new decision.

In simplified pseudocode, the core decision is:

if status is not approved, or grant is expired, revoked or exhausted: deny
if requested credential ID is outside the approved subset: deny
if the store is locked: deny
commit disclosure audit and increment use count
return that credential's fields

The ordering is deliberate. If the audit cannot be committed, the secret is not released. Expiry and use count are separate: a grant with ten permitted reads does not remain usable after its time window, and a long-lived grant still stops after its final read. Logout and application restart clear grants entirely. A revoked grant blocks later disclosures, though it cannot erase a secret that was already delivered to an agent.

What the tests establish

We used synthetic credentials to test the boundaries. The local security fixtures cover these boundaries: an unapproved request is denied; approval for credential A does not disclose credential B; a one-use approval succeeds once and fails on the second read; expired and revoked grants fail; and logout or restart removes access. A separate access-control test holds a user-session reveal request in flight while revoking that user's grant, checking that the stale request cannot complete after revocation. That fixture concerns the user-session endpoint, not a general proof of every agent-broker race. The focused access-control and security suites were run through the development workflow on 24 September 2026: twenty-one tests passed. These tests show the intended behavior under those fixtures, not immunity to every process or network attack.

Where the boundary stops

The architecture has an important limit. A broker can control callers that use its API. It cannot sandbox an agent that already has unrestricted filesystem and process access under the same Windows account. That agent may be able to reach files or memory outside the broker's path. For that reason, we treat this as a governed disclosure interface, not a general security boundary around every program on the machine. To make the stronger claim, the runtime would need OS-level isolation and a threat model covering what the agent can actually execute.

That honest boundary made the feature more useful. The founder can delegate a specific operation, review the requester label and the credentials requested, cap how many disclosures are possible, and revoke the remaining access. The system does not pretend that a model's self-description is identity or that a timed token solves the problem of a secret after it has left the vault.