Builders never hold a credential

Where credentials live decides every control above them. Follow one API key through a normal week and you’ll see why.

How a key travels today

An analyst wants an app that reads open opportunities from Salesforce and posts a summary to Slack. The assistant writes the code in minutes, 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.

It doesn’t work first time, so they paste the config into the chat to ask what’s wrong. Then the project goes into a repository, and a colleague deploys a copy to a personal cloud account for the team.

One key, five copies: the config file, the chat transcript, the repository, its history, and the colleague’s deployment. None shows up in an inventory. And the key belongs to a person, so when the analyst leaves, either the app breaks or the credential outlives their job.

Everyone did something ordinary. The path is the problem.

Design out the path

• The builder and the assistant never hold a secret. The code says “use the Salesforce connection”, by name, so the repository and the prompt history hold nothing worth stealing.
• The deployed app asks for access by alias. What the name points to can change without touching the code.
• A credential broker resolves the alias. It’s the one component that sees the secret. It holds it, rotates it, and records each use.
• Your systems see a known connection with known scopes, never a token someone generated on a Tuesday.

Look at what the diagram leaves out: any path from the builder to a working secret. In a design review, look for that path first. If you can draw it, the design has failed.

Why this decision comes first

It decides whether identity means anything. An app that reaches Salesforce with a personal token acts as that person, whoever’s using it.

It decides whether ownership survives a reorg. A credential held by a broker belongs to the organization, so the app’s owner can change and the app keeps working.

It decides how fast you respond to a leak. With a broker you change it in one place. Without one, every copy you can’t find stays live.

Gartner’s guidance on governing citizen development puts least-privilege access in the development layer, attached to the build itself.¹ You can’t over-scope a key you never see.

The vendor test

A good answer names a broker, says who can create and change the underlying credential, and shows where access is recorded. Encryption at rest for secrets the builder pastes in is weaker: the builder had the key once, so the copies already exist.

Then ask two follow-ups. What happens when the builder leaves? And how do you rotate a credential twenty apps use? If the answer is “redeploy twenty apps”, the credential lives in the apps.

How Helix does it

Helix uses Tray auth aliases. The app references a named authentication, and Helix resolves it at runtime against a credential held centrally in the Tray platform. The builder asks their AI assistant to connect Salesforce, and the assistant wires up the alias without ever seeing the secret. Anyone on the project can check what it uses:

The config holds the alias and the secret stays in Tray. So you change or revoke access in one place, with no code change in the apps that use it.

One dependency: auth aliases need Tray enabled in your organization, with the authentication created there first. An app can’t create its own credentials. The detail is on App Security.

Do this week

Pick three AI-built apps you know about. For each, ask the vendor question of your own setup: when it calls a system of record, where’s the credential, and whose account issued it? Count how many answers are “in the app” or “a person’s token”.

What you have now

The design to hold every platform to, and a question that cuts through a demo in a minute. Next: tiers, identity, owners and the path to production.