The auth handoff that strands an AI feature outside your systems

A director of platform at a B2B software company showed me a feature that read from their CRM, drafted an update, and offered to write it back. In the demo it worked end to end. Then the launch date slipped, and slipped again. When I asked why, the answer was not the model and not the UI. Nobody had figured out how the AI service was supposed to authenticate into the CRM and the data warehouse as itself, with the right permissions, for real users. The demo had run on one engineer’s personal token, and that token was the only reason it worked at all.

A personal token is a demo, not an integration

In a demo, borrowing a person’s credentials is the fast path. You paste in a token, the feature can suddenly see the CRM, and everything flows. It feels like the integration is done. It is not. What you built is a feature that acts as one specific human being, using access that was granted to that person for their own work.

Production asks harder questions immediately. When user A triggers the feature, whose data should it be allowed to touch? Certainly not everything that one engineer’s token can reach. The feature has to act inside the identity and permission model of the systems it talks to, which means it needs its own way to authenticate, its own scoped access, and a clear answer for how a given user’s request maps to the right permissions in the CRM and the warehouse.

That is not a small addition you bolt on at the end. It touches how the service gets credentials, how it keeps them, how it scopes what each request can do, and how every access is logged. When none of that was scoped, the feature is finished in every way except the one that lets it run. It works on a laptop and stalls at the boundary of your real systems. This is a big part of why so many AI pilots stall on integration and operations rather than on model quality.

Design the handoff at scoping time

The lesson is to treat authentication as a first-class part of the design, decided before you build, not discovered after the demo lands. Ask early how the AI service will identify itself to each system, what it is allowed to do there, and how a user’s request carries the right permissions through.

What good teams settle up front.

How the AI service authenticates to each system it reads from or writes to, as itself, not as a borrowed person.
What scope of access it gets, kept to the least it needs for the feature.
How a specific user’s request maps to the permissions it should have, so the feature cannot act outside them.
Where credentials live and how they rotate, so the design does not depend on one static secret.
How every access is logged, so you can answer who did what through the feature.

Decide these while the work is still cheap to change. The auth handoff is not a detail you can leave for later. It is the thing standing between a working demo and a shipped feature.

How we approach it at Density Labs

Most stalled AI features I see are not blocked on the model. They are blocked at the boundary where the feature has to become a real actor inside existing systems, with a real identity and real permissions, and nobody scoped that handoff.

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500, that scopes the real production work before you build. Part of that is designing exactly how the feature authenticates into your systems and how user permissions flow through it, so the integration is real from the start instead of a personal token holding the whole thing up.

A demo runs on someone’s credentials. A product runs on its own.