Giving my agents real power without handing over my keys

The more I lean on AI agents, the more they need to reach into my email, my files, my NAS. Bridgr is how I give them that reach, one service at a time, without ever giving away a single credential.

A powerful agent is a hungry agent

An agent is only as useful as what you let it reach. On its own it is a clever conversation and nothing more. Give it your inbox, your files, your NAS, your repositories, and it starts doing the work: reading threads, moving files, sending messages on your behalf.

So the longer I used agents, the more I wanted to give them. And every time, I stopped at the same place.

The barrier nobody likes to cross

To give an agent access to a service, the usual path is to give it the credential. The OAuth token. The app password. The API key. The literal key to the thing.

But an AI agent is autonomous and non-deterministic. I do not always know in advance what it will do, which is the whole point, and also the whole problem. Handing my credentials to an entity like that, and trusting it, and every library it loads, to never leak them and never act outside what I meant, is a decision I kept refusing to make casually.

"I wanted my agents to be powerful. I did not want to pay for it with my credentials."

What I actually wanted

I wanted to break the barrier and keep the control at the same time. Three things at once:

• give my agents access to the services I use,
• keep fine-grained control over exactly what they can touch,
• and make granting that access easier, not another chore.

That set of constraints is Bridgr.

What Bridgr is

Bridgr is a self-hosted broker that sits between my agents and my services. It holds the credentials in an encrypted vault. The agent never sees them. It sees tools.

When an agent wants to read recent email, it does not get my password. It asks Bridgr. Bridgr checks that this agent is enrolled and that the capability is switched on for that account, pulls the credential out of the vault, makes the call, and hands back only the result. The agent does the work. The key never leaves the box.

One operator, one box. My home server, a VPS, my laptop. No SaaS, no cloud holding my secrets, nothing extra standing between my agent and my own credentials.

Fine-grained control, on my side

Control here is per-capability, not per-service. Connecting my mailbox does not grant "email access". It grants nothing. Every capability starts off. I turn on exactly the ones I want: read my threads, yes; send mail, only when I decide; delete, almost never.

One switch per capability, defaulting to off. A master "pause everything" control that cuts every agent's access in a single click. And an audit log that records every call an agent makes: which agent, which tool, when. The agent can call tools through Bridgr, but it has no way to reach or edit that log. A strict rule keeps credentials and payloads out of it, so the record never becomes the leak.

One interface for everything

My services do not speak one language. Email is IMAP and SMTP, or Microsoft Graph over REST. My NAS speaks Synology's own HTTP API. Tomorrow it might be GitLab, a cloud drive, a smart-home hub.

Bridgr's job is to flatten all of that into one thing my agents already speak: MCP, the protocol they use to call tools. Whether the real service is a REST API, an existing MCP server, or just a script I wrote on a Sunday, Bridgr wraps it as a connector and exposes it through a single MCP interface. The agent learns one way to talk to everything I own.

My actual Bridgr instance. Two connectors, four accounts, and every capability is its own switch with a read or write badge and a live call count. "Send an email" is off on all three mailboxes: the agent can read, not send, until I decide otherwise.

Connectors: extend it to anything

Connectors are the part I care about most, because they are what let Bridgr keep up with whatever I want next. A connector is a small drop-in package. No marketplace, no plugin store, no fork of Bridgr itself. I drop a folder into a directory and Bridgr picks it up: it scans on startup, and it rescans on demand from the admin UI, so a new connector appears without restarting anything that is already running. If one is broken, it is logged and skipped on its own, so it can never take the others down with it.

What the author actually writes is small. A manifest that declares the service and its capabilities, where each capability becomes one MCP tool tagged read, write, or destructive. Then a handful of methods: how to connect an account, how to check the credentials are valid, how to run a capability, and how to revoke. That is the whole contract.

Everything hard stays Bridgr's job, not the connector's: encrypting the credential, authenticating the agent, enforcing the per-capability switches, writing the audit row, and speaking MCP. The connector only has to know how to talk to its one service. That is why a new one is an afternoon, not a project.

And a connector can wrap almost anything with a way in: a REST API, an existing MCP server, or a plain script. If I can reach it from code, I can put it behind Bridgr. Mail and my NAS are connected today. Cloud storage and my repositories are next. The day I want an agent to dim my lights or check the charge left in my car, that is one more connector, not a new design. The agent does not learn anything new either. It is the same single interface, with one more tool switched on.

How it is built

It is security-first, because the entire value is trust. Credentials live in a vault encrypted with XChaCha20-Poly1305. The key is derived with Argon2id from a master secret I enter to unlock Bridgr, and it is never written to disk. Each credential's encryption is tied to the account it belongs to, so a ciphertext copied onto another account fails its integrity check instead of opening. Networked agents authenticate with mutual TLS, each carrying its own revocable certificate; a local agent over stdio uses a per-enrolment token instead. Either way there is no shared password and no static secret sitting in a config file.

And I did not hand-write Bridgr. I built it with my own software development lifecycle, the Black Box App Factory: an AI agent that plays 7 roles across 22 phases, from specification through architecture, implementation, code review, security audit, and testing, to release. Eleven cycles, 1,053 tests, mypy --strict and ruff clean, an 85% coverage floor on every security-sensitive module, and a standalone security audit on each pass. Bridgr is what the factory built, and the factory is why I trust it with my keys.

Where it is, honestly

Bridgr is alpha, version 0.1.0, single-operator by design, and open source under the MIT license. It is not a SaaS, not multi-tenant, and not a vault you should trust with life-or-death corporate secrets. It is the smallest thing that lets one person give their agents reach while keeping the keys, the switches, and the audit trail on hardware they control.

It is a work in progress, and it is already the layer the rest of my personal infrastructure plugs into. Mail and NAS today; my cloud storage, my repositories, and eventually anything with an API I care about.

The line I am drawing

This is the same instinct that runs through everything I build: give the powerful new tool real reach, but keep the human in control of what actually matters. With agents, the thing that matters most is the keys. Bridgr is where I drew that line for my own data, so I could stop hesitating and start handing my agents the access that makes them useful.

Repository: gitlab.com/nirmak-group/bridgr.