How attackers are turning OAuth grants into the new attack surface
| Ctrl+Alt+Del |
| Three issues from the past week that are shaping trust and security in AI. |
|
01
|
Identity Security
The permission is now the password
ShinyHunters did not steal credentials - it harvested permissions via voice phishing and OAuth consent. The resulting tokens persist after password changes and operate independently of MFA. Google's Salesforce instance exposed 2.55 million records; Allianz Life followed with 1.1 million.
TakeawayDefault-block OAuth grants for unreviewed third-party apps.
|
|
|
02
|
Data & Identity
Knowledge-based identity is no longer a secret
The National Public Data breach exposed approximately 2.7 billion records including SSNs. Asking a caller for their last four digits now verifies internet access, not identity.
TakeawayMove helpdesk verification to possession-based controls - hardware tokens or device-bound proof.
|
|
|
03
|
Architecture
Systems that require human perfection will fail
Toyota's 240GB GitHub misconfiguration required no sophisticated attacker - just one default set to public. Complexity without guardrails transfers risk to the most tired person in the chain.
TakeawayGovern data pipelines and developer endpoints, not only detection.
|
|
|
In Context
How the OAuth consent kill chain works
The ShinyHunters campaign deserves more than a breach notification. It is a precise demonstration of what happens when an enterprise's trust model has not kept pace with its integration architecture.
The mechanism works as follows.
1 |
Attacker calls an employee, establishes credibility as internal IT support. |
2 |
Directs them to a page requesting OAuth authorisation for a convincing Salesforce tool. |
3 |
Employee clicks "Allow" - conditioned by years of routine permission requests. |
4 |
Attacker receives a token, not a credential, authorising API-level access. |
5 |
Endpoint detection sees nothing. Firewall sees nothing. MFA is irrelevant. |
The failed control boundary is not within the security stack. It is part of the identity platform's default posture. A governance programme that does not include an active review of third-party OAuth grants - and a default-block posture for unreviewed integrations - has an open exposure it may not be measuring.
Long Read
Goes deeper on the mechanism, the architectural change required, and what a default-block posture looks like in practice across Salesforce, Microsoft 365, and Google Workspace.
Read the full piece →
|
|
Rearview
Events from this week that add colour to our themes.
Personal inboxes are now part of the corporate attack surface. Google's Threat Analysis Group documented APT42, an Iranian state-sponsored actor running targeted credential phishing against senior figures across US political campaigns. The mechanism is patience: the group inserts itself into existing conversational threads via personal email accounts. Corporate email controls do not extend to the personal Gmail of a C-suite executive, yet those accounts are routinely used for sensitive coordination.
Single-vendor AI dependency now carries regulatory risk. California's SB 1047 passed the State Senate, introducing developer liability for large AI models and mandating a full-shutdown capability. Organisations that have hard-coded production workflows to a single foundation model now carry regulatory disruption risk if that model's developer faces compliance action or mandatory shutdown.
| Applying AI |
| Learning from others, applying it to your context. |
| Who governs which AI tools your employees can connect? |
| If the answer is unclear, the Salesforce exposure likely applies. AI writing assistants, meeting summarisers, and workflow agents all require OAuth grants - often with broad scopes, often without IT visibility. Third-party AI grants need the same review cycle as privileged accounts, not the default-allow posture designed for productivity. |
|
| Does your helpdesk still verify identity with biographical data? |
| 2.7 billion records including SSNs are now searchable. Asking for the last four digits verifies internet access, not identity. Possession-based controls - hardware tokens or device-bound proof - are the only direction that still holds. |
|
| Could your organisation switch its primary AI provider in 30 days? |
| If the answer is no, SB 1047 is your signal. Hard-coded model API dependencies are now a regulatory and commercial risk. You may not need to switch providers - but you need to know you could. The time to build abstraction layers is before you need them. |
|
|
| Takeaways |
|
01
|
OAuth tokens persist beyond password resets and bypass MFA.
The permission layer needs the same rigour as the credential layer. Governance built around password hygiene has a structural gap at the consent grant.
|
|
02
|
Biographical data is no longer a reliable secret.
Verification processes built on knowledge-based questions are now confidence tests for attackers. Move to possession-based controls.
|
|
03
|
Single-configuration errors can expose hundreds of gigabytes.
Detection-only postures leave the root cause ungoverned. Govern data pipelines and developer endpoints - not only detection.
|
|
04
|
AI tooling has made shadow OAuth grants significantly harder to see.
Extend identity governance scope explicitly to include third-party AI application grants - same review cycle as privileged accounts.
|
|
Poll of the Week
MANUAL POLL PLACEHOLDER: Replace this block with the native Beehiiv poll.
Question: How does your organisation currently govern employee-initiated OAuth grants and third-party SaaS integrations?
All third-party app connections require IT approval before they can be authorised - default block is in place
We review high-risk permission scopes but standard productivity apps are generally permitted without a workflow
We rely primarily on security training and employee judgment
We have limited visibility into which third-party applications employees have granted access to
Opinion
❝
What strikes me about this week is not the sophistication of the attacks. What strikes me is that the defence still relies, at its critical moment, on an employee correctly assessing a permission request they were never trained to evaluate, while under social pressure from a caller pretending to be IT.
We have spent years hardening the password layer and the endpoint layer. The permission layer received the productivity design, not the security design. That is not a failure of individual employees. It is a failure of the architecture they were given to work inside.
The reasonable question for this week is not whether your employees clicked the wrong thing. It is whether the system would have caught them if they had.
I hope you found this useful. I’m looking to improve, so feedback is always welcome. If it shifted your thinking, the highest compliment is forwarding it to one person whose thinking it might shift, too.
Thanks for staying with me until the end,
Weekly Context is one part of an ongoing body of work at synoptikon.com on navigating AI and cyber resilience for digital trust.
