Technology
The credential boundary: how should an AI agent use a login without holding it?
Source: Dev Community|
3 min read
I work with AI agents every day, and the hardest problem I've run into isn't model quality. It's credentials. The agent needs to log in to something to finish the job, and the default answer is pasting a password into chat: the secret ends up in a transcript and a model's context, unscoped and unrevocable in practice. This post is about the design principles I've landed on for solving that, and how I'm applying them in AgentKey, the agent credential vault I'm building. I want feedback on the principles more than the product. Principle 1: structural separation, not behavioral trust The model should never need to hold the plaintext credential. Not "we trust it not to look" and not "we redact afterwards." The secret and the model live on different sides of a boundary, and only a narrow execution layer may cross it, after explicit owner approval. If your design relies on the model choosing not to misuse a secret it can see, you don't have a security boundary; you have a policy hope. Principle 2: the human's job is one decision Every extra step between "agent asks" and "human approves" pushes people back to pasting secrets into chat. The approval has to be one tap, in the place the human already is. In AgentKey that's a request link: the agent sends a link, the owner opens it, approves on the phone, done. Approving once grants ongoing use of that login until revoked. The link can lapse; the approval shouldn't silently expire on a timer the owner never set. Principle 3: scope per agent, per credential, with receipts A grant is never "the agent may use my accounts." It's per login, or explicitly all-access, per agent. Revocation is a single switch, and revoked access goes to an archive the owner can restore. Requests and approvals are recorded in an activity view. If the owner can't answer "who can use this password right now?" in one glance, the model is wrong. Principle 4: agents are contacts, not infrastructure If connecting an agent feels like provisioning, the workaround wins. In AgentKey, agents are contacts you add like people. Agents that live inside other apps connect through standard OAuth consent as custom connectors; Claude and ChatGPT both support that with a name and a URL. The connector's vocabulary is request links and statuses. It never carries secrets. Principle 5: execution is a separate, narrow layer Approval says "may you." Performing the login is a different job. The principle that follows is separation: one dedicated executor - a sandboxed browser session - is the only component meant to touch the plaintext, while the agent works against a scrubbed view of the page, labels rather than values. An AI in that loop reads the login page instead of hand-maintained per-site adapters, because a credential vault that only works on a compatibility list isn't a vault, it's a plugin collection. Worth comparing notes If you're working on agent identity or permissions, I'd genuinely like to compare notes - for example on where task scoping should live (in the grant or in the executor), how agents should prove which task a credential use belongs to, and what audit format actually works for a human who checks receipts twice a year. Site: https://agentkey.waiwiser.com