Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
Where most AI governance stops
AI governance programs usually begin with the model. Which models are approved, what data may go into a prompt, how outputs are logged, which vendors have signed the right agreements. That work matters, and it ends before the moment an agent changes something in production.
The gap shows up when an agent is given a task like resizing a database or adding a queue. Your model policy has nothing to say about it. Your code scanner sees, at most, the Terraform the agent wrote. The decision that counts, whether this actor may make this change in this environment, falls to cloud IAM and to whoever reviews the pull request, if there is one.
Governing AI infrastructure changes does not need a new security stack. It needs every agent-originated change to enter the infrastructure change control you should already have, and to leave the same evidence as a change from a person.
The controls you probably have, and where each one stops
Keep all of these. The question is whether any of them sits between an agent and a production change.
Control
What it covers
Where it stops
AI gateway or model governance
What it covers
Which models are allowed, what data reaches them, and a log of prompts and outputs.
Where it stops
It sees the conversation. It does not see or decide the cloud change the agent makes afterward.
SAST and code review
What it covers
Findings on the code the agent generates.
Where it stops
An agent that calls a cloud API directly produces no code to review.
Cloud IAM
What it covers
Precise control over which API calls an identity may make.
Where it stops
IAM cannot express a rule like “this team may deploy the approved Postgres module in dev and may only propose changes in production.”
OPA or Sentinel on Terraform runs
What it covers
Strong policy at plan time, with rules you can version and test.
Where it stops
The policy applies to changes that go through that system. An agent holding a cloud key can skip it.
A separate AI sandbox
What it covers
Containment while agents experiment.
Where it stops
A second estate with its own path to production, which is the thing you are trying to avoid.
Massdriver
What it covers
One execution path for every actor. Agents hold scoped Massdriver tokens, policy runs before each deploy, approvals follow your rules, and every change is recorded.
Where it stops
You define the catalog, the policies, and the grants for each group of actors.
Separate the permissions an agent needs
Most of the risk in agent access comes from bundling these together in one credential. In Massdriver each is its own grant, set by policy on environment, team, and blast radius.
01
Design
Read the catalog and the graph of what is running, so the agent can plan a change against your real estate. A design changes nothing.
02
Propose
Submit a change to a specific instance. The proposal is validated against the bundle’s schema and waits for someone who can deploy it.
03
Approve
Decide whether a proposed change ships. With separation of duty on for an environment, the account that proposed a change cannot approve it.
04
Deploy
Run the change. Teams usually grant this to agents in dev and preview first, and widen it by changing grants and blast-radius attributes as trust builds.
How an agent change moves from request to apply
An agent working on a latency ticket decides the orders database needs a larger instance class in production.
What happensWhat the record shows
- 01What happens
The agent queries the graph for the database, the services that depend on it, and the instance classes the bundle allows.
What the record showsA read. The agent’s plan is based on what is actually deployed.
- 02What happens
The agent proposes the new instance class on the production instance.
What the record showsThe proposal names the agent’s service account, the instance, and the parameter change.
- 03What happens
Massdriver checks the proposal against the bundle’s schema and runs policy checks on the plan.
What the record showsSchema validation and policy results are attached to the change.
- 04What happens
The agent has no deploy grant in production, so the change waits. A person with deploy permission reviews the diff and the policy results, and approves.
What the record showsThe approver is recorded, separate from the proposer.
- 05What happens
Massdriver applies the change with credentials the agent never held.
What the record showsThe deploy, its diff, and its result join the instance’s deployment history.
The evidence security and auditors ask for
Change-management controls ask the same questions whether a person or an agent made the change. Each Massdriver change answers them.
- Who proposed it. The person, pipeline, or agent service account.
- Who approved it. A named approver, recorded separately from the proposer.
- What changed. The diff, the bundle version, and the parameters.
- Which checks ran. The results of the policy checks (SOC 2, HIPAA, CIS) that ran before the deploy.
- What it touched. The inventory shows each resource’s owner, environment, and dependencies, and the record can be exported for an audit.
Questions security architects ask
Is this AI governance or cloud governance?
Cloud change governance, applied the same way to AI callers. The standards for an infrastructure change do not depend on who requested it.
Does Massdriver inspect prompts?
No. Keep your model and prompt governance where it is. Massdriver governs the infrastructure action the agent takes.
Do our existing policies still apply?
Yes. The policies your provisioners run apply to every change, whoever proposed it.
Which checks run automatically?
Schema validation runs on every proposal, and policy checks (SOC 2, HIPAA, CIS) run on the plan before every deploy.
What if we do not want agents touching production at all?
Do not grant them deploy permission there. They can still design and propose, and a person decides.
When IAM and code review are enough
If your agents only write application code, and every infrastructure change goes through a pull request that a person reviews and applies, your current controls cover the risk. The calculation changes when agents start acting on infrastructure themselves, or when the volume of generated changes outgrows the people reviewing them.
For the control-by-control view, the executive brief maps these records to SOC 2, PCI DSS, NIST AI RMF, and ISO/IEC 42001. A mapping shows where the evidence fits. Your auditor decides what satisfies a control.
Test it against one real application
Pick one application that agents already touch and one environment where its changes matter. Move its infrastructure onto the governed path, give the agents propose-only access in that environment, and keep everything else as it is. After 30 days you can count the agent changes that went through policy and approval, see how many an approver rejected, and hand your auditor the record of each one.
If the record answers the questions your security team asks today, widen the scope. If it does not, you have lost nothing, and the modules are still your own Terraform, OpenTofu, and Helm.
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.