A month after the April 20 OAuth "Allow All" compromise reached Vercel through a third-party AI tool, no customer of Vercel has published an architecture-change document, which is precisely the missing receipt the paper's Monday brief on Vercel making OAuth a customer-architecture problem said was needed.

The vendor-side write-ups exist and are good. Cybernews documented the OAuth path itself [1], and Kiteworks reframed the incident as a buyer's architecture problem rather than a vendor sympathy story, arguing that OAuth apps must be treated as identity infrastructure rather than productivity software. [2] What has not appeared is the corresponding artifact from the buyer side: a Vercel customer publishing the inventory of OAuth grants it rotated, the environment variables it reclassified as sensitive, the identity-provider audit trail it tightened, or the AI tools it now treats as identity infrastructure rather than productivity software.

The absence is significant for two reasons. First, customer write-ups are how the industry learns. A vendor bulletin tells a single team what happened; a customer architecture document tells the rest of the market what to redesign. Second, the AI-tool class that produced this incident has only grown since April. Every additional integration adds more OAuth scope, more trusted identity-provider channels, and more environment variables that someone will later wish had been labeled sensitive.

The paper's question is therefore the same as last week, on a longer clock. Which Vercel customer publishes the architecture change first, and how much of the OAuth-trust map do they rewrite before the next incident reaches them through the same shape of integration?

Until that document arrives, the breach was Vercel's and the architecture lesson is still unwritten.

-- DAVID CHEN, Beijing