3 ms·

In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their da

In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department. Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem. There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...

amluto 4mo ago
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 4mo ago
  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 4mo ago
    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.
    - iugtmkbdfil834 4mo ago
      << 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.'
    - deleted 4mo ago
      [deleted]
    - niyikiza 4mo ago
      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 https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
      - amluto 4mo ago
        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 4mo ago

amluto 4mo ago

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 4mo ago
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 4mo ago
  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.
  - iugtmkbdfil834 4mo ago
    << 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.'
  - deleted 4mo ago
    [deleted]
  - niyikiza 4mo ago
    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 https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
    - amluto 4mo ago
      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 4mo ago