Surface, control, foundation: the three layers every AI-built app passes through

In the first post in this series I argued that a policy answer can’t govern apps built with AI, because every control in it is opt-in for the person you’re trying to control. The alternative is an architecture: a path to production that attaches identity, credentials, ownership and audit to every app because the app runs on it.

Here’s that architecture, drawn out. It’s a model, and you can build it with or without a vendor. It has three layers, and every app built with an AI assistant passes through all of them on its way to being used by anyone other than the person who built it.

Governance attaches at two moments

Before the layers, the timing. Gartner’s research on governing vibe coding for citizen developers splits governance into two layers.¹ The first is a development layer: standards, sandboxing and least-privilege access, attached to the build while it happens. The second is a validation layer: the check before anything reaches production, together with audit logging from then on.

Most organizations already have some of the development layer, through the SDLC tooling their engineers use: linters, dependency scanning, secret detection in repositories. The validation layer is usually the gap. Between a working app on a laptop and a live URL there’s only the builder’s own judgement about where to host it.

A plain statement of scope, since this series is written by a vendor: Tray Helix sits in the validation layer. It doesn’t scan or test the code an assistant generates. If you need code-level checks, they belong in the development layer, and Helix doesn’t replace them.

Three layers, top to bottom

Read it top down. Surface is where your people already are, and you don’t get to move them. Foundation is mostly what you already own: infrastructure, identity providers, secrets management of some kind. Control is the layer few organizations have built, and it’s the one this whole model exists to supply.

The two arrows between the layers mark the two moments from Gartner’s model. Deploy is the move from surface to control; run is everything that happens on the foundation afterwards. Every governance decision attaches at one of those two points.

Governance applied at deploy becomes the default condition of going live. Governance applied afterwards becomes a cleanup project, and when apps take an afternoon to build, cleanup projects don’t finish.

Surface: meet builders where they already are

The surface is where people build, and where they find what already exists.

Concede the assistant

Your builders picked their assistant: Claude Code, Codex, Cursor, Copilot, and whatever ships next quarter. Concede that choice immediately and without regret. Fighting over which assistant people use is a battle you’ll probably lose, and it makes IT the obstacle at exactly the moment you want builders to come to you.

Own the exit ramp

What you can own is the exit ramp: the point where the road builders drove in on meets production. That means one command from the assistant to a running app, and no ticket to file. If the sanctioned exit is slower than a personal cloud account, builders take the personal cloud account, and you’re back to discovering apps after the fact.

Own the catalog

The catalog is the part most organizations forget. When builders can publish what they made and colleagues can find what they’re cleared to use, the fifth renewal tracker never gets built. Duplication is the hidden cost of cheap building, and Gartner treats reuse rate as one of the main health signals for a vibe coding program for that reason.²

Set permissions by risk

The last piece of the surface is permissions: which groups of builders get which rights within each risk tier. Permissions should follow the risk of the thing being built. A senior engineer building something that touches payroll needs more scrutiny than an analyst building a meeting-notes summarizer.

Control: the layer that is usually missing

Control is where IT governs everything that ships. Six things belong in it.

• Identity on every app. SSO in front, scoped roles behind. The app your analyst built has no login at all, so anyone with the URL is inside. This is the most visible gap and the easiest one to explain to a board.
• Approval where it matters. A gate on the tiers that warrant one, and none on the rest. Tiering exists so that the controls you apply stay credible; gating everything teaches builders to route around the gate.
• An audit trail by default. What shipped, who owns it, who has access, and when each of those changed. Retained, and written by the platform whether or not the app remembers to log.
• Observability past uptime. Defects, rework, exceptions, failures. Counting apps and users looks like progress while it hides rising rework and security exposure. The signals Gartner says are worth watching are prototype-to-production conversion and reuse rate.²
• Cost attributed to the app and the team. Model, token and compute spend, broken down far enough that someone can answer for it. If you can’t see what an app spends, you can’t stop a runaway one.
• A named owner, always. No app enters production unowned. The person who prompted it isn’t automatically the person accountable for running it, and the model needs to say who is.

All six attach at one moment: the app going live. That’s the design principle of the control layer. None of them should depend on a builder asking for them, because builders in a hurry won’t ask.

If identity, audit and ownership arrive as part of deploying, every app that goes live has them. If they arrive as a follow-up request, a share of apps never get them, and you won’t know which.

Foundation: three services under everything

The foundation is the kernel that every app and every control above runs on. Three services matter.

A credential broker

Credentials are held centrally and referenced by alias. The app asks for “the CRM connection”, the broker resolves it, and the secret itself never appears in code, in a config file, in a chat window or in a repository. Rotation happens in one place. Builders never handle a secret, and neither does the assistant writing the code.

This is the foundation decision that constrains all the others. If secrets live in the app, every other control is decoration. You can put SSO in front of an app and keep an immaculate audit trail of who opened it, and the API key in its source still works for anyone who copies it.

The test to put to any platform, including one you build: when this app calls a system of record, where is the credential? If the answer is “in the app”, you have a secrets-sprawl problem with a nicer dashboard.

A project service

The project service owns the deploy lifecycle and versioning. Architects care about this one most, because it guarantees that what passed review is what ships, and that a bad release can be rolled back to a known version. Without it, the validation layer checks one thing and production runs another.

A runtime

Managed execution, with integration and core security built in, and no infrastructure to provision for each app. This is where the economics sit. If every new app needs its own hosting setup, its own database and its own on-call arrangement, the cost of running apps grows with the number built, and the number built is the curve that went vertical.

Map your own stack

Take the three layers and mark what you already have. Most organizations find foundation pieces (a cloud account, an identity provider, a secrets manager the platform team uses) and a surface they didn’t choose. The control layer, the one that attaches identity, ownership, audit and cost at the moment an app goes live, is usually empty. That’s where the work is, whoever does it.

Where Tray Helix fits

Tray Helix is one implementation of this model. On the surface, builders keep the assistant they use and deploy with one command from it. In control, every app deployed through Helix gets enterprise SSO and scoped roles, a registry entry with a named owner, an audit trail, and activity, logs and AI and compute spend on record. The foundation is the Tray platform: the managed runtime, a credential broker built on Tray auth aliases so no secret sits in an app, and connectors into the systems apps need to reach. Helix governs what’s deployed through it, and leaves code-level checks to the development layer where they belong.