Poisoned tenant attacks are evolving through AI platform invitations

At a glance

What this is: This is an analysis of a poisoned-tenant attack using OpenAI organization invitations to impersonate a target company and reach specific employees.

Why it matters: It matters because AI platform invitations now sit inside the identity perimeter, creating a governance blind spot for NHI, SaaS, and workforce security programmes.

By the numbers:

• At its peak, Cisco Talos estimated approximately 2.89% of emails sent from GitHub on a single day were associated with this activity.

👉 Read Push Security's analysis of poisoned tenant attacks through OpenAI invitations

Context

Poisoned tenant attacks exploit a simple governance gap: organisations trust platform-generated invitations more than they trust the sender behind them. In AI collaboration tools, that matters because joining a tenant can expose prompts, files, usage logs, connected apps, and account relationships inside a single workflow.

The article describes a targeted OpenAI organization impersonating Push Security, which is a SaaS identity abuse case rather than a traditional phishing campaign. The security problem is not just email authenticity, but the lack of controls around who can create organisations, name them, and invite employees into a shared work environment.

Key questions

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. Monitor who creates tenants, who can join them, and whether those tenants can become hubs for prompts, files, or connected apps. The key control is visibility into membership changes before employees begin using the environment for real work.

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. The attacker uses trusted delivery infrastructure to carry a malicious invitation, so the weak point is governance over tenant creation and member onboarding rather than message spoofing.

Q: What breaks when employees can join external AI workspaces without review?

A: The review boundary disappears. Once a user accepts a tenant invitation, the organisation may lose sight of what data is being entered, which accounts are connected, and whether the tenant is controlled by an attacker. That makes membership approval part of identity governance, not a low-risk admin action.

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.

Technical breakdown

How poisoned tenant invitations create trusted entry

A poisoned tenant attack begins when an attacker creates a legitimate account or organisation on a SaaS platform and uses platform-native invitation mechanics to reach the target. The invitation is often fully authenticated by the service provider, so mail security checks can pass even though the intent is malicious. Because the invitation arrives through a trusted domain and workflow, the user is nudged to treat joining as routine administration rather than a security event. The control gap is usually organisational visibility, not message authenticity.

Practical implication: treat tenant invitations as security-relevant events and monitor who can create, name, and distribute them.

Why platform membership becomes an identity control point

Once a user accepts a platform invitation, the attacker can gain visibility into membership, roles, and sometimes usage metadata inside the new tenant. In AI platforms, that can matter more than in ordinary collaboration tools because the payload may include prompts, uploaded files, integrations, and linked accounts. The identity issue is that a tenant join can function like a soft authorization grant with downstream data access implications. If the organisation does not govern join decisions centrally, the attacker has converted a social lure into an access path.

Practical implication: govern platform membership the same way you govern access approvals, not as a simple email action.

How invitation abuse extends into broader SaaS attack chains

Poisoned tenants are rarely valuable on their own. The real risk appears when the attacker uses the trusted channel to request OAuth consent, SSO linking, file uploads, or other actions that expand access into adjacent systems. That makes the technique a bridge between social engineering and identity compromise, especially where the platform sits in the middle of work activity. In practice, the attacker is exploiting delegated trust across SaaS, not stealing a password directly.

Practical implication: review which SaaS platforms can become trust anchors for downstream delegation, consent, and data movement.

Threat narrative

Attacker objective: The objective is to turn a trusted SaaS invitation into a durable foothold that can capture sensitive work activity and expand into connected systems.

1. Entry occurs when the attacker creates a fake organisation using the target company's name and sends invitation emails through a legitimate AI platform notification flow.
2. Escalation occurs if an employee accepts the invite and the attacker gains an administrative foothold, visibility into members, and a channel for further social engineering or integration abuse.
3. Impact is the exposure of prompts, files, connected-app data, or usage logs if employees begin treating the attacker-controlled tenant as a legitimate work environment.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• OmniGPT breach — OmniGPT breach exposed API keys, email addresses and chat logs.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Trusted AI workspaces create a new identity blast radius. When a collaboration or AI platform becomes a work hub, the risk is not just account compromise but data pulled into the tenant through normal user behaviour. Prompts, files, and connected-app activity can become a live stream of sensitive work. The practical conclusion is that platform membership governance now belongs in identity security, not only in security awareness training.

Cross-domain invitation trust was designed for benign collaboration, not attacker-controlled tenant creation. That assumption fails when an actor can create a realistic org name, target employees by email, and pre-fund the tenant to reduce suspicion. The implication is that enterprise identity programmes must rethink what counts as a trusted onboarding path across SaaS platforms.

Platform-native notifications are becoming a reusable delivery layer for social engineering. The same pattern appears across collaboration tools, code platforms, and AI systems because the platform is carrying the lure, not merely hosting it. That makes invitation abuse a category-level governance issue across human IAM, SaaS access, and non-human identity oversight.

Browser-layer telemetry and platform membership telemetry should be treated as complementary controls. The article shows that security teams may only discover the attack after a user joins the tenant, which means identity visibility must extend beyond the IdP. The lesson for practitioners is that access governance now requires observation across the browser, the SaaS platform, and the identity provider.

From our research:

• 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.
• For a broader breach pattern view, the 52 NHI Breaches Analysis shows how identity exposure turns platform trust into an attack path.

What this signals

Poisoned tenant abuse will keep expanding wherever platform invitations outrun governance. The pattern is attractive because it uses legitimate infrastructure, which means blocking bad URLs is no longer enough. Teams should expect more attacks that sit inside SaaS onboarding flows rather than around them, especially as AI tools become routine work hubs.

Identity programmes need a separate control view for external workspaces and AI tenants. If the same employee can join a collaboration tenant, upload sensitive material, and connect business apps without central review, then the programme has an ungoverned trust edge. Browser telemetry, IdP events, and SaaS membership logs need to converge into one decision surface.

With 79% of organisations reporting secrets leaks in our research, the broader lesson is that trusted workflows routinely carry sensitive data outside intended boundaries. That makes invitation abuse part of the same control family as secrets exposure and shadow AI usage, where the question is not whether a platform is legitimate, but whether the organisation controls how it is entered and used.

For practitioners

• 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. Correlate those events with the employee directory so security teams can identify unexpected memberships before sensitive work starts flowing through them.
• 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. Use browser telemetry, IdP signals, or platform API monitoring to surface joins to unapproved tenants in near real time.
• 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. Include verification steps for joining AI organizations, collaboration tenants, and third-party workspaces before anyone uploads data or connects accounts.
• Restrict outbound trust into AI platforms Review which employees may connect business apps, upload sensitive material, or run work in external AI environments. Require explicit approval for connections that could expose prompts, documents, or account metadata to a tenant the organisation does not control.

Key takeaways

• Poisoned tenant attacks turn legitimate SaaS invitation flows into identity attack surfaces that traditional phishing controls do not cover.
• The practical risk is not the invitation itself, but the trust created when employees join attacker-controlled workspaces and start using them normally.
• Identity teams should govern tenant creation, membership approval, and platform visibility with the same seriousness they apply to privileged access.

Key terms

• Poisoned Tenant: A poisoned tenant is an attacker-created SaaS organisation or workspace that looks legitimate enough to lure a target into joining. The security risk comes from trust in the platform itself, because joining the tenant can open a path to data exposure, follow-on social engineering, or integration abuse.
• Platform-native Notification Abuse: Platform-native notification abuse is the use of a legitimate service's own emails, invites, or alerts to deliver malicious intent. The message often passes standard authentication checks, which makes governance, membership control, and user verification more important than traditional spoofing detection.
• Trusted Channel Social Engineering: Trusted channel social engineering is an attack pattern that uses a normal business workflow, rather than a fake one, to persuade users to take risky actions. In identity terms, the attacker borrows the credibility of the platform and converts routine onboarding into an access or data exposure event.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity governance in your organisation, it is worth exploring.

This post draws 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. Read the original.