Four security layers for enterprise AI agents
A useful agent security model separates the problem into four layers. Each one solves a different class of failure.
Identity
Give every agent a unique non-human identity with least privilege and short-lived credentials.
Semantic controls
Filter prompts, retrieved content, and outputs so the agent is harder to hijack through language or poisoned context.
Execution controls
Contain what the agent can do at runtime through tool mediation, sandboxing, network boundaries, and scoped transactions.
Governance
Apply approvals, evidence collection, and lifecycle accountability to high-risk actions and privileged agent operations.
Who is acting?
What is the agent being asked to do?
What can it actually invoke?
Should this proceed without human approval?
Identity layer
The identity layer should be grounded in existing cloud workload identity, not in overstated assumptions about agent-specific control planes.
What enterprises can do now
- Azure-hosted agents: use system-assigned or user-assigned managed identities when the runtime is native to Azure.
- External or SaaS-hosted agents: use service principals or workload identity federation when Entra-issued tokens are needed.
- AWS-hosted agents: use runtime-scoped IAM roles such as Lambda execution roles, ECS task roles, EKS Pod Identity, or service roles.
- Cross-cloud access: use federation and temporary credentials rather than embedded secrets.
Agent-specific identity capabilities
- Microsoft Entra Agent ID is a real Microsoft capability for governing and securing agent identities.
- It should be described as an emerging Microsoft control plane, not the universal identity baseline for all enterprise AI agents today.
- Conditional Access for Agent ID should be treated as preview capability, not as a mature cross-platform norm.
- Managed identities remain strong runtime identities, but they are not covered by Conditional Access for workload identities.
Recommended identity hierarchy
| Hosting pattern | Preferred identity | Why |
|---|---|---|
| Azure-native agent runtime | User-assigned or system-assigned managed identity | Secretless, auditable, tightly integrated with Azure RBAC and data-plane authorization. |
| External agent requiring Entra access | Service principal with federation | Works with supported workload identity controls and avoids long-lived secrets. |
| AWS-native agent runtime | IAM role + STS temporary credentials | Shortest path to least privilege at the runtime boundary. |
| Cross-cloud / hybrid agent | Federation in each cloud | Clear trust anchors, scoped tokens, and auditable short-lived access. |
Semantic layer
Identity does not prevent an agent from being manipulated through language. The semantic layer is the defense against prompt injection, context poisoning, and unsafe tool selection.
Threats this layer addresses
- Direct prompt injection and instruction override.
- Indirect prompt injection through email, documents, knowledge bases, or web content.
- Unsafe tool invocation caused by malicious or ambiguous instructions.
- Unsafe output generation including data leakage and policy violations.
Realistic controls
- Azure: Azure AI Content Safety, Prompt Shields, groundedness and safety evaluation patterns.
- AWS: Amazon Bedrock Guardrails and explicit tool mediation around prompts and outputs.
- Independent validation steps before tool invocation and before returning output to users.
- Structured prompts, tool schemas, and retrieval filters that reduce ambiguity and blast radius.
Semantic validation flow
Allow · Challenge · Block
Execution layer
Even a well-identified and semantically screened agent can still cause damage if runtime permissions, network paths, and tool access are too broad.
Containment controls
- Ephemeral compute or isolated task runtimes.
- Private networking and egress control.
- Per-tool allow-lists and explicit action mediation.
- Read-only filesystems where possible and scoped temporary storage.
- Resource quotas, circuit breakers, and rollback design.
Task-scoped authorization, stated correctly
- Task-scoped permissions are a valid architectural target.
- In practice they are usually built through orchestration logic, policy engines, ephemeral credentials, and approval workflows.
- They should not be presented as though a single cloud-native “TBAC” feature already exists universally across platforms.
- Use them as a design pattern: scope identity, tool access, transaction range, and time window to the active task.
Execution authorization envelope
| Dimension | Question | Example control |
|---|---|---|
| Task | What is the agent trying to achieve? | Permit only the task-specific workflow and data scope. |
| Tool | Which APIs, plugins, or systems may it invoke? | Tool allow-list and per-tool parameter validation. |
| Transaction | Which exact action is allowed right now? | Rate limits, value limits, object scoping, and time-bounded credentials. |
Governance layer
High-impact agent actions should not be described as if there is a single turnkey “step-up token” feature for every case. Governance is usually implemented as a composed workflow.
What governance should cover
- Financial actions above a threshold.
- Destructive data changes.
- Privilege grants and identity changes.
- Security policy or network policy modifications.
- Bulk export or cross-boundary movement of sensitive data.
How to phrase the control model accurately
- Use Conditional Access, authentication context, PIM-style elevation, or custom approval workflows where supported.
- Describe the end state as a governed approval pattern, not as a universal built-in agent authorization mechanism.
- Preserve strong evidence: who approved, what context was reviewed, what changed, and for how long.
- Ensure approval grants are time-bound and tied to a narrow action set.
High-risk action approval flow
Cross-cloud security
Cross-cloud agents introduce real confused-deputy and trust-boundary risks. The underlying problem is real, but trust policies must be described using documented cloud patterns.
What is valid to say
- Azure-hosted or federated agents that access AWS need carefully scoped AWS trust and authorization boundaries.
- Confused deputy protection is relevant when one system can act on behalf of another across trust boundaries.
- AWS documents the use of aws:SourceArn and aws:SourceAccount for confused-deputy mitigation in appropriate AWS service contexts.
- CloudTrail and equivalent logs should be used to monitor role assumptions and anomalous access paths.
What to avoid
- Do not invent AWS ARN formats for Azure application identities.
- Do not imply a generic Azure-app-to-AWS-role trust policy pattern that AWS officially documents if it is not actually documented.
- Do not overfit confused-deputy guidance that is intended for AWS cross-service scenarios into unsupported cross-cloud examples.
Recommended cross-cloud pattern
Use standards-based federation and short-lived credentials in each cloud, then enforce resource-side least privilege, logging, and approval for high-risk actions. Keep the trust relationship explicit and minimal. Treat the agent as an external workload from the perspective of the target cloud unless it is natively hosted there.
Implementation comparison
A useful comparison should stay architectural and avoid unsupported precision in cost, time-to-production, or compliance outcomes unless assumptions are explicitly defined.
| Pattern | Strengths | Constraints | Best fit |
|---|---|---|---|
| Azure-first | Strong Entra integration, native managed identity, authentication context, Microsoft control-plane visibility. | Agent-specific features may include preview capabilities; external runtime integration still needs careful design. | Enterprises centered on Microsoft identity and Azure-hosted workloads. |
| AWS-first | Strong runtime identity scoping with IAM roles, STS, and service-role boundaries; mature logging and resource policy model. | Agent-specific human-approval and semantic control workflows may require more explicit composition. | Serverless or containerized agents operating primarily inside AWS. |
| Hybrid / multi-cloud | Resilience and portability; avoids single-cloud lock-in. | Highest governance overhead, strongest need for federation design, policy consistency, and observability discipline. | Organizations with hard regulatory, geographic, or platform-diversity requirements. |
Decision tree
Use this simple decision tree to choose the right control emphasis for an agent deployment.
1. Where does the agent run?
Azure-native, AWS-native, or external / SaaS-hosted?
- Azure-native → managed identity first
- AWS-native → IAM role first
- External → service principal or federation
2. Does the agent perform high-risk actions?
If yes, add explicit approval workflows and evidence collection.
- Financial transfer
- Privilege grant
- Destructive change
- Bulk export
3. Does it access cross-boundary data?
If yes, emphasize retrieval-time authorization, segmentation, and cross-cloud federation hygiene.
- RAG over sensitive data
- Partner data access
- Cross-cloud APIs
4. Is the agent fully autonomous?
If autonomy increases, so must mediation, kill switches, and containment.
- Semi-autonomous → scoped approvals
- Broad autonomy → strong runtime containment
5. Are preview capabilities acceptable?
If not, avoid designing core security dependencies around preview-only features.
- Use GA IAM baselines
- Treat preview controls as additive
6. Can you observe and stop the agent quickly?
If no, your architecture is not ready for broad production autonomy.
- Need logs, alerts, kill switch, and rollback
- Need clear ownership and incident playbooks