[amluto]

This is bonkers.

Sure, if I’m a business, I will make a business decision to share, or not share, some resource with ChatGPT. But, if I do decide to share something with ChatGPT, I absolutely do NOT want it shared with every single ChatGPT thread, more or less how I don’t want it shared with every single tab an employee has open in a browser.

[qt31415926]

Isn't that what's solved by this method? Your SSO provider (e.g. Okta) is now what gates each employee's resource access for different MCP resources.

[amluto]

I don't think so.

The article is all about reducing friction. Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps "Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such." That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted!

Now I realize it's silly for the prompt to look like "Would you like to grant [OpenAI/Anthropic/whatever] access to such-and-such account with such-and-such OAuth resources?", but having some kind of explicit opt-in, per conversation, to MCP access seems really quite important. But the article all about reducing friction and avoiding prompts.

So maybe LLM providers will do a good job, but I'm not holding my breath.

[hobofan]

Just to be clear, enforcing proper access control and data seperation is the job of a client (/harness), not the job of an LLM Provider (though of course the most popular clients are the first party clients for the LLM providers).

Ensuring that an LLM doesn't have free reign over calling any MCP tool at any point in time is one of the main jobs of a client (apart from the general data persistence, etc.), and one that's very dependent on the setup (e.g. many MCP servers expose public data where tool calling is mostly not that sensitive) and the acceptable risk profile.

This MCP extension also doesn't significantly change anything about tool calling control from the perspective of the client. MCP servers were previously also authenticated once per user, and not once per conversation or once per tool call.

[niyikiza]

There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.) [1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

[amluto]

I skimmed that. It seems to me:

(a) A major problem where one agent can give dangerous instructions to another.

(b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)?

(c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation.

ISTM:

- (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner.

- (b) could be addressed by a capability or proxy system.

- Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting.

- Why would one ever want to give a bearer token to an “agent”?

- Wouldn’t a proxy serve this purpose more flexibly and more universally?

[niyikiza]

I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.

The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.

Full draft's here if you want to pick it apart: https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...

[iugtmkbdfil834]

<< The article is all about reducing friction.

I read the initial paragraph from the page and I had similar reaction with an additional touch of:

'There is a purpose for that friction.'

[sandeepkd]

The key here is the separation of target segment for this. Enterprise identities (you being an employee) are the target for this not the consumer identity (personal account). When you are an employee then the sensitivity and security of your account can be managed by your employer.

Other way to look it is that as an employee you will not be able to connect to any MCP server anymore unless its configured in your IDP.