You can vibe code features, but not enterprise trust

At a glance

What this is: This is a commentary on why AI-assisted development speeds feature delivery but does not eliminate the enterprise trust work needed for identity, access, tenancy, and compliance.

Why it matters: It matters because IAM, IGA, and PAM teams are being pulled into faster release cycles while the hard parts of enterprise readiness still depend on governed identity design, not generated code.

Context

AI-assisted development can compress the time needed to build visible product features, but it does not compress the trust requirements enterprises apply before adoption. The article's core point is that authentication, authorisation, multi-tenancy, and certifications remain human governance problems even when code can be generated quickly.

For identity and access practitioners, the important shift is not the speed of feature creation. It is the growing mismatch between software delivery velocity and the time required to design enterprise-grade access controls, tenant boundaries, and assurance processes.

Key questions

Q: How should security teams handle enterprise trust when AI speeds up feature delivery?

A: They should treat trust work as a parallel programme, not a downstream task. Authentication, authorisation, tenant isolation, and assurance evidence need named owners and design review before product teams commit to an enterprise launch. AI can accelerate implementation, but it does not reduce the governance burden behind customer trust.

Q: Why do AI-built features still need human judgment before enterprise release?

A: Because the hardest decisions are not about whether code runs. They are about where the trust boundary sits, what level of access is acceptable, how tenants are separated, and what evidence proves the controls are working. Those are judgment calls that require accountability, not code generation.

Q: What breaks when teams try to scale enterprise software without trust governance?

A: The product may function, but enterprise adoption stalls when customers ask for federation, separation, evidence, and reviewability that were never designed in. The usual failure is rework across access models, tenant boundaries, and certification evidence, which consumes the time AI supposedly saved.

Q: Should IAM teams prioritise trust architecture or feature velocity in AI-era delivery?

A: They should prioritise trust architecture first when the product is intended for enterprise buyers. Velocity only matters if the underlying authentication, authorisation, and tenancy model can survive scrutiny from security, compliance, and procurement teams. Otherwise, the fastest path to market becomes the slowest path to revenue.

Technical breakdown

Authentication and authorisation still define enterprise readiness

Authentication and authorisation are the control plane that decides who or what can access a system and what they can do once inside. AI can accelerate implementation, but it cannot determine the right identity model, assurance level, or permission boundary for a specific enterprise context. Those choices depend on risk tolerance, customer requirements, and operational exceptions that must be evaluated by humans. In practice, teams that treat access control as code-generation work tend to miss edge cases such as delegated administration, tenant isolation, and enterprise federation.

Practical implication: Treat access design as an identity architecture decision, not as a feature by-product.

Multi-tenancy is a governance problem before it is a software pattern

Multi-tenancy is not just a database or routing design. It is a trust boundary problem that determines how one customer is separated from another in data, identity, and administration. Fast-moving teams often over-focus on functional delivery and under-specify tenant isolation, which creates hidden exposure when enterprise buyers begin asking for stronger separation, custom controls, or auditability. The article's message is that trust breaks when teams assume the product layer can improvise governance later.

Practical implication: Design tenant isolation and administrative separation before enterprise rollout, not after first customer demand.

Security certifications are process disciplines, not code outputs

Certifications and enterprise assurance depend on repeatable controls, evidence, and review, not on the speed of feature shipping. AI can produce code, but it cannot produce accountable control ownership, validated evidence trails, or the judgement needed to decide whether a control is actually adequate. That gap matters because enterprise buyers often use certifications as a proxy for operational maturity, and immature governance becomes visible quickly when due diligence starts. The article frames this as the difference between building software and building trust.

Practical implication: Build assurance evidence, control ownership, and review cadence into the delivery process from the start.

NHI Mgmt Group analysis

Enterprise trust is now the bottleneck, not software output. AI compresses feature development, but it does not compress the time required to establish access boundaries, assurance, and operating discipline. That means the enterprise readiness gap is widening between teams that can ship and teams that can be trusted. Practitioners should stop treating AI speed as a substitute for governance capacity.

Authentication and authorisation are becoming the new product differentiation layer. Once feature parity becomes cheaper to reach, buyers will judge products on whether identity, tenancy, and admin controls are ready for enterprise scrutiny. That shifts IAM from a late-stage dependency to a market-entry requirement. The practical conclusion is that access design now influences revenue readiness as much as product capability.

Pre-AI infrastructure is the right framing for enterprise trust work. The article's strongest signal is that some controls have to exist before AI-driven scale creates pressure to cut corners. Authentication, authorisation, and certifications cannot be improvised at the point of customer demand. For identity teams, that means governance must be designed as foundational infrastructure, not as a post-build review.

Enterprise trust cannot be vibe coded because it depends on judgment, not syntax. Human review is still required to decide which controls are sufficient, which exceptions are acceptable, and where the trust boundary should sit. AI can produce implementation options, but it cannot own the accountability chain behind them. The implication is that security and IAM leaders must defend time for control design even when delivery cycles accelerate.

Vibe coding exposes a governance debt problem, not a tooling problem. The real issue is that faster development makes hidden trust work look optional until enterprise buyers force it into view. That is why trust debt accumulates in identity, tenancy, and compliance decisions long before it appears in the UI. Practitioners should treat unresolved trust design as accumulated risk, not deferred polish.

What this signals

Enterprise trust debt: When product teams use AI to accelerate visible delivery, unresolved decisions about identity, tenancy, and assurance do not disappear. They accumulate as trust debt and show up later as blocked sales cycles, security review failures, and expensive rework.

The practical signal for IAM and security leaders is that enterprise readiness now starts earlier in the product lifecycle. If authentication, authorisation, and tenant separation are not designed before scale pressure arrives, the organisation will spend the next cycle retrofitting controls under customer deadline.

Teams that can articulate pre-AI infrastructure for identity and access are better positioned to withstand enterprise scrutiny. The issue is not whether AI can build the feature, but whether the operating model can prove control ownership, evidence, and accountable trust decisions.

For practitioners

• Define enterprise trust requirements before feature sprints Document the required authentication, authorisation, multi-tenancy, and certification controls before product teams promise delivery dates. Make those requirements part of design review, not a post-release checklist.
• Separate tenant boundaries from feature delivery Establish clear tenant isolation, admin separation, and data partitioning patterns so that enterprise onboarding does not require redesign for every new customer profile.
• Budget human review for trust decisions Assign accountable owners to decide on control adequacy, exception handling, and assurance evidence because AI can accelerate implementation but not governance judgement.
• Treat certifications as operating discipline Build evidence collection, control ownership, and review cadence into the delivery process so enterprise assurance is maintained continuously rather than assembled at the end.

Key takeaways

• AI speeds feature production, but enterprise trust still depends on governed identity, tenancy, and assurance work that cannot be generated automatically.
• The article's central lesson is that shipping software and earning enterprise confidence are different disciplines, even when AI makes the first look effortless.
• Identity and security leaders should move trust design earlier in the delivery process so control decisions are made before customer pressure forces shortcuts.

Key terms

• Enterprise trust: The assurance a buyer needs before allowing a product into a regulated or controlled environment. It combines identity controls, administrative separation, auditability, and evidence that the system behaves predictably under enterprise review.
• Multi-tenancy: Multi-tenancy is the design pattern that keeps multiple customer organisations isolated inside one application. For identity teams, the key issue is whether access, policy, and administration remain separable at the tenant level, or whether customer boundaries leak into support, logging, and provisioning workflows.
• Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.