How to secure AI agents in the cloud

AI agents are no longer experimental. They plan tasks, call tools, execute code, and take action in live systems with real credentials and real permissions. A compromised agent does not return a misleading response. It modifies infrastructure, exfiltrates data, or escalates privileges before anyone notices.

The security practices around AI agents have not kept pace with their deployment. Most guidance focuses on the model layer: prompt filtering, output validation, and tool call authorization. The infrastructure layer, where execution is isolated, credentials are managed, access is controlled, and every action is logged, is what ultimately limits what a compromised agent can do. This article covers those controls.

Traditional application security assumes a defined, predictable flow. Inputs arrive at defined endpoints. Outputs are defined outputs. The attack surface is the application boundary.

AI agents break this assumption. An agent reasons about which tools to call and in what order. It can chain a file read to a database query to an API call to a code execution step. The path between input and output is not defined in advance. It is determined at runtime by the agent's reasoning.

This creates specific security risks that traditional controls were not designed for:

• Prompt injection: An agent processing external data, a web page, an email, or a document can be manipulated by content in that data to take actions outside the intended task. A malicious document that contains instructions the agent follows as if they were from the user is a prompt injection attack. Traditional input validation does not catch this because the agent's reasoning is the parser.
• Credential accumulation: Agents need credentials to access databases, call APIs, and interact with cloud services. As the scope of agent tasks grows, credentials accumulate. An agent with access to a CRM, a code repository, a file store, and an external API has a large blast radius if compromised. Many organizations do not yet have a complete inventory of the credentials their agents hold.
• Tool misuse: An agent given a tool can use that tool for purposes outside the intended task. An agent with file system access can read files outside the working directory. An agent with API access can make calls to endpoints outside the intended integration. Without constraints at the platform layer, tool misuse is limited only by what credentials the agent holds.
• Lateral movement: A compromised agent can use its existing permissions to move laterally across systems. Agents move between clouds and SaaS platforms, frequently bypassing standard identity monitoring and creating blind spots across the broader environment.

Model-layer controls reduce the likelihood of an agent taking an unintended action. Infrastructure-layer controls constrain what an agent can do, even if it is manipulated or compromised. Both layers are required. This article focuses on the infrastructure layer.

AI agents that execute code at runtime, including code interpreter features, shell command execution, and any workload that runs user-submitted or agent-generated code, need hardware-isolated execution environments.

Standard container isolation shares the host kernel across workloads. A compromised agent execution can affect adjacent workloads, read from the host filesystem, or escalate privileges to the host. MicroVM isolation using Kata Containers with Cloud Hypervisor or Firecracker provides each execution with its own dedicated kernel. gVisor adds isolation by intercepting system calls in user space. Neither approach limits what an agent is permitted to do inside the sandbox. They prevent it from affecting anything outside it.

Northflank runs agent code execution in isolated environments using Kata Containers with Cloud Hypervisor, Firecracker, or gVisor. In the ComputeSDK 2026 Scale Invitational, Northflank reached 100,000 concurrent sandboxes in 24 seconds from a cold start with zero failures, with P99 allocation latency of 566ms and P99 readiness of 733ms.

Every agent should have the minimum permissions required to complete its task. RBAC at the platform layer applies access controls by default to every agent and every workload deployed through the platform. An agent that can only access the resources the project grants it cannot access adjacent services, secrets, or databases that belong to a different project. The platform enforces this boundary, not the application code.

Northflank applies RBAC at the organisation, project, and environment levels. Every agent execution and every service deployment is tied to a named identity. SAML and OIDC SSO with Okta, Entra ID, and Google Workspace means provisioning is managed centrally, and deprovisioning revokes access automatically.

Agent credentials, API keys, database connection strings, and service account tokens should never appear in source code, prompts, environment files, or build logs. AI coding agents can inadvertently include credentials in generated code. Agents that log their reasoning may inadvertently log credentials that appeared in tool call results.

A platform-level secrets manager stores credentials and injects them at build and runtime. Credentials are never visible to the agent's reasoning process as plaintext in the prompt. Secret scanning runs as a required check on every pull request, catching credentials that AI-generated code may have included before they reach production.

Northflank secret groups store credentials and inject them at build and runtime. A single rotation point updates credentials across every service and agent that uses them.

Every action an agent takes must be logged with a timestamp and identity. Not just deployments. Every tool call, every secret access, every environment change, every configuration modification. This is what enables incident response when an agent is compromised and forensics when something goes wrong.

MCP servers are now present in a large proportion of enterprise cloud environments. Most of those MCP server actions are not logged with the granularity required for security incident investigation. When an agent makes an API call through an MCP server, the question "which agent made this call, at what time, with what parameters, and what did it return?" should be answerable from the audit log.

Northflank logs every deployment, secret access, environment change, and access control modification with a timestamp and user or agent identity. Audit logs can be exported to a SIEM for real-time monitoring and retention. SOC 2 Type 2 certified across managed cloud and BYOC deployments. HIPAA Business Associate Agreements are available on request.

An agent's network access should be scoped to the services it needs to interact with. Default-deny network policies that require explicit allowlisting of permitted connections prevent a compromised agent from making outbound connections to exfiltration endpoints or communicating laterally with services it has no business reason to access.

Even if an agent is compromised, network policies limit where it can communicate, reducing opportunities for lateral movement or data exfiltration.

Northflank applies default-deny network policies at the project and environment level. Services can only communicate with other services they are explicitly configured to reach. Agent executions in sandbox environments have network access scoped to the services they are allowed to call.

Agents that process sensitive data, including PII, PHI, financial records, or classified information, should run inside the enterprise's own cloud account rather than on shared vendor infrastructure. For many regulated organizations, data residency requirements make BYOC a practical requirement rather than an infrastructure preference.

BYOC deploys the platform's data plane into the enterprise's own cloud account. Agent executions, tool calls, and data access all happen inside the enterprise's own VPC. The vendor manages the control plane. The enterprise controls the data.

Northflank self-serve BYOC deploys into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal. For enterprises with the strictest isolation requirements, including defence technology companies, healthcare institutions, and financial services firms, Northflank supports a forward-deployed control plane that runs entirely within the enterprise's own environment with no dependency on Northflank's managed cloud.

Northflank provides the infrastructure layer that secures AI agents in the cloud. It applies the controls above by default, without requiring platform engineering teams to assemble and maintain them separately.

• MicroVM sandbox isolation: Agent code executions run in isolated environments using Kata Containers with Cloud Hypervisor, Firecracker, or gVisor. Each execution gets its own dedicated kernel boundary. A compromised execution cannot affect adjacent workloads or the host system.
• RBAC and SSO at the platform level: RBAC at the organisation, project, and environment level applied to every agent and every service. SAML and OIDC SSO with Okta, Entra ID, and Google Workspace. Every agent execution is tied to a named identity. Deprovisioning revokes access automatically.
• Secrets management: Secret groups store credentials and inject them at build and runtime. Credentials never appear in source code, environment files, or build logs. Secret scanning runs as a required check on every pull request.
• Managed databases with scoped access: PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ provisioned with automated backups and point-in-time recovery. Database credentials are managed through secret groups and scoped per service, so an agent can only access the databases its project explicitly grants it. No shared database credentials across services.
• Audit logging exported to SIEM: Every deployment, secret access, environment change, and access control modification is logged with a timestamp and identity. Exportable to the enterprise SIEM for real-time monitoring and retention.
• Default-deny network policies: Agent executions and services operate under default-deny network policies. Permitted connections are explicitly configured. Agents cannot reach services or endpoints outside their allowed scope.
• BYOC and forward-deployed control plane: Self-serve BYOC into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal. Agent workloads run inside the enterprise's own VPC. For the most regulated environments, the forward-deployed control plane provides air-gapped execution with no external dependencies.
• Northflank Skills for governed agent deployments: Teams using Claude Code, Codex, Gemini CLI, or Cursor can use Northflank Skills to deploy services, manage databases, and configure environments directly from the agent session, within the governance controls the platform applies by default.

The biggest risk is agents operating with more permissions than they need in an environment where their actions are not logged. An agent with broad credential access, no network isolation, and no audit trail has a large blast radius if compromised and leaves no forensic evidence. The infrastructure controls that address this are RBAC, secrets management, sandbox isolation, network isolation, and audit logging applied at the platform layer.

Prompt injection is an attack where malicious content in data the agent processes causes the agent to follow instructions embedded in that content rather than its original task. Infrastructure controls do not prevent prompt injection at the model layer, but they constrain what the agent can do even if it is successfully injected. An agent running in a microVM sandbox with least-privilege access and default-deny networking has a much smaller blast radius than one running with broad permissions on shared infrastructure.

Standard container isolation shares the host kernel. A compromised agent execution can potentially access the host filesystem, affect adjacent containers, or escalate privileges. MicroVM isolation using Kata Containers or Firecracker gives each execution its own dedicated kernel, providing a hardware-level boundary between executions. gVisor adds a further layer by intercepting system calls in user space.

Agent credentials should be stored in a platform-level secrets manager, never in source code, prompts, environment files, or build logs. AI coding agents can inadvertently generate code containing credentials. A secrets manager injects credentials at build and runtime, outside the agent's visible context. Secret scanning as a required PR check catches AI-generated credentials before they reach production.

BYOC means the platform's data plane runs inside the enterprise's own cloud account. Agent executions, tool calls, and data access all happen inside the enterprise's own VPC, under the enterprise's own network controls, with the enterprise's own audit trail. For enterprises processing sensitive data with AI agents, BYOC is often a compliance requirement rather than an infrastructure preference.

Northflank applies RBAC, network isolation, secrets management, and audit logging to every service deployed through the platform, including MCP servers. Every MCP server action, tool call, and connection is subject to the platform's default-deny network policies and access controls. Audit logs capture every action with a timestamp and identity.

Securing AI agents in the cloud is an infrastructure problem as much as it is a model problem. Prompt guardrails and output validation reduce the likelihood of unintended actions. The infrastructure controls, execution isolation, RBAC, secrets management, audit logging, network isolation, and BYOC constrain what an agent can do even when it is compromised.

Most guidance on securing AI agents focuses on the model layer. The infrastructure layer is where the gap is often largest and where the blast radius of a compromised agent is determined. Northflank provides that infrastructure layer as a managed platform, applied by default, for teams of any size.

• Enterprise AI coding agent deployment: How enterprises deploy AI coding agents safely in production with the governance controls that take pilots to production.
• How enterprises should govern AI-built applications at scale: The infrastructure-level governance controls that determine whether AI-built applications are safe in production.
• Best enterprise AI sandbox platforms in 2026: A comparison of enterprise sandbox platforms covering SOC 2, HIPAA, BYOC, and microVM isolation for AI agent execution.
• GPU sandboxes: isolation models and platform support in 2026: How GPU sandbox isolation works and which platforms support GPU workloads in sandboxed environments.