5 ms·

How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll

How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards. Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.

blazarquasar 26d ago
Quite a few options as of now: https://www.1password.dev/get-started/secure-ai-access#secure-mcp-server-config-files https://www.1password.dev/get-started/secure-ai-access#secur... https://1password.com/blog/1password-trusted-access-layer-for-openai-codex https://1password.com/blog/1password-trusted-access-layer-fo... Still far from perfect tho.
elenaviter 25d ago
There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run. Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting. The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card. So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".

blazarquasar 26d ago

Quite a few options as of now: https://www.1password.dev/get-started/secure-ai-access#secure-mcp-server-config-files https://www.1password.dev/get-started/secure-ai-access#secur... https://1password.com/blog/1password-trusted-access-layer-for-openai-codex https://1password.com/blog/1password-trusted-access-layer-fo... Still far from perfect tho.

elenaviter 25d ago

There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run. Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting. The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card. So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".