Surface, control, foundation: the three layers

Every app built with an AI assistant passes through three layers before anyone but its builder uses it. Map what you already own onto them and you’ll probably find the same gap most teams do.

Governance attaches at two moments

Gartner’s research on governing vibe coding for citizen developers splits governance into two layers.¹ A development layer puts standards, sandboxing and least-privilege access on the build while it happens. A validation layer checks before anything reaches production, and logs from then on.

You probably have some of the development layer already: linters, dependency scanning, secret detection. The validation layer is usually the gap. Between a working app on a laptop and a live URL sits one thing: the builder’s judgement about where to host it.

Tray Helix sits in the validation layer. It doesn’t scan or test the code an assistant generates, so keep your code-level checks in the development layer.

Three layers, top to bottom

The arrow from surface to control is deploy. The arrow from control to foundation is run. Every governance decision you make attaches at one of those two points.

Attach it at deploy and it’s the default condition of going live. Attach it afterwards and it’s a cleanup project. When apps take an afternoon to build, cleanup projects don’t finish.

Surface: meet builders where they are

Concede the assistant. Your builders already picked Claude Code, Codex or Cursor. Fight that and IT becomes the obstacle, right when you want builders coming to you.

Own the exit ramp. Own the point where the build meets production: one command from the assistant to a running app, with no ticket to file. If it’s slower than a personal cloud account, builders take the personal cloud account.

Own the catalog. When people can find what colleagues already built, the fifth renewal tracker never gets started. Gartner treats reuse rate as one of the main health signals for a vibe coding program.²

Set permissions by risk. A payroll app needs more scrutiny than a notes summarizer, whoever built it.

Control: the layer that’s usually empty

Five things belong here, and all five should attach the moment an app goes live:

• Identity on every app. SSO in front, scoped roles behind.
• Approval where it matters. A gate on the tiers that warrant one, and none on the rest.
• An audit trail by default. What shipped, who owns it, who has access, and when each changed.
• Observability past uptime. Errors, failures and rework, as well as whether the app is up.
• A named owner, always. No app enters production unowned.

Builders in a hurry won’t ask for any of these. So none of them should depend on asking.

Foundation: three services under everything

A credential broker. Secrets held centrally and referenced by alias, so they never appear in code, config or chat. Lesson 3 covers it, because it constrains every other decision.

A project service. It owns deploys and versions, so what passed review is what ships, and a bad release can go back to a known version.

A runtime. Managed execution, with no infrastructure to set up for each app.

How Helix maps to it

On the surface, builders keep their assistant and deploy from it. In control, every app deployed through Helix gets SSO and access control, managed credentials, an activity trail, and logs for every run. The foundation is the Tray platform: the managed runtime, a credential broker built on Tray auth aliases, and the Tray authentications apps reach your systems through. Helix governs what’s deployed through it. An app hosted somewhere else stays outside that line.

Do this week

What you have now

A shared model for talking about this with security, platform and the business, and a list of the control items you’re missing. Next: where credentials live, the foundation decision that comes first.