DEV Community: 김형운

Mythos and the Defender Time That Vanished

김형운 — Tue, 28 Apr 2026 15:51:57 +0000

On April 7, 2026, Anthropic released Claude Mythos Preview into Project Glasswing, a limited-access program. Twelve launch partners — AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and Anthropic — got first access, with 40+ additional organizations behind them. No Korean firm appears on the list.

In Anthropic's own evaluations, Mythos autonomously found thousands of zero-day vulnerabilities across every major operating system and web browser, including a 27-year-old integer overflow in OpenBSD's TCP SACK implementation. It produced a working proof-of-concept on the first attempt 83.1% of the time. Anthropic called the model "too powerful to release publicly" and held it back from general availability.

Sixteen days later, on April 23, Korean CISOs gathered at the 2026 CISO Insight Forum. This piece reads the Forum for the structural shifts it surfaced, organized around the changes themselves rather than the speaking order.

1. Two things Mythos changed

Traditional vulnerability discovery had three steps. Discovery of a candidate flaw. Validation that it's real. Exploitation — building a working PoC. Each step needed different people, different tools, different context. The friction between them was the defender's grace period.

Mythos collapses all three into a single agentic loop. The published scaffold is minimal: an isolated container with no internet, the target source code inside, a one-paragraph prompt asking the model to find a security vulnerability. Then you let it run. The model reads code, hypothesizes, executes the program to confirm, drops into a debugger, and outputs a bug report with a working PoC.

Two things changed here.

One, the human time between discovery and exploit is gone. Time cost was tied to human salary and human learning curves. Defender patch windows were sized against that friction. Remove the friction and the patch SLA needs a new unit of measure.

Two, the cost floor for attacks collapsed. Anthropic's published numbers put 1,000 OpenBSD scans at under $20,000. For comparison: a 2025 enterprise penetration test runs $10K–$35K. So one pentest's budget covered 1,000 sweeps of a single major OS. Run the same math against every major open-source project and the picture writes itself. Risk models that assumed "attacks are expensive" need to be redrawn.

The same capability serves defenders, but almost no Korean CISO has access to a Mythos-grade tool. Capability arrives at attackers first and at defenders later. That asymmetry is policy, not technology.

2. Korean AI policies sit on top of Generation 1

Korean enterprises spent the last 18 months drafting AI usage policies that assume Generation 1 — the user asks, the model answers. "Review AI-generated content before sending." "Don't paste customer data into ChatGPT." Rules built on top of single-shot Q&A.

That isn't where AI is going. Generation 2 is agentic execution: the user states a goal, the model plans and acts. Vibe coding lives here. Generation 3 is multi-agent: a high-level objective, agents talking to other agents to produce results.

Generation 3 can't be governed by Generation 1 rules. By the time a human is in the loop, dozens of agent decisions have already happened. Auditing what an agent did becomes a forensic problem, not a real-time control problem. That requires agent activity logs at a granularity most organizations don't have. Korean enterprises included.

There's a trade-off. Companies that block Generation 3 lose the productivity race. Companies that adopt it without audit infrastructure lose the compliance race. There's no middle path without new tooling.

Vibe coding produces a parallel rule. Don't hand-edit AI-generated code. The moment you do, the agent's context breaks. The next agent edit lands on top of your edit and the code degrades faster. Push corrections back through the agent. That's a real shift in what code review means, and most security teams haven't internalized it yet.

3. The unit of attack surface has changed

Frontier models now process text, audio, video, documents, meeting recordings — all in a single pass. The change that creates is a change of unit.

Thinking about attack surface in units of "this codebase" or "this document" no longer holds. The new unit is everything that flows into a single model invocation, regardless of where that data physically sits. If it's in the same session, it's in the same exposure.

There's another trade-off here. Restrict context and you restrict your own analysts' capacity. Mythos-grade vulnerability discovery doesn't work without the model reading a full codebase in context. The same property creates the offensive risk and the defensive capability. The right move isn't input restriction, it's logged exposure with scoped controls — knowing which data went into which model call.

Shadow AI deepens this problem. SBOMs run on the assumption that you know what software is running inside the company. Shadow AI breaks that assumption a level deeper than shadow IT ever did. An employee uses ChatGPT or Claude through a personal account on a personal device, then pastes the output into work systems. The "tool" never touches the corporate network.

So the control point has to move. Not "what tools are employees allowed to use," but "what data are they allowed to handle". That's an HR and labor-policy problem before it's a technical one.

4. Board reporting is now a legal requirement, and translation doesn't carry the room

In 2026, Korean law moves board-level security reporting from "good practice" to "legally required." Three changes drive it. The Personal Information Protection Act now requires CPO appointment and dismissal to go through the board, and adds a board reporting obligation for privacy posture. The Information & Communications Network Act adds a parallel reporting obligation for information protection status. The Electronic Financial Supervisory Regulation is already in force — CISO must report to the board, not just the CEO.

Press will summarize this as "CISOs must now report to boards." True and uninteresting. The interesting question is why most CISOs will fail at this reporting.

CISOs typically prepare for a board session by translating technical material into accessible language. That doesn't work. Korean corporate boards are dominated by lawyers and business-school graduates. Sociotechnical risk language — CVEs, attack surfaces, MITRE ATT&CK matrices — doesn't land. The translation isn't bad. The attempt itself wastes the slot.

Start in business language. Boards want four data points.

One — risk in monetary terms. Not CVSS scores. The expected loss from an unpatched exposure if it becomes an incident.

Two — maturity against a recognized standard. NIST CSF, Zero Trust framework levels. "We're at level 2 of 4."

Three — compliance posture. PIPA, GDPR, Network Act — exposure to penalties under current and pending regulation.

Four — supply-chain risk. Most modern breaches enter through supply chain. Boards have started asking about it.

ISMS-P certification is the first thing Korean CISOs reach for to show the board "we're handling this." But ISMS-P was designed as an operational compliance standard, not a board communication tool. It shows whether you're patching things. It doesn't show whether your unpatched exposure is worth ₩100M or ₩10B in expected loss. The board needs the second number. ISMS-P doesn't produce it.

A quantitative risk model has to layer on top of ISMS-P, not replace it. Right direction, meaningful operational lift, and most Korean CISOs haven't started.

One more thing. Secure your allies before the formal board meeting. Pre-meetings with the CFO and one or two friendly outside directors aren't optional. The actual board session is the wrong place to surface a controversial finding. The right place is the prep meeting, where you can lose without losing publicly. Has nothing to do with security and everything to do with surviving as a CISO long enough to do the security work.

5. Disclosure, repurposed as competitive pressure

Korea's information protection disclosure regime makes four things public and audited: information protection investment, workforce composition, certifications held, security activities. Most CISOs skim this regime because it looks administrative. Mistake.

In 2024, the law added post-hoc verification authority — the regulator can now check what was disclosed. Before that, filings were essentially what companies wrote. Now they aren't.

Then in 2027, the exclusion thresholds disappear. Companies that had been below the cutoff start filing.

Once filings are public and compared year over year, competitive pressure replaces regulatory pressure as the primary driver. A peer in your sector with a higher security investment ratio shows up in a filing that customers and audit committees both read. Annually. Compared to last year's, and compared to peers.

That shifts the political center of gravity inside the company. Security budget stops being a fight for IT-spend share and becomes a question of where you sit on a public benchmark. The CISO suddenly holds a number the CFO has to defend externally. ISMS-P certification status sits in the public artifact. The certification stops being something you renew quietly every three years and becomes something the market reads.

6. Dynamic access control — externalizing tacit knowledge

The shifts above all push the same question at operators: what can you actually do today, without Mythos-grade tooling? The Forum's most operationally specific answer was dynamic access control.

Korean enterprise access controls have been binary. You have permission or you don't. Employees who need access to personal information get exception-permissions, and those exceptions stay open.

Revalidating those exceptions dynamically is the alternative. Examples: a privileged user accessing the same data through VPN gets masked output. If the VPN-source IP matches a less-trusted endpoint, that's another signal. If a DBA's badge-in record isn't in the system this morning, their DB access is suspended.

What makes this interesting is the choice of signals. Operational signals nobody else queries — badge-in records, IP reputation deltas, peer behavior baselines — get pulled into authorization decisions. Familiar territory in zero-trust literature, but the implementation cues are different.

There's a deeper point underneath. The "abnormal" in anomaly detection mostly lives as tacit knowledge in CISOs' heads. "User X is sketchy" is a judgment that doesn't sit in any system. The dynamic control project is about externalizing that tacit knowledge into systematic signals.

This is harder than it looks. The moment a rule is formalized, it becomes gameable. Anyone trying to evade just routes around it. But the direction is right. Without formalizing and systematizing the concept of "abnormal," dynamic control doesn't actually run.

The same principle applies to pre-launch security review. Business teams skip it. There's a limit to how much you can prevent that. When skipping happens, run a post-implementation review. Document the gaps. List them. Escalate to executives. Preserve the paper trail. Not a control that prevents the skip. A control that ensures responsibility lands in the right place when a skip turns into an incident. Honest, and operationally workable.

This is the operational answer to "AI defense requires AI." Pattern-based security tools were built around static signatures. Post-Mythos attacks are context-driven — they reason, they chain. The only thing fast enough to defend against context-driven attacks is something that reasons in context. That's an AI system. Which is why AI security teams need dedicated personnel — not a generalist who also covers AI, but a specialist whose job is the AI defense layer.

7. The asymmetry Korea is facing

One gap to close on.

Mythos exists. Glasswing exists. AWS, Microsoft, Google, NVIDIA, Palo Alto Networks have access. No Korean firm is on the list.

The implicit assumption running through every Forum discussion was that Korean CISOs need to prepare for AI-driven attacks. The honest framing is that Korean CISOs need to prepare for AI-driven attacks without access to AI-driven defense at the same tier. The asymmetry is structural. By the time Mythos-equivalent capability is commercially available in Korea, the same capability will have been adversarial for some time.

That's the conversation the Forum didn't have. Also the most important one. The threat model, the board reporting mandate, the disclosure regime, the dynamic controls — all correct, all important. None of them resolve the asymmetry.

Three directions might shrink it.

Domestic security AI tooling — built defensively, designed for Korean compliance and Korean-language constraints. There's a view that the government's foundation-model push lost some strategic urgency post-Mythos. There's a case for re-pointing the goal — from "sovereign model" to "defensive AI."

Open-source defensive tooling — the Linux Foundation sits in the Glasswing launch partner list, which matters. Korean CISOs should track these projects actively rather than wait for vendor productization.

Operational discipline that doesn't need Mythos-grade tooling — dynamic access control is the example. Achievable today with existing infrastructure plus better signal integration.

The CISO's job in 2026 isn't to wait for Mythos-grade defense to land in Korea. It's to do everything that doesn't require it, and to prepare the ground for absorbing it the moment it arrives. That's a shorter list than people think. The Forum's value was in mapping it.

nginx-ui's MCP endpoint shipped with 'empty allowlist equals allow-all' — and that's the story worth sitting with

김형운 — Mon, 27 Apr 2026 03:38:19 +0000

What happened

On 2026-03-15, the nginx-ui maintainers released version 2.3.4. The release fixed a missing authentication check on a single HTTP endpoint. That endpoint is /mcp_message, the delivery path for the Model Context Protocol integration the project had added to let AI tools manage nginx configurations.

The advisory describes the shape of the problem in one paragraph. "The nginx-ui MCP (Model Context Protocol) integration exposes two HTTP endpoints: /mcp and /mcp_message. While /mcp requires both IP whitelisting and authentication (AuthRequired() middleware), the /mcp_message endpoint only applies IP whitelisting — and the default IP whitelist is empty, which the middleware treats as 'allow all'."

The consequence, in the advisory's own words, is that "any network attacker can invoke all MCP tools without authentication, including restarting nginx, creating/modifying/deleting nginx configuration files, and triggering automatic config reloads — achieving complete nginx service takeover."

The CVE is CVE-2026-33032, CVSS 9.8, class: missing authentication. The finder is Yotam Perkal of Pluto Security, who published a technical writeup alongside the fix and codenamed the bug "MCPwn."

What is Confirmed vs Reported vs Claimed

Confirmed (primary source or NVD record):

The two endpoints, the middleware mismatch, and the "empty allowlist equals allow-all" default — all direct from the maintainers' advisory.
CVSS 9.8. Missing-authentication class.
Fix released in version 2.3.4 on 2026-03-15.
Workarounds: add middleware.AuthRequired() to /mcp_message, or change the IP allowlist default to deny-all.

Reported (multiple independent secondary outlets — The Hacker News, Security Affairs, Rapid7):

Exploitation in the wild since March 2026, per Recorded Future's 2026-04-13 report cited by Rapid7.
Chaining with CVE-2026-27944 (CVSS 9.8, an unauthenticated information-leak on /api/backup that exposes the node_secret required to open a session on /mcp). Fixed in 2.3.3.
Approximately 2,600 publicly reachable nginx-ui instances per Pluto Security's scan, ~2,689 per Shodan data cited by The Hacker News, with most located in China, the U.S., Indonesia, Germany, and Hong Kong. These are exposure counts, not compromise counts.
Affected-version reporting is inconsistent across advisories: the finder's blog lists ≤ 2.3.3 as vulnerable; the NVD record lists ≤ 2.3.5. Rapid7 recommends updating to 2.3.6 to avoid the ambiguity.

Claimed (single-source, explicitly attributed):

Perkal's structural explanation: "When you bolt MCP onto an existing application, the MCP endpoints inherit the application's full capabilities but not necessarily its security controls. The result is a backdoor that bypasses every authentication mechanism the application was carefully built with." This is his quote, and we cite it as his.

The chain, step by step

Only the hops the sources actually describe.

Step 1 — Leak the node_secret. The attacker issues an unauthenticated request to /api/backup. On nginx-ui versions before 2.3.3, that endpoint returns enough information to recover the node_secret value, the query parameter that authenticates the MCP interface. This step is CVE-2026-27944, reported by The Hacker News and Rapid7 as being chained in active exploitation.

Step 2 — Open the MCP session. The attacker issues GET /mcp?node_secret=xxx to establish a server-sent-events session and receive a sessionId. The advisory confirms this endpoint is protected by both IP allowlist and AuthRequired(). The node_secret obtained in step 1 satisfies the auth side; the empty-allowlist default satisfies the network side.

Step 3 — Invoke tools on /mcp_message. The attacker issues POST /mcp_message?sessionId=xxx carrying the tool-invocation payload. No node_secret, no JWT, no cookies. Because /mcp_message is only gated by the same empty allowlist, the request is accepted. Per the advisory, the invocable tools include restarting nginx, creating / modifying / deleting configuration files, and triggering automatic reloads.

Two HTTP requests in total, if the attacker already holds the node_secret. Three, if they also have to chain the backup leak.

The broken assumption

The design intent reads well. Two endpoints, both behind AuthRequired() in intent, both behind an IP allowlist. Defense in depth. What shipped was different.

Two separate assumptions failed together.

The first failed assumption is that every privileged endpoint in a family would be wired to the same authentication middleware. /mcp was. /mcp_message was not. One line of code separated "authenticated" from "unauthenticated," and that line was absent for the endpoint that carried the write operations. Security Affairs notes that the 2.3.4 fix added that missing line and a regression test so the same kind of omission cannot silently recur.

The second failed assumption is that the IP allowlist would be meaningful at runtime. The allowlist's default was empty. The middleware treated empty as allow-all. So the network control that was supposed to sit beneath the authentication control sat at zero as well. Two defenses, both disabled at their defaults, on the same endpoint.

Neither assumption is unique to this project. Both describe the general shape of what happens when MCP — a protocol whose value is that AI tools can drive application internals — is added to an application that already has authentication, but whose authentication is wired by convention rather than by a single enforcement point.

Perkal states the structural version of this directly: "the MCP endpoints inherit the application's full capabilities but not necessarily its security controls." Treat that as his claim, not ours. But the class of failure matches what the advisory says happened here.

Why detection gets harder

The exposed surface is a management UI that normally sits in an internal or administrative network. The exploit uses two HTTP requests that look, on the wire, like the product's own MCP traffic. There is no malware signature. There is no credential stuffing pattern. A defender watching authentication logs sees a successful session. A defender watching network logs sees traffic to the product's own ports.

The only reliable detection signal is the one the application itself would have to produce: "this /mcp_message invocation was served without a verified identity." On a vulnerable version, that signal does not exist, because the endpoint does not check for identity. Detection has to shift to the outside — to whether the /mcp_message endpoint is reachable from the network at all, and whether the config-change events it produces are consistent with the change-management trail your operators expect.

What to check this week

Operational, in priority order.

Inventory nginx-ui deployments. Run an internal scan for port 9000 and any known nginx-ui hostnames. The Shodan-derived public-surface count is ~2,600; your internal surface is typically larger.
Patch status. If any instance is at 2.3.3 or earlier, the /api/backup information leak (CVE-2026-27944) is usable to harvest the node_secret. If any instance is at 2.3.4 or earlier per the NVD record's stated coverage (≤ 2.3.5), treat it as exposed to CVE-2026-33032. Rapid7's guidance to go straight to 2.3.6 is the cleanest way to eliminate the version-number ambiguity.
Exposure cutoff. Confirm the management interface is not reachable from any network segment that carries untrusted users. If the workaround path is the only option, change the IP allowlist default from empty to an explicit deny-all, and add middleware.AuthRequired() to /mcp_message per the advisory.
Change audit on managed nginx configs. Compare the on-disk nginx config files against the last known-good revision. An attacker who succeeded would leave their signal there, not in the UI logs. Pay attention to any additions that introduce new proxy_pass targets, new upstream blocks, or new log_format definitions that could capture credentials.

What to change in policy

One policy change has high leverage.

Treat any MCP endpoint as privileged by default — at the same tier as an admin RPC — regardless of what the rest of the application looks like. In this case, the nginx-ui codebase already had AuthRequired(). The bug was that not every MCP endpoint was behind it. The preventive rule is to require, as a code-review gate, that every route registered by the MCP integration passes through a single enforcement point, and that a regression test fails the build if a new route skips it. Security Affairs reports this is exactly what the 2.3.4 release added.

Two secondary rules follow from the same posture.

First, "empty allowlist equals allow-all" is a footgun that only makes sense in development. In production it is an outage waiting to happen. Allowlists should fail closed. A configuration loader that sees an empty list should refuse to start, not accept everything.

Second, when a project adds MCP — or any AI-integration surface that exposes the application's capabilities as callable tools — the threat model should be re-run specifically for that surface, not inherited from the rest of the app. Capability exposure is the part of MCP that is new. Authentication is the part that is assumed.

What this does NOT say

This post does not name any organization as an exploited victim. No source does.
It does not count compromised instances. The ~2,600 figure is exposed surface per a Pluto Security scan, not a tally of successful exploits.
It does not attribute the in-the-wild exploitation to a threat group. None was named.
It does not claim the allow-all default was an intentional design choice or an implementation bug. The advisory does not say which, and neither does this post.
It does not generalize from this CVE to claims about MCP as a protocol. The specific failure here is an application-level mis-wiring that happens to be on MCP endpoints. The broader pattern Perkal describes — bolting MCP onto an existing app — is his statement, and we leave it as his.

Sources

Primary: nginx-ui maintainers' advisory (release 2.3.4, 2026-03-15); Pluto Security technical blog (Yotam Perkal, 2026-03-15); NVD CVE-2026-33032.
Secondary: Rapid7 Emerging Threat Response (2026-04-16, updated 2026-04-17); The Hacker News (2026-04-15); Security Affairs (2026-04-15); Cyber Security Agency of Singapore alert AL-2026-039.

The Vercel/Context.ai Breach Wasn't a Vulnerability. It Was a Delegation Path.

김형운 — Wed, 22 Apr 2026 07:33:37 +0000

On April 19, 2026, Vercel disclosed an incident involving one of its employee accounts. The confirmed chain was not a zero-day and not a cloud misconfiguration. It was a chain of delegated trust. A Lumma stealer log harvested from a Context.ai contractor's laptop yielded Context.ai's own Google Workspace OAuth credentials. Those credentials gave the attacker a working access token for a Vercel employee's Google account — the employee had previously authorized Context.ai on it. That Google account, in turn, held Vercel dashboard notifications in its inbox, which the attacker used to reach internal project environment variables.

No CVE was exploited. No MFA was broken. No conditional access policy was bypassed in the traditional sense. Every step rode on a permission the user had already granted, months or years earlier, to a third-party AI tool.

That is the pattern worth studying. This post walks through it slowly.

What is Confirmed, and What is Not

Confirmed by Vercel's own security advisory: one employee account was accessed; the initial vector was an OAuth application owned by Context.ai, an AI meeting-notes tool the employee had connected to their Google Workspace account; certain internal project metadata was visible to the attacker.

Reported by multiple security outlets (BleepingComputer, The Record, Recorded Future News): the upstream credential leak originated in a Lumma stealer infection on a Context.ai contractor's laptop two weeks prior; Context.ai's OAuth client secret was among the harvested material; the same OAuth app was used to pivot into downstream customers.

Claimed by the attacker on a leak forum: possession of environment variables from "hundreds" of Vercel projects. Vercel has not confirmed this number. Treat it as claimed until an independent source verifies it.

Everything that follows reasons from the confirmed portion only.

The Chain, One Hop at a Time

Step 1. The contractor laptop. A Context.ai contractor's Windows machine was infected with Lumma, a commodity infostealer that scrapes browser credential stores, session cookies, and developer tokens. In the harvested dump were Context.ai's own OAuth application credentials — the client ID and client secret that Context.ai uses to talk to Google on behalf of its customers.

Step 2. The OAuth app itself. Context.ai is a Google Workspace Marketplace app. When a customer installs it, they grant it a durable set of scopes — typically Calendar read, Gmail read, Drive read. Those grants live on Google's side as refresh tokens issued to Context.ai's client ID. An attacker holding Context.ai's client credentials could, under certain configurations, ride those refresh tokens against any customer who had installed the app.

Step 3. The Vercel employee's Google account. This employee had Context.ai authorized on their personal-domain Google account. The attacker used the stolen OAuth credentials to obtain a live access token for this account without ever touching the user's password, without triggering a new MFA prompt, and without hitting any conditional access policy that guards interactive sign-in. From Google's logs this looked like Context.ai doing what Context.ai always does: reading calendar, reading mail.

Step 4. The pivot into Vercel. The attacker read the employee's inbox. In it were Vercel dashboard notification emails, a password-reset link issued during an unrelated earlier event, and email-based 2FA codes for a separate internal tool. The attacker used a subset of this material to authenticate to the Vercel dashboard as the employee and browse project settings, including environment variables.

Every hop was a legitimate use of a previously granted permission. Nothing in the chain required a new vulnerability.

The Assumption That Broke

The control model most teams run today assumes that the identity provider is the chokepoint. Sign-in goes through Okta or Entra. MFA is enforced there. Conditional access policies check device posture there. Audit logs flow from there. If an attacker wants to reach an internal resource, they have to get through the IDP.

OAuth delegation bypasses this chokepoint by design. Once a user has clicked "Allow" on an OAuth consent screen, the third-party app holds a durable credential that does not pass through the IDP on subsequent use. The app can call the API directly with its refresh token. The IDP sees nothing, because the IDP is not in the call path.

That is the assumption that broke here. The organization's IDP-centered control plane does not cover permissions the user delegated to AI SaaS vendors. Those permissions live on Google's side, or Microsoft's side, as grants the user can make without any security team ever reviewing them.

Put concretely: your Okta admin console will not show you that an employee connected Context.ai to their Google Workspace account last month. Your SIEM will not alert when a stolen Context.ai token reads that employee's inbox, because from Google's perspective the token is being used by the application it was issued to. It is only unusual if you are watching the right signal — and most teams are not watching the OAuth signal at all.

Why Detection Gets Harder

Detecting this kind of abuse is harder than detecting a credential-stuffing attack for three reasons.

First, the traffic looks legitimate at the API level. The OAuth token is valid. The client ID matches a known, approved application. The scopes match what the user originally granted. No anomaly detector keyed on authentication events will fire, because no authentication event happened — the app used a refresh token it already held.

Second, the source IP will often look fine. Attackers using stolen OAuth credentials can route calls through residential proxies or even through the vendor's own infrastructure, depending on how they extracted the credentials. "Unusual location" signals that work for human sign-in do not transfer cleanly to machine-to-machine API calls.

Third, the volume is low. The attacker does not need to read 10,000 inboxes. They need to read one, find the right thread, and pivot. A single extra API call buried in a day of normal Context.ai activity will not stand out in a log line count.

The detection has to shift from "Did someone sign in weirdly?" to "Is this OAuth grant still justified, and did its usage pattern change?"

What to Check This Week

Four checks are worth running regardless of whether you use any of the specific products involved.

First, enumerate your OAuth grant inventory. In Google Workspace: Admin Console → Security → API controls → Manage Third-Party App Access. In Entra ID: Enterprise applications → filter by "Microsoft Graph" and "Application permissions." You are looking for every third-party app that can read mail, read calendar, read files, or write anywhere. For each one, answer: who approved this, when, and for which scopes?

Second, find the AI tools specifically. Meeting-note apps, email assistants, "summary" integrations, code-review bots connected to GitHub, and anything marketed as an "AI agent" that talks to your data. Any of these that holds a broad scope (gmail.readonly, calendar.events.readonly, drive.readonly) is a pivot candidate if the vendor is breached.

Third, look at the usage side. In Google Workspace logs, filter for OAuth token use by third-party client IDs over the last 90 days. In Entra, use sign-in logs filtered by "service principal sign-ins." Baselines matter here — if an app that normally reads 50 calendar events a day suddenly reads 5,000, that is your signal.

Fourth, if you are on Vercel specifically, mark your secret-class environment variables as "Sensitive" in project settings. This is an opt-in flag that prevents the dashboard from displaying the value in the UI after save. It does not change what the running deployment can see, but it does mean that an attacker browsing the dashboard with a stolen session cannot just read the values. As of today, this flag is off by default. That default is the right thing to argue with your platform team about.

What to Change in Policy

Two policy shifts follow from this case. Neither is novel, but both are easier to argue for now than they were last week.

First, stop treating OAuth consent as a user decision. Most organizations let end users install Workspace Marketplace apps or authorize Entra OAuth applications without any review. That worked when third-party apps were calendars and to-do lists. It does not work when "third-party app" means "an AI product that reads your entire inbox and calendar and summarizes them to an LLM provider." Move OAuth consent behind an admin allowlist. Google and Microsoft both support this. The cost is friction. The benefit is that your security team sees every new delegation path before it becomes a pivot route.

Second, treat the IDP as necessary but insufficient. Your IDP enforces sign-in. It does not enforce what the user has delegated. Build a second layer of control for delegated scopes: regular review of the OAuth inventory, alerting on new high-scope grants, and rotation / revocation procedures that assume a vendor breach is a recurring event, not a rare one.

The larger shift is uncomfortable. An employee connecting an AI meeting-notes tool to their calendar is not, from the user's perspective, a security event. It is a productivity decision made in 30 seconds on a vendor's marketing page. The organization now has to insert itself into that 30-second window. There is no clean way to do that without slowing some of those decisions down.

What This Does Not Say

This post is not a takedown of Context.ai. The same pattern could have run through any AI vendor with similar OAuth scopes. If you remove Context.ai from the chain, the structural problem — broad delegation, no IDP visibility, the vendor as a credential concentrator — is still there.

This post is also not a claim that OAuth is broken. OAuth is doing exactly what it was designed to do. The design assumes the delegated party is trustworthy. When the delegated party is a rapidly growing AI SaaS vendor running on commodity contractor laptops, that assumption deserves a harder look than it is currently getting.

The specific remediation Vercel chose — rotating the affected employee's credentials, revoking the Context.ai grant, and reviewing environment variable exposure — is the minimum. The broader remediation is inventory and policy. The former you can do this week. The latter is a quarter of work, and it is overdue.

If you are running SIEM queries or want the concrete OAuth audit steps for Google Workspace and Entra, reply in the comments and I will put the queries in a follow-up post.