September 23, 2026
The transition from generative artificial intelligence to agentic artificial intelligence represents a fundamental change in the cybersecurity problem. Conventional AI systems primarily generate information in response to prompts. Agentic systems can interpret objectives, plan activities, invoke tools, access enterprise data, communicate with other agents, modify systems, and take actions with limited or no human intervention. Consequently, securing an agent is no longer simply a matter of protecting a model or filtering prompts. It requires establishing trustworthy identities, constraining authority, protecting data and model execution, validating tools and software supply chains, monitoring behavior, and continuously determining whether an agent remains within its authorized operating envelope.
This article proposes a Defense-in-Depth Security Architecture for Agentic AI based on the principle of bounded autonomy. The architecture combines governance, identity, authorization, agent guardrails, runtime security, model and tool protection, confidential computing, infrastructure security, continuous validation, and security operations. It also introduces a critical distinction between identity-based trust—knowing which agent is acting—and execution-based trust—knowing what software and hardware environment is actually executing the agent. Confidential Computing and Trusted Execution Environments (TEEs) provide an important foundation for the latter through hardware-backed isolation and remote attestation.
The article maps this architecture to an emerging ecosystem of commercial and open-source technologies, including Microsoft Entra Agent ID and Agent 365, Palo Alto Networks Prisma AIRS, Cisco, CrowdStrike, JFrog, NVIDIA NeMo Guardrails, Check Point, Aembit, Zenity, Dash Security, ReliaQuest GreyMatter and GreyMatter Attack, WWT ARMOR, IBM BeeAI, Somansa, Guardrails AI, Vigil, LLM Guard, and Rebuff. The analysis identifies areas in which the market is rapidly developing as well as persistent architectural gaps, particularly around agent-to-agent trust, memory integrity, execution provenance, and the relationship between identity and attested runtime state.
Introduction
Artificial intelligence is moving from systems that answer questions toward systems that take actions.
The distinction is consequential.
A traditional software application executes predefined logic. A generative AI application typically accepts a prompt, generates an output, and returns that output to a user. An agentic AI system can instead receive an objective, reason about how to accomplish it, select tools, retrieve information, interact with other systems, evaluate intermediate results, revise its approach, and continue operating until it believes the objective has been achieved.
This creates a new cybersecurity problem.
An AI agent may have:
- access to corporate databases;
- permission to send email;
- access to source-code repositories;
- authority to execute software;
- access to cloud infrastructure;
- access to financial or operational systems;
- credentials for external services;
- access to sensitive enterprise knowledge;
- the ability to invoke other AI agents; and
- the ability to make decisions that affect subsequent actions.
The traditional security model assumes that software follows relatively deterministic paths. Agentic systems introduce a decision-making layer whose behavior can change according to context.
The result is a fundamental shift: The security question is no longer simply whether an AI model is trustworthy. It is whether the entire agentic system can be trusted to act within a defined and continuously enforced boundary.
This article develops an architecture for doing that.
The proposed approach is based on bounded autonomy: agents should receive enough authority to accomplish legitimate objectives, but that authority should be explicitly defined, continuously evaluated, technically constrained, and revocable.
The architecture builds upon conventional cybersecurity concepts—including zero trust, least privilege, identity management, segmentation, secure software development, monitoring, and incident response—but adapts them to the unique characteristics of autonomous AI.
OWASP’s 2026 Agentic Applications framework illustrates why this adaptation is necessary. Its threat taxonomy includes goal hijacking, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.
These risks demonstrate that agent security must be treated as a systems architecture problem, not merely an AI-model problem.
From Application Security to Agent Security
Traditional application security generally revolves around several questions:
- Is the application authentic?
- Who can access it?
- What can the user do?
- Is the application vulnerable?
- Is data protected?
- Can malicious activity be detected?
Agentic AI introduces additional questions:
- What exactly is the agent?
- Who owns it?
- What objective is it pursuing?
- What authority has it been granted?
- What tools can it invoke?
- What data can it access?
- Which model is controlling its decisions?
- What instructions and memory are influencing it?
- What other agents can it communicate with?
- What environment is actually executing it?
- Can the organization verify that environment?
- Can its behavior be continuously evaluated?
- Can its authority be immediately revoked?
These additional questions create a security architecture that is broader than conventional application security.
The architecture proposed here therefore treats an AI agent as a nonhuman digital actor with an identity, capabilities, permissions, execution environment, objectives, memory, tools, and behavioral history.
Microsoft’s current Entra Agent ID architecture illustrates this emerging model by giving agents dedicated identities and extending authentication, authorization, governance, and monitoring capabilities to nonhuman AI actors.
The Principle of Bounded Autonomy
The central design principle of this architecture is bounded autonomy. Autonomy should not mean unrestricted authority. An agent should instead operate inside a defined security envelope: Objective → Identity → Authorization → Attestation → Action → Validation → Audit
This creates a continuous trust process rather than a one-time authentication event.
An agent may therefore be required to satisfy several conditions before taking a sensitive action:
- the agent identity is valid;
- the requesting principal is authorized;
- the requested operation is within the agent’s mission;
- the tool is trusted;
- the destination is permitted;
- the data is authorized for use;
- the execution environment is trusted;
- the model and agent configuration have not been altered;
- runtime behavior remains within policy; and
- the action does not violate a higher-level organizational control.
This represents an extension of Zero Trust.
Traditional Zero Trust asks: Who are you, and should you have access?
Agentic Zero Trust must additionally ask: What are you, what are you running, what are you trying to do, and does the current execution state remain trustworthy?
That distinction becomes particularly important when Confidential Computing is incorporated into the architecture.
The Defense-in-Depth Architecture
The proposed architecture consists of ten principal layers with three cross-cutting control planes and an underlying root of trust.
Core Security Layers
- Governance and policy
- Agent identity and authorization
- Agent development and supply-chain security
- Agent guardrails
- Model and prompt security
- Runtime and tool security
- Confidential computing and attested execution
- Infrastructure and network security
- Continuous validation and adversarial testing
- Security operations and incident response
Cross-Cutting Control Planes
- Enterprise agent control plane
- Security telemetry and observability
- Human oversight and accountability
A simplified conceptual model is shown in Figure 1 below:
A key architectural construct introduced by Confidential Computing is that execution trust is established beneath the agent runtime rather than assumed by it.
The ten security layers provide the defensive mechanisms.
The three cross-cutting planes provide the management, visibility, and accountability mechanisms that allow those defenses to operate coherently at enterprise scale.
The architecture can therefore be summarized as:
Ten Security Layers
→ protect the agent, its data, tools, runtime, infrastructure, and operations.
Three Cross-Cutting Control Planes
→ govern the agent population, observe agent behavior, and maintain human accountability.
Hardware and Root of Trust
→ establish the foundational security properties upon which higher-level controls depend.
Bounded Autonomy
→ provides the overarching operating principle that connects the architecture.
The resulting model is not simply an AI security stack. It is an enterprise control system for autonomous digital actors.
That distinction becomes increasingly important as organizations transition from deploying individual AI assistants to managing large populations of interconnected autonomous agents.
Cross-Cutting Control Planes
The ten security layers listed in the reference architecture provide the principal technical and operational controls for securing agentic AI. However, three capabilities cut across all ten layers and provide the mechanisms necessary to coordinate, observe, and govern those controls:
- Enterprise Agent Control Plane
- Security Telemetry and Observability
- Human Oversight and Accountability
These should not be interpreted as additional security layers. They are cross-cutting control planes that operate across the architecture.
The distinction is important. An organization could deploy strong identity controls, guardrails, runtime protection, Confidential Computing, and security operations and still have an incomplete architecture if it cannot determine which agents exist, continuously observe their behavior, or establish where human responsibility resides.
The three control planes therefore provide the architecture’s organizational and operational connective tissue.
Enterprise Agent Control Plane
The Enterprise Agent Control Plane provides centralized visibility, governance, lifecycle management, and policy coordination for an organization’s population of AI agents.
As organizations move from deploying individual copilots to operating hundreds or thousands of autonomous agents, the problem begins to resemble cloud and endpoint management. An enterprise needs to know what agents exist, who owns them, what they are authorized to do, what systems they can access, what models they use, and whether they remain compliant with organizational policy.
Without such a control plane, agent deployment can produce agent sprawl—a condition in which autonomous systems are created faster than they can be inventoried, secured, monitored, and retired.
The control plane should therefore maintain an authoritative inventory of:
- agents;
- agent owners;
- business purpose;
- model and model version;
- agent framework;
- system instructions;
- tools and APIs;
- MCP servers;
- agent-to-agent relationships;
- data sources;
- credentials;
- permissions;
- deployment environments;
- risk classification;
- security policies;
- validation status;
- attestation requirements;
- lifecycle state.
The result should be an enterprise-level agent registry.
Agent Discovery and Inventory
The first responsibility of the control plane is discovery. Organizations should be able to answer a basic question: How many AI agents are operating within the enterprise right now?
That question is more difficult than it appears.
Agents may be:
- centrally developed;
- embedded in commercial applications;
- created by business units;
- deployed by developers;
- created dynamically by other agents;
- operating in cloud environments;
- operating on employee endpoints;
- accessing external services.
The control plane should therefore continuously discover agents rather than relying exclusively on manual registration.
Each discovered agent should receive an identity and a minimum security profile.
Ownership and Accountability
Every production agent should have an accountable owner.
Ownership should identify:
- business owner;
- technical owner;
- security owner;
- deployment environment;
- authorized use cases;
- escalation contact;
- review schedule.
This prevents the common situation in which an autonomous system continues operating after the people who originally created it have moved to another project or organization.
Policy Distribution
The control plane should also serve as the distribution mechanism for enterprise policies.
Policies may govern:
- permitted models;
- permitted tools;
- data classifications;
- geographic restrictions;
- transaction limits;
- human approval requirements;
- credential lifetimes;
- agent-to-agent communication;
- use of external services;
- prohibited actions.
This creates a separation between agent capability and agent authority.
An agent may technically possess the capability to perform an action without being authorized to perform that action.
Lifecycle Management
Agents should have a formal lifecycle:
Request → Design → Test → Approve → Deploy → Monitor → Revalidate → Modify → Retire
The control plane should enforce transitions between these states.
Lifecycle management should include:
- creation;
- registration;
- approval;
- deployment;
- version management;
- credential issuance;
- periodic review;
- suspension;
- retirement;
- credential revocation.
This is particularly important because changing an agent can effectively create a new security object.
Changing its:
- model;
- system prompt;
- tools;
- permissions;
- memory;
- dependencies;
- runtime environment
may materially change its security posture. Consequently, significant changes should trigger revalidation.
Relationship to the Ten Security Layers
The control plane interacts with every layer of the architecture.
| Security Layer | Control Plane Function |
| Governance and Policy | Distributes and enforces enterprise policy |
| Identity and Authorization | Creates and manages agent identities |
| Supply Chain | Tracks models, tools, dependencies, and provenance |
| Guardrails | Defines required guardrail policies |
| Model Security | Tracks approved models and versions |
| Runtime Security | Records approved execution environments |
| Confidential Computing | Defines attestation requirements |
| Infrastructure Security | Associates agents with approved infrastructure |
| Continuous Validation | Tracks test and validation status |
| SOC / Incident Response | Provides agent context during investigations |
The Enterprise Agent Control Plane therefore becomes the management backbone of the agentic enterprise.
Security Telemetry and Observability
The second cross-cutting control plane is Security Telemetry and Observability.
Traditional applications generate logs. Agentic systems generate something more valuable and more complicated: behavioral evidence.
An agent’s security telemetry should allow an organization to reconstruct not merely what software executed, but:
- what the agent was asked to accomplish;
- what information it accessed;
- what decisions it made;
- which tools it invoked;
- what other agents it contacted;
- which credentials it used;
- what data it transmitted;
- what policies were evaluated;
- whether those policies were satisfied;
- what execution environment was involved.
This creates the possibility of an agent activity record rather than simply an application log.
Agent Behavioral Telemetry
Important telemetry should include:
- agent identity;
- user or initiating principal;
- session;
- objective;
- model;
- model version;
- prompt/context metadata;
- tools invoked;
- tool parameters where appropriate;
- resources accessed;
- data classification;
- destination;
- authorization decision;
- policy decision;
- execution environment;
- attestation status;
- timestamps;
- outcome.
Sensitive prompt and data contents should not automatically be retained simply because they are technically available. Logging itself must follow privacy, data-minimization, and security requirements.
The objective is to capture security-relevant evidence, not indiscriminately record everything.
Behavioral Baselines
Agent behavior can be modeled over time. For example, an agent normally might:
- access three internal databases;
- invoke two APIs;
- communicate with one other agent;
- operate during business hours;
- perform approximately 50 transactions per hour.
A sudden change—such as accessing an unfamiliar database or initiating thousands of API requests—can become a security signal.
Behavioral analytics should therefore detect:
- unusual tool invocation;
- unusual destinations;
- abnormal transaction volumes;
- privilege escalation;
- unusual data access;
- unexpected agent-to-agent communication;
- unusual credential usage;
- changes in model or runtime;
- deviation from the agent’s mission.
Observability Across the Agent Chain
A particularly important requirement is distributed agent observability.
Consider: User → Agent A → Agent B → MCP Server → Database → External API
A traditional application log may record only the final API request. An agent security architecture needs to preserve the causal chain.
The organization should be able to reconstruct:
User X initiated Agent A, which delegated task Y to Agent B, which invoked Tool C, which accessed Resource D, producing Action E.
This creates an agent provenance graph. Such graphs can become particularly valuable during incident response because they reveal how a compromise propagated through an agent ecosystem.
Telemetry and Confidential Computing
Confidential Computing introduces an important observability challenge. The purpose of a TEE is to prevent unauthorized parties—including potentially infrastructure administrators—from inspecting protected execution.
Security telemetry therefore cannot simply assume unrestricted access to runtime memory. Instead, the architecture should distinguish between:
Protected execution data
and
Security evidence about the execution.
Remote attestation provides one example of the latter.
An attestation report can provide cryptographically verifiable evidence about the environment without exposing the protected contents of the workload.
This creates an important architectural principle:
Observe the security properties of confidential workloads without unnecessarily exposing the confidential workload itself.
Integration With the SOC
Agent telemetry should feed existing enterprise security operations. Integration points include:
- SIEM;
- SOAR;
- XDR;
- identity platforms;
- cloud security platforms;
- data-loss prevention;
- vulnerability management;
- incident-response systems.
The SOC should be able to search for events such as:
“Show all autonomous agents that accessed restricted data during the past 24 hours.”
or:
“Show all agents that executed from an environment whose attestation state changed.”
or:
“Show all agents that communicated with Agent X before and after its compromise.”
This transforms agent security from a specialized AI function into an enterprise security capability.
Human Oversight and Accountability
The third cross-cutting control plane is Human Oversight and Accountability.
The objective is not to require a human to approve every agent action. Such a model would eliminate much of the value of autonomous systems.
Instead, humans should remain responsible for defining:
- objectives;
- acceptable risk;
- authority boundaries;
- escalation requirements;
- prohibited actions;
- accountability structures.
The agent operates autonomously inside those boundaries.
Human-in-the-Loop Versus Human-on-the-Loop
Two concepts are useful.
Human-in-the-loop means a human must approve an action before it occurs.
Human-on-the-loop means the agent operates autonomously while humans monitor its behavior and can intervene.
The appropriate model depends on the consequences of the action.
For example:
| Action | Potential Oversight Model |
| Retrieve public information | Autonomous |
| Analyze internal documents | Autonomous with monitoring |
| Create a low-risk ticket | Autonomous |
| Modify production configuration | Human approval |
| Disable an employee account | Conditional approval |
| Execute a major financial transaction | Human approval |
| Modify security controls | Human approval |
| Initiate widespread containment | Human approval or tightly defined emergency policy |
The architecture should therefore implement risk-based autonomy rather than treating all agent actions equally.
Approval Gates
Approval gates should be technically enforceable.
An agent should not simply be instructed:
“Ask a human before transferring money.”
The system should enforce: Agent → Policy Engine → Approval Required → Human Decision → Authorized Tool Call
The agent should be technically unable to bypass the approval mechanism. This is an important distinction between procedural safeguards and architectural safeguards. Procedural safeguards depend on the agent following instructions. Architectural safeguards prevent unauthorized behavior even if the agent attempts it.
Human Accountability
Autonomous operation does not eliminate organizational accountability.
Every production agent should have a clearly defined responsibility chain: Agent → Technical Owner → Business Owner → Security Authority → Executive Accountability
This does not mean that every agent action should be manually attributed to an individual employee.
Rather, it establishes responsibility for:
- deployment;
- authorization;
- policy;
- risk acceptance;
- monitoring;
- incident response.
Emergency Intervention
Every high-impact autonomous system should have a mechanism for rapid intervention.
Possible controls include:
- credential revocation;
- agent suspension;
- tool-access termination;
- network isolation;
- model rollback;
- memory rollback;
- deployment shutdown;
- parent-agent termination.
A critical requirement is that the kill mechanism must not depend entirely on the agent cooperating.
If an agent becomes compromised, the organization must be able to terminate its authority externally.
Accountability and Auditability
Human oversight also requires an audit trail. For consequential actions, organizations should be able to establish:
- who authorized the agent;
- what policy governed the action;
- what agent identity was involved;
- what execution environment was used;
- whether attestation succeeded;
- what tools were invoked;
- whether human approval was required;
- who provided that approval;
- what action ultimately occurred.
This produces a chain of accountability extending from organizational policy to autonomous execution.
The Three Control Planes Working Together
The three cross-cutting planes are most powerful when integrated.
Consider an agent attempting to access a highly sensitive database.
The process could be:
- Enterprise Agent Control Plane – Confirms that the agent is registered, approved, and authorized for the business function.
↓
- Identity and Authorization – Confirms that the agent possesses the required identity and permissions.
↓
- Confidential Computing / Attestation – Confirms that the agent is executing approved software in an approved trusted environment.
↓
- Policy Engine – Determines whether the requested data access is permitted.
↓
- Human Oversight – If the operation exceeds the agent’s autonomous authority, requests human approval.
↓
- Runtime – Agent executes the authorized operation.
↓
- Security Telemetry – Records the agent, action, resource, policy decision, execution environment, and outcome.
↓
- SOC – Receives the event and can correlate it with other security activity.
This creates a continuous control loop:
Govern → Identify → Verify → Authorize → Execute → Observe → Evaluate → Intervene
The significance of this model is that no individual control is expected to solve the agent security problem.
The three control planes collectively establish the practical meaning of bounded autonomy.
The Enterprise Agent Control Plane answers: What agents are allowed to exist and what are they authorized to do?
Security Telemetry and Observability answers: What are the agents actually doing?
Human Oversight and Accountability answers: Who is responsible for the authority granted to the agent, and when must humans intervene?
Together they create a continuous feedback loop between policy and behavior. This is represented in the following figure:
This feedback loop is fundamental to the architecture.
An autonomous agent should not be viewed as a system that receives authority once and then operates indefinitely. Instead, authority should be continuously contextual, observable, and revocable.
Ten Security Layers
The ten security layers listed in the reference architecture provide the principal technical and operational controls for securing agentic AI. Each layer is described below.
Layer One: Governance and Policy
Security begins before an agent is deployed.
Organizations need policies governing:
- which agents may be created;
- who may create them;
- what data classifications agents may access;
- which tools they may invoke;
- what actions require human approval;
- maximum transaction values;
- maximum privilege levels;
- permitted models;
- permitted deployment environments;
- acceptable autonomous behavior;
- logging requirements;
- retention requirements;
- incident-response procedures;
- agent retirement and credential revocation.
An agent should therefore have an explicit mission definition.
For example:
“This agent may analyze security alerts, retrieve supporting telemetry, correlate events, and recommend containment actions. It may not independently disable production systems.”
This creates an enforceable boundary between decision support and autonomous action.
Governance also needs to address agent lifecycle management.
An enterprise should be able to answer:
- How many agents exist?
- Who owns each agent?
- What model does each agent use?
- What tools can each agent access?
- What credentials does each agent possess?
- Which data can each agent access?
- When was the agent last validated?
- What actions has it taken?
- Has its configuration changed?
Without an enterprise-wide inventory, agent sprawl can rapidly become an unmanaged attack surface.
Layer Two: Agent Identity and Authorization
Identity is the foundation of agent security. Every meaningful agent action should be attributable to a specific agent identity.
Microsoft Entra Agent ID demonstrates the emerging enterprise pattern: purpose-built agent identities, identity governance, access controls, and authentication mechanisms designed for autonomous and interactive agents.
An enterprise agent identity should contain—or be associated with:
- unique identifier;
- owner;
- business purpose;
- parent application;
- model;
- capabilities;
- approved tools;
- authorized data sources;
- environment;
- risk classification;
- expiration or review date;
- credentials;
- policy bindings;
- audit history.
Least privilege becomes dynamic – Traditional least privilege typically establishes permissions around applications or users.
Agentic systems require contextual least privilege. An agent might be allowed to read a database but not modify it. It might be allowed to modify one database but not another. It might be allowed to perform a transaction only below a particular financial threshold. It might be allowed to invoke an administrative API only after additional authentication or human approval.
Authorization should therefore evaluate: Agent + User/Principal + Tool + Resource + Action + Context + Execution State
rather than simply: User → Resource
Layer Three: Agent Development and Supply-Chain Security
Agentic systems introduce a new software supply chain.
The chain may include:
- foundation models;
- fine-tuned models;
- agent frameworks;
- orchestration libraries;
- MCP servers;
- A2A components;
- plugins;
- tools;
- APIs;
- containers;
- Python packages;
- prompts;
- system instructions;
- memory stores;
- vector databases;
- external knowledge sources.
Each component creates a potential attack surface.
A malicious or compromised component could:
- alter agent behavior;
- steal credentials;
- manipulate tool calls;
- inject instructions;
- exfiltrate data;
- introduce unauthorized dependencies;
- compromise another agent.
Consequently, organizations need an AI/agent software bill of materials and provenance mechanisms connecting development artifacts to production execution.
Security scanning should extend beyond source code to:
- models;
- model dependencies;
- agent configurations;
- prompts;
- tools;
- MCP servers;
- container images;
- packages;
- model artifacts.
Palo Alto Networks, for example, describes Prisma AIRS capabilities spanning model security, supply-chain assessment, AI red teaming, and runtime controls.
The objective is to establish a chain of trust:
Developer → Source → Build → Artifact → Agent Package → Deployment → Runtime
Layer Four: Agent Guardrails
Guardrails constrain what the agent is allowed to do. They can operate at several points:
Input
Detect:
- prompt injection;
- malicious instructions;
- sensitive information;
- suspicious context;
- unauthorized objectives.
Reasoning/context
Evaluate:
- instruction hierarchy;
- policy conflicts;
- suspicious context;
- unsafe objectives;
- anomalous reasoning patterns.
Tool invocation
Validate:
- destination;
- parameters;
- credentials;
- scope;
- data sensitivity;
- transaction limits.
Output
Inspect:
- sensitive information;
- malicious content;
- policy violations;
- unsafe recommendations;
- unintended disclosure.
Guardrails should not be considered a complete security solution. An agent can satisfy a textual guardrail while still operating inside a compromised runtime. This is one reason the architecture includes Confidential Computing.
Layer Five: Model and Prompt Security
The model is only one component of an agentic system, but it remains critical.
Model security includes:
- model provenance;
- model integrity;
- model supply-chain security;
- malicious model detection;
- prompt protection;
- system-instruction protection;
- model access control;
- inference monitoring;
- model version control.
The architecture should distinguish between model integrity and model behavior. A model can be authentic but still generate unsafe actions. Conversely, a model may behave normally while the surrounding agent framework or tool infrastructure has been compromised.
Therefore: Model integrity ≠ agent integrity
and: Agent identity ≠ execution integrity.
These distinctions are central to the architecture.
Layer Six: Runtime and Tool Security
The most significant difference between generative AI and agentic AI is the ability to act. Tools therefore become security boundaries.
An agent might call:
- an email service;
- a database;
- a cloud API;
- a shell;
- a browser;
- a payment system;
- a CRM;
- an EDR platform;
- a ticketing system;
- another AI agent.
Every tool call should be treated as an authorization event.
The security architecture should enforce: Who → Agent → Tool → Action → Resource → Result
rather than allowing: Agent → Tool
without contextual validation.
Palo Alto Networks describes its Prisma AIRS agent security capabilities as providing visibility into agent actions, identity verification, runtime policy enforcement, and control over tool calls and MCP connections.
Other vendors—including Cisco, CrowdStrike, Check Point, Aembit, Zenity, and Dash Security—represent different approaches to securing AI workloads, identities, access, runtime behavior, and agent ecosystems.
The important architectural point is that these technologies should be treated as control components, not as substitutes for the architecture itself.
Layer Seven: Confidential Computing and Attested Agent Execution
Confidential Computing addresses a security problem that conventional encryption does not fully solve.
Data can be encrypted:
- at rest;
- in transit;
but historically it has often been exposed in memory while being processed.
Confidential Computing introduces hardware-assisted mechanisms designed to protect data in use through Trusted Execution Environments.
NIST’s 2026 draft work on Confidential Computing specifically addresses protecting AI workloads and describes the objective of ensuring that AI model memory is accessible only to authorized code running within an appropriate trust domain.
This is particularly relevant to agentic AI because agents may process:
- confidential business information;
- credentials;
- proprietary models;
- sensitive prompts;
- private memory;
- security telemetry;
- customer information;
- regulated data.
Where It Belongs in the Architecture
Confidential Computing should not be treated as merely another application-level control.
It occupies a deeper position between the runtime and hardware / root of trust.
This placement is important.
Identity tells us: Which agent is acting?
Confidential Computing helps answer: What execution environment is actually running the agent?
Remote attestation provides the bridge between the two.
Remote Attestation
Remote attestation allows a remote party to obtain cryptographically verifiable evidence about the state of a computing environment.
For example, AWS Nitro Enclaves can generate signed attestation documents containing measurements associated with the enclave. Those measurements can then be used by an external service to determine whether the enclave should receive access to cryptographic operations or sensitive data.
Google similarly describes Confidential Computing attestation as a mechanism for verifying that sensitive data is being processed inside an appropriately trusted hardware-backed environment.
For agentic AI, this creates a potentially powerful security pattern:
Agent Identity + Runtime Identity + Attestation = Attested Agent Identity
Instead of merely asking:
Is Agent X authorized to access this data?
the system can ask:
Is Agent X authorized to access this data and is Agent X executing approved code in an approved confidential environment?
This is a major architectural improvement. Figure 2 provides and overview of an attested agent execution architecture using Confidential Computing.
Protecting Agent Memory
Agent memory represents a particularly important attack surface.
Memory may contain:
- previous conversations;
- credentials;
- business context;
- user preferences;
- intermediate reasoning information;
- retrieved documents;
- operational state;
- instructions.
OWASP explicitly identifies memory and context poisoning as an agentic security risk.
Memory protection should therefore include:
- integrity controls;
- access controls;
- encryption;
- provenance;
- versioning;
- poisoning detection;
- rollback;
- isolation between tenants and agents.
Confidential Computing can provide an additional layer by protecting sensitive memory while it is actively processed. However, confidential execution does not automatically guarantee semantic integrity. A malicious instruction placed legitimately inside an enclave remains a malicious instruction.
Therefore: Confidentiality of memory ≠ integrity of memory
Both must be addressed.
Protecting Credentials and Secrets
Agents frequently require credentials to accomplish their objectives.
Examples include:
- cloud credentials;
- API tokens;
- database credentials;
- signing keys;
- service-account credentials.
Storing these directly in agent prompts or persistent memory creates significant risk.
A more secure architecture uses attestation-bound secret release.
The process becomes:
- Agent requests access.
- Identity service validates agent identity.
- Runtime provides attestation evidence.
- Attestation verifier validates the environment.
- Policy engine evaluates agent authorization.
- Secret-management system releases only the permitted secret.
- Agent performs the operation.
- Access is logged and potentially revoked.
AWS demonstrates this general pattern by integrating Nitro Enclave attestation with KMS so cryptographic operations can be conditioned on enclave measurements. This pattern could become particularly important for high-value autonomous agents.
Protecting AI Models
Confidential Computing also has implications for model protection. Organizations increasingly use proprietary models or models containing sensitive intellectual property.
A confidential execution environment can potentially protect:
- model parameters;
- inference data;
- prompts;
- intermediate state;
- sensitive model-serving operations.
NVIDIA has extended Confidential Computing into GPUs, with hardware-rooted attestation for supported GPU platforms. Its current documentation describes remote attestation for Hopper and Blackwell GPUs operating in Confidential Computing mode.
This is significant because many modern AI workloads are GPU-intensive.
The security boundary therefore needs to evolve from: CPU → VM
toward: CPU + VM + GPU + accelerator + network + software.
An agent could eventually require an attestation chain spanning the entire computational environment.
Limitations of Confidential Computing
Confidential Computing should not be treated as a universal solution.
A TEE can help protect data and code from certain classes of infrastructure-level compromise, but it does not automatically prevent:
- prompt injection;
- malicious instructions;
- model hallucination;
- unsafe tool use;
- compromised dependencies;
- malicious data;
- memory poisoning;
- authorization mistakes.
Nor does attestation prove that an agent will behave correctly.
It establishes evidence about a measured environment.
That distinction is fundamental:
Attestation establishes properties of an execution environment; policy and behavioral controls determine whether the resulting actions are acceptable.
Consequently, Confidential Computing should be viewed as a trust-enabling technology within a larger architecture, not a replacement for agent security.
Layer Eight: Infrastructure and Network Security
Confidential Computing does not eliminate conventional infrastructure security. Agents still require:
- network segmentation;
- container security;
- Kubernetes security;
- endpoint protection;
- vulnerability management;
- cloud security;
- firewalling;
- API security;
- secrets management;
- secure configuration.
The difference is that infrastructure controls become part of a larger chain of trust.
NIST’s hardware-enabled security guidance emphasizes that protecting the platform on which workloads execute is foundational to higher-level security controls.
The resulting hierarchy is: Hardware Root of Trust → Trusted Infrastructure → Trusted Runtime → Trusted Agent → Authorized Action
No single layer is sufficient.
Layer Nine: Continuous Validation and Adversarial Testing
Agentic systems cannot be secured through a one-time assessment.
Their:
- prompts change;
- models change;
- tools change;
- permissions change;
- memories change;
- dependencies change;
- environments change.
Security testing must therefore be continuous.
This includes:
AI red teaming
Testing for:
- prompt injection;
- jailbreaks;
- tool abuse;
- privilege escalation;
- data exfiltration;
- memory poisoning;
- malicious tool calls.
Agent behavioral testing
Testing whether an agent:
- follows mission constraints;
- respects authorization;
- handles ambiguity safely;
- stops when required;
- escalates appropriately.
Runtime validation
Monitoring for:
- unusual tool usage;
- unusual destinations;
- excessive privileges;
- abnormal transaction patterns;
- suspicious inter-agent communication.
The objective is not merely to determine whether the agent is secure at deployment. It is to determine whether the agent remains secure while operating.
Layer Ten: Security Operations and Incident Response
Agentic AI must become part of the SOC.
Security operations should monitor:
- agent creation;
- agent identity;
- authentication;
- tool invocation;
- model usage;
- data access;
- policy violations;
- inter-agent communication;
- anomalous behavior;
- credential usage.
The SOC also needs new response capabilities.
A conventional incident response process might disable:
- a user;
- an endpoint;
- an application;
- an API key.
Agentic incident response may require simultaneously disabling:
- the agent identity;
- credentials;
- active sessions;
- tool permissions;
- memory;
- MCP connections;
- A2A relationships;
- deployment artifacts.
GreyMatter and the Agentic SOC
ReliaQuest GreyMatter and GreyMatter Attack represent an important direction in this area.
The underlying concept is that AI can increasingly participate in security operations themselves—investigating alerts, correlating information, accelerating analysis, and potentially orchestrating response actions.
This creates an interesting recursive problem: Who secures the AI that is securing the enterprise?
An AI security agent may possess particularly sensitive privileges.
For example, a SOC agent could potentially:
- isolate endpoints;
- disable accounts;
- block network connections;
- modify firewall rules;
- initiate investigations.
Consequently, security agents should receive more, not less, architectural scrutiny.
The security architecture proposed here requires that autonomous security agents remain subject to the same:
- identity controls;
- least-privilege requirements;
- runtime monitoring;
- attestation;
- policy enforcement;
- human escalation;
- audit controls
as other agents.
Agent-to-Agent Security
One of the most significant emerging challenges is the transition from individual agents to agent ecosystems.
An agent may ask another agent to:
- retrieve information;
- perform an action;
- authorize a transaction;
- analyze data;
- execute code.
This introduces a new form of distributed computing.
The security question becomes: How does Agent A know that Agent B is trustworthy?
Authentication alone is insufficient. Agent A may know that Agent B possesses a valid identity while knowing nothing about:
- B’s current software;
- B’s model;
- B’s authorization;
- B’s provenance;
- B’s runtime state;
- B’s security posture.
The future architecture therefore needs attested agent-to-agent trust.
A potentially stronger protocol is:
Agent Identity → Capability Declaration → Authorization → Runtime Attestation → Action
This is an area where the current ecosystem remains immature.
MCP and A2A Security
The emergence of protocols such as the Model Context Protocol and agent-to-agent communication frameworks creates both interoperability and security challenges.
MCP can give agents access to external tools and resources. A2A-style protocols can allow agents to communicate and delegate tasks. But every additional connection increases the attack surface.
Security controls should include:
- mutual authentication;
- capability discovery;
- authorization;
- provenance;
- message integrity;
- replay protection;
- rate limiting;
- policy enforcement;
- runtime monitoring.
OWASP explicitly identifies insecure inter-agent communication and agentic supply-chain vulnerabilities among the major risks of agentic applications.
Memory Security
Memory is likely to become one of the most important—and least understood—security boundaries in agentic AI.
An agent can potentially retain information that influences future behavior.
An attacker who successfully poisons that memory may not need to compromise the model itself.
The attack can instead manipulate:
Context → Memory → Future Decision → Future Action
Security controls should therefore include:
- memory provenance;
- signed memory objects;
- trust levels;
- source attribution;
- expiration;
- anomaly detection;
- rollback;
- compartmentalization.
Confidential Computing can protect memory from unauthorized observation, but organizations must still determine whether the memory should be trusted
Human Oversight
The objective is not to eliminate humans from agentic systems.
Rather, human involvement should be concentrated at high-value control points.
Examples include:
- unusual financial transactions;
- privilege escalation;
- production changes;
- security containment;
- external communications;
- sensitive data transfers.
This produces a graduated autonomy model:
Level 0 — Advisory
Agent recommends; human executes.
Level 1 — Assisted
Agent executes low-risk actions with continuous monitoring.
Level 2 — Conditional autonomy
Agent executes defined actions subject to policy.
Level 3 — High autonomy
Agent performs complex workflows with limited intervention.
Level 4 — Strategic autonomy
Agent manages other agents or high-impact processes.
Higher autonomy should correspond to stronger:
- identity;
- authorization;
- attestation;
- monitoring;
- testing;
- rollback;
- governance
Vendor and Tool Mapping
The emerging market can be mapped against the architecture.
| Security Function | Representative Technologies / Platforms |
| Agent identity | Microsoft Entra Agent ID |
| Enterprise agent control plane | Microsoft Agent 365 |
| AI/runtime security | Palo Alto Prisma AIRS |
| AI security / network security | Cisco |
| Endpoint / identity / AI security | CrowdStrike |
| Software and AI supply chain | JFrog |
| Guardrails | NVIDIA NeMo Guardrails |
| Network and AI security | Check Point |
| Agent identity / access | Aembit |
| Agent discovery and governance | Zenity |
| Agent runtime security | Dash Security |
| AI-powered SOC | ReliaQuest GreyMatter |
| AI attack simulation / validation | GreyMatter Attack |
| AI security architecture / validation | WWT ARMOR |
| Agent framework / orchestration | IBM BeeAI |
| Data-loss / information protection | Somansa |
| Guardrails | Guardrails AI |
| Agent monitoring / security | Vigil |
| LLM input/output security | LLM Guard (representative) |
| Prompt-injection defenses | Rebuff (representative) |
| Confidential GPU execution | NVIDIA Confidential Computing |
| Confidential cloud execution | AWS Nitro Enclaves / Google Confidential Computing |
This table should not be interpreted as a product ranking.
The products operate at different architectural layers and often solve different problems.
The more important observation is that no individual product currently represents the entire security architecture.
The Architecture’s Major Gaps
Several areas remain immature.
- Agent-to-Agent Trust – There is not yet a universally adopted model for establishing trust between autonomous agents.
- Memory Integrity – Protecting memory confidentiality is easier than proving that memory contains trustworthy information.
- Runtime Provenance – Organizations need stronger mechanisms linking: approved artifact → deployed agent → running instance
- Model-to-Runtime Integrity – Model provenance alone does not establish that the expected model is actually executing.
- Attested Agent Identity – Identity systems are increasingly sophisticated, while hardware-backed execution attestation for agents remains less mature.
- Agent Behavior – Authentication can establish who an agent is. It cannot guarantee what the agent will do. Behavioral monitoring therefore remains essential.
A Unified Trust Model
The architecture ultimately produces five distinct forms of trust.
- Identity Trust
Who is the agent?
- Authorization Trust
What may the agent do?
- Artifact Trust
What software, model, tools, and configuration make up the agent?
- Execution Trust
Where and under what verified conditions is the agent executing?
- Behavioral Trust
Is the agent behaving consistently with its mission and policy?
These should not be collapsed into one concept. An agent can have valid identity but malicious software. An agent can have approved software but compromised runtime infrastructure. An agent can have a trusted runtime but poisoned memory. An agent can be fully authentic and still make an unsafe decision.
Consequently: Trust in agentic AI must be compositional rather than binary.
Control Matrix
| Threat | Primary Control | Secondary Controls |
| Prompt injection | Guardrails | Runtime monitoring, red teaming |
| Excessive privilege | Agent identity | Least privilege, JIT access |
| Credential theft | Secrets management | Confidential Computing, attestation |
| Tool abuse | Tool authorization | Runtime policy |
| Memory poisoning | Memory integrity | Provenance, rollback, monitoring |
| Model compromise | Model supply-chain security | Confidential execution |
| Malicious MCP server | Supply-chain controls | Runtime isolation |
| Rogue agent | Identity + behavior monitoring | Kill switch |
| Agent impersonation | Strong identity | Attestation |
| Compromised runtime | Confidential Computing | Infrastructure security |
| Data exfiltration | DLP | Guardrails, network controls |
| Inter-agent attack | Mutual authentication | Authorization, attestation |
| Cascading failure | Segmentation | Rate limiting, circuit breakers |
| Unauthorized autonomy | Governance | Human approval |
| Unknown agent | Discovery/control plane | Identity lifecycle management |
Implementation Roadmap
Organizations should not attempt to implement every capability simultaneously.
Phase 1 — Discover
Create an inventory of:
- agents;
- models;
- tools;
- APIs;
- identities;
- data sources;
- MCP servers;
- agent-to-agent relationships.
Phase 2 — Establish Identity
Assign every production agent:
- unique identity;
- owner;
- purpose;
- permissions;
- lifecycle.
Phase 3 — Apply Least Privilege
Reduce:
- standing privileges;
- shared credentials;
- unrestricted tool access;
- excessive data access.
Phase 4 — Introduce Guardrails
Implement:
- input filtering;
- output controls;
- tool authorization;
- prompt-injection detection;
- data-loss controls.
Phase 5 — Secure the Runtime
Implement:
- sandboxing;
- isolation;
- monitoring;
- network segmentation;
- secure deployment pipelines.
Phase 6 — Introduce Confidential Computing
For higher-risk workloads, evaluate:
- confidential VMs;
- TEEs;
- confidential containers;
- confidential GPUs;
- remote attestation;
- attestation-based secret release.
Phase 7 — Continuous Validation
Implement:
- adversarial testing;
- red teaming;
- behavioral validation;
- continuous policy verification.
Phase 8 — Integrate With the SOC
Connect agent telemetry to:
- SIEM;
- SOAR;
- EDR/XDR;
- identity monitoring;
- incident response.
The Emerging Security Paradigm
The security architecture for agentic AI is beginning to resemble the architecture developed for distributed computing and cloud infrastructure—but with an important difference.
Cloud workloads generally execute predetermined software.
Agentic workloads contain a decision-making component capable of dynamically selecting actions.
This creates a new security paradigm:
Secure the identity.
Secure the instructions.
Secure the model.
Secure the tools.
Secure the memory.
Secure the execution environment.
Secure the communications.
Secure the actions.
Continuously verify the entire system.
The resulting architecture is closer to a digital immune system than a traditional application firewall.
Final Thoughts
Agentic AI represents a transition from software that primarily processes information to software that can make decisions and take actions.
That transition changes cybersecurity fundamentally.
The principal challenge is not simply protecting the underlying AI model. It is creating a trustworthy environment in which autonomous systems can operate while remaining constrained, observable, accountable, and reversible.
A mature architecture therefore requires multiple complementary layers:
- governance establishes the boundaries;
- identity establishes accountability;
- authorization establishes permitted actions;
- supply-chain security establishes provenance;
- guardrails constrain behavior;
- runtime security controls tools and interactions;
- Confidential Computing protects sensitive execution;
- remote attestation provides evidence about the execution environment;
- infrastructure security protects the underlying platform;
- continuous validation tests whether controls remain effective;
- security operations detect and respond when those controls fail.
The introduction of Confidential Computing adds an important dimension to this model.
Traditional agent security asks:
Who is the agent?
The next generation must ask:
Who is the agent, what is it authorized to do, what software is it running, where is it running, can that environment be cryptographically verified, and is it continuing to behave within its authorized mission?
That is the foundation of bounded autonomy. The ultimate objective is not to prevent AI agents from acting. It is to make autonomous action trustworthy, constrained, observable, and revocable.
As enterprises move from isolated AI experiments toward fleets of autonomous agents, the organizations that succeed will likely be those that treat agent security not as an add-on to AI development, but as a new enterprise security architecture in its own right. Give me your views on agent security architectures. Are you using Confidential Computing? What is in your agent security toolbox? And thanks to my subscribers and visitors to my site for checking out ActiveCyber.net! Please give us your feedback because we’d love to know some topics you’d like to hear about in the area of active cyber defenses, artificial intelligence, authenticity, quantum cryptography, risk assessment and modeling, autonomous security, digital forensics, securing OT / IIoT and IoT systems, Augmented Reality, or other emerging technology topics. Also, email chrisdaly@activecyber.net if you’re interested in interviewing or advertising with us at Active Cyber™.
