Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
It usually starts with a discovery
Somebody in operations built a tool that reconciles onboarding records. It works, people use it, and then someone in security asks where it runs. The answer is a laptop, a personal AWS account, a hosting service nobody reviewed, or nowhere yet, because IT will not hand out cloud credentials and the builder has been waiting for weeks.
Citizen developer programs were designed for low-code tools. They govern the tool: who gets a license and which connectors are allowed. A builder with a coding agent produces ordinary code that runs on AWS, Azure, or GCP, so those controls never see it. The questions your risk team needs answered have moved to the infrastructure. What is running, what data does it read, who owns it, and who approved it?
This is an old problem with new volume. Cory O’Daniel wrote about it in The Citizen Developer: you cannot stop these builders, and the business does not want you to. You can decide what they are able to deploy.
What teams try first
Each response below is reasonable on its own. None of them decides where a citizen-built app runs or what it may touch.
Response
What it gives you
What it leaves to you
Ban coding agents
What it gives you
A clear policy that is easy to state.
What it leaves to you
The agents are already on people’s laptops. The work continues in personal accounts, where you have no visibility at all.
Code scanning and SAST
What it gives you
Findings on vulnerable code and leaked secrets, which you need anyway.
What it leaves to you
Scanning judges the code. It does not decide where the app runs, which database it connects to, or who approved the infrastructure.
Single sign-on for every tool
What it gives you
A record of who signed in to what.
What it leaves to you
Identity tells you who the builder is. It puts no limit on the architecture the builder’s agent creates.
Sandbox cloud accounts
What it gives you
A contained blast radius for each builder or team.
What it leaves to you
Sandboxes fill with unowned databases, public endpoints, and duplicate copies of sensitive data. There is still no path to production.
Route every request through platform tickets
What it gives you
An engineer reviews everything before it exists.
What it leaves to you
The platform team becomes the new bottleneck, and builders route around the queue.
Massdriver
What it gives you
Each group deploys only the capabilities you approved for it, holds a Massdriver token and no cloud key, and every app gets an owner and an audit record.
What it leaves to you
Your platform and security teams decide what each group may use, and they answer catalog requests for anything missing.
Govern capabilities instead of prompts
You cannot review every prompt a builder types. You can decide what their agent is able to deploy. Your platform and security teams publish the databases, compute, and networks the company already trusts, and then grant a slice of that catalog to each group.
A finance operations group might get one compute option and two approved data stores, in dev and staging only. A production release from that group needs an engineer’s approval. When the group’s needs grow, you widen the grant. Nothing about the builder’s workflow changes.
An HR builder’s app, from prompt to inventory
An HR operations analyst asks Claude Code for a tool that reconciles new-hire records against the HR warehouse. Massdriver Architect handles the infrastructure.
What happensWhat your teams can see
- 01What happens
Architect checks what the analyst’s group may use before it plans anything.
What your teams can seeA read against the catalog. Nothing changes in your cloud.
- 02What happens
The records the tool needs already live in an approved, restricted warehouse. Architect gives the app access to that warehouse.
What your teams can seeNo new data store, and no export of restricted data to a laptop or a new bucket.
- 03What happens
The tool also needs to read from the HR system, and the catalog has no approved connector for it. Architect files a catalog request with the platform team.
What your teams can seeThe gap becomes a request your platform team can see and answer.
- 04What happens
Policy checks run, and the app deploys to dev under the analyst’s Massdriver token.
What your teams can seeThe deploy is recorded with the analyst as the actor, along with the policy results and the diff.
- 05What happens
The analyst proposes a production release, and an engineer with deploy permission approves it.
What your teams can seeThe approver is named on the change.
- 06What happens
The app appears in the inventory with its owner, team, environment, and the restricted data it reads.
What your teams can seeYour risk team can answer what is running and who owns it from one place.
What a business builder can do, and what stays with engineering
A typical starting grant. Every line is a policy you can change by group and by environment.
- Deploy approved bundles to dev and staging. The builder’s agent chooses from the slice of the catalog their group was granted.
- Propose a production release. An engineer with deploy permission on production approves it or sends it back.
- Ask for a capability the catalog lacks. The request goes to the platform team, who decide whether to publish a new bundle.
- Hold a Massdriver token and never a cloud key. Massdriver keeps the cloud credentials and uses them only for deploys that policy allows.
- Hand the app to engineering. The infrastructure is plain Terraform, OpenTofu, or Helm from your own catalog, so engineering takes it over without a rewrite.
When the builder moves on
Citizen-built apps outlive the projects that created them. The analyst changes roles, and a tool that half the department depends on has nobody who knows how it was deployed. With Massdriver the infrastructure, the owner, the dependencies, and the change history are already in the platform. Engineering reassigns the owner and keeps running the app on the same bundles every other service uses.
Questions risk and platform teams ask
Are you saying business users should deploy to production?
No. Their apps should enter the same governed path as everything else. Most teams keep production behind an engineer’s approval for these groups.
Do builders need to understand AWS or Terraform?
No. Their agent works from the catalog, and the only infrastructure decisions open to them are the ones your platform team chose to expose.
Can we limit a group to a few services in dev?
Yes. Catalog access and actions are scoped by group and environment through attribute-based policy.
What happens when someone asks for something we have not approved?
The agent cannot deploy it. The request goes to the platform team as a catalog request, where it can be approved, published as a new bundle, or declined.
Does this replace our Power Platform or low-code governance?
No. Keep those controls for low-code tools. Massdriver covers the apps that are ordinary code running on your cloud.
Start with one group and one app
The fastest way to test this is a single team that is already building. Pick the group, decide the slice of the catalog it may use, and move one real app onto the governed path. In 30 days you know how many requests the catalog could not meet, how many changes needed an approver, and whether your risk team can answer its questions from the inventory.
One governed path, for agents and every other change.
Give us an hour with your platform and security leads, and within a day you have a governed path running on your own infrastructure, ready to prove for 30 days.