The credential boundary: how should an AI agent use a login without holding it?

In my work with AI agents, I've found that the most challenging issue isn't the model's performance, but rather handling credentials. The problem arises when the agent needs to log into a service to complete a task. Simply copying a password into the conversation poses risks, as the password ends up in the transcript and the model's context, without any protection or ability to revoke it later.

Here, I'll discuss the design principles I've developed to address this issue, and how I'm implementing them in AgentKey, the credential vault I'm creating.

Firstly, we should maintain a clear distinction between the secret and the model. The secret and the model should be on opposite sides of a boundary, and only a narrow execution layer may cross it after explicit approval from the owner. Relying on the model to refrain from misusing a secret it can see is not a secure boundary; it's merely a policy hope.

Secondly, the human's role should be limited to a single decision. Every additional step between the agent asking for the login and the human approving pushes people towards pasting secrets into the chat. The approval process should be as simple as one tap, in the same place the human is already located. In AgentKey, this is achieved through a request link.

The agent sends a link, the owner opens it on their phone, and approves. Once approved, the owner has ongoing access to that login until it's revoked. The link can be invalidated, but the approval shouldn't silently expire based on an arbitrary timer that the owner didn't set.

Thirdly, each grant should be scoped per agent and per credential, with detailed records. A grant shouldn't be "the agent may use my accounts." Instead, it should specify the exact login or an all-access permission, tailored for each agent. Revocation should be a single switch, and the revoked access should be moved to an archive where the owner can restore it if needed.

All requests and approvals should be recorded in an activity view. If the owner can't quickly answer "who can use this password right now?" with a glance, the model is doing something wrong.

Fourthly, agents should be treated as contacts, not infrastructure. Connecting an agent should feel like adding a contact, similar to how we add people. Agents integrated into other apps should connect through standard OAuth consent as custom connectors. Claude and ChatGPT both support this with a name and a URL. The connector's vocabulary is request links and statuses, and it never carries secrets.

Lastly, the execution layer should be a separate, narrow component. The approval indicates "may you," but the actual login process is a different job. The principle of separation applies here: a dedicated executor, a sandboxed browser session, is the only component meant to handle the plaintext. While the agent works with a scrubbed view of the page, using labels instead of values.

An AI in this loop reads the login page, rather than maintaining separate adapters for each site. This approach makes a credential vault that only works with a compatibility list less than ideal, as it's not a vault, but rather a collection of plugins.