Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS

Register Here!

Infrastructure change control with one governed path for every change

Changes reach production from more places every year: developers, CI pipelines, business workflows, and now AI agents. Each source tends to arrive with its own credentials, its own review step, and its own logs, so nobody can say in one place who changed what and who allowed it.

Massdriver puts every change on the same path. Each actor holds a scoped identity, policy runs before every deploy, approvals follow your rules, and every step lands in one audit trail.

Get My Platform BuiltHow agents fit in
Changes from a developer, a CI pipeline, a business workflow, and an AI agent all enter one governed path. Each change gets a scoped identity with no cloud key, comes from an approved bundle with validated inputs, runs policy checks on the plan, gets a second person to approve production, deploys with Massdriver’s credentials, and writes an audit event for each step. The production record shows the agent that proposed the change, the lead who approved it, and the deployed result.

Changes reach production from more places than your controls cover

Most change processes were designed around engineers. A pull request, a reviewer, and a pipeline with a cloud role. Then CI jobs got roles of their own, a workflow tool got an API key, and coding agents arrived holding whatever credentials the person running them had.

Each of those paths has its own controls. Some go through review and some do not. The cloud audit log shows a role or a key, so when something breaks, finding the person, pipeline, or agent behind the change takes a day of correlation across systems.

Change control for infrastructure means one path that every source has to take, with the same identity, policy, approval, and record, whoever or whatever started the change.

How teams control infrastructure change today

Most organizations run several of these at once. The gaps show up between them.

  • Pull request review and CI

    What it covers

    A reviewed diff for every change that lives in the repository, and a pipeline that applies it.

    What it leaves open

    Changes made outside the repository, broad cloud roles held by CI and agents, and approvals that live in branch protection instead of in the environment.

  • Change tickets and a change board

    What it covers

    A documented approval for each change, in a system your auditors already know.

    What it leaves open

    A record that is separate from what actually ran, and a wait that pushes teams to find a faster route.

  • Cloud IAM and service control policies

    What it covers

    Hard limits on what a role can do in an account, enforced by the cloud provider.

    What it leaves open

    Rules like “propose in production, deploy in staging” or “this team may change non-production databases.” The logs name the role, not the person or agent.

  • Policy as code in the runner

    What it covers

    Sentinel or OPA checks on every plan that goes through that runner.

    What it leaves open

    Changes that take another route. Identity and approvals stay in other systems.

  • Massdriver

    What it covers

    One path for every actor: scoped tokens, attribute-based access by environment, team, and blast radius, policy checks before every deploy, separation of duty, and one audit trail.

    What it leaves open

    Writing the modules and the rules for who may change what, which your platform and security teams already own.

The architecture of one governed path

Every change takes the same six steps, whether it starts in the UI, the CLI, CI, the API, or an AI agent through the MCP server.

Identity

People sign in through SSO with Okta, Microsoft Entra ID, or any SAML or OIDC provider, and SCIM adds and removes them. CI jobs and agents use service accounts with tokens that expire, and service accounts are their own actor type.

Credential scope

No actor holds a cloud key. Massdriver holds the cloud credentials and uses them only for deploys that policy allows.

Catalog

Every change uses an approved bundle, and its inputs are validated against the bundle’s schema. A change can only use values your platform team allows.

Policy

Attribute-based policies on environment, team, and blast radius decide who may plan, propose, or deploy. Policy checks (SOC 2, HIPAA, CIS) run on the plan before apply.

Approval

Proposing a change and deploying it are separate permissions. With separation of duty on for an environment, the account that proposed a change cannot approve it.

Record

Each proposal, plan, approval, and deploy is an audit event with its actor. Deployment history shows what changed, and rollback returns an instance to its last good state.

One database change from three sources

A coding agent tuning the checkout service wants a larger instance class on the orders database. The same change has to pass through staging and production.

  1. 1

    The pipeline deploys it in staging

    The release pipeline applies the new instance class in staging with its service account. Policy checks run on the plan, and the deploy uses Massdriver’s credentials.

  2. 2

    The agent proposes it in production

    The agent’s group may deploy in dev and staging and only propose in production, so the change becomes a proposal. The proposal names the agent’s service account, the instance, and the parameter it changed.

  3. 3

    Policy runs on the production plan

    Massdriver validates the proposal against the bundle’s schema and runs the policy checks on the plan. The plan diff and the results are attached to the proposal.

  4. 4

    A person approves

    A database lead with deploy permission in production reads the diff and the policy results, and approves. Separation of duty means the agent could not approve its own change.

  5. 5

    Massdriver deploys

    The deploy runs with Massdriver’s credentials. The agent never held a cloud key, and neither did the pipeline.

  6. 6

    The record answers the audit question

    The audit trail shows the pipeline that ran the change in staging, the agent that proposed it in production, the lead who approved it, the diff, and the result.

When your current controls are enough

Pull request review and a single pipeline can cover change control for a small, steady estate. Massdriver earns its place when the number of change sources grows.

Every change goes through one repository and one pipeline
If nothing reaches production any other way, branch protection and pipeline review already put every change in one place.
Production belongs to a few people on one team
When the same engineers make and review every production change, a separate approval system adds little.
No agents or workflows change infrastructure yet
Once they do, each needs credentials and a review path, and that is where the gaps appear.

Massdriver in two minutes

A two-minute overview of how changes move from the catalog to production under policy.

Infrastructure change control questions

No. Your policies decide. A common setup lets changes in dev and preview environments deploy on policy checks alone, and requires a second person for production or for changes above a blast radius you set.

Massdriver records the change itself: who proposed it, who approved it, the plan, and the result. If your process needs a ticket for each change, the ticket can point to that record.

Agents take the same path as everyone else. An agent gets a scoped service account token through the Massdriver MCP server, proposes changes, and a person with deploy permission approves where your rules require it.

Massdriver cannot revoke credentials you have handed out elsewhere. It makes the governed path the one that needs no cloud key, so you can remove broad roles from CI jobs, agents, and people one at a time.

Each proposal, plan, approval, and deploy is an audit event with its actor, and deployment history keeps the diff and the result. The SOC 2, HIPAA, NIST AI RMF, and EU DORA pages map these records to specific controls.

Yes. Massdriver Self-Hosted installs with a Helm chart on your own Kubernetes cluster, and state, secrets, and audit records stay in your environment.

Yes. Your platform team keeps writing Terraform, OpenTofu, and Helm. Massdriver adds the schema, policy, and approvals around each module and runs it.

Related reading

Get your platform built.

Give us an hour with your platform and security leads and have a working governed path to production on your own infrastructure within a day, then prove it for 30 days. If you stop, you keep the code.

Get My Platform Built