5 ms·

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along

by zackify 27d ago

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules. "Oh no it's a long lived token that's bad" Put it in a secret manager like 1pw cli and now start an agent...

danappelxx 27d ago
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 27d 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 26d 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".
filearts 27d ago
The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent. The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
mpyne 27d ago
That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.
bensyverson 26d ago
Yes, MCP was already overly complicated, and these new features will make it even more unapproachable. If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.
sofixa 26d ago
> "Oh no it's a long lived token that's bad" > Put it in a secret manager like 1pw cli and now start an agent... And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that"). Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.
- v0idw4lker 20d ago
  [flagged]

by zackify 27d ago

danappelxx 27d ago

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 27d 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 26d 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".

filearts 27d ago

The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent. The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).

mpyne 27d ago

That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.

bensyverson 26d ago

Yes, MCP was already overly complicated, and these new features will make it even more unapproachable. If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.

sofixa 26d ago

> "Oh no it's a long lived token that's bad" > Put it in a secret manager like 1pw cli and now start an agent... And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that"). Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.

v0idw4lker 20d ago
[flagged]