Four security layers for enterprise AI agents
The four CAZT layers work together throughout an agent’s task. They are complementary responsibilities, not checkpoints passed once. ATF’s five zero-trust elements describe protection objectives that span these layers.
Identity
Establish workload and applicable human identity, ownership, trusted run/task attribution and least privilege. Use SPIFFE/SPIRE on supported runtimes or documented native identities; govern enrollment, rotation and retirement. Identity proves who is acting, not whether an action is authorized.
Semantic controls
Assess proposed actions, prompts, retrieved content and outputs for manipulation, policy violations and data leakage. Combine intent validation with trusted behavioral signals; reassess changed actions. Semantic screening reduces risk and cannot grant authority.
Execution controls
Enforce PDP decisions at the tool PEP, segment resources, tools and networks, and constrain each operation. Monitor execution, block bypass paths and support effective stop controls, containment and rollback or compensating actions.
Governance
Define risk policy, data classification/provenance requirements, eligible approvers, identity lifecycle and evidence retention. Assign incident-response ownership and recovery criteria. Require exact-action human approval when high-risk actions exceed existing authority.
ATF zero-trust elements mapped to CAZT
Agentic Trust Framework (ATF) identifies five zero-trust elements: Identity, Behavior, Data Governance, Segmentation and Incident Response. These elements define protection objectives that span the four CAZT security layers described in this guide: Identity, Semantic, Execution and Governance. The mapping below is a high-level element mapping, not an ATF conformance crosswalk. ATF is an open specification published through the Cloud Security Alliance (specification v0.9.1, public review draft, April 2026; licensed CC BY 4.0; author Josh Woodruff, MassiveScale.AI). Its distinguishing mechanism is earned autonomy: four maturity levels (Intern, Junior, Senior, Principal) with five promotion gates and demotion criteria. Question 16 in the decision tree applies the maturity level alongside the autonomy and approval answers.
| ATF element | CAZT responsibility | Controls and evidence |
|---|---|---|
| Identity | Identity, Governance and Execution | Authenticate workloads and applicable users; record owners and trusted run/task attribution; authorize each action; govern enrollment, renewal, suspension and retirement. |
| Behavior | Semantic, Execution, Identity and Governance | Validate intent, correlate observed tool actions with the authorized task, detect deviations and feed trusted risk signals into policy reassessment and containment. |
| Data Governance | Governance, Semantic and Execution | Track provenance and classification; validate retrieved material; enforce resource-level retrieval permissions, purpose limits, DLP, output controls and retention. |
| Segmentation | Execution and Identity, under Governance policy | Separate tenants, environments, resources, tools and networks; isolate agent/runtime/tool permissions; deny unauthorized paths and lateral movement. |
| Incident Response | Execution and Governance, informed by Identity and Semantic signals | Detect and triage incidents, contain activity, invalidate pending approvals, restrict credentials/sessions, stop agents and tools, recover safely and preserve evidence. |
Continuous evaluation: on each consequential operation and relevant change in context, validate current identity, task scope, policy, risk and approval. Behavioral monitoring supplies evidence to these checks. SPIFFE/SPIRE supplies workload identity; CIBA supports human authentication/consent. Neither replaces the other zero-trust elements.
Layer 1: 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.
Microsoft Entra agent identity capabilities
This guidance applies to Microsoft Entra identities and policies. It does not describe AWS IAM, Okta, Curity or Ping controls; workload hosting alone does not determine which identity policies apply.
- Microsoft Entra Agent ID is a Microsoft-specific agent governance capability. Verify current availability, licensing and supported controls for the target tenant before deployment.
- It is Microsoft-specific and license-gated — not the universal identity baseline for all enterprise AI agents across platforms.
- Separate application-only agent identity policies, agent-user policies and delegated-user policies. Do not apply human MFA to a workload. For supported managed-endpoint agent-user sessions, Microsoft documents device compliance and compliant-network controls using the Agent execution environments (Preview) condition. These are not application-only workload MFA controls. Microsoft scope documentation (updated September 30, 2026).
- Application-only agent policies use documented block controls, including exclusions for approved identities/blueprints or security attributes; agent-risk blocking has its own feature status. Microsoft autonomous-agent policy guidance.
- Endpoint prerequisites: the documented device-compliance scenario requires an Intune-managed Windows 365 Cloud PC for Agents; compliant-network controls additionally require the Global Secure Access client. Scope the preview execution-environment condition to endpoint sessions; these controls do not cover arbitrary AWS/Azure hosted agents.
- Licensing: Microsoft’s October 6, 2026 reviewed documentation lists Microsoft 365 E7, or Agent 365 paired with at least Entra P1 or Microsoft 365 E3. Verify current tenant entitlement. Agent-user prerequisites and limitations.
- Verify the current agent-risk feature status and license for the target tenant; preview/GA status must be dated and feature-specific.
- Managed identities remain strong runtime identities, but they are not covered by Conditional Access for workload identities.
AWS agent identities and resource access
- Separate the AWS products and identities. An IAM role, a Bedrock Agents service role and an AgentCore workload identity have different jobs. A role does not automatically identify each agent instance or task; maintain trusted run attribution.
- AgentCore Identity is AWS-specific. It provides workload identity and credential management, including OAuth tokens and API-key providers. It is not automatically SPIFFE attestation or an end-to-end secretless solution. Scope credential-provider access to the intended workload and user context.
- Separate caller, runtime and tool permissions. Permission to invoke an agent must not imply permission for every tool action. Restrict service-role trust, iam:PassRole and action-group/tool roles; apply supported confused-deputy conditions for the actual AWS service.
- Temporary AWS credentials are not per-action approvals. Task completion or a human denial does not automatically end an STS session. Enforce task expiry and approval at the tool PEP; test IAM deny/revocation and emergency containment paths.
- IAM has its own policy model. Entra Conditional Access can evaluate the human Entra sign-in used to federate into AWS. It does not evaluate subsequent AWS API calls made with IAM role credentials; AWS IAM governs workload role assumptions and resource authorization. External IdP sign-in and CIBA consent do not automatically authorize AWS actions. Preserve least-privilege IAM and exact-operation approval independently.
- Managed AWS hosting does not establish SPIFFE support. Verify the runtime before installing SPIRE. A gateway SVID identifies the gateway; managed agents require documented native credentials and verified caller/run context.
- Check the selected AWS feature. Confirm region, API version, quotas and availability for Bedrock or AgentCore features. Do not assume native CIBA support merely because OAuth integration is available.
Bedrock Agents service roles · AgentCore workload identities · Credential-provider access · Temporary credential containment
Common identity requirements across vendors
Choose the enterprise human IdP separately from AWS/Azure hosting. Verify workload identity, issuer/audience and trust mapping, least privilege, human approver eligibility, and exact-action enforcement. Product-specific controls complement these requirements. Neither Microsoft agent identity features nor AWS agent identity services replace semantic checks, execution containment or governance.
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. |
Ownership, identity lifecycle and attribution
Assign an accountable business owner and technical operator to each agent deployment. Maintain its permitted tasks, enterprise human IdP, runtime identity, tool permissions and retirement criteria. Establish trusted agent/run/task and tenant attribution outside model-generated text; distinguish a shared SPIFFE service identity from an instance-unique identity.
Review registrations and role trust, test credential/key rotation, remove retired identity bindings and revoke replaced credentials. On suspension, also stop execution and restrict resource access: short-lived SVIDs or cloud tokens do not guarantee immediate revocation of existing sessions.
Layer 2: 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
Permit · Deny · Approval required
Continuous behavior and intent assessment
Compare proposed and observed operations with the authorized task, expected tools, resources, destinations, transaction limits and delegation scope. Detect patterns such as repeated denied calls, unusual privilege requests, unexpected data exports, tool sequences or activity outside the task window. Derive signals from verified execution records and trusted services, not solely from the agent’s description of its intent.
Send relevant signals to the runtime policy decision process. Depending on policy, deny the action, require eligible-human approval, narrow the request or initiate containment. Re-evaluate changed parameters and approval context before execution. Anomaly scores and model confidence cannot create authority; define thresholds, ownership and handling of false positives.
Layer 3: Execution layer
The execution layer is the final gate before an agent calls a tool or changes a resource. The tool service/gateway acts as the Policy Enforcement Point (PEP), consulting the authorization engine or Policy Decision Point (PDP). It enforces identity, task scope, policy decisions and any required human approval on AWS or Azure—even after prompts have passed semantic checks.
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? | Validate the exact operation, target and canonicalized arguments; enforce value/rate limits and any required human approval. |
| Workload identity | Who is actually calling the tool? | Validate an SVID at supported boundaries or the documented native cloud token; check issuer/trust domain, audience, expiry and authorized principal. A gateway identity does not attest its caller. |
| Human approval | Was this exact high-risk operation approved? | Validate a tamper-protected approval bound to workload principal, trusted task/run, eligible human issuer/subject, operation, target, argument digest, policy version and expiry. |
| Replay and change | Has the operation changed or already run? | Atomically consume a single-use approval nonce. Changed parameters require a new decision/approval. Use idempotency and reconciliation so retries do not duplicate side effects. |
| Lifetime and cancellation | Is the task still authorized now? | Check task status, current policy, approval expiry and emergency deny immediately before execution. Credential validity alone does not permit the task. |
| Enforcement boundary | Can the agent skip the gateway? | Keep consequential permissions on the gated executor; restrict agent roles, network paths and alternate endpoints. Validate all independently reachable tool paths. |
AWS STS — temporary credentials with task restrictions
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.
Use STS for validated role-assumption profiles. Task authorization may expire before the cloud session; enforce task deadlines independently at the PEP.
Model Context Protocol (MCP)
Use the pinned HTTP authorization profile described in Protocol and deployment requirements: flow-specific OAuth, protected resource metadata, audience binding and no token passthrough. Local STDIO requires separate process and credential controls.
CIBA-backed execution: pause, approve, enforce
- Pause: a semantic policy decision of “approval required” creates a durable pending operation. Do not execute while awaiting human intervention.
- Authenticate and obtain consent: the approval service uses the selected provider’s supported CIBA integration, or a secure alternative human workflow. For Entra, follow the dated CIBA support assessment and choose a supported alternative or separately integrated CIBA provider.
- Bind: record authorization for the exact requested operation. A successful human login or CIBA token alone is insufficient.
- Revalidate: verify approver eligibility, current policy, workload/run identity, parameter digest, task status and expiry immediately before the tool acts. Denial, timeout or missing evidence blocks execution.
- Execute once: consume the approval atomically and execute with the tool’s least-privilege identity. Audit completion/failure; recovery requires safe retries, reconciliation and any renewed approval.
CIBA calls belong in a protected approval service, not in this browser SPA. Pending approval must not require an agent process to wait indefinitely; resume through an authenticated task handle and recheck all controls.
SPIFFE/SPIRE at execution boundaries
- Verify SVIDs and authorize the SPIFFE ID for the specific tool operation; mTLS establishes peer identity, not permission for every action.
- Protect the Workload API socket, isolate workloads and registrations, support credential rotation and trusted bundle updates, and reject untrusted domains/audiences.
- Keep service identity separate from instance/run attribution. Bind approval to independently verified run context, especially when replicas share a SPIFFE ID.
- Across gateways, propagate integrity-protected identity/context with explicit trust mapping. Never accept agent-supplied identity headers as proof or claim the gateway’s SVID attests a managed agent.
AWS and Azure enforcement
- AWS: constrain agent invocation roles, runtime roles and tool/service roles separately. IAM/STS resource permissions complement exact-action approval; an Okta or Entra human token does not replace AWS credentials.
- Azure: use documented Entra workload tokens and least-privilege Azure RBAC for Azure resources, even when Okta or another vendor provides human identity. OAuth consent does not grant unrestricted tool access.
- Managed agents: route consequential Foundry, Bedrock or AgentCore tool actions through an enforceable gateway/tool PEP using supported authentication. Disable high-risk actions if trusted identity/run correlation or approval enforcement cannot be established.
- Cloud sessions: test emergency IAM deny/revocation or Azure containment paths. Enforce shorter application task deadlines independently; do not rely on token expiry or stopping a process to undo completed actions.
Execution evidence and acceptance checks
Correlate the workload principal, trusted run/task identifier, policy decision, human approver, approval identifier and actual tool result. Join application evidence with CloudTrail or Azure resource logs where available; do not log tokens, private keys or sensitive payloads.
Before enabling high-risk tools, test wrong identity/audience, expired approval, wrong approver, changed arguments, replay, concurrent consumption, provider timeout, task cancellation, direct bypass and failures after partial execution. Set transaction limits, circuit breakers, kill switches and compensating actions appropriate to the tool.
Policy-as-Code authorization engines — the PDP
Policy-as-Code expresses authorization rules in a form software can evaluate. The authorization engine normally acts as the Policy Decision Point (PDP). It decides whether a specific operation is permitted. The Policy Enforcement Point (PEP), usually the tool service or tool gateway, enforces that decision before execution. These roles can share an application, but they remain distinct responsibilities.
| Term | Implementation in this guide | Responsibility |
|---|---|---|
| PDP — Policy Decision Point | Authorization engine / policy service | Evaluate verified identity, action, resource, task context and approval evidence against current policy. |
| PEP — Policy Enforcement Point | Tool service / tool gateway / executor authorization boundary | Request and enforce the decision before side effects; reject missing or invalid evidence and prevent bypass. |
| PIP — Policy Information Point | Trusted context sources | Supply verified attributes such as workload/run identity, resource ownership, risk classification and approver eligibility. Agent-supplied assertions alone are not trusted evidence. |
| PAP — Policy Administration Point | Governed policy management and deployment process | Author, review, version, test and distribute rules. CI/CD can support this role; runtime evaluation does not take place only in the pipeline. |
| Approval service | Human approval orchestrator | Initiate CIBA or an alternative workflow, validate the human result and create/store exact-operation approval evidence. It is not automatically the PDP or PEP. |
Runtime example: an agent requests a firewall change from the tool service (PEP). The PEP asks the authorization engine (PDP), using verified context from trusted sources (PIP). If application policy requires human approval, the approval service obtains it; the PEP requests a fresh decision and executes only the approved change. Some engines return permit/deny only; the application implements the “approval required” workflow around those decisions.
Deployment: on AWS, host a compatible policy service on EKS/ECS/EC2 or embed it in the tool application; on Azure, use AKS/VMs or supported application hosting. Place the PEP in the actual tool execution path. An API gateway may perform some enforcement, but model-endpoint access control alone does not govern downstream tool actions. Validate the chosen engine’s runtime support.
CI/CD versus runtime: the pipeline tests and deploys policy; the PDP evaluates requests and the PEP enforces decisions while the agent runs. Failed or unavailable required authorization checks must block consequential execution. Cache decisions only within explicit limits tied to identity, action, parameters, policy version and expiry.
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 — open-source policy language/engine; Amazon Verified Permissions is an AWS managed service using Cedar.
- Polar — Oso’s logic-based policy language; the original library is deprecated, while Oso Cloud is a separate service.
These tools evaluate authorization requests in real-time against declarative policies that encode ABAC, ReBAC, and TBAC rules.
Segmentation and incident containment
Separate production from test, tenants from one another, and agent runtime permissions from tool-executor permissions. Apply resource, network/egress and tool allowlists with argument validation. Ensure sensitive resources cannot be reached through alternate credentials, tools or network paths that bypass the PEP.
On an incident signal, the execution service can suspend new tool calls, cancel queued operations and invalidate unconsumed approvals. Apply tested AWS IAM/session restrictions or Azure access/network containment as appropriate, and isolate affected workloads. Confirm containment at the resource side; stopping a process or waiting for token expiry is insufficient. Use rollback or compensating actions for completed side effects.
Layer 4: 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
Data governance across retrieval, execution and output
Define data owners, authoritative sources, provenance metadata, classifications and permitted purposes. Validate source integrity and access rights before retrieval; treat retrieved instructions as untrusted content. Carry trusted sensitivity and tenant context into policy decisions, minimizing data sent to models, tools and other organizations.
The execution PEP enforces resource and destination permissions; semantic checks inspect content and outputs for leakage and unsafe instructions. Apply appropriate redaction, DLP, output review, retention and deletion controls. Provenance supports traceability but does not prove content is truthful or safe. Record necessary evidence without logging credentials or unnecessary sensitive payloads.
Incident response and safe recovery
- Detect and triage: correlate identity, run/task, policy, tool, cloud and human-approval events; identify the affected agent, resources and accountable responders.
- Contain: block consequential execution at the PEP, invalidate pending approvals, restrict resource access and isolate affected runtimes. Verify the actual stop and containment effect.
- Investigate and remediate: preserve controlled-access evidence, inspect compromised identities, policy, source content and tool behavior; rotate or retire affected credentials and trust bindings where necessary.
- Recover: restore known-good policy/runtime state, roll back or compensate for side effects, revalidate permissions and require fresh approval for resumed gated operations.
- Review: document impact and lessons, improve detection and runbooks, and meet applicable notification and retention obligations.
Assign incident commander, technical responders, data owners and recovery approvers. Define escalation thresholds, response targets and separation of duties; exercise denial, replay, credential compromise, approval-service outage and resource-bypass scenarios. Human approval is an authorization control, not a substitute for incident response.
SPIFFE/SPIRE workload identity foundation
Attested workload identity: purpose, trust boundaries and integration with enterprise identity and cloud authorization.
What SPIFFE and SPIRE provide
SPIFFE defines workload identities and verifiable identity documents (SVIDs). SPIRE implements node/workload attestation and short-lived SVID issuance through the Workload API. Use X.509-SVIDs for mTLS and audience-bound JWT-SVIDs where the recipient supports them. Deploy on supported AWS EKS/EC2 or Azure AKS/VM environments; use native identities at managed service boundaries. Enterprise human IdPs, cloud authorization and exact-action approval remain separate controls.
Resolving the bottom turtle
Use independently verified platform/node evidence and local workload selectors to obtain identity through the Workload API, without an application-held bootstrap password. Protect the signing authority, administrative registry, authentic bootstrap bundle, node OS and orchestrator. SVID private keys and bearer tokens remain secrets. Hardware protection is optional and configured explicitly; production join tokens are not the preferred bootstrap.
Authentication and action authorization
Use X.509-SVIDs for SPIFFE-aware mTLS; verify certificate chain, expiry, exactly one SPIFFE URI SAN and expected peer. For JWT-SVIDs, verify signature, permitted algorithm, trusted issuer/keys, SPIFFE subject, narrow audience and expiry. Bind the authenticated principal to trusted instance, run, tenant, task, parent/delegating user and approval context. Model intent and confidence cannot grant authority.
At the tool boundary, intersect workload permissions, task grant, applicable user authority, resource policy and conditions. Use Permit, Deny and Approval required consistently. If policy requires narrower parameters, return obligations and evaluate the revised operation again before permitting it. Bind approval to exact operation/resource/argument digest, principal, task, expiry and a single-use nonce. Child delegation may only narrow scope. Block alternate tool/cloud credential paths.
AWS deployment and cloud federation
For supported EKS/EC2 execution, deploy SPIRE Server with protected keys and durable storage, node Agents, narrow registration selectors and restricted local sockets; use SDK/SDS credential refresh. Validate platform attestation and plugin support for the pinned release. Do not assume managed/serverless runtimes can host a SPIRE node Agent.
Choose federation according to the target resource. For AWS-hosted workloads accessing Entra-protected APIs, a documented federation pattern to validate is SPIRE JWT-SVID → Entra workload federation → Entra-issued resource token. For AWS resources, use native IAM roles or configured SPIRE OIDC → AWS STS federation. An Entra federated identity credential does not establish AWS STS compatibility. Azure-hosted applications similarly use supported native identity or verified workload federation for Azure APIs. Enterprise human IdP selection is independent of these workload paths. Microsoft workload federation · SPIFFE federation guidance. Product documentation does not establish that this deployment has passed integration testing.
Lifecycle, containment and acceptance
Choose measured SVID lifetimes; test live rotation, bundle/key rollover, HA, clock skew and recovery. Removing registration prevents future issuance but does not instantly revoke issued SVIDs or cloud sessions. Deny affected identities/tasks at PEPs, terminate connections and isolate compromised nodes. Fail closed for expired identity or unavailable required policy/approval services.
- Reject wrong node, selectors, peer, trust domain, audience and expired or forged SVIDs.
- Reject valid identities with unauthorized actions, widened delegation or replayed/changed approval.
- Test cloud exchange negative cases, workload isolation, renewal/outage behavior and end-to-end containment delay.
- Revoke replaced passwords/API keys and prove no bypass path remains; record legacy broker exceptions.
SPIRE architecture · X.509-SVID · JWT-SVID · AWS OIDC tutorial
Enterprise IdP options and SPIFFE integration
AWS or Azure can host the agent; Entra ID, Okta, Auth0, Curity or PingFederate can provide enterprise human identity. SPIRE remains the attestation and SVID signing authority on supported customer-controlled runtimes. Select each federation relationship for its actual recipient.
| Provider | Role / supported integration basis | Deployment acceptance requirement |
|---|---|---|
| Microsoft Entra ID | External SPIFFE workload federation into an application or supported user-assigned managed identity, with issuer/subject/audience binding. | Validate SPIRE discovery/JWKS and exact claims; separately validate any Entra-to-AWS STS token profile. Microsoft documentation. |
| Okta | OAuth/OIDC enterprise authentication and machine-to-machine API token services. Okta client credentials documentation. | Confirm the exact Okta product, authorization server, licensing and supported client authentication. Do not assume native JWT-SVID acceptance. A static client secret or stored signing key does not solve the bottom turtle; any SPIFFE-aware broker must have a documented, tested trust mapping and residual credential inventory. |
| Curity Identity Server | Vendor documents client authentication with SPIFFE JWT-SVIDs and X.509-SVIDs. JWT-SVID integration · X.509-SVID integration. Official product reference (checked October 5, 2026). | Configure trusted issuer/keys, expected SPIFFE subject and audience, or the trusted CA and URI SAN. Verify token scopes, lifecycle and proof-of-possession where configured. |
| PingFederate | Enterprise federation and OAuth authorization-server roles. Ping federation roles. | Validate product/version-specific workload assertion or certificate authentication support; native SPIFFE support is not asserted here. Broker/plugin trust and AWS token compatibility require separate tests. |
| Auth0 | Enterprise application authentication and OAuth token services; a separate Okta product. Auth0 workload flow documentation. | Validate the supported client-authentication method, issuer/audience and broker mapping. Native SVID acceptance is not established by CIBA support. Record any residual credential exception. |
Common controls: pin the chosen issuer, expected subject/audience and permitted algorithms; verify discovery/JWKS rollover, tenant boundaries, workload enrollment and API authorization. Human SSO federation, workload federation, SPIFFE bundle federation and AWS role assumption are separate trust relationships. Do not apply Entra-specific Conditional Access claims to Okta, Curity or Ping.
CIBA and human step-up authorization
Client-Initiated Backchannel Authentication (CIBA) enables a backend client to initiate human authentication and consent on a separate authentication device. It is defined by OpenID CIBA Core 1.0, an OpenID Foundation specification, not a standalone IETF RFC. It is an optional protocol choice for the required approval workflow.
Policy for high-risk agent actions
In this CAZT profile, a high-risk action exceeding the agent’s existing authority requires explicit approval by an eligible human before execution. Any pre-authorized exception requires an explicit governance policy. Approval does not confer broad administrative authority. Human step-up authentication, action authorization and workload authentication are separate controls.
| CAZT layer | Responsibility |
|---|---|
| Governance | Define risk thresholds, approver roles, separation of duties, exceptions, retention and assurance requirements. |
| Semantic | Evaluate the actual tool operation, target, parameters and context. Return permit, deny or approval required; reassess if the proposed action changes. |
| Identity | SPIFFE/SPIRE attests the workload. The CIBA provider authenticates the designated human and obtains consent using its supported authenticator. Validate human identity, assurance and approver eligibility. |
| Execution | The PEP suspends the operation and the approval service orchestrates CIBA. Validate a narrowly bound approval, current policy and agent identity before execution; reject denial, timeout, replay or changed parameters. |
Common approval sequence across deployment patterns
- The agent presents a valid SVID on an attested runtime, or its documented native workload credential to the tool gateway/PEP. The gateway verifies the applicable issuer/trust domain, identity and audience; native callers are not represented as SVID holders.
- The semantic policy decision requires approval. The approval service creates a pending operation with a digest of canonicalized action parameters.
- Use the deployment’s enterprise human IdP: Okta, Curity, PingFederate or Auth0 can supply their documented CIBA flow. With Entra enterprise identity, integrate a separately verified CIBA service or a supported non-CIBA approval workflow. Enrollment/federation must work for the chosen authenticator; cloud hosting does not determine the CIBA provider.
- The approval service acts as the registered CIBA client, identifies the eligible approver and initiates the request. The human sees the exact operation in a trusted approval UI and authenticates/consents. The service retrieves and validates the result using the provider’s supported delivery mode.
- The approval service issues or stores a tamper-protected, short-lived, single-use authorization bound to the verified workload principal (SPIFFE ID or native identity), verified run/task identity, human subject/issuer, operation, resource, parameter digest, policy version, expiry and nonce.
- The AWS- or Azure-side tool PEP atomically consumes the approval only for that operation, rechecks policy and records the decision/execution audit correlation. No execution occurs on failure or expiry.
Authenticating the user is not proof that the user approved these exact parameters. A CIBA binding_message helps correlate the interaction; it is not by itself a cryptographic transaction authorization artifact. Prevent approval fatigue, enforce request limits and apply dual approval where governance requires it.
Microsoft CIBA support status — October 5, 2026
As of October 5, 2026, Microsoft Entra ID and Microsoft Entra External ID do not support native CIBA. This guide treats CIBA as unsupported for both services because Microsoft’s published supported OAuth/OIDC flow references do not document it. This is an assessment of published product support, not an explicit Microsoft denial of all private-preview capabilities or a tenant-level protocol test.
Microsoft’s .NET IdentityModel Ciba constant is a library definition, not evidence of an Entra CIBA endpoint. Entra MFA, device authorization and External ID native authentication are different mechanisms. Use a supported Entra sign-in plus application approval workflow, or integrate a documented external CIBA provider.
Microsoft identity platform supported authentication flows · Workforce and External ID OAuth/OIDC feature comparison
Documented product capabilities
Documentation reviewed 5 October 2026 (America/Chicago). Confirm product version, licensing, availability and enrolled authenticators before production.
| Identity product | CIBA support | SPIFFE/SPIRE integration status |
|---|---|---|
| Curity Identity Server | Documented native CIBA; poll result-delivery mode, with configured backchannel authenticators. | Can participate through an application/broker integration. CIBA support alone does not verify direct SVID client authentication. |
| PingFederate (Ping Identity) | Documented CIBA poll and ping flows (delivery-mode metadata reference); CIBA authenticator/request policy, including PingOne MFA integration or custom authenticator. Official product reference (checked October 5, 2026). | Verify the exact client-authentication method and trust mapping. No automatic native SVID acceptance asserted. |
| Okta Identity Engine | Documented transactional CIBA with a Custom Authenticator/Devices SDK and polling. The documented client integration is a Web Application; verify tenant eligibility. Official product reference (checked October 5, 2026). | Documented private_key_jwt support is not equivalent to accepting an unmodified JWT-SVID. Broker/adapter acceptance must be tested. |
| Auth0 (Okta company) | Documented CIBA for confidential, first-party, OIDC-conformant clients. Guardian/custom mobile app notification; email requires the paid Auth0 for AI Agents add-on. Official product reference (checked October 5, 2026). | Application/broker composition is possible; native SPIFFE-to-CIBA client authentication has not been verified here. |
| Microsoft Entra ID / Microsoft Entra External ID | See the dated Microsoft CIBA support assessment. Use supported human sign-in plus application approval, or a separately integrated CIBA provider. | Entra can provide enterprise human identity and Azure resource tokens; SPIRE identifies supported AWS or Azure workloads. Validate any federation independently. |
Mobile push notifications are not the CIBA “push” token-delivery mode. Poll/ping/push describe how the client receives the result, not human approval frequency or authentication strength.
Does SPIFFE/SPIRE support CIBA?
SPIFFE/SPIRE does not implement human CIBA authentication or issue CIBA user tokens. The protocols are architecturally complementary: use SVID-authenticated connections between the agent, gateway and approval service; use CIBA between the approval service and the human identity provider. This is a proposed composition, not a vendor-certified interoperability claim.
Direct X.509-SVID OAuth mTLS client authentication requires explicit authorization-server certificate trust, client registration, identity mapping and rotation support. A JWT-SVID is not automatically a private_key_jwt client assertion: its subject, audience and claims have different semantics. SPIRE OIDC discovery exposes verification metadata; it does not transform an SVID into a user login or CIBA assertion.
For the secretless objective, require tested asymmetric client authentication or a supported identity broker for the CIBA client, with protected keys and rotation. Do not silently introduce a static client secret because a vendor tutorial uses one. If unsupported, record the residual credential exception and migration plan. SPIRE still needs protected trust roots and signing keys; secretless agents do not mean an architecture without cryptographic keys.
Protocol and deployment requirements
Human approval and identity-policy scope
CIBA poll/ping/push specify client notification/token delivery. They do not define biometrics, autonomy or approval volume. FAPI CIBA excludes push. CIBA authentication does not itself bind approval to a transaction. Entra, Okta, Curity and Ping require their own supported authentication and approval integration; see the dated Microsoft CIBA assessment.
MCP authorization — pinned baseline 2025-11-25
Authorization is optional in the protocol. Where enabled for HTTP transports, use protected resource metadata (RFC 9728), resource indicators (RFC 8707), token audience validation and no token passthrough. Apply authorization-code PKCE to user-delegated code flows; use supported workload authentication for app-only access. Existing pre-registration comes first, supported Client ID Metadata Documents next, then supported DCR fallback. STDIO uses a separately secured local credential/process boundary.
Federation acceptance gates
Expose the SPIRE OIDC Discovery Provider via authentic HTTPS with discovery/JWKS reachable by Entra, not SPIRE administrative APIs. Validate key rollover and availability. Match Entra FIC issuer, subject and audience exactly, including case; typically request the api://AzureADTokenExchange audience. Check current per-application FIC limits before adopting per-instance subjects. AWS OIDC role trust must pin issuer/provider and expected aud/sub. ExternalId applies to appropriate third-party AssumeRole profiles, not AssumeRoleWithWebIdentity.
Task duration and policy engines
Enforce task deadlines at the PEP even while cloud credentials remain valid. AssumeRoleWithWebIdentity has a 900-second minimum; its credentials are not automatically bound to a single tool call. Cedar is a language/engine; Verified Permissions is the AWS managed service. Polar is a policy language; the original Oso library is deprecated, while Oso Cloud is a separate service.
CIBA Core · MCP authorization · Entra agent policy · EU amendment
TBAC attribution: Roshan K. Thomas and Ravi S. Sandhu (1997), Task-Based Authorization Controls: A Family of Models for Active and Enterprise-Oriented Authorization Management.
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.
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 (Data Integrity BBS Cryptosuites) — selective disclosure of attributes without revealing the underlying claim set.
Deployment profile comparison
Compare workload hosting, enterprise human identity, step-up workflows and resource authorization. Each profile requires deployment-specific validation; these are not cost or compliance scores.
| Deployment | Workload foundation | Human step-up | Resource authorization / boundary |
|---|---|---|---|
| AWS-1 · Entra human IdP | EKS/EC2 SPIRE or supported native AWS identity | Entra sign-in plus application approval, or separate CIBA provider | AWS IAM/STS; tool PEP prevents direct bypass |
| AWS-2 · Okta / Auth0 / Curity / Ping | EKS/EC2 SPIRE or supported native AWS identity | Selected product’s documented CIBA integration or verified alternative | AWS IAM/STS; validate vendor-specific client authentication |
| AZ-1 · customer-managed AKS/VM | SPIRE on supported nodes or native workload identity | Entra alternative workflow or external-provider CIBA | Entra resource tokens + Azure RBAC; enforce tool PEP |
| AZ-2 · managed application | Documented native managed identity; gateway SVID identifies gateway only | Same human IdP choices as AZ-1 | Trusted caller/run context and gated tool service |
| AZ-3 · managed Foundry agent | Documented service agent/project identity; no assumed SPIRE installation | Same human IdP choices; durable approval service where needed | Supported tool authentication and PEP; disable tools without enforceable integration |
Deployment patterns
Select runtime and enterprise human IdP independently. Compare AWS-1, AWS-2 and Azure profiles AZ-1 through AZ-3 below; each Azure runtime can use Entra or an external enterprise human IdP.
AWS-1: AWS workloads with Entra enterprise identity
Microsoft Entra ID provides enterprise human identity; AWS hosts the agent and tools. SPIRE attests supported EKS/EC2 workloads and issues SVIDs. AWS IAM/STS authorizes AWS resources using separately configured native runtime roles or SPIRE OIDC federation. Entra user tokens do not directly replace workload credentials.
For high-risk step-up, the semantic layer requires approval. Use a supported Entra human sign-in plus application approval workflow, or integrate a separately verified CIBA provider; see the dated Microsoft CIBA assessment. The execution PEP validates exact-operation approval and prevents direct resource bypass. Governance defines approvers, assurance and audit retention. Managed AWS runtimes require their own documented identity path.
AWS-2: AWS workloads with an external enterprise IdP
AWS-2: AWS hosts the agent, orchestration and tool services; Okta is the worked example for enterprise human identity and CIBA. Auth0, Curity or PingFederate can fill that role with their own documented integration. Microsoft Entra ID is not required in this pattern. SPIRE issues workload SVIDs; AWS IAM/STS governs AWS resource access.
Deployment and trust boundaries
| Component | Identity and responsibility |
|---|---|
| Enterprise users and approvers | Okta Identity Engine provides application sign-in and the documented CIBA transactional verification flow. Configure a registered Web Application client, authorization policy, Custom Authenticator and enrolled eligible approvers. |
| Customer-managed agent runtime | Run the agent on EKS or EC2 with validated SPIRE node/workload attestation and narrow registrations. Use X.509-SVID mTLS for controlled gateway/tool connections or audience-bound JWT-SVIDs where explicitly supported. The agent can call an AWS-hosted model service using appropriate AWS permissions. |
| AWS resource credentials | Choose either supported native IAM runtime identity or a configured SPIRE OIDC Discovery Provider plus AWS IAM OIDC role trust and STS AssumeRoleWithWebIdentity. Pin provider, subject and audience; issue least-privilege temporary credentials. Okta human federation is a separate trust configuration. |
| Policy and approval service | Run the PDP, approval orchestration and PEP on customer-controlled AWS services. Authenticate their workloads, validate Okta human results and issue/store exact-operation approvals. Verify supported asymmetric CIBA client authentication; record any credential exception. |
| Managed AWS runtimes | For Lambda, managed ECS/Fargate or managed agent services, use the documented native identity path and validate runtime support. Do not assume host access for a SPIRE node daemon. A separately attested gateway identifies itself and retains the managed caller identity/run correlation. |
High-risk action sequence
- The AWS agent authenticates to the tool PEP with its verified workload identity. The PEP resolves trusted task/run context.
- The authorization engine (PDP) evaluates the proposed operation and semantic risk context against governance rules to determine whether eligible human approval is required.
- The approval service initiates CIBA with Okta. The approver reviews the exact action on the trusted approval interface and authenticates/consents using the enrolled Custom Authenticator. The service polls and validates the CIBA result.
- The service binds authorization to workload identity, human issuer/subject, task, operation, target, parameter digest, policy version, expiry and single-use nonce.
- The execution PEP rechecks policy and consumes that authorization only for the approved operation. The tool executor uses its own narrow AWS role; the agent lacks permissions to bypass the tool gate.
A CIBA user token is neither an AWS access key nor an automatic permission to assume a workload role. A SPIRE JWT-SVID is not an Okta user token. Keep Okta user identity, SPIFFE workload attestation, AWS role credentials and application approval artifacts distinct.
Four-layer mapping
Governance defines risk and eligible approvers. Semantic returns approval required for the concrete action. Identity combines separately verified SPIFFE/native workload identity and Okta human authentication. Execution pauses, validates and enforces the exact approval before side effects.
Use CloudTrail for AWS API activity and correlate it with application decision/execution records and Okta authentication events. Record trusted identifiers and approval status without logging credentials or tokens. Test denied/expired approval, wrong approver, changed arguments, replay, issuer/audience mismatch, key rotation and direct-resource bypass.
Curity, PingFederate or Auth0 can occupy the external enterprise human IdP/CIBA role using their own documented configuration; this is not a claim of interchangeable vendor capabilities or certified end-to-end interoperability.
Primary implementation references
Azure workloads with Entra or an external enterprise IdP
Entra ID, Okta Identity Engine, Auth0, Curity or PingFederate provides enterprise human identity/approval services; Azure hosts the AI application or agent. Microsoft Entra remains the issuer for Azure-managed workload identities and Azure resource authorization. External enterprise IdP and Azure workload identity are separate roles.
Azure + Entra enterprise identity
Use the same AZ-1, AZ-2 or AZ-3 runtime boundaries below. Entra provides enterprise human sign-in and separately issues workload tokens for Azure resources; Azure RBAC controls resource permissions. On supported AKS/VM runtimes, SPIRE can attest customer-managed workloads. Managed applications and Foundry agents use their documented native identity path. Human approval uses supported Entra sign-in plus an application approval service, or a separately integrated CIBA provider; see the dated CIBA assessment. Enforce exact-action approval at the tool PEP and prevent direct bypass.
Deployment choices
| Profile | Agent execution and model | Workload identity | Human step-up |
|---|---|---|---|
| AZ-1: customer-managed agent | Agent/orchestrator on AKS or Azure VMs; Azure OpenAI/Foundry model endpoint supplies inference. | Deploy SPIRE on supported nodes; verify Kubernetes or Azure VM attestation and workload selectors. Use SVIDs on controlled service/tool connections. Access Azure APIs using supported Entra workload federation or a native managed identity with least-privilege RBAC. | Use the selected provider’s verified CIBA integration, or supported Entra sign-in plus application approval. The tool gateway blocks high-risk operations until exact-action approval is valid. |
| AZ-2: Azure application with managed hosting | Agent application on App Service, Functions or another managed Azure runtime calls Azure OpenAI. The model endpoint is not the application's agent runtime. | Use supported managed identity for keyless Azure access. Do not assume a SPIRE node daemon/Workload API can be installed in this runtime. A separately hosted SPIFFE-enabled gateway authenticates with its own SVID, not an invented SVID for the calling app. | The selected IdP authenticates the human: use verified external-provider CIBA or supported Entra sign-in plus application approval. Preserve verified caller/run context across the gateway and enforce approval before tools execute. |
| AZ-3: managed Foundry Agent Service | Foundry hosts/orchestrates the agent and invokes configured tools. Validate the exact agent type, region, API version and feature status. | Use the service's documented Entra agent identity or project managed identity path, as applicable to the selected feature. No native SPIRE installation or SVID issuance inside the managed service is assumed. | Route consequential tools through an independently enforced PEP/approval service. The selected external CIBA provider or supported Entra alternative authenticates the approver. SPIFFE can identify customer-operated gateway/tool services after the boundary, without relabelling the managed agent as SPIFFE-attested. |
Okta enterprise identity and Azure workload identity
Configure enterprise sign-in to the application using validated Okta OIDC/SAML integration. The application validates issuer, audience, subject and entitlement mappings. Do not forward an Okta token to an Azure OpenAI endpoint expecting an Entra token, or assume a user federation configuration establishes workload federation. Azure RBAC grants resource permissions to the actual Entra workload principal.
For CIBA, register a dedicated confidential approval-service client with Okta, configure the documented authorization policy and Custom Authenticator, enroll eligible approvers and verify the supported asymmetric client-authentication method. An Okta user push notification can coexist with CIBA poll result delivery. Auth0 is a separate product/integration; Curity and PingFederate require their own authenticator and policy configuration.
CAZT placement and bypass prevention
- Governance: approve vendor trust, identity mappings, eligible approvers, data residency and any preview or credential exceptions.
- Semantic: evaluate each proposed tool operation; require human approval when a high-risk action exceeds existing authority.
- Identity: validate the external human identity separately from the Azure native workload identity or attested SPIFFE identity. Correlate run/task identity without trusting agent-supplied claims.
- Execution: enforce an exact-operation, expiring, single-use approval at the tool service. Restrict direct resource access so the agent cannot bypass the gate. A model-inference gateway alone does not govern downstream tool side effects.
For managed Foundry tool calls, use the supported tool authentication path to reach the PEP. If that path cannot carry a trusted run identity or enforce approval, disable the high-risk tool until an enforceable integration is implemented. Do not assume a paused agent run can wait indefinitely; use a durable pending operation and revalidate policy before resuming.
Acceptance checks and primary references
Test valid/invalid issuer and audience, expired workload credentials, unavailable approval provider, wrong approver, changed parameters, approval replay and direct tool bypass. Verify SVID/key rotation and Entra resource permissions independently. The profiles are architectural patterns, not claims of certified Okta–SPIRE–Foundry interoperability.
Cross-organization overlay for AWS or Azure
Apply this overlay to any hosting pattern when agents act across enterprise boundaries. Establish explicit partner trust, issuer/audience/subject and tenant mappings, resource-side least privilege and eligible approver authority. SPIFFE bundle federation authenticates workloads; it does not grant partner resource permissions or authorize human approvers. Evaluate both organizations’ applicable policies at the tool PEP. Keep approvals bound to the exact operation and correlate partner decision, approval and execution records. Unknown partner trust blocks production readiness.
Decision tree
Complete all 16 questions to select a control profile. Readiness failures block deployment; a provisional target profile explains the controls needed after remediation. Profile selection is not deployment approval.
Identity and human approval decisions
Choose AWS, Azure or external hosting separately from enterprise human IdP and workload bootstrap. Supported customer-controlled runtimes can use SPIFFE/SPIRE; managed runtimes use documented native identities. Select verified CIBA, a verified alternative, no approval workflow or unknown readiness. CIBA support does not establish native SVID client authentication.
Every high-risk deployment requires effective stop controls, rollback or appropriate compensating actions, a runtime PDP/tool PEP and auditable exact-action approval when existing authority is exceeded. Human supervision alone does not replace stop controls. Legacy credentials require a reviewed, time-limited exception with an owner, restricted permissions, broker protection and migration plan; choosing that option is not evidence of exception approval. Approval cadence affects workflow timing, not risk classification.
These definitions are generated from the same questions and rules as the interactive assessment. Every answer remains selectable; readiness failures appear as findings.
Decision questions
Outcome rules and baseline controls
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.
Regulatory review — 2026-10-05
Regulation (EU) 2024/1689 as amended by 2026/1744 sets the specified Chapter III high-risk provisions to 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems. The Article 50(2) transition to 2 December 2026 is limited to covered systems placed on the market before 2 August 2026; it is not a blanket transparency delay. Official amendment · Commission application timeline.
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.
- Specified Chapter III high-risk provisions apply from 2 December 2027 (Article 6(2)/Annex III) and 2 August 2028 (Article 6(1)/Annex I), under the 2026 amendment. Article 50 transparency obligations apply from 2 August 2026; the Article 50(2) marking transition to 2 December 2026 is limited to covered pre-existing systems. See the dated regulatory review.
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.
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.
Claims register
Time-sensitive statements in this guide, with their sources and review dates. Status is computed against the date on your device: statements past their review date are flagged for re-verification before you rely on them.
| Claim | Area | Source | Checked | Re-review by | Status |
|---|