Beyond a Basic PaaS: How 8 Platforms Actually Govern AI Agents That Provision Infrastructure

Key Points:

• A basic PaaS cannot govern AI agents because it models exactly one actor: a human pushing a container. It has no per-agent non-human identity, no policy evaluation before execution, no approval gate on high-risk actions, no per-actor spend cap, and no audit record tying a change to an agent version and a commit.
• No single platform delivers AI agent infrastructure governance end to end in 2026. Working stacks combine three layers: identity and policy (AWS IAM plus Bedrock AgentCore, Microsoft Entra Agent ID plus Azure AI Foundry, Google Vertex AI Agent Engine); an infrastructure control plane (Upbound/Crossplane, HashiCorp Terraform plus Sentinel plus Vault, or Pulumi with CrossGuard and ESC); and a deployment and runtime layer that enforces environment isolation, RBAC, and cost limits.
• Demand six testable controls from any candidate: scoped non-human identity per agent, policy-as-code evaluated before apply, human approval gates on defined high-risk classes, hard environment isolation, cost guardrails with TTL and auto-stop, and a tamper-evident audit trail linking agent identity to commit.
• The rule that prevents most incidents: the agent proposes, a deterministic pipeline applies. Agents open a pull request or file a resource claim, never hold long-lived production credentials, and receive short-lived credentials brokered at apply time.
• Pick by hardest constraint, not brand. Single cloud with tool-calling agents: use the hyperscaler-native runtime. Agents creating real cloud resources: put Crossplane claims or a Terraform plus Sentinel pipeline between the agent and the cloud API. Multi-cloud, hybrid, or an existing Kubernetes cluster: use a cloud-agnostic deployment layer such as Qovery plus one policy engine you standardize on.

---

Last quarter a friend running platform at a mid-size fintech told me an agent had opened a managed Postgres instance in the wrong region, on a long-lived AWS key someone had pasted into the agent's environment variables months earlier. Nobody could say which agent, which run, or which prompt did it, because every action in the log read "ci-deployer." That single shared credential in an env var is the most common failure mode I see, and it is exactly what a basic PaaS leaves you with.

Here is the direct answer to the question I get asked most: no hyperscaler-native platform governs autonomous agents on its own, but three do the identity-and-guardrail work well inside their own cloud - Amazon Bedrock AgentCore, Microsoft Azure AI Foundry with Entra Agent ID, and Google Vertex AI Agent Engine. Real AI agent governance is a three-layer problem: identity and policy, an infrastructure control plane, and a deployment and runtime layer. The rest of this article names the eight platforms that cover those layers, scores them against six controls, and gives you a decision table. The stakes are not theoretical: Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls (Gartner).

Why does a basic PaaS break down when AI agents start provisioning infrastructure?

A basic PaaS breaks on agentic workloads because it models one actor, a human pushing code, while an agent calling cloud APIs needs its own identity, a policy check before it executes, an approval gate on high-risk actions, and an immutable record of what it did. A git-push-to-container PaaS supplies none of those, so teams end up pasting a long-lived cloud key into an agent's environment variables and hoping.

The five structural gaps, in one scannable list:

• No per-agent non-human identity. The agent borrows a human or CI account, so the audit trail cannot tell you which agent acted.
• No pre-execution policy evaluation. A PaaS deploys what it is handed. There is no deny-by-default check on resource types, regions, or account targets before the change lands.
• No human-in-the-loop gate. There is no built-in "a person must approve this" step for irreversible actions.
• No per-actor cost limit. Spend caps, where they exist, are per-app, not per-agent or per-resource-class.
• No immutable action log tied to intent. You cannot reconstruct which agent version, prompt, and commit produced a given change.

Long-lived shared credentials in env vars are the failure mode that hurts most, because the agent inherits far more permission than the task needs, and revoking that secret means rotating a key that every service shares. Non-human identities already dominate the estate: CyberArk's 2025 landscape research reports machine identities outnumbering human ones by roughly 82 to 1, with 42% of them holding privileged or sensitive access (CyberArk). An agent is one more of those, moving at machine speed.

Two more properties make agents different from a CI job. They are non-deterministic, so the same prompt can produce a different plan on the next run, which means governance has to happen at execution time, not at code-review time. And their cost blast radius is real: a retry loop that provisions GPU nodes or managed databases can run for hours before anyone notices, and a request/response PaaS models none of the durable state, retries, queueing, or concurrency limits that multi-step agent orchestration needs.

So here is the frame I will use for the whole article, the three layers a governed agent stack actually needs:

1. Identity and policy - who the agent is, and what it is allowed to ask for.
2. Infrastructure control plane - how a request becomes real cloud resources, safely, with policy checked before apply.
3. Deployment and runtime - where the agent and the applications it changes actually run, with isolation, RBAC, and cost limits enforced.

Most competitor comparisons conflate these three. Keeping them separate is what makes the rest of this readable.

What does "governance" mean for autonomous AI agents, and which six controls should you demand?

AI agent governance is six concrete, testable controls: a scoped non-human identity per agent, policy-as-code evaluated before execution, human approval gates on named high-risk actions, hard environment isolation, cost guardrails with TTL and auto-stop, and a tamper-evident audit trail linking every change to an agent identity and a commit. If a platform cannot demonstrate all six, your job is to name which of the three layers supplies the rest.

Mapped to the three-layer frame, here is what each control means and who owns it.

A few of these deserve a sharper definition:

• Non-human identity means per-agent, short-lived credentials with least privilege. On AWS that is an IAM role assumed via STS; on Azure it is Microsoft Entra Agent ID; on Google it is a service account with Workload Identity Federation.
• Policy-as-code for AI agents means deny-by-default rules on resource types, regions, instance families, and account targets, evaluated before anything is applied.
• Human-in-the-loop gates only work if you write down the high-risk classes explicitly: IAM and permission changes, data deletion, cross-account networking, production writes, and spend above a threshold.
• Cost guardrails need both ends. Account budgets and quotas at the top stop the category; TTL on agent-created resources and auto-stop for idle non-production at the bottom stop the drip. You need both, not one.

Compliance teams will ask how this maps to the frameworks they already track. The six controls line up cleanly with the NIST AI Risk Management Framework's four functions - Govern, Map, Measure, Manage (NIST) - and with ISO/IEC 42001, the certifiable AI management system standard published in 2023 (ISO). The audit-trail control has a regulatory anchor too: Article 12 of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events (logs) over their lifetime (EU AI Act, Article 12). The phased deadlines for high-risk obligations were revised by the 2026 Digital Omnibus and some now land as late as December 2027, so do not treat a specific date as binding today, but the direction of travel toward automatic, retained, exportable logs is not in doubt. The governance gap is wide: the Cloud Security Alliance found only 20% of organizations have a formal process to offboard and revoke API keys (Cloud Security Alliance).

The one-line self-test I use: if an agent deleted a production database at 3am, could you name the agent, the credential it used, the policy that allowed it, and the commit? If any of those four is a shrug, you have a gap.

Which hyperscaler-native platforms are built for AI agent orchestration and governance?

All three hyperscalers now ship a first-party agent runtime with identity and guardrail primitives - Amazon Bedrock AgentCore, Microsoft Azure AI Foundry with Entra Agent ID, and Google Vertex AI Agent Engine - and each governs what an agent says and calls very well inside its own cloud while governing nothing outside it. Treat them as layer one, the identity-and-policy layer, not the whole stack.

AWS. Amazon Bedrock AgentCore reached general availability in October 2025 (AWS) and ships as a set of modules: AgentCore Runtime, Identity, Gateway, Memory, Observability, Code Interpreter, and Browser (AWS docs). Each session runs in a dedicated microVM with isolated CPU, memory, and filesystem, sanitized on termination. Around it you get Amazon Bedrock Guardrails for model-level content and topic filtering (AWS docs), IAM roles for agent identity, CloudTrail for audit, and Service Control Policies plus AWS Budgets as the outer fence.

Microsoft. Azure AI Foundry Agent Service is the managed runtime, and Microsoft Entra Agent ID gives each agent a first-class identity in your Entra directory, assigned automatically to agents built in Azure AI Foundry and Copilot Studio (Microsoft Learn). Entra Agent ID was announced at Microsoft Build in May 2025 (Microsoft) and has since moved to general availability. Azure Policy handles resource guardrails, Microsoft Purview covers data governance, and Azure Monitor carries the traces.

Google. Vertex AI Agent Engine provides a managed runtime with Sessions and a Memory Bank, and deploys agents you build with the open-source Agent Development Kit (Google Cloud). Model Armor screens prompts and responses for prompt injection, jailbreak, and sensitive data (Google Cloud), while the Organization Policy Service and IAM Conditions constrain what an agent's service account can touch. Note that some pieces, such as the Example Store, are still in preview.

OpenAI. OpenAI AgentKit, announced at DevDay in October 2025 (OpenAI), and the Agents SDK are strong at orchestration, tool-calling, guardrails, and evals, and explicitly are not an infrastructure control plane. The SDK guards agent behavior and data inside OpenAI's own platform, not your cloud's compute, networking, or IAM. State that boundary out loud so nobody files it under the wrong layer. (One 2026 caveat: OpenAI is retiring the visual Agent Builder in favor of the Agents SDK, so build on the SDK.)

Here is how the four compare on the primitives that matter.

What all three hyperscalers do well: managed session isolation, model-level guardrails, per-agent identity, and native audit into the cloud's own log sink. What none of them do: govern a multi-cloud or hybrid estate, govern the deployment of the agent's own application infrastructure, or hand developers governed self-service environments with RBAC. The trade is plain. You buy managed identity and isolation primitives, and you pay in single-cloud lock-in.

Should AI agents provision infrastructure through Crossplane/Upbound, Terraform, or Pulumi?

If agents must create real cloud resources, never let them call the cloud API directly - put a declarative control plane between the agent and the cloud. That control plane is layer two, and it is where the hardest guardrails for AI agents provisioning infrastructure live. Upbound with Crossplane is the strongest answer when you want to constrain exactly what an agent can ask for, HashiCorp Terraform with Sentinel and Vault is the strongest answer for pre-apply policy plus short-lived credentials, and Pulumi with CrossGuard and ESC is the strongest answer when agents generate code rather than fill in a template.

Upbound / Crossplane. The agent files a claim against a Composite Resource Definition, the platform team defines the allowed shape, and Kyverno or OPA Gatekeeper admission policies deny anything out of bounds. Drift is continuously reconciled back to declared state. Crossplane is a serious foundation: it graduated to the top CNCF maturity level in October 2025 (CNCF), and Upbound is the company behind it (Upbound). Kyverno, the policy engine many teams pair with it, also graduated in the CNCF in 2026 (CNCF). This is the best answer when your goal is to constrain, precisely, what an agent is even able to request.

HashiCorp (now part of IBM, since February 2025 (IBM)). Terraform with Sentinel gives you policy sets at three enforcement levels - advisory, soft-mandatory, and hard-mandatory (HashiCorp) - plus a private module registry to constrain what agents can call. Vault dynamic secrets issue credentials with a lease and TTL, so they auto-expire and get revoked without anyone rotating a shared key (HashiCorp). This is the best answer for pre-apply policy plus short-lived credentials.

Pulumi. CrossGuard policy packs enforce at three levels - advisory, mandatory, and remediate (Pulumi) - and you write them in TypeScript, Python, or Rego. Pulumi ESC issues short-lived OIDC credentials for AWS, Azure, and GCP (Pulumi). Because Pulumi is real-language IaC, it is the best fit when agents write code rather than fill in a template, and that flexibility is exactly why it demands harder gates and mandatory review.

Red Hat. OpenShift with Advanced Cluster Management gives you a policy-driven governance framework across clusters (Red Hat), and Ansible Automation Platform can remediate a policy violation automatically. This is the pragmatic answer for regulated and hybrid estates that already live on OpenShift.

The pattern that actually works across all four is the same: agents never hold cloud admin keys, they open a pull request or file a claim, and a deterministic pipeline applies it with credentials brokered at apply time. The core trade-off is also the same. Templates constrain agents best and frustrate them most; free-form code is more capable and needs harder policy gates. And every one of these leaves the same gap: none of them run the agent's own application environments with developer RBAC and cost auto-stop. That is layer three, and it is why the matrix below has one more row.

This is the table to bookmark. Every cell is verifiable from vendor docs.

Where does the deployment and runtime layer fit, and how does Qovery govern it?

The layer most teams forget is layer three, the one that actually runs the agent and the applications it changes, and it is where blast radius, developer RBAC, and cost containment get enforced in practice. Qovery covers that layer: it deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, with per-environment RBAC, ephemeral environments per pull request, environment auto-stop for non-production, and every deployment tied to a git commit.

Here is what that buys you, control by control:

• Blast radius by design. Each agent or agent fleet gets its own environment with its own scoped service credentials, so a bad plan cannot reach production. Isolation is the boundary, not a hope.
• Per-environment RBAC. You control which humans and which service accounts can deploy, restart, or promote through role-based access control. Promotion to production becomes the approval gate, held by a human role while the agent's token is scoped to preview and development.
• Ephemeral preview environments per pull request. Agent-generated changes get a real, disposable environment to be validated in before anyone merges.
• Environment auto-stop for non-production. Deployment Rules stop idle environments automatically, which is the single most effective cost guardrail when agents spin things up and forget them.
• Git-push deployments as the audit trail. Because deployments come from git, every running state maps to a reviewable diff, and the audit log records who or what triggered each action. That commit-to-running-state link is what auditors actually ask for.
• Managed cluster upgrades and databases backed by managed cloud services, so the platform team is not hand-rolling the substrate under the agents.

One sentence on BYOC, because this is a governance article and not a data-residency one: because Qovery runs in your own account, the cloud bill, any Savings Plans, the VPC boundaries, and data residency all stay in your name. That matters here because wasted spend is rising, not falling - Flexera's 2026 report put estimated wasted cloud spend at 29%, its first increase in five years (Flexera) - and every dollar auto-stop saves is your dollar.

Be explicit about the boundary, because fairness is what makes a comparison worth citing. Qovery is not an IaC policy engine and not an agent framework. It does not evaluate Rego against a Terraform plan, and it does not orchestrate an agent's reasoning loop. Pair it with Crossplane, Terraform plus Sentinel, or Pulumi for layer two, and with IAM, Entra Agent ID, or Google service accounts for layer one. Its honest place is layer three, and most teams running agents discover they need all three.

How do you choose an AI agent governance platform? A decision path by hardest constraint

Choose by the constraint that hurts most today and add the missing layers later. Single cloud with tool-calling agents means a hyperscaler-native runtime; agents creating cloud resources means Crossplane/Upbound or Terraform plus Sentinel in front of the cloud API; and multi-cloud, hybrid, or an existing Kubernetes cluster means a cloud-agnostic deployment layer such as Qovery plus one policy engine you standardize on.

Two constraints deserve a note. For a regulated industry - finance, health, public sector - make human approval mandatory on every production and IAM change, and keep OpenShift plus ACM or HashiCorp as the spine. For runaway cost, the FinOps Foundation's 2026 survey found 98% of practitioners now manage AI-related spend, up from 63% a year earlier (FinOps Foundation), which tells you the acute pain has already arrived; implement both the account budget and the auto-stop, because one without the other leaves half the leak open.

Run this six-question checklist in your next planning meeting. Every "no" is a layer you have not filled.

1. Does each agent have its own identity, distinct from any human or CI account?
2. Are its credentials short-lived and scoped to one environment, with no wildcard IAM?
3. Is policy evaluated before apply, deny by default, with no path to the cloud that skips it?
4. Is there a human approval gate on production, IAM, networking, and stateful data?
5. Do agent-created resources have a TTL and does idle non-production auto-stop?
6. Can you name the agent, credential, policy, and commit behind any change, six months later?

The reference architecture in one line: identity (IAM / Entra Agent ID / Google service account) into a policy engine (Sentinel / OPA / Kyverno) into a Crossplane or Terraform pipeline into Qovery environments in your own cloud account, with everything feeding one centralized audit sink.

What does a governed agentic deployment pipeline look like in practice?

The working pattern is one sentence: the agent proposes, a deterministic pipeline applies, and every step is scoped, policy-checked, and logged. The agent never holds production credentials, and every change lands with an agent identity, a policy decision, and a commit attached.

The flow, end to end:

1. The agent opens a pull request or files a resource claim. It does not touch the cloud API directly.
2. Policy-as-code evaluates the change, deny by default, before apply.
3. A human approves anything in a defined high-risk class.
4. The pipeline applies with short-lived credentials brokered at apply time.
5. The change validates in an ephemeral environment.
6. A promotion gate controls the move to production.
7. An audit record links the result to the commit and the agent identity.

Write down the high-risk action classes before you turn any agent loose: IAM and permission changes, data deletion, cross-account networking, production writes, and spend above a threshold. Everything else can be auto-approved or policy-gated so reviewers are not worn down by trivial clicks.

Two requirements teams skip and regret. First, observability: agent traces and infrastructure change logs have to live in one place, or you cannot answer "what did the agent do at 3am" during an incident review. Second, failure drills: rehearse a per-agent kill switch, credential revocation, environment teardown, and rollback to the last known good commit, and give each one a named owner. A kill switch you have never tested is a hope, not a control.

Name the anti-patterns so you can spot them in a design review: granting an agent an admin role "temporarily," letting agents apply straight to production, long-lived cloud keys in agent config, no TTL on agent-created resources, and one shared identity for a fleet of agents. Every one of those is the 3am-database story waiting to happen. OWASP catalogs the underlying risks as excessive agency (OWASP) and tool misuse (OWASP), and both point at the same fix: least privilege and approval gates.

If you only have a week, instrument two things first: a per-agent identity, and a TTL on everything the agent creates. Those two alone move you from "we hope the agent behaves" to "the agent is bounded and attributable," which is most of the distance.