How your agent uses a login it never sees

The claim that your agent can use your accounts without holding your passwords sounds like a trick. It is not. It is just a matter of where the secret lives and who touches it. Here is one request, start to finish.

Say your agent builds a morning brief, and part of that is today’s calendar.

The request

Your agent is connected to the broker over MCP. It does not ask for your Google password. It asks the broker for an action: get today’s calendar events. That is the whole request. No credential goes across that connection, in either direction.

What the broker does

The broker runs on your device. It opens your vault, reads the Google token you connected earlier, and makes the API call itself. Google answers with the full event payload, which usually carries far more than the task needs. The broker filters that down to the fields the brief asked for, the event titles and times, and returns only those to the agent.

The token never leaves the broker. It is not in the request, the response, an error message, a log line, or the audit log. The agent sees event titles and times, and nothing else.

Three kinds of connection

Not every account works the same way, so there are three shapes.

A session connection is a website you sign in to. The broker logs in for your agent and acts inside that session.

An API connection is a service with OAuth or a token, like Google or GitHub. Responses are filtered to the fields the task needs before the agent sees them.

A custom connection is any other API you want to wire up yourself.

The log you can actually read

Every action the broker takes lands in an append-only audit log on your device. One line per call: the time, the agent, the action, the result. You can see that the brief read your calendar at 7:00 and the weather a second later. What you will not find anywhere in it is the secret that made the call work.

That is the shape of the whole system. The agent gets results. You keep the keys.