Notifications
Clear all
Topic starter
27/06/2026 1:05 pm
TL;DR: Attackers used OpenAI organization invitations to impersonate Push Security, target named employees, and create a trusted channel for possible prompt and data exposure, according to Push Security. The case shows that legitimate SaaS notifications can become identity attack surfaces when organisations cannot verify invitations, memberships, or cross-domain tenant creation.
NHIMG editorial — based on content published by Push Security: Someone created a fake OpenAI organization using our company's name and invited specific Push employees to join it
Questions worth separating out
Q: How should security teams handle invitation-based attacks on SaaS and AI platforms?
A: Security teams should treat platform invitations as access events, not email events.
Q: Why do poisoned tenant attacks work even when email authentication passes?
A: They work because authentication proves the email came from the platform, not that the tenant behind it is legitimate.
Q: What breaks when employees can join external AI workspaces without review?
A: The review boundary disappears.
Practitioner guidance
- Monitor SaaS tenant invitations and joins Create detection for invitations, joins, and role changes on platforms where employees can be added to external workspaces or AI organisations.
- Block unapproved platform memberships at the browser or IdP layer Where possible, apply policy controls that prevent users from accepting external workspace invitations without a verified business reason.
- Train employees on legitimate-looking invitation abuse Update awareness content so staff know that a technically valid email can still be part of an attack.
What's in the full article
Push Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact invitation flow and screenshots that show how the poisoned tenant was constructed.
- The investigation steps used to confirm that no employees had actually joined the attacker-controlled organization.
- Specific examples of the emails and indicators associated with the campaign.
- The article's broader discussion of how SaaS invitation abuse is evolving across platforms.
👉 Read Push Security's analysis of poisoned tenant attacks through OpenAI invitations →
Poisoned tenant attacks on AI platforms: what IAM teams miss?
Explore further
27/06/2026 2:16 pm
Poisoned tenant attacks are an identity problem disguised as messaging abuse. The attacker does not need to bypass email authentication if the platform itself sends a genuine invitation from a trusted domain. That shifts the governance question from message filtering to tenant creation, invitation authority, and membership visibility. Practitioners should treat SaaS invitations as access grants with security consequences, not as administrative convenience.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, showing how often identity teams lack basic coverage before abuse begins.
A question worth separating out:
Q: Who is accountable when a fake company tenant is used to solicit employee activity?
A: Accountability sits with both the platform operator and the enterprise identity team. The platform needs stronger tenant creation and invitation controls, while the enterprise needs policy, visibility, and response rules for external memberships that can expose work activity and connected applications.
👉 Read our full editorial: Poisoned tenant attacks are evolving through AI platform invitations
