You can vibe code features, but not enterprise trust

At a glance

What this is: This conversation argues that AI can speed feature development, but enterprise trust still depends on auth, policy, and operational rigor.

Why it matters: IAM teams need to see where AI-driven delivery accelerates product features while leaving identity governance, SSO, and authorisation decisions unchanged.

👉 Read WorkOS's conversation on why you can vibe code features but not enterprise trust

Context

AI-assisted development changes how fast teams can build software, but it does not change the fact that enterprise readiness depends on identity controls, policy decisions, and assurance work. In practical terms, the first draft of a feature can be generated quickly, while the trust layer still has to survive real customer identity requirements.

For IAM programmes, the issue is not whether AI can produce working code. The issue is whether authentication, authorisation, multi-tenancy, and certification work is being treated as durable identity architecture rather than an afterthought. That gap matters across human IAM and non-human access because speed increases the chance that teams ship before governance catches up.

Key questions

Q: How should teams keep AI-assisted development from weakening enterprise trust?

A: Teams should separate fast feature generation from slower trust engineering. Authentication, authorisation, tenant isolation, logging, and assurance evidence need explicit review gates because enterprise readiness depends on correctness, not speed. The practical rule is simple: if a feature touches identity or access, it must be validated as infrastructure, not just shipped as code.

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. Human judgment is still needed to define who may authenticate, what they may access, and how the system proves that those controls are working. That is especially true when multiple identity providers and tenants are involved.

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. That creates brittle, inconsistent identity handling and slows rollout even when the core feature is already built. The failure is not just technical debt. It is governance debt that accumulates across every integration.

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.

Technical breakdown

Why authentication and authorisation do not speed up with code generation

AI can accelerate implementation, but authentication and authorisation remain constraint-heavy because they depend on correct trust boundaries, tenant isolation, and entitlement logic. These are not features that can be inferred safely from a prompt. They require explicit policy modelling, integration testing, and edge-case handling for federated identity providers, account linking, and fallback flows. In enterprise software, a small auth mistake can become a systemic trust failure because access decisions sit on the critical path for every user and every tenant.

Practical implication: treat auth and authorisation as design disciplines, not accelerators, and review them with the same rigour as production access controls.

The enterprise-ready gap in multi-tenancy and certification work

Multi-tenancy is where rushed delivery often breaks down, because tenant boundaries must be enforced consistently across data, sessions, admin actions, and audit trails. Certifications add another layer of friction because enterprise buyers expect evidence, not just functionality. AI can generate scaffolding, but it cannot substitute for control design, review evidence, or assurance that the product behaves predictably under enterprise scrutiny. The result is a common mismatch between how quickly a feature can be built and how slowly it can be trusted.

Practical implication: validate tenant separation, logging, and assurance artefacts before expanding an AI-assisted feature into enterprise rollout.

The pre-AI infrastructure mindset for identity integration

The phrase pre-AI is useful because it points to infrastructure that must exist before innovation can be safely scaled. Identity integration, especially SSO and tool access, needs a repeatable operating model rather than one-off engineering heroics. The governance problem becomes sharper with agents and MCP-style tool access, because teams must decide who or what can authenticate, what it may do, and how that access is bounded. That is identity architecture work, not feature work.

Practical implication: standardise enterprise identity primitives early so AI delivery does not create a backlog of custom trust exceptions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

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.

Enterprise software still fails on the same old trust problems, only faster. The article points to a familiar pattern: teams can prototype quickly, then discover that each enterprise customer introduces new identity variation, policy complexity, and assurance demand. That is not a tooling problem alone. It is a lifecycle problem across onboarding, federation, and support for multiple identity providers. Teams should assume that speed will multiply governance debt unless the identity model is standardised first.

Pre-AI infrastructure is now the differentiator for AI-era delivery. The named concept here is enterprise trust debt: the gap between a feature that works and a feature that can be safely adopted in regulated or large-scale environments. This debt accumulates when identity, policy, and certification work are deferred in favour of visible product velocity. Practitioners should recognise that the market will increasingly reward teams that can make trust repeatable, not just code generation fast.

Identity integration is becoming the control plane for AI products. As more products expose agents, tools, and enterprise workflows, the question shifts from whether software works to whether it can authenticate, authorise, and evidence its own behaviour. That pushes IAM, PAM, and governance teams closer to product architecture decisions. The practitioner takeaway is clear: the trust layer is now part of product differentiation, even if the code itself was AI-assisted.

From our research:

• 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.
• The deeper lesson is in Ultimate Guide to NHIs , Why NHI Security Matters Now, where identity teams can map why speed without governance creates lasting access risk.

What this signals

Enterprise trust work is becoming the pacing item for AI-assisted delivery. Teams that optimise only for feature velocity will accumulate identity and assurance debt faster than they can retire it. The practical signal is that SSO, authorisation, and tenant boundaries need to move from implementation details to programme-level controls, especially where products are aiming at regulated enterprise buyers.

Identity standards and repeatable access patterns will matter more than bespoke engineering. The more products expose users, services, and agents through the same trust layer, the more important it becomes to standardise authentication and access policy. That is where the NIST Cybersecurity Framework 2.0 remains useful as a governance scaffold: identify, protect, detect, and respond must be visible in the product trust model.

Trust debt is the right concept for AI-era product teams. It captures the gap between something that functions and something an enterprise can safely adopt. With 27 days to remediate a leaked secret in our research, the governance lesson is that delayed trust work compounds quickly, especially when access boundaries are changing as fast as the codebase.

For practitioners

• 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. Require sign-off on tenant boundaries and access flows before release.
• 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. Document the supported identity providers and fallback behaviours.
• Treat certifications as product inputs Build evidence collection, audit logging, and control mapping into the delivery process rather than retrofitting them after launch. Enterprise buyers will test whether the product can prove trust, not just claim it.
• Govern agent and MCP access as privileged integration If AI features expose tools or automate actions, define who can authenticate, which tools are exposed, and what approval gates exist around sensitive operations. Do not let dynamic capability become unbounded access.

Key takeaways

• AI can make software faster to build, but it cannot generate the identity governance needed to make it enterprise-ready.
• The practical bottleneck is trust engineering, especially around authentication, authorisation, multi-tenancy, and assurance evidence.
• Teams that standardise identity patterns early will avoid turning AI-assisted speed into long-term governance debt.

Key terms

• Enterprise Trust Debt: The growing gap between a feature that works and a product that can be safely adopted by enterprise customers. It builds when identity, policy, auditability, and assurance are deferred until after launch, then multiplies across customers, tenants, and integrations.
• Federated Identity Integration: The process of accepting identities from external identity providers while preserving correct authentication, authorisation, and session behaviour. It covers SSO, account linking, tenant-specific policy, and fallback handling, all of which can fail if they are treated as one-off engineering tasks.
• Tenant Isolation: The controls that keep one customer separated from another across data, sessions, administration, and audit trails. It is both an identity problem and an access problem because the boundary must hold under support workflows, delegated administration, and shared service infrastructure.

Deepen your knowledge

Identity, federation, and enterprise trust boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to scale AI-assisted delivery without weakening access governance, it is worth exploring.

This post draws on content published by WorkOS: You can vibe code features. You cannot vibe trust. A conversation with Forrest Brazeal from Freeman & Forrest. Read the original.