Notifications
Clear all
Topic starter
07/06/2026 8:26 pm
TL;DR: AI can lower the cost of building features, but it does not remove the enterprise trust work around authentication, authorisation, multi-tenancy, and certifications, according to WorkOS. The real bottleneck is not code generation but the human judgment and process discipline needed to make software enterprise-ready.
NHIMG editorial — based on content published by WorkOS: You can vibe code features. You cannot vibe trust. A conversation with Forrest Brazeal from Freeman & Forrest
Questions worth separating out
Q: How should teams keep AI-assisted development from weakening enterprise trust?
A: Teams should separate fast feature generation from slower trust engineering.
Q: Why do AI-built features still require human judgment in identity design?
A: AI can generate code, but it cannot reliably decide enterprise policy boundaries, customer-specific federation requirements, or assurance expectations.
Q: What breaks when teams treat trust work as an afterthought?
A: Teams usually end up reworking SSO, authorisation logic, and tenant separation for each new enterprise customer.
Practitioner guidance
- Separate feature velocity from trust engineering Create an explicit review path for authentication, authorisation, multi-tenancy, and assurance work so AI-generated features do not bypass identity design.
- Standardise enterprise identity patterns early Use repeatable SSO, federation, and account-linking patterns across products and customers so each new enterprise deal does not restart identity design from scratch.
- Treat certifications as product inputs Build evidence collection, audit logging, and control mapping into the delivery process rather than retrofitting them after launch.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How Forrest Brazeal frames the enterprise trust bottleneck for AI-era software teams
- Specific examples of SSO and IDP variation that create repeated engineering work
- Why certifications and process discipline slow down upmarket sales even when features ship quickly
- The article's broader perspective on why pre-AI infrastructure still matters for modern products
👉 Read WorkOS's conversation on why you can vibe code features but not enterprise trust →
Enterprise trust in the AI era: what IAM teams are missing?
Explore further
07/06/2026 10:19 pm
AI lowers delivery friction, but it does not lower trust requirements. The core mistake in many AI-era product teams is assuming that faster code generation also shortens the path to enterprise readiness. It does not. Authentication, authorisation, tenant isolation, and certification evidence still require deliberate identity governance, and that work becomes more visible as feature velocity rises. Practitioners should stop treating trust as a post-build phase and start treating it as the product boundary.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How should product teams govern AI features that expose tools or actions?
A: They should treat tool exposure as privileged access and define approval boundaries before release. That means deciding which identities can authenticate, which actions are allowed, and where human review is required for sensitive operations. Without those controls, the AI layer becomes an uncontrolled trust surface rather than a managed capability.
👉 Read our full editorial: You can vibe code features, but not enterprise trust
