Defense in Depth for AI Agents: Five Layers of Security

Building Defense in Depth for AI Agents: A Five Part Series

Traditional workloads and applications tend to fail in predictable ways. A broken API call throws an error; a bad input gets rejected by a schema check. These are natural "safe" defaults when something goes wrong. AI agents are different because their nature is non-deterministic. When something goes wrong, an agent won’t stop or error out. There’s a good chance it will just keep going, taking plausible sounding, but harmful actions, because nothing forced a safe stop.

In this five-part series, we'll introduce defense in depth for AI agents, showing how multiple independent layers of validation, authorization, and monitoring work together to reduce risk at every stage of the agent lifecycle. We'll start with the five layers that make up this architecture, then get hands-on: how this architecture works in real time, integrating this model with existing infrastructure through gateways like AWS AgentCore, GCP, and Kong, and walking through a real-world example of how these layers work together to stop data exfiltration before it happens. We’ll move from architectural principle to practical implementation so you can see not just why defense in depth matters for AI agents, but how to build it into your environment.

Post 1 - Defense in Depth for AI Agents: Five Layers of Security

AI agents are no longer experimental. They're operating inside enterprise environments, invoking APIs, accessing sensitive data, and making decisions that impact real business systems.Yet unlike traditional applications, AI agents exhibit non-deterministic behavior, making static security controls and conventional access models insufficient on their own.

Securing AI agents requires a defense in depth architecture:multiple independent layers of validation, authorization, governance and monitoring that work together to reduce risk. No single control can address every failure mode. Instead organizations need continuous verification throughout the agent lifecycle, with each layer providing a critical checkpoint for identity, intent, access, and action.

This architectural philosophy is the foundation of Saviynt Zuma, the Enterprise AI Identity Security Platform, and its approach to Intent-Aware Runtime Authorization (IARA). Through three integrated pillars, Zuma Insights (Discover), Zuma Access (Protect), and Zuma Governance (Manage), Zuma delivers multiple layers of protection that enable organizations to continuously evaluate not only what is acting, but also what they are attempting to do, why they are doing it, and whether the action should be allowed.

Architecture

Defense in depth architecture as built within Saviynt’s Zuma AI and NHI security platform.

The architecture is built on a simple principle: trust is not granted once. It is continuously verified throughout the agent execution lifecycle.

The agent runtime enforces Layer 1, ensuring platform-level guardrails are respected before a request ever leaves the agent. Layers 2 through 5 are then evaluated by Zuma Access. Every decision point represents an independent validation of identity, authorization, intent, and behavior. A denial at any layer blocks the request at runtime.

Layer 1: Agentic Platform Guardrails

The first line of defense resides within the agent platform itself.

Whether deployed through Microsoft Copilot Studio, Anthropic Claude, AWS Bedrock, Google Gemini, or a custom orchestration framework, every AI agent is governed by platform-native controls that define its operating boundaries.These controls include system instructions, agent descriptions, tool restrictions, and protections against prompt manipulation.

These guardrails establish the agent's intended behavior and significantly reduce the risk of misuse, prompt injection, and confused-deputy attacks. However, they are platform-specific controls whose effectiveness varies by vendor and implementation.

As architects, we should view platform guardrails as foundational security controls, not comprehensive security controls.

Layer 2: Governance and Lifecycle Rules

Before an AI agent is permitted to act, organizations must establish whether it should exist and operate in the first place.

This layer enforces organizational policies about who, what, and when:

• Ownership requirements — block agents that lack assigned owners or accountability contacts from accessing enterprise systems
• Status enforcement — only agents in "active" or "approved" status can operate; suspended, decommissioned, or pending-review agents are blocked
• Model restrictions — limit which LLM models are approved for production use (e.g., only approved foundation models, not experimental or unvetted ones)
• Classification rules — agents handling sensitive data must meet higher compliance bars before deployment
• Lifecycle gates — require security review, risk assessment, or owner sign-off before an agent graduates from development to production

Many of the highest-risk AI agents are not actively malicious. They are abandoned, forgotten, poorly governed, or operating outside of approved processes. The governance layer catches the organizational gaps: the agent someone built six months ago and forgot about, the one running an unapproved model, the one with no owner after a team reorg. These are the agents most likely to be compromised or misconfigured, and governance rules catch them before they cause damage.

Layer 3: Policy Based Access Control (PBAC)

Once governance requirements are satisfied, access decisions must be evaluated dynamically. Policy-Based Access Control remains one of the most effective mechanisms for enforcing contextual authorization.

Every agent tool call against fine-grained policies that consider:

• Identity attributes — who is the user behind the agent? What are their OAuth scopes, group memberships, hosted domains?
• Agent metadata — what platform is this agent on? What's its status, version, owner?
• Tool details — what tool is being called? What arguments are being passed? What resource is being targeted?
• Contextual factors — what time is it? Which gateway is this coming from? What environment is targeted?

PBAC answers a fundamental question:

"Is this action by this agent under the known context at runtime permitted?"

Policies are written in a declarative language (like Rego) and evaluated at runtime with sub-millisecond latency. They express rules like:

• "Only OAUTH-authenticated agents on the aws-bedrock platform may call Gmail tools"
• "Email sends are blocked outside business hours"
• "Agents may not read files with CONFIDENTIAL sensitivity labels unless the token carries full Drive scope"
• "Batch reads of more than 10 files require admin-level authorization"

Because policies are deterministic, auditable, and consistently enforced, they form the structural backbone of runtime authorization. They ensure that the correct agent accesses the correct resource under the correct conditions.

Layer 4: Intent Deviation Analysis

This is where AI security fundamentally diverges from traditional application security.

Conventional applications execute predictable code paths. AI agents do not. They reason, adapt, and generate actions dynamically based on evolving context. That flexibility creates enormous value, but it also creates new attack surfaces.

A permission may be technically valid while still being operationally inappropriate.

PBAC can tell you whether an agent is allowed to call a tool. It cannot tell you whether the agent should be calling that tool in this specific context with these specific arguments. That requires understanding intent.

Examples of this kind of risk include: A calendar assistant that tries to send an email with sensitive meeting data to an external address. A code review agent that submits a PR with an authentication bypass buried inside a bug fix. A sales support agent that includes internal cost margins in an outbound pricing email. An ETL agent that writes customer PII to an external federated export table instead of an internal analytics table

The question is no longer whether an action is allowed. The question is whether the action aligns with the agent's intended purpose.

Intent-Aware Runtime Authorization (IARA) evaluates three dimensions simultaneously at runtime:

1. The agent’s declared purpose (its purpose and constraints)
2. What the tool does (its description and expected usage)
3. Actual action being performed (the specific arguments and content of the call)

When these elements diverge, risk emerges.

IARA enables detection of attacks that traditional access controls cannot identify, including data exfiltration, prompt manipulation, privilege misuse, and confused-deputy scenarios that occur within otherwise valid permissions.

In Saviynt’s case, Zuma takes this further with a unique approach: design-time intent baselining. When agent builders register or update an agent in the Zuma registry, the platform continuously compares the agent's declared intent with the permissions it holds — verifying alignment and flagging over-provisioning before the agent ever runs in production. If an agent's stated purpose is "read calendar events" but it holds permissions to send emails and delete files, that mismatch is surfaced immediately. These design-time violations can then be enforced at runtime — blocking over-provisioned actions that fall outside the agent's baselined intent, even if the permissions technically allow them.

To secure AI, we need to use AI.

Layer 5: Anomaly and Drift Detection

The final layer doesn't compare against rules or intent — it compares against history.

Not every attack violates a policy. Not every compromise produces a clear intent mismatch. Some threats emerge gradually through subtle shifts in activity patterns, resource access, or operational behavior.

Anomaly and drift detection establishes a baseline of expected activity for each agent and caller, then identify and flags meaningful deviations from baseline:

• Volumetric anomalies: an agent that normally makes 50 calls per hour suddenly makes 5,000
• Tool novelty: an agent that has only ever called three tools suddenly calls a fourth it has never used before
• Pattern drift: the distribution of tool usage gradually shifts over weeks, diverging from the established baseline
• Parameter anomalies: argument shapes or values that have never been observed for this caller/tool combination

Layer 5 catches slow, progressive compromise — the kind that doesn't trigger any single rule or intent check but represents a meaningful shift in behavior over time. It also catches sudden spikes that might indicate a compromised credential or hijacked agent session.

Anomaly detection starts in "monitor" mode, learning the baseline. Once the system has enough confidence in what "normal" looks like, it graduates to active enforcement — blocking requests that score above the configured risk threshold.

Rather than asking whether an action is permitted or aligned with intent, this layer asks:

"Is this behavior consistent with what we have historically observed?"

The Layers Working Together

The strength of this architecture is not any individual control. It is the interaction of all five. In July, we introduced Zuma, which delivers and coordinates all five layers in a single platform.

Each layer addresses a different failure mode and compensates for the blind spots of the others. The objective is not to build a perfect control. The objective is to build a resilient system in which the failure of one control does not result in the failure of security. In the era of autonomous AI, trust cannot be established through a single authorization decision. It must be continuously earned through multiple layers of independent verification.

Five layers. Five independent failure modes. One unified decision.

That's defense in depth for the age of AI agents.

Coming Up: In our next post, we'll start getting more hands on, looking at how defense in depth operates in real time.

Thanks for reading!

Miss a post? Check out the other blogs in the series:

Post 2 – Defense in Depth in Real Time

Post 3 - Defense In Depth: AgentSentry

Post 4 - Defense in Depth: GCP

Post 5 - Defense in Depth: Kong

To learn more about Zuma's approach to AI identity security, visit saviynt.com/zuma.