Comment by izend | Hacker News Reader

Comment by izend | Hacker News Reader

Parent Full thread

I am very curious how many MCP servers will actually implement all of this:

"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.

The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."

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...

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.

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".

Quite a few options as of now:

https://www.1password.dev/get-started/secure-ai-access#secur...

https://1password.com/blog/1password-trusted-access-layer-fo...

Still far from perfect tho.

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).

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.

> "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.

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.

Authorization for sub-entities is what is needed.

Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents.

Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role.

I am Jack's right ear - awesome you get to hear stuff.

I am jack's right hand - great you get to input stuff.

This. Especially when you have agents calling other agents. Just published an article about that yesterday: https://niyikiza.com/posts/agents-to-agents/

I am Jack's synaesthesia.

What people who care about security want -- finely grained permissions that guarantee security boundaries, at the expense of bad UX

What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible

Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible.

But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).

Yeah. If we want fine grained "intelligent" authorization, there's a lot of work to be done. You can't simply slap a gateway on existing systems.

I wrote about this more on my employer's blog[0].

> The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible.

And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly).

0: https://fusionauth.io/blog/ai-authorization

Hopefully quite a few.

I really love the idea of fully enabled agents and being able to cut down on human in the loop moments.

Things like https://projects.dev/ for example.

A ton of security problems and others to solve but it's still where I want the future of all this to go.

Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users.

And the individual work attached to making that transition will be done by agents.

agree. it seems there are two streams and they could diverge or converge?

1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.

2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?

It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client:

1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within

2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof

3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.

4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.

5. Clients generate fresh DPoP proofs and send them along with the access token

There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.

Are you reinventing SPIFFE here?

No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.

Such an example of overengineering, why not just use OAuth?

WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.

Any service offering MCP that doesn't already have OAuth set up is going to have to build out that support first, so instead they just go for a simple API token.

I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work.

An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.

Oauth assumes interactivity

No. Client assertion flow is for services (or agents).

Thanks, TIL. Will read up.

The dpop thing is oauth. It’s providing a significant enhancement to preventing token replay, or token theft, at the cost of some request size bloat + an additional key verification.

Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.

I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.

Reply on news.ycombinator.com