Notifications
Clear all
Topic starter
07/06/2026 8:42 pm
TL;DR: Duality AI’s Falcon uses high-fidelity digital twins to generate synthetic data and validate robotics and embodied AI safely, while the article also argues that enterprise auth, scoped permissions, and auditability still need a separate governance layer according to WorkOS. That split matters because simulation expands testing capacity, but it does not answer who can launch, modify, or export the resulting data and outputs.
NHIMG editorial — based on content published by WorkOS: Duality AI digital twins and the identity controls that surround them
Questions worth separating out
Q: How should teams govern access to digital twin simulation platforms?
A: Treat the simulator as a governed platform, not a standalone engineering tool.
Q: Why do digital twins still need IAM controls if they are only test environments?
A: Because the outputs are often not just test artefacts.
Q: What breaks when simulation platforms are shared across contractors and internal teams?
A: The access model usually becomes inconsistent.
Practitioner guidance
- Separate simulation access from model access Define distinct permissions for scenario creation, simulation execution, result export, and deployment handoff.
- Gate external access with enterprise identity controls Require SSO, directory sync, and scoped roles before contractors, customers, or auditors can view or manipulate synthetic data and simulation outputs.
- Audit simulation artefacts as governed assets Track who created each environment, which datasets were used, who exported results, and when access was revoked.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How Falcon maps simulation-ready assets into browser-accessible workflows for teams that need hands-on setup detail.
- Where WorkOS fits into the access model for SSO, SCIM, permissions, and auditability across simulation users.
- Why the article recommends combining simulation infrastructure with enterprise auth when exposing tools to internal teams, customers, or auditors.
- The specific examples of robotics, drones, and embodied AI deployment contexts that benefit from the dual-layer stack.
👉 Read WorkOS's analysis of Duality AI digital twins and enterprise identity →
Digital twins for AI and robotics: what identity teams must govern?
Explore further
08/06/2026 8:21 am
Simulation expands what teams can test, but it does not collapse the identity boundary around the test environment. High-fidelity digital twins reduce physical risk and speed validation, yet the core governance questions remain outside the simulator itself: who can create scenarios, who can access outputs, and who can move a model toward deployment. That means the security model must extend beyond compute and data fidelity into access scope, auditability, and offboarding. Practitioners should treat the simulation plane as one layer in a broader identity stack.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do IAM teams evaluate the risk of AI or robotics outputs coming from simulation?
A: Start by asking which identity paths can modify the input, observe the output, or move the output into production workflows. If those paths are not clearly separated and logged, the governance model is too weak. The control goal is traceability from access grant to operational consequence.
👉 Read our full editorial: Duality AI digital twins sharpen identity needs for AI and robotics
