Builders should never hold a credential

In the three-layer model for running AI-built apps, the foundation is the part people skim. Surface is where builders already are, control is the layer few organizations have built, and foundation sounds like plumbing you already own. One foundation decision deserves more attention than it gets, because it constrains every decision above it: where the credentials live.

If the secret lives in the app, the rest of the architecture is decoration. SSO in front of the app keeps the wrong people out of the interface, but the key inside it reaches your CRM regardless of who logged in.

An audit trail records who deployed the app, and says nothing about the five other places the key was copied on the way. An owner can be named, and still not know which copies exist. Every control you add later sits on top of a credential that has already escaped.

How a key travels today

Follow one API key through a normal week of building with an AI assistant.

An analyst wants an app that reads open opportunities from Salesforce and posts a summary to Slack. The assistant writes the code in minutes and then asks for a token. The analyst generates one, under their own account, with whatever scopes the default offered, and pastes it into a config file.

The app doesn’t work on the first try, so they paste the config into the chat window to ask the assistant what’s wrong. The fix works. The project goes into a repository so a colleague can run it, and the config file goes with it. The colleague deploys a copy to a personal cloud account so the team can use it.

That’s one key and five copies: the config file, the chat transcript, the repository, its history, and the colleague’s deployment. Each copy is one you now have to find. None of them shows up in an inventory, because nothing about pasting a token creates a record. And the key belongs to a person, so when that analyst changes roles or leaves, either the app breaks or the credential outlives their employment.

Everyone in that story did something ordinary. The assistant asked for a token because a token is what the code needed. The analyst supplied one because there was no other way to get the app working. The problem is the shape of the path, so the fix is to replace the path.

The design is about the path that does not exist

The architecture that fixes this has four parties and one missing line.

The builder and the assistant describe the app and never hold a secret. They write code that says “use the Salesforce connection”, by name. The project, the prompt history and the repository hold nothing worth stealing.

The deployed app requests access by alias. At runtime, the app asks for a named connection. The name is stable; what it points to can change without anyone touching the code.

A credential broker resolves the alias, and holds and rotates the real secret. This is the one component that ever sees the credential. It decides whether this app may use this connection, supplies it for the call, and keeps a record that it did. Because every app references the same held credential, rotation happens in one place. Revoking access is one change in the broker; the alternative is a hunt through every repository that might contain a copy.

Your systems (the CRM, Slack, the warehouse, the ticketing tool) see a call from a known connection with known scopes. On the old path, they saw whatever token someone generated on a Tuesday.

The line that matters is the one missing from the diagram: there’s no direct credential path from the builder to your systems. Everything else in the design exists to make sure that path never has to be drawn.

When you review an architecture for AI-built apps, look for that missing line first. If you can draw a route from the person building the app to a working secret, the design has failed, however good the rest of it looks.

This is also where most of the exposure lives. Gartner’s analysis of more than 500 client inquiries on scaling vibe coding names integration, meaning approved connectors and restricted data sources, as one of four capabilities an organization needs to scale it.¹ Every app worth deploying reaches a system of record. How it reaches that system is the security question.

Why this decision comes first

Credential policy constrains the other decisions, and they don’t constrain it back.

It decides whether identity means anything. If an app reaches Salesforce with a personal token, the app acts as that person no matter who’s using it. Scoped roles in front of the app can’t narrow what the key behind it can do.

It decides whether ownership survives a reorganization. A credential tied to a builder’s account ties the app’s life to that person’s employment. A credential held by a broker belongs to the organization, and the owner of the app can change without the app breaking.

It decides whether your audit trail is complete. When every call to a system goes through the broker, you have one record of which app touched which system. When keys live in apps, you have as many partial records as you have apps, and no record at all of the copies.

It decides how fast you can respond. When a key leaks, the question is how many places you have to change it. With a broker the answer is one. Without one, the answer is however many copies you can find, and the copies you can’t find stay live.

Gartner’s guidance on governing citizen development puts least-privilege access in the development layer, attached to the build itself, alongside standards and sandboxing.² A credential the builder never holds is the most direct form of that: you can’t over-scope a key you never see.

The vendor test

You’ll evaluate tools for this, whether that means a hosting platform, an internal tool builder or a runtime built for AI-built apps. One question cuts through most of the demos, and it’s worth handing to anyone on your team who sits in an evaluation:

Good answers name a broker, explain how an app references a connection without seeing it, say who can create and change the underlying credential, and show where access is recorded. Weaker answers describe encryption at rest for secrets the builder still pastes in. Encrypting them is fine, and the builder still had the key once, so the copies already exist.

Two follow-ups separate the rest. Ask what happens when the builder leaves: does the app keep working, and does the credential stop being theirs? And ask how you rotate a credential used by twenty apps. If the answer involves redeploying twenty apps, the credential lives in the apps.

If you build it yourself

You can build all of this without a particular product. A platform team can put a secrets manager behind a small resolving service, give apps a name to ask for so they never hold the value, and refuse deployments that carry raw secrets.

That’s real work, and the hard part is keeping it the easiest route: a broker that takes a ticket and a week to add a connection will lose to the pasted token every time. Whatever you build, measure it against the workaround. If pasting a key is faster, the key will be pasted.

Where Tray Helix fits

Tray Helix implements this model with Tray auth aliases. The app, and the AI assistant that wrote it, reference a named authentication; Helix resolves it at runtime against a credential held centrally in the Tray platform, so no key sits in the code, the repository or the chat history. Changing or revoking that access happens in one place, with no code change in the apps that use it.

There’s one dependency to know up front: auth aliases need Tray enabled in your organization, with the authentication already created in Tray. The app references what exists there; it can’t create its own credentials. The detail is on App Security.