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.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “We coined the poisoned tenant attack in 2023; in 2026, someone used it on us”.
Key questions
Q: What breaks when employees can join external AI workspaces without review?
A: The review boundary disappears.
Q: Why do platform invitations create identity risk even when the email is genuine?
A: Because the danger is not spoofing but enrolment.
Q: How can security teams detect poisoned tenant abuse in SaaS platforms?
A: They need visibility into account creation, organisation membership, and cross-domain invitation activity.
Practitioner guidance
- Map external tenant creation paths Inventory which collaboration and AI platforms let outsiders create organisations, name them freely, and invite employees, then classify those flows as identity entry points rather than admin noise.
- Gate tenant joins through a verification channel Require employees to confirm any new external workspace or AI organisation through an internal identity channel before accepting an invitation, especially when the tenant can expose prompts, logs, or integrations.
- Block or surface suspicious membership changes Use browser telemetry, IdP monitoring, or platform API checks to detect when staff join external tenants that could create a trusted channel for prompt exposure or follow-on social engineering.
Bottom line: Poisoned tenant attacks exploit legitimate platform invitation flows, which means normal email trust signals do not remove the identity risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 24 hours ago by NHI Mgmt Group
27/06/2026 2:16 pm
Poisoned tenant attacks are a governance problem, not a mail-security problem: the critical failure is the moment a user treats an external SaaS tenant as an internal workspace. Standard email authentication can be perfect and still not answer the identity question that matters: who controls the tenant the user is about to join? Security teams need to think in terms of membership trust, not just message trust.
A question worth separating out:
Q: When should organisations block or verify external tenant invitations?
A: They should do it whenever joining the tenant could expose sensitive work data, connected apps, or administrator-level visibility. The safest default is to require an internal verification step for new external workspaces, especially on AI platforms that can become a work hub for prompts and integrations.
👉 Read our full editorial: Poisoned tenant attacks are evolving through AI platform invitations
This post was modified 24 hours ago by NHI Mgmt Group