Conditional Access and Zero Trust for AI Agents

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.

Layer 1

Identity

Give every agent a unique non-human identity with least privilege and short-lived credentials.

Layer 2

Semantic controls

Filter prompts, retrieved content, and outputs so the agent is harder to hijack through language or poisoned context.

Layer 3

Execution controls

Contain what the agent can do at runtime through tool mediation, sandboxing, network boundaries, and scoped transactions.

Layer 4

Governance

Apply approvals, evidence collection, and lifecycle accountability to high-risk actions and privileged agent operations.

Identity
Who is acting?

→

Semantic
What is the agent being asked to do?

→

Execution
What can it actually invoke?

→

Governance
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.

Current baseline

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.

Position carefully

Agent-specific identity capabilities

Microsoft Entra Agent ID reached general availability at Ignite 2025 (November 2025) and is a real Microsoft capability for governing and securing agent identities.
It is Microsoft-specific and license-gated — not the universal identity baseline for all enterprise AI agents across platforms.
Conditional Access for agent identities is currently limited to Block Access only. MFA, authentication strength, device compliance, and session controls are not supported for agent identities.
Agent Risk detection in Conditional Access remains in preview.
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.

The practical design rule is simple: one logical agent, one workload identity, one auditable trust boundary.

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

Prompt or Retrieved Content

→

Safety / Injection Inspection

→

Policy Decision
Allow · Challenge · Block

→

Tool Invocation or Response Generation

The semantic layer should be treated as risk reduction, not as proof that the agent is now safe. It must be paired with execution constraints.

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.

TBAC (Task-Based Authorization Controls) originates from Sandhu & Thomas, IFIP WG11.3, 1997 — it is an academic access-control model, not a NIST/ISO standard or productized cloud feature. Note: “TBAC” is also used in industry for “Time-Based Access Control” (JIT, time-boxed grants) — a distinct concept sharing the acronym.

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.

Execution security is where Zero Trust becomes operational: never assume the agent should retain standing access once the current task step is complete.

Cloud-native

AWS STS — ephemeral task-scoped credentials

AWS STS AssumeRoleWithWebIdentity vends temporary credentials with a minimum duration of 900 seconds (15 minutes). Session policies (inline Policy parameter or managed PolicyArns) can further restrict the assumed role’s permissions to only what the current task requires — session policies can only reduce, not grant.

This is the primary cloud-native mechanism for ephemeral, task-scoped agent access in AWS.

Emerging standard

Model Context Protocol (MCP)

The Model Context Protocol (MCP, donated to the Linux Foundation’s AAIF in December 2025) is emerging as the standard for exposing Tools, Resources, and Prompts to AI models.

Every MCP tool invocation is an authorization decision point — the execution layer should enforce per-tool allow-lists, argument validation, and policy-engine authorization before any tool executes.

MCP security uses OAuth 2.1 (IETF draft) with mandatory PKCE; Dynamic Client Registration and Protected Resource Metadata are defined in the specification.

Tooling

Policy-as-Code authorization engines

Policy-as-Code tools for agent authorization include:

Cerbos — YAML policies with CEL expressions.
OPA / Rego — general-purpose policy engine widely adopted in Kubernetes and service-mesh deployments.
Cedar — Amazon Verified Permissions, AWS-native.
Polar — Oso’s logic-based policy language.

These tools evaluate authorization requests in real-time against declarative policies that encode ABAC, ReBAC, and TBAC rules.

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.

Important caveat: authentication context, PIM-style elevation, and MFA-based step-up apply to USER identities, not to agent/workload identities. Service principals cannot satisfy interactive authentication challenges. For agents, governance is implemented through conditional access policies scoped to service principals (Block Access only), custom approval workflows in orchestration logic, time-bound scoped credential issuance via STS, and policy-engine-driven authorization gates.

High-risk action approval flow

Agent Requests Sensitive Action

→

Policy / Risk Check

→

Human Approval or Denial

→

Time-Bound, Scoped Execution

Do not imply that every governance flow is natively cryptographic and automatic. In many enterprises, the secure implementation is a composite of IAM, approval workflow, orchestration logic, and logging.

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.

The correct architectural emphasis is federation + temporary credentials + least privilege + auditability, not custom identity translation logic.

Emerging patterns

Decentralized identity for cross-organizational agents

For future cross-organizational agent scenarios where centralized identity providers are insufficient, emerging patterns include:

W3C Decentralized Identifiers (DIDs v1.0) — self-sovereign identifiers decoupled from any single provider.
Verifiable Credentials (VC Data Model v2.0) — cryptographically signed claims exchangeable across trust boundaries.
Zero-Knowledge Proofs (BBS+ cryptosuite) — selective disclosure of attributes without revealing the underlying claim set.

These are research-stage as of 2025 and not production-ready alternatives to federation. They may, however, become relevant for decentralized agent ecosystems where bilateral federation is impractical or where no single trust anchor is acceptable to all parties.

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.

Do not publish exact cost, timeline, or compliance scores without explicit scope assumptions. Those values become misleading very quickly.

Decision tree

Use this decision tree to choose the right control emphasis for an agent deployment. Walk forks 1–12 in order; the answers converge on one of nine terminal outcomes. The recommended outcome provides a baseline control set, which the wizard then augments with additional controls based on your specific answers.

Question 1 of 12

Allow unusual combinations

Decision forks

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
Security or network policy modification

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

7. Identity type — delegated or workload?

Is the agent acting on behalf of a user, or as an autonomous workload? This is a bigger fork than hosting location.

Delegated → user-bound tokens, authentication-context step-up available
Workload → managed identity / IAM role / federation; no interactive MFA

8. Does the agent invoke external tools or MCP servers?

Every MCP tool invocation is an authorization decision point.

Per-tool allow-list + argument validation
OAuth 2.1 + PKCE for MCP servers
Policy-engine gate (OPA / Cedar / Cerbos) before each call

9. What data sensitivity tier does it touch?

Tier drives the governance burden by an order of magnitude.

Public / internal → baseline RBAC + light semantic screening
PII / PHI → DLP, retrieval-time authorization, redaction, audit trail
Secret / regulated → tightest containment, JIT elevation, biometric re-auth

10. What is the approval latency profile?

Choose the CIBA delivery mode that matches the workflow cadence.

Background / batch → CIBA Poll (async, non-blocking)
Interactive → CIBA Ping (callback on decision)
Real-time / high-velocity → CIBA Push + biometric step-up

11. Does the agent cross organizational trust boundaries?

Cross-org agents need federation hygiene distinct from cross-cloud.

Same org, multi-cloud → federation + STS in each cloud
Cross-org → bilateral federation; consider DIDs / Verifiable Credentials
Unknown / dynamic trust → defer; not production-ready

12. What regulatory tier applies?

Regulation shifts minimum obligations, not just best practice.

EU AI Act high-risk → strict obligations, evidence retention
GDPR-scope personal data → data minimisation, purpose limitation
NIST AI RMF voluntary → governance scaffolding, no binding force

Terminal outcomes

Compose controls from the forks above. The nine canonical outcomes below cover the most common combinations. The wizard augments each baseline with controls based on your specific answers.

Outcome A

Lightweight internal agent

When: workload identity, no MCP, internal data, async, single-org, minimal-risk.

Cloud-native managed identity or IAM role
Scoped RBAC, short-lived credentials
Light semantic screening (Prompt Shields or Bedrock Guardrails)
Standard logging; no human-in-loop required

Outcome B

Interactive delegated agent

When: delegated identity, MCP tools, internal + PII, interactive Ping, single-org, GDPR-scope.

User-bound tokens with authentication-context step-up
Per-tool allow-list + OAuth 2.1 PKCE for MCP
DLP + retrieval-time authorization + redaction
CIBA Ping callback for human consent
Conditional Access (Block Access) on the workload identity

Outcome C

High-risk autonomous agent

When: workload, MCP, PHI / secret, real-time Push, single-org, EU AI Act high-risk.

Workload identity + PIM-style elevation for sensitive actions
Per-tool policy-engine gate (OPA / Cedar)
Strict containment: ephemeral compute, egress control, read-only FS
CIBA Push + biometric re-auth for high-velocity actions
Evidence retention per EU AI Act; kill switch + rollback

Outcome D

Cross-org federated agent

When: workload, MCP, partner data, async or interactive, cross-org, mixed regulatory.

Bilateral federation + STS in each cloud
Confused-deputy protection (aws:SourceArn / SourceAccount)
Per-tool allow-list scoped to partner resources
DIDs / Verifiable Credentials if no central trust anchor
Cross-cloud audit (CloudTrail + Azure Monitor)

Outcome F

Hardened internal agent

When: workload identity, no MCP, no high-risk, same-org — but with sensitive data, broader autonomy, partial observability, or interactive latency that requires hardening beyond the lightweight baseline.

Cloud-native managed identity or IAM role
Scoped RBAC, short-lived credentials
Light semantic screening (Prompt Shields or Bedrock Guardrails)
Standard logging + audit trail

Baseline only. The wizard augments with additional controls (DLP, kill switch, CIBA mode, containment) based on your specific answers.

Outcome G

Delegated lightweight agent

When: delegated identity, no MCP, no high-risk, same-org — a user-bound agent that drafts content, summarizes, or fills forms without invoking external tools or performing sensitive actions.

User-bound tokens with Conditional Access (Block Access) on auth context
Light semantic screening (Prompt Shields or Bedrock Guardrails)
Standard logging + user activity audit trail
No human-in-loop required for routine actions

Baseline only. The wizard augments with additional controls based on your specific answers.

Outcome J

Workload integration agent

When: workload identity, MCP tools, no high-risk, same-org — a workload bot that calls SaaS APIs (Salesforce, ServiceNow, Jira) for data enrichment without performing sensitive actions.

Cloud-native managed identity or IAM role
Per-tool allow-list + OAuth 2.1 PKCE for MCP servers
Light semantic screening (Prompt Shields or Bedrock Guardrails)
Standard logging + per-tool invocation audit

Baseline only. The wizard augments with additional controls based on your specific answers.

Outcome K

Assisted high-risk agent

When: high-risk actions, semi-autonomous — a co-pilot that drafts financial transfers, privilege grants, or destructive changes but waits for explicit human approval before executing.

Workload identity + PIM-style elevation for sensitive actions
Per-action human approval workflow (CIBA Ping)
Evidence collection: who approved, what context, what changed, for how long
Per-action audit trail + kill switch + rollback

Baseline only. The wizard augments with additional controls based on your specific answers.

Outcome L

High-risk workload agent

When: high-risk actions, broadly autonomous, workload identity, same-org — a workload agent that performs sensitive actions autonomously (e.g., cloud resource scalers, credential rotators, batch financial processors) without the extreme-C characteristics (secret data, real-time biometric re-auth, EU AI Act).

Workload identity + PIM-style elevation for sensitive actions
Per-tool policy-engine gate (OPA / Cedar) when MCP is invoked
Standard containment: ephemeral compute, egress control
Kill switch + rollback
Standard audit trail + evidence collection

Baseline only. The wizard augments with additional controls based on your specific answers.

Outcome E

Not production-ready

When: fully autonomous + high-risk + no observability + no kill switch + cross-org with no trust anchor.

Do not deploy to production
Pilot only in sandbox with synthetic data
Re-architect: add containment, kill switch, audit, governance
Re-evaluate against forks 1–12 before promotion

Constraint matrix

To keep recommendations decisive, the wizard restricts later answers based on earlier ones. When a constraint applies, the unavailable options appear grayed out with a tooltip explaining why. If you have an unusual combination that the constraints disallow, toggle "Allow unusual combinations" at the bottom of the wizard to lift all restrictions.

If you answer…	Then these options become restricted…	Why
Q4 autonomy = Broadly autonomous	Q10 latency: Ping unavailable · Q6 observe: Partial and No unavailable	Broad autonomy requires full observability + kill switch (no per-action human oversight), and cannot use Ping (which requires human callback).
Q4 autonomy = Semi-autonomous	Q10 latency: Push unavailable · Q6 observe: No unavailable	Human-in-the-loop provides oversight, so some observability is required; Push (biometric re-auth) is only relevant without a human in the loop.
Q2 high-risk = Yes	Q9 data tier: Public / internal unavailable	High-risk actions imply sensitive impact — public data with high-risk actions is contradictory.
Q7 identity type = Delegated	Q1 hosting: AWS-native unavailable	Delegated identity requires Entra auth context — AWS-native hosting does not support this natively.
Q11 cross-org = Cross-org	Q1 hosting: AWS-native unavailable	Cross-org agents should be externally hosted or Azure-native for federation hygiene.

How to use this tree: Walk forks 1–12 in order. The answers converge on one of outcomes A–K (excluding I). The recommended outcome provides a baseline control set; the wizard then augments with additional controls based on your specific answers (e.g., DLP for PII data, kill switch for partial observability). Treat Outcome E as a hard stop: if any of its conditions are true, do not promote the agent to production.

Compliance & regulatory considerations

Agent architectures operate inside an emerging and uneven regulatory landscape. The frameworks below are the most commonly cited; treat them as design inputs, not as product checklists.

Binding · phased

EU AI Act

Risk-tiered framework: Unacceptable (prohibited), High (strict obligations), Limited (transparency), Minimal (voluntary).
Article 50 imposes transparency obligations for AI systems, including disclosure when users interact with AI and labelling of deepfakes and AI-generated content.
Phased application through August 2027, with earlier milestones for prohibited practices and GPAI obligations.

Binding · data

GDPR — data minimisation

Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purposes for which it is processed.
Directly constrains agent retrieval scope, context retention, and tool argument forwarding.
Pairs with purpose-limitation (Art. 5(1)(b)) and storage-limitation (Art. 5(1)(e)) principles.

Voluntary

NIST AI RMF

Voluntary risk-management framework from the U.S. National Institute of Standards and Technology.
Four core functions: GOVERN, MAP, MEASURE, MANAGE.
Useful for structuring internal policy even where regulation is not yet binding.

Not legal advice. This section summarizes publicly known regulatory frameworks for architectural awareness only. Compliance posture depends on jurisdiction, sector, data processed, and deployment specifics — engage qualified legal counsel for binding determinations.