How should organisations govern AI agents that can provision cloud resources?

Why This Matters for Security Teams

AI agents that can provision cloud resources sit at the intersection of automation, privileged access, and software supply chain risk. That makes them materially different from chatbots or approval helpers. Once an agent can create roles, modify security groups, spin up workloads, or attach secrets, it has operational reach that can outpace human review unless governance is explicit. Current guidance in NIST AI Risk Management Framework and agentic security research both point to the same issue: autonomy must be bounded by policy, traceability, and ongoing oversight.

The practical risk is not only malicious misuse. A well-intentioned agent can still overprovision, select the wrong environment, inherit broader permissions than intended, or expose secrets through a tool call. In cloud environments, those mistakes become durable because infrastructure changes can persist long after the prompt or workflow that caused them has ended. That is why governance needs to treat the agent as a machine identity with a narrow blast radius, not as a convenience layer attached to a human session. In practice, many security teams encounter the real failure only after an agent has already created standing access or modified production resources, rather than through intentional design.

How It Works in Practice

Governance starts by defining the agent’s purpose, target systems, and allowed actions in machine-readable policy. For cloud provisioning, that usually means mapping each task to a tightly scoped role, then binding the agent to short-lived credentials, approval gates, and environment-specific limits. The agent should not be able to retrieve broad secret stores or assume privileged roles unless a separate control explicitly authorises it. This is consistent with the direction of OWASP Top 10 for Agentic Applications 2026 and the defensive focus in MITRE ATLAS adversarial AI threat matrix.

Operationally, teams should build the following controls around the agent:

• Separate identity and authorization from the human requester so the agent cannot inherit excess permissions.
• Use just-in-time credentials with automatic expiry tied to job completion, workflow closure, or explicit cancellation.
• Log every tool call, parameter, and resulting cloud change so change review can reconstruct intent and outcome.
• Require policy checks for risky actions such as IAM changes, network exposure, secret creation, and production deployment.
• Maintain rollback paths for every agent-authorised infrastructure action, including drift detection and reversion workflows.

Monitoring should look for tool misuse, prompt injection effects, and unexpected privilege escalation paths, especially when an agent can interact with orchestration APIs or infrastructure-as-code pipelines. The strongest designs also separate planning from execution, so an agent can propose changes while a narrower control plane performs the actual provisioning. That approach aligns with the governance emphasis in NIST Cybersecurity Framework 2.0 and helps security teams keep the agent inside auditable bounds. These controls tend to break down when the agent is allowed to chain tools across multiple cloud accounts because policy inheritance and token reuse become difficult to contain.

Common Variations and Edge Cases

Tighter governance often increases workflow friction, so organisations have to balance speed of provisioning against the cost of review, logging, and rollback design. That tradeoff becomes sharper in fast-moving engineering teams, but current guidance suggests the added control is justified wherever the agent can make persistent infrastructure changes.

One common edge case is delegated administration in multi-account or multi-tenant cloud environments. An agent that can provision in dev may still need a different trust boundary before it can touch shared services, identity systems, or production landing zones. Another is “human-in-the-loop” approval, which helps but does not solve everything if approvers cannot see the exact resource graph or inherited permissions. For that reason, approval should be paired with policy as code and post-change validation, not used as a substitute for authorization design.

Another emerging issue is agent-to-agent delegation. Best practice is evolving, and there is no universal standard for this yet. If one agent can call another to complete provisioning, the security team must know where authority begins and ends, how delegated actions are logged, and how revocation propagates. For agentic systems that touch cloud infrastructure, governance should also consider the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and the threat patterns described in the CSA MAESTRO agentic AI threat modeling framework. Where the agent can mint or rotate secrets, revoke access, or alter trust policies, lifecycle controls must be stricter than for ordinary automation.

Related resources from NHI Mgmt Group

• How can organisations govern AI agents that use service accounts and tokens?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?