Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!Why a cloud key in an agent is a production risk
A cloud credential does not know who is using it. An agent with an access key or an assumed role can create, change, or delete anything the role allows, in every environment the role reaches, and the cloud audit trail shows the role, not the agent. Narrowing IAM per agent and per environment becomes a second permission system the platform team maintains by hand.
How the access is split
The agent holds a Massdriver token
The token belongs to a service account with an expiry you set. The agent receives it through the Massdriver MCP server’s environment and never sees a cloud key.
Policy decides what the token may do
The service account belongs to a group, and the group’s attribute-based policies say which actions it may take on which environments, projects, or teams.
Massdriver holds the cloud credentials
AWS, Azure, and GCP credentials stay in Massdriver, which uses them only for deploys the policy allows.
Production needs a person
Proposing a change and deploying it are separate permissions, so an agent can propose a production change while a person with deploy permission decides.
The configuration
Field names are the API’s. Values are illustrative. Revoking the token or removing the service account from its group ends the agent’s access, with no cloud IAM change.
Watch Architect work inside those controls
A two-minute demo: a developer describes an app in Claude Code, and Architect builds it only from the approved catalog, under the same policy as every other change.
In production
“Massdriver’s platform has revolutionized our approach to infrastructure, saving us 89% of the time spent managing infrastructure. Our operation could upscale by an order of magnitude.”

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.