Some Thoughts Pat Opet's open letter
“The game is the same, just got more fierce” -Slim Charles
My wife is an artist, and her mantra making sculptures is - "no tears when you are making it, no tears when others see your sculptures."
Pat Opet's "Open Letter to third party suppliers"[1] is written by someone who clearly has seen the scars left by poor quality third party software. He points out this is a time for realizing there are more tears ahead for the industry.
You might think tech is always moving forward, and innovation automatically drives higher quality. But this is not so. SaaS security is getting worse not better.
Pat Opet’s call to action cites the specific example of the failure of identity protocols to deliver what SaaS security needs, effectively making the problem worse:
"Modern integration patterns, however, dismantle these essential boundaries, relying heavily on modern identity protocols (e.g., OAuth) to create direct, often unchecked interactions between third-party services and firms’ sensitive internal resources. As a generic example, an AI-driven calendar optimization service integrating directly into corporate email systems through "read only roles" and "authentication tokens" can no doubt boost productivity when functioning correctly. Yet, if compromised, this direct integration grants attackers unprecedented access to confidential data and critical internal communications."
One driver here is the landgrab for vendors chasing features and prioritizing them over security. I will go one step further, the security industry has not delivered solutions that fit well for SaaS solutions.
There is nothing hotter these days than MCP, but when it comes to the most basic discussions on how to build access control policies and mechanisms, the answer is - “let's use OAuth”. OAuth is fine...for the problems it actually solves...as I wrote last week:
“Let's start with identity protocols generally, they do not "solve" access control, instead the identity protocols give a way to transform an access decision (i.e. delegation) and move it around in a networked system. Since MCP provides a new integration layer for LLMs and agents, it is reasonable to expect that unexpected linkages will occur due to the combination of multiple integration layers plugged together over MCP resulting in over-permissioned access to data because OAuth permissions are not by default tuned to the new target environment.”
In other words, the approach to the shiniest, brightest tech innovation lacks even the most basic security controls.
OAuth can certainly ferry information about an identity across MCP, but the overall security profile will depend on initial authentication, client SDKs, authorization mapping, proxy/delegation/impersonation, and so on - these are all left a open policy zones as problems for implementers to solve.
A fair question is - should MCP even do this? Is this gap something that a transport (which is designed to be open and pluggable) and also need to solve an identity layer problem? It is a problem for sure, but am not sure that this is a MCP problem as much as it is a problem in an over-reliance on OAuth where the security industry is over-leveraged to security protocols that only deliver a small piece of a solution. This can end fine if implementers handle the upstream and downstream concerns, but that is a lot of design and engineering responsibility for an entire industry to solve.
MCP is just one case study. A lot of SaaS was built when the security environment was more benign than it is now. The assumptions that system builders made that identity protocols like OAuth could deliver a safe computing base do not hold up in the face of developments like Infostealing malware.
To sum up, great credit to Pat Opet for raising such an important discussion, this is all the more useful coming from a JPMC megaphone. It would be nice if other large buyers would follow his example. Make security architecture mean something, not a "secure by design" paper tiger, but driving security design improvements towards meaningful change in the software we all depend on.
https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers