7 ms·
From the blog post: "The Auth problem At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth
by mehdibl 1y ago
From the blog post:
"The Auth problem
At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth for agents that act on behalf of the user. This is a good long term goal, but we are quickly realizing that LLM sessions with no distinguishable credentials of their own are difficult to authorize and will require a complete re-imagining of our authorization systems. Data leakage in multi-tenant apps that have MCP servers is just not a solved problem yet.
I think a very strong case for MCP is to limit the amount of damage the model can do and the amount of data it will ever have access to. The nice thing about client side APIs in multi-tenant apps is they are hopefully already scoped to the user. If we just give the model access to that, there's not much damage they can do.
It's also worth mentioning that OAuth2.1 is basically incompatible with internal Auth at Amazon (where I work). I won't go to much into this, but the implications of this reach beyond Amazon internal."
1. Oauth is not working in Amazon ==> need solution.
2. Oauth are difficult to authorize
3. limit the amount of damage the model can do WHILE "ulti-tenant apps is they are hopefully already scoped to the user".
I feel from a security side there is an issue here in this logic.
Oauth for apps can be far more tuned than current web user permission as usually, user have modification permission, that you may not want to provide.
Oauth not implemented in Amazon, is not really an issue.
Also this means you backdoor the App with another APP you establish trust with it. ==> This is a major no go for security as all actions on MCP app will be logged in the same scope as USER access.
You might just copy your session ID/ Cookie and do the same with an MCP.
I may be wrong the idea seem intersting but from a security side, I feel it's a bypass that will have a lot of issues with compliance.
- miguelspizza 1y agoNot sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner
- tehryanx 1y agoI think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.
- owebmaster 1y ago> The agent should be treated as an untrusted user in your client, An untrusted user in a client is a hacker/invasor, not an agent.
- tehryanx 1y agoan untrusted, but permitted, user is why sandboxes exist. There are plenty of times you want to allow an untrusted user to have capabilities in a system, that's why you restrict those capabilities.
- owebmaster 1y agoa sandboxed user is not an untrusted user of the client but an unstrusted user of the host, that is why the client is sandboxed.
- tehryanx 1y agosandboxing is a general term for actor isolation, and its context agnostic. For example, when you use the sandbox attribute on an iframe in a web application, it's not the user that's untrusted, it's some other user that's attempting to trigger actions in your client.
- miguelspizza 1y agoI've thought more about this and I think the only way to make completely sure that sensitive data does not get leaked is by making sure it never makes it into the models context in the first place. The issue is even if the MCP-B extension makes it so the user has to give confirmation when the agent want's to call a tool on a new domain after interacting with another domain, there is no clear way to determine if a website is malicious or not. A solution to this might be to give server owners the ability to write the restricted data to extension storage on tool response instead of returning it to the models context. Instead, a reference to this location in extension storage get's passed to the model. The model then has the ability to "paste" this value into other website via tool call without ever actually seeing the value itself. That way, MCP-B can put lots of warnings and popups when this value is requested to be shared. Any thoughts?
- ImPostingOnHN 1y agoWhen you say "the user", do you mean that if Alice set up the MCP, and Bob, Charlie, and Dave all access it, the MCP will only execute commands as Bob, or Charlie, or Dave, depending on who is accessing it?
- arkh 1y agoWait, isn't it already part of Oauth? > https://datatracker.ietf.org/doc/html/rfc8693#name-delegation-vs-impersonation https://datatracker.ietf.org/doc/html/rfc8693#name-delegatio...