[GAME THEORY] The OAuth Prompt Is Becoming the New Diplomatic Pouch

The FBI warned in September that attackers have approached prominent people and their families or acquaintances with links to malicious apps. The target lands on a real provider consent screen and approves access. The attacker does not need the password: the app can keep calling the provider's APIs within the granted permissions, and a password change does not remove the grant. [1]

The call: For high-consequence accounts, treat third-party app consent as delegated authority, not a phishing choice left to one busy user. Deny unmanaged apps by default for that population; allow reviewed apps through a fast, accountable exception path. This is a governance recommendation, not evidence that the reported campaign is widespread across enterprises.

Fast scan

• What changes: The durable object is the permission grant. Resetting the password without removing it may leave the app's access intact. [1][3]
• Who makes the move: The attacker supplies the app and pretext; a user supplies consent; tenant policy and reviewers determine whether that approval can become authority.
• Where defenders have leverage: Move consequential consent decisions to a reviewable control plane, then test how long it takes to verify that an app has lost access.
• What remains uncertain: The public warning establishes prominent-person targeting, not a quantified enterprise prevalence or a named diplomatic campaign. The costs and efficacy of a protected-user default-deny policy depend on actual platform configuration and legitimate integration needs.

A user trying to open a shared file should not have to adjudicate the publisher's identity, requested scopes, and future API access in one click. That is an organizational decision disguised as a convenience screen. The prompt is the invitation; the grant is the souvenir.

One clean win this week: Pick one protected account and a workflow-adjacent assistant. Inventory their third-party app grants, owners, and scopes. If one looks wrong, can your team remove the grant and verify loss of access—not just reset the password?

Below the tear: how to set the boundary without trapping legitimate work, where an attacker moves after direct consent is blocked, and what to measure in a revocation drill.

Make delegation expensive for the attacker, workable for the user

The first policy choice is not whether every app is safe. It is which actor must do the work before an app receives lasting access: one hurried user, or an accountable reviewer with a record of the request.