Securing Cloud Applications in the Age of AI Agents

Overview

Artificial intelligence systems are increasingly deployed in cloud-based data centers, where they interact with applications, databases, internal documents, external services, and other digital resources. AI introduces risks such as prompt injection, unauthorized tool use, and unintended data disclosure, but the controls needed to manage those risks are still grounded in cloud security practice.

This paper organizes AI workload security around six layers: Identity, Connectivity, Execution, Credentials, Data, and Detection. The framework asks a practical sequence of questions. Who or what is acting? Where can it connect? What can it run? What credentials can it use? What data can it reach? Can the organization see what happened?

1 Introduction

AI agents change the risk profile of cloud applications because they do more than answer questions. They can retrieve documents, call tools, trigger workflows, and act across systems at machine speed. In a modern cloud data center, that means traditional controls such as identity, network segmentation, workload isolation, secrets management, data protection, and logging must work together as one security design.

AI agents make that coordination more important. An agent may interpret instructions, call tools, retrieve information, and act on behalf of a user. If an attacker manipulates the agent, the agent may attempt to use whatever permissions, data access, credentials, and network paths are available to it.

This matters now because AI agents can turn ordinary cloud permissions into powerful chains of action. A permission that once allowed a service to read a file, call an API, or reach an external endpoint may become more dangerous when an agent can combine those permissions in response to a prompt, a retrieved document, or a tool result. The practical goal is not to block AI adoption, but to make sure each agent has only the access it needs and enough monitoring around it to detect misuse quickly.

The central principle is simple: an AI workload should have only the identity, connectivity, execution rights, credentials, and data access required for its task, and its actions should be visible enough for detection and response.

2 Reference Cloud Architecture

A secure cloud environment separates public entry points from private applications and sensitive data. Cloud providers often call this private network a virtual private cloud, or VPC. The name varies by provider, but the idea is the same: a private network boundary where teams place applications, services, and data resources. The table below summarizes the main architecture layers and the security expectation for each layer.

Architecture layer	Role	Security expectation
Internet edge	Receives public traffic and applies filtering before requests reach applications.	Only public entry points should be reachable from outside the organization.
Public application layer	Handles user-facing requests and forwards only approved traffic inward.	Public systems should not have direct access to sensitive data stores.
Private application layer	Runs application services, AI agents, internal APIs, and background workers.	Workloads should use private addresses, workload identities, and limited egress.
Private data services	Stores databases, document repositories, search indexes, and vector stores.	Access should be granted by identity, data classification, and business purpose.
Management and detection	Collects logs, evaluates alerts, and supports response.	Detection should cover each layer rather than sit outside the architecture.

Building Analogy for Cloud Private Network Security

Another way to understand this architecture is to compare it to a secured building. The cloud private network is the property boundary. Public subnets are entry areas, private subnets are interior rooms, isolated subnets are locked rooms for sensitive assets, and shared controls such as routing, DNS, IAM, and monitoring determine who can move through the building and what they can do.

Cloud component	Building analogy	Security meaning
Cloud private network (VPC or VNet)	The building property	The private boundary where the organization controls network design.
CIDR range	The address plan	The internal numbering scheme for rooms and hallways.
Public subnet	Front porch or entry area	Systems designed to receive controlled outside traffic.
Private subnet	Interior rooms	Application services and AI agents that should not be directly exposed.
Isolated subnet	Locked vault room	Sensitive data services with no direct path from the internet.
Internet gateway	Front gate to the street	The controlled connection between the private environment and the public internet.
Load balancer and WAF	Reception desk and front door guard	Receives visitors, routes requests, and blocks suspicious web traffic.
NAT gateway and egress controls	One way service exit	Lets private workloads reach approved outside services without exposing them to inbound traffic.
Route tables	Hallway map	Defines which paths traffic may take between rooms, exits, and shared services.
Security groups and network ACLs	Room guards and hallway rules	Permit only specific traffic between workloads, subnets, and services.
DNS and private DNS	Building directory	Maps service names to the right internal or external destinations.
Bastion	Guarded maintenance entrance	Provides controlled administrative access to private systems.
Peering VPN or dedicated connection	Covered walkway or private driveway	Connects the environment to another cloud network or on premises site.
IAM	Badges and keys	Determines which people, services, and agents may act and what they may do.
Logs and Detection	Cameras and visitor records	Records movement and actions so security teams can investigate events.

The analogy is useful because it shows why cloud security cannot rely on one control. A front door is not enough if every room is unlocked. Room guards are not enough if visitors can bypass the front door. A secure design needs identity, connectivity, execution, credentials, data protection, and detection to work together.

This architecture keeps public-facing services narrow, places AI agents and internal APIs in private application areas, protects data services behind controlled access paths, and treats monitoring as part of every layer.

3 Six Layer Security Framework

The framework is a reading order for design and review. Detection is listed last because it evaluates the full path, but monitoring should operate across all six layers.

Layer	Control question	Building analogy	Practical meaning
Identity	Who or what is acting?	Badges and keys	Named user, service, workload, or agent identity with least privilege.
Connectivity	Where can it connect?	Doors and hallways	Approved inbound paths, private access, segmented networks, and controlled egress.
Execution	What can it run?	Authorized activity in each room	Hardened containers, trusted images, limited runtime permissions, and controlled tools.
Credentials	What secrets can it use?	Special keys to cabinets	Secrets retrieved through managed services, scoped by workload identity and purpose.
Data	What information can it reach?	Valuables in rooms or vaults	Classified, encrypted, and access-controlled data with limits on copying and export.
Detection	Can we see what happened?	Cameras and visitor records	Logs and alerts that connect identity, network, workload, credential, and data events.

4 Identity

Identity controls who or what is allowed to act. Every user, application, service, workload, and AI agent should have a defined identity. Permissions should follow least privilege and should be narrow enough that an agent cannot become a broad proxy for a user or service account.

An AI agent might be allowed to read a specific collection of documents, query a designated search system, call an approved model service, retrieve one required credential, and submit requests for human approval. The same agent should not automatically be allowed to read all organizational documents, access financial records, modify infrastructure, retrieve every credential, or send data to arbitrary external destinations.

• Use managed workload identities where possible instead of shared long-lived keys.

• Review AI agents with broad permissions as privileged identities.

5 Connectivity

Connectivity controls where a workload can communicate. Network segmentation, routing, firewalls, private access to cloud services, and egress controls should limit both inbound and outbound paths. Outbound communication deserves special attention because a compromised workload or manipulated AI agent may try to send sensitive information to an external destination.

Public systems should receive only necessary external traffic. Private application systems should reach only approved internal services and approved external dependencies. Sensitive data services should generally have no public network address and should be reached through controlled application paths or private cloud service connections.

• Start from a default-deny posture and add specific allow rules only when needed.

• Define approved egress destinations for each AI workload class.

6 Execution

Execution controls what the workload can run and how much freedom it has at runtime. Many AI systems run in containers, orchestration platforms, or serverless environments. Those platforms help with isolation, but they do not remove the need for image scanning, trusted deployment sources, limited runtime permissions, and workload monitoring.

AI tools should be governed as part of execution. If an agent can call a shell, browser, database client, document retriever, or external API tool, that capability should be approved, scoped, and logged. A restricted runtime is more useful when the tools available inside it are also constrained.

• Run workloads with the minimum operating-system and network privileges required.

• Restrict deployment sources, image registries, host access, and tool invocation.

7 Credentials

Credentials connect an executing workload to other systems. AI applications often require access to databases, model services, external interfaces, and internal APIs. Those credentials should not be placed in prompts, source code, public repositories, plain-text configuration files, application logs, or user-uploaded documents.

Applications should retrieve credentials from a dedicated secrets management service at runtime. Access to each secret should be limited by workload identity and purpose. Credentials should be rotated, monitored for use, and revoked when no longer necessary.

Step	Component	Action	Security check
1	AI agent	Requests a credential for a specific task.	Uses its workload identity.
2	Secrets service	Evaluates whether that identity may retrieve the secret.	Checks policy, purpose, and scope.
3	Credential	Returns only the required secret or token.	Avoids broad vault access.
4	Detection	Records retrieval and downstream use.	Supports review and incident response.

8 Data

Data protection controls what information an AI system can read, infer, copy, or send elsewhere. AI workloads may process customer records, internal documents, source code, security findings, business plans, intellectual property, credentials, configuration data, prompts, retrieved context, and generated output.

The first data question should be: what data can this AI system access? The answer should drive classification, encryption, access controls, retention limits, segregation of sensitive information, monitoring of data access, and restrictions on external transfers.

• Limit access to the minimum data required for the task.

• Treat prompts, retrieved context, and generated responses as data assets when they may contain sensitive information.

9 Detection

Detection makes the architecture observable. Security controls are incomplete without evidence that shows which identity acted, where it connected, what workload executed, which credentials were retrieved, what data was accessed, and whether any action was blocked or approved.

Important events include network connections, firewall decisions, identity usage, database queries, document access, secrets retrieval, external API calls, AI tool calls, model requests and responses, data transfers, human approvals, and failed or blocked actions. Logs should have owners, retention expectations, and alert paths so they can support response rather than merely accumulate.

• Use one consistent term for this layer: Detection.

• Correlate AI-specific telemetry with traditional infrastructure logs.

10 Example Defending Against Prompt Injection

Consider an employee who uploads a malicious document to an AI agent. Hidden in the document is an instruction telling the agent to retrieve confidential files and send them to an external destination. The immediate AI security issue is indirect prompt injection, but the attack succeeds only if the surrounding cloud controls allow it.

A secure environment can break the attack chain at several points. The agent may lack permission to access the confidential files. The files may sit in a protected data area. The agent may be unable to communicate with arbitrary internet destinations. The action may require human approval. The attempt may generate an alert. The agent may also have read-only access that prevents changes to downstream systems.

This example shows why prompt injection is not only a model problem. It is also an Identity, Connectivity, Execution, Credentials, Data, and Detection problem.

11 Implementation Checklist

The framework can be used as a design review checklist for any AI workload before deployment and during periodic access reviews.

Layer	Review question	Practical next step
Identity	Does every user, service, workload, and AI agent have a defined identity?	Remove shared accounts and reduce broad roles.
Connectivity	Can the workload reach only approved internal and external destinations?	Block unknown egress and use private access to cloud services.
Execution	Can the workload run only trusted code and approved tools?	Restrict images, deployment sources, runtime privileges, and tool access.
Credentials	Can it retrieve only the secrets required for the current purpose?	Move secrets to managed storage and scope retrieval by identity.
Data	Can it access only the data needed for its task?	Classify data, limit read/write paths, and restrict exports.
Detection	Can the team reconstruct what happened after suspicious activity?	Correlate logs across identity, network, workload, secrets, and data.

12 Conclusion

AI security can feel new, but the work is still grounded in familiar cloud security habits: know who or what is acting, limit where it can connect, control what it can run, protect the credentials it can use, narrow the data it can reach, and make the activity visible.

That is the value of the six-layer framework. It gives teams a practical way to review AI workloads without treating them as mysterious exceptions to the rest of the cloud environment. If an agent needs access, grant it deliberately. If it does not need access, remove it. And if something sensitive happens, make sure the organization can see it, understand it, and respond.