In the last twelve months AI security has turned into something every security organization is being asked to own, and almost none have been handed a clear way to think about it.

The term gets stretched across a dozen unrelated things: prompt injection, poisoned training data, AI use policies, agent manipulation, and more. Each one is a real problem, and each comes with its own controls, its own vendors, and its own team. The catch is that none of them, on its own, adds up to AI security.

What this guide gives you is a way to make sense of all of it.

Why a working frame matters

Buy an AI gateway and call AI security handled, and you have spent heavily on the most visible problem while underspending on the most consequential one. Buy a cloud posture tool and assume it already covers your AI agents, and you have missed the shift the access layer is going through. Neither move is wrong. They are just incomplete.

That same breadth is what makes the conversation so hard to have in the first place. One CISO will ask five different questions in a single sitting:

• “How do I stop my agent from being prompt-injected?”
• “How do I keep my corporate data from leaking?”
• “How do I know what my agent actually has access to?”
• “How do I write an AI use policy?”
• “How do I red-team an AI system?”

Each of those is a different problem, sitting under a different control category, carried by a different vendor footprint, and owned by a different team. Without a shared frame to hang them on, every conversation rewinds to first principles, and the cloud security work that actually pays the rent stalls in the queue behind it. The frame below is built to close that gap.

---

The framework in three cuts

The model runs on three questions, asked in order. Each has its own answer, and together they let you drop any AI security question onto the map and see where it lands.

Cut 1: Where does the agent live, and what does it reach?

The first cut is a deployment map, and it turns on two dimensions: where the agent runs, and what it can touch.

	Reaches: Cloud (IaaS)	Reaches: SaaS	Reaches: On-prem
Lives on: Endpoint / dev machine	Claude Code, Kiro, local agents calling AWS APIs	Local agent calling Salesforce / Notion via OAuth	Rare today, growing
Lives on: Cloud-hosted runtime	Bedrock AgentCore, Vertex AI Agent Engine, Lambda-hosted agents	Cloud agent that fans out into SaaS	Hybrid / data-residency cases
Lives on: SaaS-hosted agent	Third-party agent platform reaching back into your env	SaaS-to-SaaS chains	Rare

Between them, those two dimensions decide how the agent can be governed.

• Where it lives sets its credential model. An agent on a developer’s laptop almost always inherits that developer’s human credentials, while an agent in a hosting environment almost always runs under a dedicated execution role. The controls follow from there: permission boundaries and SCPs at the org layer for the first, per-invocation session policies at runtime for the second.
• What it reaches sets its blast radius. An agent that only touches IaaS presents a very different threat surface from one that fans out across a half-dozen SaaS apps under federated identity.

What this cut won’t tell you is the layer a given failure happens at. A prompt-injection attack and an over-privileged role can land in the very same cell here and still be completely different control problems. That is what the second cut is for.

Cut 2: Which layer does the failure happen at?

The second cut is a control map, and this is where Google’s Secure AI Framework (SAIF) earns its place. SAIF sorts AI security into six categories of control, four of them architectural (the components of the AI system itself) and two cross-cutting (applying across all four). It is published, technology-neutral, and the most defensible public cut available, which is why we lean on it here.

Data: protecting the data the AI is trained on, draws from, and stores.

• Covers the integrity and lawful use of every piece of data that touches the system, from training and fine-tuning data to RAG sources, prompts, and logs.
• What fails when it is missing: a model memorizes PII from its training data and surfaces it in a response, a poisoned RAG source quietly biases the answers, or a vector store leaks sensitive embeddings.

Infrastructure: protecting who and what can reach the AI, and the resources it acts on.

• Covers the substrate AI runs on: identity and role design for non-human principals, network boundaries, configured-versus-observed access, access-path modeling, and the integrity of model and data assets.
• What fails when it is missing: over-privileged agent roles inherit human-scale permissions, transitive access through cloud roles opens unintended blast radius, and there are no org-level guardrails on agent identity at all.

Model: protecting the prompt that goes in and the response that comes back.

• Covers the model in operation: how it handles input, how it validates output, how well it holds up under adversarial pressure.
• What fails when it is missing: a prompt manipulates the agent (prompt injection), sensitive data leaks out through a response, or the output carries harmful content.

Application: protecting how users and agents interact with the AI system.

• Covers the surface where users, and increasingly other agents, actually interact with the AI.
• What fails when it is missing: an agent takes unauthorized actions on a user’s behalf, integrated tools and connectors carry trust they never should have, and agent activity goes unobserved.

Governance: setting policy and accountability for AI use.

• Wraps the technical layers in policy: which models are allowed, who signs off on fine-tuning data, who approves an agent before it ships.
• What fails when it is missing: residual risk no one is managing, an AI surface no one is tracking, regulatory exposure, and third-party AI use that answers to no one.

Assurance: testing, monitoring, and responding to AI threats.

• Provides the feedback loops that prove the rest actually hold up under adversarial pressure.
• What fails when it is missing: a compromise goes undetected, controls sit unvalidated, and incident response is slow or simply absent for AI-specific events.

These are not strict layers in a stack. They overlap, and they share controls. What makes them useful is that each one has a distinct vendor footprint and a distinct team inside the organization. A prompt-injection problem lives at the Model layer, gets solved by an AI gateway, and is owned by the AI/ML team. An over-privileged role lives at the Infrastructure layer, gets solved by a cloud security platform, and is owned by the cloud security team. Blur the two together, and the conversation ends without anyone making a decision.

Cut 3: Who owns each layer, and which vendor addresses it?

The third cut is an ownership map. A model like this only earns its place if it tells you which category of vendor, and which internal team, owns each layer.

Layer	What it covers in short	Who typically owns it	Vendor categories
Data	Training data, RAG sources, prompts and logs	Data security and data platform teams	Data security platforms, modern DLP, vector store / RAG governance
Infrastructure	Identity, role design, access paths, network	Cloud security and platform teams	Cloud security platforms, CNAPP-adjacent posture tools, NHI platforms, CIEM
Model	Input/output validation, adversarial robustness	AI/ML platform and application security teams	AI gateways, model firewalls
Application	Agent permissions, runtime, observability	AI/ML platform and application teams	Agent runtime platforms (Bedrock AgentCore, Vertex AI Agent Engine, AgentScope, Strands), agent observability tools
Governance	AI policy, risk register, vendor governance	CISO office, Chief Risk Officer, compliance and legal	GRC platforms, internal policy
Assurance	Red teaming, threat detection, IR	Detection-and-response and red team functions	Red teaming services, SIEM/SOAR with AI extensions, IR services

The trap to avoid: plenty of vendors market themselves as “AI security” while really covering one or two of these layers, then present that slice as the whole problem. The map is the test. Any vendor claim should be locatable on it, and a CISO should be able to ask, in plain terms, which layers this covers and which ones still need a different tool.

---

Three questions, asked in order

The three cuts are really three lenses on the same surface: the deployment surface (Cut 1), the control surface (Cut 2), and the ownership surface (Cut 3). A mature AI security program works all three at once. Day to day, that turns into three questions a CISO can ask, in order:

1. Where are our agents running, and what are they reaching?
2. Which layer is the failure mode we’re most worried about?
3. Who owns that layer, and which vendor category covers it?

---

Three test cases

A model is only worth using if it can locate real failures cleanly. So here are three, each a composite of patterns we keep seeing in customer environments. Nothing invented, everything anonymized.

Test case A: The cloned Lambda role

Six months ago a Lambda function got an execution role cloned from an existing one, and the clone quietly carried over permissions to a production S3 bucket. A Bedrock agent now invokes that Lambda. The agent is not compromised, and it is not under attack. It runs exactly as designed, and in doing so it reads sensitive data from a bucket nobody ever meant it to reach. The only sign is buried in CloudTrail.

• Cut 1. Cloud-hosted runtime, reaches IaaS.
• Cut 2. Infrastructure layer (over-privileged role, transitive access path).
• Cut 3. Cloud security platform.

Test case B: The prompt-injected support agent

A customer-support agent has read access to the ticketing system. A user files a ticket containing instructions crafted to make the agent leak the whole ticket queue back through its own response. The agent’s role is scoped correctly, it can only read. The trouble is that read is already enough to leak.

• Cut 1. Cloud-hosted runtime, reaches SaaS.
• Cut 2. Model layer (prompt injection, insecure output).
• Cut 3. AI gateway / model firewall.

Test case C: The poisoned RAG source

A RAG pipeline ingests a vendor’s knowledge base. The vendor pushes a corrupted update laced with adversarial text built to bias the model’s answers. From then on the agent confidently produces wrong answers, in customer-facing contexts no less.

• Cut 1. Cloud-hosted runtime, reaches SaaS / on-prem data sources.
• Cut 2. Data layer (poisoned RAG ingestion), with a Governance failure (no provenance check on third-party RAG sources).
• Cut 3. Data security platform / RAG-aware ingestion controls.

The bottom line? No single layer catches all three.

Why the Infrastructure layer carries disproportionate weight

Infrastructure is one layer out of six. It is also, in 2026, the layer that matters most. The others are important as well, and any complete program covers them. However, the reason infrastructure is so important comes down to how AI is actually being used in production, and to the fact that every other layer’s failure eventually routes through it.

AI shows up in an enterprise in two shapes:

In the first, a human uses AI through their own credentials: a developer runs Claude Code on a laptop set up with their own AWS credentials, and every list, read, and write the assistant performs flows through that developer’s IAM identity.

In the second, a service runs AI under its own credentials: a Bedrock agent in production reasons through a chain of tools under its execution role, and every action flows through that role’s IAM identity.

The reasoning lives in the model, but the access lives in IAM. In both shapes, the AI’s reach into cloud resources is governed at the Infrastructure layer. The Model layer keeps the prompt from being misread, and the Infrastructure layer bounds the damage when it isn’t. The Application layer configures the agent runtime, and the Infrastructure layer decides what the agent can touch once it is running. Even a Data-layer failure has to exfiltrate through an Infrastructure-layer access path in the end.

“Unlike traditional applications with deterministic code paths, agents reason dynamically, choosing different tools or accessing different data depending on context. You must assume an agent can do anything within its granted entitlements.”

• AWS Security Blog, April 2026

Because AI agents are non-deterministic at runtime, their access controls have to be deterministic by design, and that deterministic layer has to sit outside the agent’s reasoning, down in the Infrastructure where IAM and network are configured.

A successful prompt injection only becomes an unsafe action when the agent can reach a resource it shouldn’t. A poisoned dataset only becomes unsafe output when the model is invoked by a principal whose downstream access amplifies the harm. A program can be incomplete in plenty of ways and still hold. The one place it cannot afford to be incomplete is the Infrastructure layer.

AWS’s three principles

This is exactly the layer AWS’s April 2026 guidance speaks to, and it is the most operationally specific public material out there on the subject. AWS runs every IAM decision involving an AI agent through three principles:

1. Assume every granted permission will be used. Design permissions around the scope of impact you can live with, not around what the agent is meant to do. If a permission is granted, treat it as exercisable.
2. Drive role usage from the organization, not the team. The controls that actually hold are applied above any single team: permission boundaries, Service Control Policies (SCPs), and per-tool session policies, rather than whatever the developer deploying the agent happens to set.
3. Tell AI-driven actions apart from human ones. Even when a human and an agent share one role, you should be able to govern their actions separately, which is what makes progressive policies work: read is allowed where the data is safe to read, AI-driven writes require approval, AI-driven deletes denied outright.

Read together, the three principles describe what “putting AI in a box” actually looks like at the Infrastructure layer. The box is a bounded set of permissions the agent is allowed to exercise. It gets built before the agent ships, applied above the team that deploys it, and instrumented so that AI-driven and human-initiated actions can be told apart and governed on their own terms.

---

Where Act fits

Act sits at the Infrastructure layer. Everything around the cloud access path is ours: the identity and access graph for human and non-human principals, the line between what a role permits and what it has actually used, the transitive paths an agent can travel to reach downstream resources, the simulation of policy changes before they are enforced, and the design and validation of the org-level guardrails (permission boundaries, SCPs, and their equivalents across cloud providers and SaaS) that AWS’s three principles call for.

At the Application layer, Act covers agent permissions directly. When an agent assumes a tightly scoped role for each tool call, that role and its policy live in the cloud account, and Act maps and enforces them there.