Topic starter
07/06/2026 8:53 pm
TL;DR: Haize Labs’ red-teaming platform is built to find prompt injection, goal misalignment, hallucination and other behavioral failures in LLMs and AI agents, while WorkOS positions enterprise authentication as a separate control plane for access and user management. Behaviour testing can prove an AI system is unsafe, but it cannot substitute for identity, authorization or lifecycle governance.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Haize Labs: AI Safety Testing”.
By the numbers:
- WorkOS says Haize Labs received a $100M post-money valuation.
- Cascade delivered 38x faster attack generation with 4x reduction in GPU memory usage.
Key questions
Q: How should security teams test AI systems for safety and security separately?
A: Run two evaluation tracks.
Q: Why can enterprise authentication still leave AI agents unsafe?
A: Because authentication proves identity, not behaviour.
Q: What are the signs that AI safety testing is being used as a proxy for access control?
A: The clearest sign is when teams point to red-teaming results, content filters or model evaluation dashboards as evidence that user access, entitlement scope or tenant isolation is acceptable.
Practitioner guidance
- Separate model-risk testing from access governance Assign AI red-teaming, prompt injection testing and hallucination evaluation to the AI assurance process, and keep identity proofing, entitlement scoping and revocation under IAM ownership.
- Gate production AI releases on behavioural evidence Require automated red-teaming results before model updates, prompt changes or retrieval changes are promoted into production, so safety testing becomes part of release qualification.
- Keep enterprise auth evidence distinct Document SSO, SCIM, RBAC and audit logs as access controls, not as evidence that an AI agent behaves safely under adversarial input.
Bottom line: This article shows that AI red-teaming and enterprise authentication solve different problems, and only one of them governs access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 8:37 am
AI behavioural safety and enterprise identity are parallel control problems: this article is useful because it separates model red-teaming from access governance. Behavioural testing can show that an AI system is vulnerable to prompt injection or misalignment, but that evidence does not govern who can enter the system or what entitlements they receive. Practitioners need to stop treating model assurance as a substitute for IAM, because the failure modes, evidence and owners are different. The implication is that AI programmes need two assurance tracks, not one blended control narrative.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should organisations do when AI access and AI safety are owned by different teams?
A: They should define a shared governance model with separate control objectives. The identity team should own provisioning, authorization, auditability and revocation, while the AI assurance team should own adversarial testing, runtime monitoring and failure-mode analysis. Common reporting helps, but the controls should not collapse into one programme because they answer different risk questions.
👉 Read our full editorial: AI agent safety testing exposes the limits of enterprise auth
This post was modified 3 days ago by NHI Mgmt Group