I got this email:
What is this about?
It makes no actual sense and has no context whatsoever does it even mean?
If it even is real, then it’s massively unprofessional to randomly send emails without any context at all.
Please enlighten me.
Received the same one. Have the same question.
Same here! I’m worried clicking on this link will migrate my ATL id over to some other system and I will lose all access?!
It’s not like I just joined a new system and get an account creation email, so without any context this email makes no sense.
Looking forward to clarifications.
Thanks ulrich
Same here. This seems for an Okta test account, so what is this?
I received this, too. Tried reporting this to Atlassian Support, but the wall of chatbots wouldn’t help me. 
Given all the security-focused platform changes we talk about in this forum, it’s frankly a bit surprising that there’s no way to report a potential phishing attempt against Atlassian Cloud admins.
Hi @SrivathsavGandrathi ,
I think this is something Atlassian security must look into.
+1. Same email, same questions.
Notice: You may have received a test email sent in error. No action is required.
Dear Team,
You may have received an email from noreply@okta.com on December 5, 2025 at approximately 19:07 UTC. We unintentionally sent this email to partners during internal testing of our Okta sandbox instance. We sincerely apologize for any confusion this may have caused. We are reviewing our processes to help prevent this from occurring in the future. Please don’t hesitate to reach out if you have any further questions.
Kind regards,
Atlassian Support
So, you’re saying that Atlassian has:
The AI overlords suggest…
Filling test systems with real user data carries significant regulatory, legal, and security considerations, because real data can contain personally identifiable information (PII), sensitive financial information, health data, or other protected information. Here’s a thorough breakdown:
⸻
Depending on your jurisdiction and the type of data, you may be legally restricted from using real user data in test environments. Key regulations include:
• GDPR (EU)
• Real personal data cannot be processed for testing unless there is a lawful basis.
• Pseudonymization or anonymization is strongly recommended.
• Consent may be required if data is identifiable.
• CCPA / CPRA (California, US)
• Limits the use of personal information for purposes outside those disclosed to users.
• Users may request deletion of their data, which applies even in test systems.
• HIPAA (US healthcare)
• Protected Health Information (PHI) cannot be used for testing unless de-identified according to HIPAA standards.
• Other jurisdictions may have similar rules: LGPD (Brazil), PIPEDA (Canada), PDPA (Singapore), etc.
⸻
Using real data in test systems increases the risk of:
• Data breaches if test environments have weaker security controls.
• Unauthorized access by developers, testers, or contractors.
• Data leakage if test systems integrate with third-party services or cloud environments.
⸻
Regulators often require:
• Data minimization: Only use the data necessary for testing.
• Audit trails: Track who accessed data and why.
• Data protection policies: Apply same security standards as production systems.
⸻
To mitigate risks, organizations typically:
1. Use synthetic data wherever possible: Generate realistic but fake data for testing.
2. Mask or anonymize production data if real data is required:
• Replace names, emails, SSNs, etc., with random or hashed values.
• Maintain referential integrity for database relationships.
3. Separate test environments from production: No direct connection to live systems.
4. Access controls: Limit test data access to authorized personnel.
5. Encrypt test data both at rest and in transit.
⸻
Summary: Using real user data in test systems without anonymization can violate privacy laws, expose sensitive data, and create regulatory and legal liabilities. The safest approach is anonymization or synthetic data generation, coupled with strict access control and monitoring.
⸻
If you want, I can create a compliance-focused checklist specifically for filling test systems with production data—it’s very handy for engineering teams. Do you want me to do that?
——
Follow up Q: If Atlassian did this, what are the problems for them?
I’m not pasting the answer here, but it’s fair to say that it is the opposite of good.
Hi @djenkins – First, thank you for confirming the origin and context of the email.
Follow-up question – For future reference, what does Atlassian Support want us to do when we receive suspicious emails related to our Atlassian accounts? I did try to report this at https://support.atlassian.com/, but was effectively turned away by the AI support agents. Is that expected? Or was I in the wrong place altogether?
Thanks!
Thanks for confirming @djenkins .
I trust that you will be issuing a follow up email to those recipients of the spurious email, and not relying on those people to stumble upon this CDAC thread?
What are the consequences for someone that clicks on the link and activates an account?
As David notes, when loading a production data set into a non-production environment it is imperative that the data be anonymised or any PII scrubbed.
Can you confirm if the people who have access to that sandbox instance include people that would not normally have access to the production instance?
This seems like it is something that warrants a more serious response, and shouldn’t just be waved away with a mea culpa post here
The most impressive tech companies I follow are all doing the opposite: they’re hiring more human support staff.
Advantage of AI is you can effectively wipeout middle management and reduce engineering headcount. That ironically results in higher productivity with reduced costs. Then you allocate those savings into better customer support.
Sigh.
Hi everyone,
We see your questions and wanted to provide some additional clarity.
The One Atlassian engineering team is building an Okta account to expand the cloud demo platform to our Partner and Marketplace Audiences.
During testing of this Okta account, partner email addresses were inadvertently uploaded to the internal sandbox environment, triggering the email invitations that were sent out.
Importantly, no other data was present, and the sandbox environment was only accessible by the authorized people in the One Atlassian team who were working on it.
We’ve deactivated the links that were sent out in the emails. If you click on it now, it should redirect you to an error page.
If any customers clicked the link prior to the deactivation and proceeded to sign up, an Okta account was created. These accounts have since been deleted.
If you have any further questions, please contact us via the Atlassian Partner Support Portal and select ‘General Help’.
@djenkins – I just tried this, and there are two problems:
So, it seems the question about how to report suspicious emails remains unanswered.
Screenshots:
Well, I’ve done this kind of thing myself. The procedure for creating a sandbox needs to disable all outgoing email by default. I used to also remove all the notification schemes from all projects in sandbox just to be sure.
