{ "dataset": { "meta": { "domain": "identity", "domain_slug": "identity", "domain_number": 5, "title": "Apeiris Identity Control Matrix", "description": "52 machine-readable identity controls across 6 layers governing AI agent identity: registry, credential lifecycle, delegation chains, federation trust, anomaly detection, and IdentityAttestation.", "version": "1.2.0", "published": "2026-07-02", "layers": 6, "controls_count": 52, "baseline_controls": [ "II-01", "NI-01", "NI-02", "NI-05", "DE-01", "DE-04", "IM-01", "IM-02", "IC-08" ], "canonical_prefix": "apeiris://identity/controls/", "attestation_artifact": "IdentityAttestation", "attestation_control": "IC-08", "alias_domain": "identitycontrols.ai", "frameworks": [ "anthropic_rsp", "aws_iam", "cisa_zt", "eidas2", "eu_ai_act", "fapi_2_0", "google_saif", "iso_24760", "iso_42001", "nist_800_63", "nist_rmf", "nist_zt", "oauth_bcp", "oidc_federation", "okta_iam", "openai_sf", "openid", "owasp_nhi10", "ping_identity", "scim", "spiffe_spire", "w3c_did" ], "lenses": [ "iam_engineer", "security_architect", "legal_counsel", "grc_auditor", "it_operations" ], "license": "CC BY 4.0", "source": "https://apeiris.ai/domains/identity/", "integration_endpoint": "https://apeiris.ai/integration/domains/identity-controls-full.json", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "baseline_control_count": 9, "generated_at": "2026-06-28T00:00:00.000Z", "subtitle": "apeiris.ai/domains/identity \u2014 Apeiris Identity", "site": "https://apeiris.ai/domains/identity", "corpus_url": "https://apeiris.ai/integration/domains/identity-controls-full.json", "schema_version": "1.1.0", "schema_extended_on": "2026-06-29", "extended_schema_fields": [ "validation_objective", "evidence_required", "machine_tests", "human_review", "blocking_effect", "normative_status", "anti_patterns", "update_status" ] }, "controls": [ { "id": "II-01", "layer": "II", "plane": "control", "name": "AI Agent Identity Registry", "plain": "Every AI agent deployed in the enterprise must have an authoritative registry entry recording its capability manifest, owner, authorization scope, principal type, and lifecycle status.", "threat": { "tags": [ "identity-spoofing", "orphaned-credential" ], "desc": "Without a centralized, authoritative registry, AI agents can be deployed without institutional knowledge, accumulating permissions that are never revoked. Orphaned agents \u2014 those whose owning team has disbanded or whose purpose has changed \u2014 continue to authenticate and act on resources long after their legitimacy has expired. Attackers who compromise an untracked agent gain persistent access that evades standard identity governance reviews, since there is no canonical record to compare against." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63-4 (by analogy)", "title": "Digital identity lifecycle discipline \u2014 the suite scopes out NPE/machine identities" }, { "id": "scim", "section": "RFC 7644 \u00a73.3", "title": "Resource provisioning endpoint" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Identity Stores", "title": "Identity inventory and enumeration" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_nhi_top10_2025", "title": "OWASP Non-Human Identity Top 10 2025", "authority": "OWASP Foundation", "source_type": "standard", "normative_force": "best-practice", "version": "2025", "published_on": "2025-02-01", "retrieved_on": "2026-06-29", "canonical_url": "https://owasp.org/www-project-non-human-identities-top-10/", "license": "open-access", "status": "current", "flagship": false, "source_id": "owasp_nhi_2025", "relationship": "informative_reference", "rationale": "Establishes OWASP Non-Human Identity Top 10 2025 requirements informing the apeiris://identity/controls/II-01 AI Agent Identity Registry control.", "reviewed_on": "2026-07-01" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds the AI agent identity registry in the Foundation agent-identity-verification tier.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Append-only registry with version-controlled entries; each entry includes capability manifest hash, owner binding, authorization scope, principal_type=non-human, IAL/AAL/FAL assignment, and lifecycle status. SCIM 2.0 endpoints expose the registry for automated provisioning pipelines.", "steps": [ "Deploy an append-only identity registry (database with immutable audit log or purpose-built identity store) with a SCIM 2.0 compatible API; define the AI Agent resource schema extending RFC 7643 with custom attributes for capability_manifest_hash, deployment_artifact_hash, principal_type, and authorization_scope.", "Integrate the registry into the CI/CD pipeline so that agent deployment is blocked unless a provisioning ticket has been approved and a registry entry created; the deployment artifact hash must match the registry record before the agent is permitted to request credentials.", "Assign each registry entry an IAL, AAL, and FAL level at provisioning time based on the agent's authorization scope and consequence level; encode these as structured attributes so downstream policy engines can enforce assurance requirements without re-evaluating the agent's configuration.", "Implement a quarterly reconciliation job that compares active credentials in the identity provider against registry entries; flag any credential without a registry entry as unauthorized, trigger automatic suspension, and create an incident for the accountable owner to resolve within 72 hours." ], "anti_patterns": [ "Using a spreadsheet or wiki as the registry \u2014 these provide no API surface for enforcement and inevitably drift from ground truth.", "Allowing agents to self-register without human approval in the provisioning workflow \u2014 this eliminates the gatekeeping function of the registry.", "Treating the registry as mutable with update-in-place semantics \u2014 loss of historical state makes it impossible to reconstruct an agent's authorization scope at any past point in time." ] }, "validation": { "design_check": [ "Verify that the registry schema captures all required attributes: agent_id, canonical_name, principal_type, owner_id, authorization_scope, capability_manifest_hash, deployment_artifact_hash, ial, aal, fal, lifecycle_status, created_at, last_attested_at.", "Confirm that the registry backend enforces append-only semantics \u2014 updates create new versions rather than overwriting existing records, and deletion is a logical status change not a physical removal.", "Validate that the CI/CD pipeline has a registry pre-check gate that fails the deployment if no approved registry entry matching the artifact hash exists." ], "runtime_test": [ "Attempt to deploy an agent without a registry entry and confirm the deployment is blocked at the pipeline gate.", "Submit a SCIM GET /Users request filtered by principal_type=non-human and verify all deployed agents are returned with current lifecycle_status.", "Manually suspend one registry entry and confirm the corresponding agent loses the ability to obtain new tokens within one credential TTL cycle." ], "evidence": [ "registry-export:Full SCIM export of all non-human identity records showing current lifecycle status [unverified]", "pipeline-gate-log:CI/CD audit log showing registry pre-check enforcement events over the prior 90 days [unverified]", "reconciliation-report:Quarterly reconciliation results comparing active credentials to registry entries, including any gap findings [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The registry is the authoritative source of truth for every AI agent credential. Without it, access reviews are impossible and orphaned credentials accumulate silently. Your job is to ensure every provisioning and deprovisioning event flows through registry APIs rather than being handled ad hoc.", "actions": [ "Build or configure the registry with a SCIM 2.0 interface and extend the schema with AI-agent-specific attributes.", "Wire the registry pre-check into every deployment pipeline that can produce a running AI agent.", "Schedule automated reconciliation between the registry and the identity provider's active credential list." ], "failure_signals": [ "Credentials found in the IDP with no matching registry entry.", "Agents reported by runtime telemetry that do not appear in the registry export." ] }, "security_architect": { "summary": "The registry is a foundational control for non-human identity governance. Its integrity directly determines whether downstream controls \u2014 access reviews, anomaly detection, and revocation \u2014 are operating on accurate data. A compromised or incomplete registry invalidates the entire NHI governance posture.", "actions": [ "Specify tamper-evidence requirements for the registry backend and include them in the security design review checklist.", "Ensure the registry feeds SIEM correlation rules so that activity from unregistered agents triggers an alert.", "Include registry completeness as a metric in the annual identity governance review." ], "failure_signals": [ "Security incidents involving agents not present in the registry.", "Registry records that cannot be reconciled to any active deployment." ] }, "legal_counsel": { "summary": "The registry creates the evidentiary chain linking an AI agent's actions to an authorized identity and an accountable human owner. Without it, establishing who authorized an agent to act \u2014 and whether that authorization was within bounds \u2014 requires forensic reconstruction rather than reference to a maintained record.", "actions": [ "Confirm that the registry captures authorization scope in terms that map to the enterprise's data governance and acceptable use policies.", "Verify that registry records are retained for a period consistent with the enterprise's litigation hold and regulatory retention obligations.", "Ensure the accountable owner field links to a role or person with defined legal authority to authorize the agent's actions." ], "failure_signals": [ "Inability to produce a registry record for an agent involved in a disputed transaction.", "Registry records that lack a named accountable owner with documented authorization authority." ] }, "grc_auditor": { "summary": "The registry is the primary artifact for demonstrating that AI agent identities are inventoried, governed, and subject to periodic review. Completeness and accuracy of the registry are prerequisites for all downstream identity assurance controls. An incomplete registry means the assurance level ratings for other II-layer controls are unreliable.", "actions": [ "Request a full SCIM export of non-human identity records and cross-reference against deployment records from the CI/CD system.", "Sample 10% of registry entries and verify that the deployment_artifact_hash matches the hash of the artifact currently running in production.", "Review reconciliation reports from the prior four quarters and assess whether gaps were resolved within the defined SLA." ], "metrics": [ "Registry completeness rate: percentage of deployed agents with an active registry entry (target: 100%).", "Orphan resolution SLA: mean time from detection of an unregistered credential to suspension (target: <72 hours)." ], "failure_signals": [ "Registry completeness rate below 95% as measured by reconciliation.", "Reconciliation gaps not resolved within the defined SLA in two or more consecutive quarters." ] }, "it_operations": { "summary": "The registry is your inventory system for AI agents \u2014 the equivalent of a CMDB entry for a service account. It tells you who owns an agent, what it is authorized to do, and whether it is still supposed to be running. Keeping it current is a shared responsibility with the teams that deploy agents.", "actions": [ "Integrate registry lookups into the operations runbook for incident response so on-call engineers can quickly identify agent ownership during incidents.", "Set up alerting for agents approaching credential expiry that have not been re-attested.", "Include registry entry creation in the standard onboarding checklist for new AI agent deployments." ], "failure_signals": [ "Incidents where the responding engineer cannot identify the owner of an AI agent from the registry.", "Credentials silently expiring and causing production failures because no re-attestation reminder was triggered." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have no dedicated NHI registry; service account spreadsheets are the de facto inventory. Target state requires a machine-readable registry with SCIM API, pipeline integration, and quarterly reconciliation." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Platform Engineering", "DevOps" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 (applied by analogy)", "fit": "partial", "rationale": "SP 800-63-4 requires that digital identities be established, managed, and terminated through a governed lifecycle. The suite explicitly scopes machine-to-machine (non-person entity) authentication out of its requirements, so II-01 applies its lifecycle discipline to AI agent identities by analogy; the registry-and-enumeration requirement itself is drawn from NHI-specific guidance such as the OWASP NHI Top 10.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC 7644 \u00a73.3", "fit": "direct", "rationale": "SCIM 2.0 provides the standard protocol for provisioning and managing identity resources across systems; using it for the registry ensures interoperability with existing IAM tooling.", "source_version": "2.0", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "direct", "rationale": "The CISA Zero Trust Maturity Model Identity pillar's Identity Stores function requires a complete, governed inventory of identities \u2014 including non-human identities \u2014 as the foundation of the pillar.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta for AI Agents \u2014 Agent Registry", "rationale": "Okta for AI Agents (EA/GA 2026) requires each AI agent to be registered in Universal Directory as a first-class, non-human identity with a unique identifier, human accountable owner, capability scope, and lifecycle status before any credential is issued. Okta's ISPM (Identity Security Posture Management) continuously discovers unregistered agents and flags them for remediation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta for AI Agents registers each agent as a first-class NHI with unique id, owner, capability scope and lifecycle - the registry the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity for AI \u2014 Agent IAM Core", "rationale": "Ping Identity's Agent IAM Core (GA March 2026) requires every autonomous AI agent to be registered as a governed non-human identity linked to a human principal before credentials are issued. Registration records capability scope, owner binding, and authorization boundaries, forming the authoritative inventory from which runtime policy enforcement operates.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Ping Agent IAM Core registers every agent as a governed NHI linked to a human principal with capability scope and owner before credentials issue.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Best Practices \u2014 Use Roles Not Users", "rationale": "AWS IAM best practices require unique IAM roles per workload or service rather than shared IAM user credentials, creating a de-facto per-agent identity registry. AWS Organizations Service Control Policies can enforce that every role carries owner and application tags (tag:Owner, tag:Application), ensuring the role inventory is the authoritative registry of non-human identities.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS roles-per-workload plus SCP tag enforcement yield only a de-facto registry, lacking the capability manifest and lifecycle fields the control mandates.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_nhi10", "requirement_id": "NHI1:2025", "fit": "direct", "rationale": "OWASP NHI Top 10 2025 NHI1 (Improper Offboarding) requires a continuously maintained registry of non-human identities so offboarding can actually be executed; II-01 addresses this for AI agents.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Agent identity verification (persistent agent IDs; track lifecycle from creation through retirement)", "fit": "direct", "rationale": "Doc requires persistent, cryptographically-backed agent IDs tracked across the lifecycle and appearing in all logs/access requests \u2014 the agent identity registry.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The system must maintain an authoritative, machine-readable registry where every deployed AI agent has a corresponding entry capturing its capability_manifest_hash, owner_id, authorization_scope, principal_type=non-human, and lifecycle_status. No AI agent may operate in any environment without a current, human-approved registry entry whose deployment_artifact_hash matches the running artifact.", "evidence_required": [ "agent_registration_record showing agent_id, owner_id, capability_manifest_hash, authorization_scope, principal_type, lifecycle_status, and registered_at timestamp for each registered agent", "scim_export of all non-human identities via SCIM GET /Users?filter=principal_type eq \"non-human\" showing all required schema attributes populated and current", "ci_cd_gate_log covering 90 days of deployment pipeline events showing registry pre-check enforcement, with any blocked deployment events and their disposition", "quarterly_reconciliation_report comparing active credentials in the identity provider against registry entries, listing gap counts and resolution timestamps within the SLA window" ], "machine_tests": [ "Attempt to deploy an agent container without an approved registry entry \u2192 assert pipeline blocks deployment with error_code=registry_entry_missing", "Submit SCIM GET /Users?filter=principal_type eq \"non-human\" \u2192 assert all deployed agents are returned with lifecycle_status, owner_id, and authorization_scope fields populated", "Set a registry entry's lifecycle_status to suspended \u2192 assert that agent's token issuance fails within one credential TTL cycle" ], "human_review": [ "Review registry schema configuration to confirm all required attributes (agent_id, canonical_name, principal_type, owner_id, authorization_scope, capability_manifest_hash, ial, aal, fal, lifecycle_status) are enforced as non-nullable on the provisioning form", "Examine the reconciliation report for the prior four quarters to assess whether gap resolution SLA compliance is being met and whether the same agents recur as unresolved gaps", "Verify that the registry backend enforces append-only semantics by inspecting database configuration or write-audit logs to confirm update-in-place operations are blocked" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Maintaining the agent inventory in a spreadsheet or wiki with no API surface, which inevitably drifts from deployed reality and provides no enforcement capability", "Allowing agents to self-register without human approval in the provisioning workflow, eliminating the gatekeeping function that prevents unauthorized agent deployment", "Treating registry records as mutable with update-in-place semantics, destroying the historical state needed to reconstruct an agent's authorization scope at any past point in time", "Scoping the registry only to production agents while omitting development and staging instances that share infrastructure credentials and may become persistent access vectors", "Using a credential naming convention (e.g., 'svc-agentname') as a proxy for registration rather than a structured, API-enforced registry entry with validated required fields" ], "update_status": "current", "layer_code": "II" }, { "id": "II-02", "layer": "II", "plane": "control", "name": "Identity Assurance Level Assignment", "plain": "Each AI agent must be assigned an Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL) commensurate with the consequence level of its authorized actions, with a minimum of AAL2 for any agent that can modify data or trigger downstream effects.", "threat": { "tags": [ "identity-spoofing", "credential-compromise" ], "desc": "When AI agents are issued credentials without assurance level assessment, low-consequence authentication mechanisms protect high-consequence actions. An agent authorized to initiate financial transactions or modify access control lists should not authenticate with a simple bearer token equivalent to AAL1; credential compromise in that scenario enables an attacker to perform high-impact operations with minimal friction. Assurance level assignment forces explicit risk quantification at provisioning time rather than deferring it until an incident occurs." }, "standard": [ { "id": "nist_800_63", "section": "\u00a73.3.2", "title": "Identity, Authenticator, and Federation Assurance Levels (xALs)" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Authentication", "title": "Identity assurance and credential strength" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 4", "title": "Access to resources is determined by dynamic policy" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/II-02 Identity Assurance Level Assignment control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Apply NIST SP 800-63-4 IAL/AAL/FAL taxonomy to non-human AI agent identities. IAL maps to the rigor of capability manifest verification at provisioning; AAL maps to the cryptographic strength of the authenticator the agent uses at runtime; FAL maps to the strength of federation assertions if the agent crosses trust domain boundaries.", "steps": [ "Define an assurance level decision matrix for AI agents: categorize action consequence levels (read-only, data-modifying, access-control-modifying, legally-binding, hard-irreversible) and map each to required IAL, AAL, and FAL minimums; document the matrix as a policy artifact and include it in provisioning approval workflow.", "Implement AAL2 as the floor for any agent that can modify state \u2014 this requires the agent to authenticate using a cryptographic authenticator (e.g., mutual TLS client certificate or a hardware-backed OIDC client assertion with signed JWT) rather than a static shared secret.", "For agents that fall into high-consequence categories (financial authorization, access control modification, or any action classified as hard-irreversible), enforce AAL3 by requiring that the agent's private key reside in a FIPS 140-2 Level 3 or higher hardware security module, and bind the assurance level to the registry entry.", "Encode IAL, AAL, and FAL as structured attributes in the identity registry entry and in the credential itself (e.g., as AMR/ACR claims in the JWT); downstream policy enforcement points must reject requests where the presented assurance level is below the required minimum for the target resource or operation." ], "anti_patterns": [ "Assigning all AI agents the same assurance level regardless of their authorization scope \u2014 this either over-constrains low-risk agents or under-protects high-risk ones.", "Treating assurance level as a one-time provisioning decision with no re-evaluation \u2014 consequence levels change as agents gain new capabilities or are granted additional permissions.", "Using AAL1-equivalent mechanisms (static API keys, long-lived bearer tokens without cryptographic binding) for any agent authorized to modify data or trigger downstream effects." ] }, "validation": { "design_check": [ "Verify that the assurance level decision matrix exists as a documented policy artifact and is referenced in the provisioning approval workflow.", "Confirm that IAL, AAL, and FAL are stored as structured, machine-readable attributes in the registry rather than as free-text notes.", "Validate that policy enforcement points (API gateways, service meshes) are configured to reject requests from agents presenting credentials below the required assurance level for the target operation." ], "runtime_test": [ "Present an AAL1-equivalent credential (static bearer token) to an endpoint that requires AAL2 and confirm the request is rejected with a 401 or 403 response.", "Request a registry export filtered by authorization_scope=data-modifying and verify that every returned agent has aal >= 2.", "Simulate a capability expansion scenario \u2014 add a new high-consequence permission to an agent \u2014 and confirm that the assurance level is re-evaluated as part of the change process." ], "evidence": [ "assurance-matrix:Policy document mapping consequence levels to required IAL/AAL/FAL minimums, with approval history [unverified]", "registry-aal-distribution:Aggregate report of AAL distribution across all non-human identities in the registry [unverified]", "enforcement-test-results:Test results from API gateway confirming AAL-based rejection of under-assured credentials [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Assurance level assignment translates the abstract concept of 'how much do we trust this agent's identity claim?' into concrete authenticator requirements. Your job is to ensure the assignment is made at provisioning time, encoded in the registry, and enforced at every authentication boundary the agent crosses.", "actions": [ "Build the assurance level decision matrix into the provisioning approval form so approvers are forced to categorize consequence level before the registry entry is created.", "Configure the credential issuance pipeline to select authenticator type based on the AAL recorded in the registry \u2014 AAL2 triggers mTLS certificate issuance, AAL3 triggers HSM-backed key generation.", "Implement ACR (Authentication Context Class Reference) claims in issued tokens so that relying parties can verify assurance level at the point of resource access." ], "failure_signals": [ "Agents with authorization_scope=data-modifying found in the registry with aal=1.", "API endpoints that accept requests from agents without checking ACR claims." ] }, "security_architect": { "summary": "Assurance level is the formal mechanism for expressing that different agent identities carry different risk profiles and must be protected accordingly. The architecture must ensure that assurance levels are not just assigned but enforced at every trust boundary, and that the enforcement is not bypassable by a lateral-moving attacker.", "actions": [ "Define the assurance level requirements for each protected resource class in the authorization policy layer, not just in the provisioning workflow.", "Require that all service-to-service authentication for high-consequence agents uses mutual TLS with certificate pinning, not just bearer token presentation.", "Include assurance level enforcement in threat model reviews for any new AI agent capability." ], "failure_signals": [ "Service mesh or API gateway configurations that allow AAL1-equivalent credentials to reach high-consequence endpoints.", "Token introspection endpoints that do not surface ACR claims to relying parties." ] }, "legal_counsel": { "summary": "Assurance level assignment provides the documented basis for asserting that the enterprise exercised appropriate due diligence in calibrating authentication strength to the consequence level of AI agent actions. In disputes over unauthorized transactions, the assurance level policy and the agent's assigned level are key evidence of whether the enterprise met its duty of care.", "actions": [ "Confirm that the assurance level decision matrix includes coverage for legally-binding transaction categories and that those categories require AAL3.", "Verify that the assurance level policy is reviewed annually and that the review is documented.", "Ensure that the consequence level categorization covers the enterprise's specific regulatory obligations, including those under financial services, healthcare, and critical infrastructure regulations as applicable." ], "failure_signals": [ "Agents authorized to execute legally-binding transactions that are not assigned AAL3.", "No documented review of the assurance level policy in the prior 12 months." ] }, "grc_auditor": { "summary": "Assurance level assignment is the operationalization of NIST SP 800-63-4 for non-human identities. Audit focus should be on whether the decision matrix is applied consistently, whether the assignments are enforced at authentication boundaries, and whether re-evaluation occurs when agent capabilities change.", "actions": [ "Request the assurance level decision matrix and verify it covers all action consequence categories present in the current agent population.", "Sample 15% of registry entries for agents with data-modifying or higher authorization scopes and verify that AAL >= 2 is recorded and enforced.", "Review the change management log for the prior quarter and identify any agent capability expansions; confirm that assurance level was re-evaluated for each." ], "metrics": [ "AAL compliance rate: percentage of data-modifying agents with AAL >= 2 (target: 100%).", "Assurance re-evaluation rate: percentage of capability-expansion changes that triggered assurance level review (target: 100%)." ], "failure_signals": [ "Any data-modifying agent found with AAL=1 in the registry.", "Capability-expansion change records with no assurance level re-evaluation step." ] }, "it_operations": { "summary": "Assurance level assignment affects which credential type the agent uses and therefore which authentication infrastructure it depends on. Operations teams need to understand assurance level assignments to correctly provision certificate infrastructure, HSMs, and token endpoints for each agent class.", "actions": [ "Maintain a runbook entry for each assurance level describing the credential type, renewal process, and failure mode for agents at that level.", "Monitor certificate and key expiry for AAL2 and AAL3 agents separately from service account password rotation \u2014 the expiry mechanisms and blast radii are different.", "Include assurance level in the incident triage template so on-call engineers know immediately whether a failing agent's credential is HSM-backed or software-based." ], "failure_signals": [ "AAL3 agent certificates expired because the renewal process treated them identically to AAL1 API keys.", "Incidents where the authentication failure mode for an AAL3 agent was not understood by the responding engineer." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises apply no formal assurance level taxonomy to AI agent identities; all agents receive equivalent credential types regardless of consequence level. Target state requires a documented decision matrix, structured registry attributes, and enforcement at authentication boundaries." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Security Architecture" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 \u00a73.3.2", "fit": "partial", "rationale": "NIST SP 800-63-4 \u00a73.3.2 defines the IAL/AAL/FAL (xAL) taxonomy. The suite scopes non-person entities out, so II-02 applies the xAL taxonomy to AI agent identities by analogy, using the same assurance vocabulary for proofing rigor, authenticator strength, and federation assertion strength.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar's Authentication function requires authentication strength to advance with maturity and be applied to all identity types, including non-human identities; assurance level assignment operationalizes that expectation.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 4", "fit": "supporting", "rationale": "SP 800-207 \u00a72.1 Tenet 4 requires that access to resources be determined by dynamic policy that incorporates identity attributes; assurance level assignment supplies the identity-assurance input to that policy.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta for AI Agents \u2014 Assurance Levels", "rationale": "Okta for AI Agents assigns assurance levels to machine identities based on the consequence level of their authorized actions. High-risk agent interactions (e.g., those modifying access control or financial records) require step-up authentication with stronger authenticators, while low-risk read-only agents operate at lower assurance. Okta's risk-based policy engine enforces these assignments at authentication time.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta assigns machine-identity assurance by consequence and step-up, but does not structure the full IAL/AAL/FAL trichotomy the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Well-Architected Security Pillar \u2014 SEC02 (identity and access management)", "rationale": "AWS Well-Architected Security Pillar SEC02 requires that identity controls be commensurate with the sensitivity of the workload. IAM role policies with conditions (aws:MultiFactorAuthPresent, aws:RequestedRegion, aws:SourceIp) encode assurance requirements at policy enforcement time, ensuring high-consequence operations require stronger authentication signals before proceeding.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS IAM policy conditions (MFA, region, IP) encode assurance requirements but are not a structured IAL/AAL/FAL attribute set per agent.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google SAIF \u2014 Expand strong security foundations (least-privilege IAM)", "rationale": "Google's Secure AI Framework element 'Expand strong security foundations to the AI ecosystem' extends infrastructure least-privilege practice to AI systems, and Google Cloud IAM best practices identify agents holding Editor or Owner roles as high-risk. Consequence-level assessment should drive role assignment, with high-consequence agents bound to least-privilege custom roles.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Google SAIF least-privilege IAM flags over-privileged agents but addresses privilege sizing, not consequence-based IAL/AAL/FAL assignment.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Agent identity and authentication (Foundation/Enterprise/Advanced identity tiers)", "fit": "partial", "rationale": "Doc's tiered identity capabilities (cryptographic IDs to X.509 to hardware-backed attestation) map to identity-assurance levels. Partial: doc tiers capability strength, not a formal IAL assignment scheme.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent authorized to modify data, trigger downstream effects, or execute legally-binding or hard-irreversible actions must have structured IAL, AAL, and FAL attributes in the identity registry with AAL at minimum 2 for data-modifying agents. All authentication endpoints must enforce the assigned assurance level by rejecting requests from agents presenting credentials below the required minimum.", "evidence_required": [ "assurance_level_decision_matrix as an approved policy artifact mapping consequence level categories (read-only, data-modifying, access-control-modifying, legally-binding, hard-irreversible) to required IAL/AAL/FAL minimums, with documented review history", "registry_aal_distribution report showing IAL, AAL, and FAL values for all non-human identities as structured machine-readable attributes, filterable by authorization_scope", "api_gateway_enforcement_config extract showing policy rules that evaluate ACR or AAL claims and reject requests from agents below the required assurance level for each protected resource class", "capability_expansion_change_log for the prior 90 days showing re-evaluation of assurance levels whenever agent authorization scopes were modified" ], "machine_tests": [ "Present a static bearer token (AAL1-equivalent) to an endpoint requiring AAL2 \u2192 assert 401 response with error_code=insufficient_assurance_level", "Query the registry for agents with authorization_scope containing data-modifying and aal=1 \u2192 assert zero results returned", "Simulate a capability expansion by adding a high-consequence permission to a test agent without triggering assurance re-evaluation \u2192 assert provisioning system flags the change and blocks new credential issuance pending re-evaluation" ], "human_review": [ "Review the assurance level decision matrix to confirm all consequence level categories present in the current agent population are covered with explicit, approved IAL/AAL/FAL minimums and the matrix has been reviewed within the past 12 months", "Assess whether agents classified as legally-binding or hard-irreversible are enforcing AAL3 with documented HSM-backed authenticator evidence in the registry, not just an AAL=3 label", "Verify that assurance level re-evaluation is being triggered on capability expansions by reviewing change management records for the prior quarter and confirming re-evaluation steps were completed" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Assigning a uniform assurance level to all AI agents regardless of consequence level, either over-constraining low-risk agents or under-protecting high-consequence operations", "Encoding assurance level as a free-text label or comment in the registry rather than a structured machine-readable attribute that policy enforcement engines can evaluate at authentication time", "Treating assurance level as a one-time provisioning decision with no re-evaluation trigger when agent capabilities expand or authorization scopes are modified", "Using static API keys or long-lived bearer tokens without cryptographic proof-of-possession binding for agents authorized to modify data or trigger downstream effects", "Enforcing assurance level only at the perimeter API gateway without requiring proof-of-possession at internal service-to-service authentication boundaries" ], "update_status": "current", "layer_code": "II" }, { "id": "II-03", "layer": "II", "plane": "control", "name": "Cryptographic Identity Binding", "plain": "Each AI agent must be cryptographically bound to a unique key pair at provisioning time. The agent must prove possession of the private key at every authentication event. Private keys must never be exported, shared across agents, or stored in retrievable plaintext.", "threat": { "tags": [ "identity-spoofing", "credential-compromise", "lateral-movement" ], "desc": "Shared or exportable credentials enable one compromised agent to impersonate another, defeating the attribution guarantees that identity controls are meant to provide. A static API key or symmetric secret shared across multiple agent instances means that compromising any one instance yields credentials usable across all instances \u2014 lateral movement requires no additional exploitation. Cryptographic binding with non-exportable private keys means that stealing a credential requires physical or logical access to the specific hardware or process context where the key was generated, raising the cost of impersonation attacks by orders of magnitude." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "Authenticator requirements \u2014 cryptographic authenticators (AAL2/AAL3)" }, { "id": "ietf_rfc_9449_dpop", "section": "RFC 9449", "title": "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Dynamic, strictly enforced authentication and authorization" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/II-03 Cryptographic Identity Binding control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Issue each AI agent a unique key pair at provisioning time using X.509 certificates, SPIFFE SVIDs, or DID-based keys. Enforce proof of possession at every authentication event using mTLS, JWT proof-of-possession (RFC 7800), or DPoP (RFC 9449). Private keys are generated in-process or in an HSM and never exported.", "steps": [ "Select a cryptographic identity format appropriate to the deployment environment: X.509 client certificates with a private CA for on-premises or traditional cloud workloads; SPIFFE SVIDs for service mesh environments; or DID-based keys for cross-organizational federation scenarios. Document the selection rationale in the provisioning policy.", "Integrate the key generation step into the provisioning pipeline so that the private key is generated in the target runtime environment (or its HSM) and the public key is registered with the identity provider \u2014 the private key never transits the provisioning pipeline. Certificate Signing Requests (CSRs) are the only outbound artifact.", "Configure all service endpoints and API gateways to require proof-of-possession authentication: mTLS at the transport layer for server-to-server communication, or DPoP-bound access tokens for OAuth 2.0 scenarios where bearer tokens are unavoidable. Reject any request that presents a bearer token without a proof-of-possession binding for agents classified AAL2 or above.", "Implement automated certificate rotation with rotation triggered 30 days before expiry; the rotation process generates a new key pair in-process, submits a new CSR, and atomically updates the credential in the identity store \u2014 the old key is revoked immediately upon successful rotation to minimize the window of dual-key validity." ], "anti_patterns": [ "Generating key pairs in the provisioning pipeline and pushing the private key to the agent \u2014 this means the private key has transited a system the agent does not control, eliminating the proof-of-possession guarantee.", "Using symmetric shared secrets (API keys, HMAC secrets) for agent authentication in place of asymmetric key pairs \u2014 symmetric secrets cannot provide true proof of unique possession.", "Issuing wildcard or shared certificates across multiple agent instances \u2014 this defeats per-agent attribution and means revoking one instance's credential requires revoking all of them." ] }, "validation": { "design_check": [ "Verify that the key generation procedure specifies in-process or HSM-based generation with no private key export step documented.", "Confirm that the certificate or key issuance policy prohibits wildcard subjects and requires per-agent unique Subject Alternative Names.", "Validate that authentication endpoints are configured to enforce mTLS or DPoP binding rather than accepting plain bearer tokens from agents classified AAL2 or above." ], "runtime_test": [ "Attempt to authenticate to a protected endpoint using a bearer token without a DPoP proof for an agent classified AAL2 and confirm the request is rejected.", "Export the private key material for a running agent using standard OS keystore export commands and confirm that the operation fails or is prohibited by policy.", "Revoke one agent's certificate and confirm that subsequent authentication attempts by that agent fail within one OCSP/CRL TTL cycle." ], "evidence": [ "key-generation-audit:HSM or secure enclave audit log showing key generation events with agent_id, timestamp, and no export events [unverified]", "certificate-inventory:Export of all agent certificates from the private CA showing unique subjects, SANs, and validity periods [unverified]", "mTLS-enforcement-config:API gateway configuration extract confirming client certificate requirement for agent-facing endpoints [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Cryptographic binding is the technical foundation of non-repudiation for AI agent actions. Without it, any agent can claim to be any other agent, and audit logs become unreliable. Your job is to ensure the key lifecycle \u2014 generation, issuance, rotation, and revocation \u2014 is automated and does not require human handling of private key material.", "actions": [ "Build a certificate lifecycle automation pipeline that handles CSR generation, CA signing, and rotation without human intervention in the key material flow.", "Configure OCSP stapling or short-lived certificates (e.g., 24-hour SVIDs from SPIFFE SPIRE) to minimize the revocation latency window.", "Instrument the PKI to alert on any certificate issuance with a validity period exceeding the policy maximum or with a shared subject across multiple agents." ], "failure_signals": [ "Private key material found in environment variables, config files, or secrets management stores in recoverable form.", "Certificates with identical subjects issued to multiple distinct agents." ] }, "security_architect": { "summary": "Cryptographic identity binding is the enforcement point that makes all other identity controls meaningful. If an agent can authenticate without proving possession of a unique private key, the entire identity model is built on assertions rather than proofs. The architecture must ensure that proof-of-possession is enforced at every trust boundary, not just at the perimeter.", "actions": [ "Design the service mesh or API gateway layer to enforce mTLS uniformly rather than terminating TLS at the edge and using plain HTTP internally.", "Specify that SPIFFE SPIRE or an equivalent short-lived SVID issuer is the preferred approach for cloud-native environments to eliminate the operational burden of certificate rotation.", "Include cryptographic identity binding requirements in the threat model template for all new AI agent capabilities." ], "failure_signals": [ "Internal service-to-service calls between agent components using plain HTTP or bearer tokens without proof-of-possession binding.", "Key material discovered in application logs, stack traces, or error messages." ] }, "legal_counsel": { "summary": "Cryptographic identity binding provides the technical basis for asserting that a specific action was taken by a specific agent and not by an impersonator. In disputes involving AI-executed transactions, the ability to produce a certificate chain or DID proof linking the action to a unique, registered agent identity is materially stronger evidence than a log entry referencing an API key.", "actions": [ "Confirm that the certificate or key records associated with each agent are retained for a period consistent with the enterprise's evidentiary retention requirements.", "Verify that the private key generation and issuance process is documented in enough detail to support expert testimony about the uniqueness and integrity of the agent's identity.", "Ensure that key revocation events are logged with timestamps and precipitating cause so that the validity window of any key can be precisely established." ], "failure_signals": [ "No certificate issuance or revocation records available for an agent involved in a disputed transaction.", "Key material shared between multiple agents, making it impossible to attribute an action to a specific agent instance." ] }, "grc_auditor": { "summary": "Cryptographic identity binding is the technical control that supports NIST SP 800-63-4 AAL2 and AAL3 requirements for non-human identities. Audit focus is on whether private keys are generated and stored correctly, whether proof-of-possession is enforced at authentication boundaries, and whether the certificate lifecycle is managed without gaps.", "actions": [ "Request an export of the private CA's certificate issuance log and verify that all active agent certificates have unique subjects and SANs.", "Sample 10 agents and attempt to locate their private key material in the provisioning pipeline, secrets manager, or environment configuration \u2014 key material should not be retrievable in any of these locations.", "Review the certificate rotation log for the prior 90 days and verify that no certificate was renewed without generating a new key pair." ], "metrics": [ "Unique-key rate: percentage of agents with a unique, non-shared key pair (target: 100%).", "Key export event count: number of private key export events logged in the PKI audit log (target: 0)." ], "failure_signals": [ "Any private key export event in the PKI audit log.", "Shared certificates identified across multiple agent instances." ] }, "it_operations": { "summary": "Cryptographic identity binding means that agent authentication depends on certificate infrastructure rather than static credentials. This changes the operational profile: certificate expiry, OCSP availability, and CA health become availability dependencies for every agent in the fleet.", "actions": [ "Monitor certificate expiry across the entire agent fleet with alerting at 30, 14, and 7 days before expiry.", "Include CA health and OCSP responder availability in the production monitoring dashboard alongside application metrics.", "Document the emergency credential issuance procedure for scenarios where an agent's certificate is compromised and must be revoked and reissued outside the normal rotation window." ], "failure_signals": [ "Agent authentication failures spiking due to certificate expiry that was not caught by monitoring.", "OCSP responder outage causing certificate validation failures across multiple agents simultaneously." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises still rely on API keys or symmetric secrets for AI agent authentication. Target state requires per-agent key pairs with proof-of-possession enforcement and automated certificate lifecycle management." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Security Engineering", "Platform Engineering" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "partial", "rationale": "SP 800-63B-4 \u00a73 specifies the cryptographic authenticator requirements underlying AAL2 and AAL3; II-03 operationalizes those requirements for AI agents (applied by analogy \u2014 the suite scopes out machine-to-machine authentication).", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 6 requires that all resource authentication and authorization be dynamic and strictly enforced before access is allowed; mTLS and DPoP proof-of-possession enforce this for agent-to-service communication.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Roles Anywhere \u2014 Certificate Binding", "rationale": "AWS IAM Roles Anywhere allows on-premises and multi-cloud workloads to use X.509 certificates from a private PKI to authenticate to AWS STS and obtain temporary credentials, cryptographically binding the workload identity to a certificate-backed IAM role. This establishes a hardware- or PKI-rooted identity binding without requiring long-lived access keys.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "IAM Roles Anywhere binds each workload to an X.509 private-PKI key with mTLS proof-of-possession at authentication - the binding the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Workload Identity Federation \u2014 Keyless Authentication", "rationale": "Google Cloud Workload Identity Federation enables keyless authentication where external workloads present short-lived OIDC tokens that are cryptographically bound to their source identity provider. The token exchange to Google credentials is validated against the WIF pool's attribute mappings and conditions, creating a cryptographic binding between external identity and Google Cloud access.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP Workload Identity Federation is keyless and cryptographically bound to the source IdP, not a per-agent non-exportable key pair with PoP each event.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "ping_identity", "requirement_id": "PingOne Credentials \u2014 Verifiable Credentials", "rationale": "PingOne Credentials issues cryptographically signed verifiable credentials (W3C VC data model) that bind agent identity to specific capabilities and authorization scope. These credentials can be presented as DPoP-bound assertions, preventing token theft; the cryptographic signature chain provides tamper-evident identity binding without exposing long-lived secrets.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "PingOne verifiable credentials bind agent identity and can be DPoP-bound, but the VC model does not by itself guarantee a per-agent key pair with PoP.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Agent identity and authentication (Unique cryptographic identifiers backed by cryptographic material, not just labels)", "fit": "direct", "rationale": "Foundation now requires identifiers cryptographically rooted so identity forgery is hard ('Cryptographic identity is what makes non-repudiation possible').", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent must authenticate exclusively using a unique, non-exportable asymmetric key pair, with cryptographic proof of possession demonstrated at every authentication event via mTLS, JWT proof-of-possession (RFC 7800), or DPoP (RFC 9449). No shared credentials, symmetric secrets, or unbound bearer tokens may be accepted from agents classified AAL2 or above at any authentication boundary.", "evidence_required": [ "hsm_or_enclave_key_generation_log showing key generation events with agent_id, timestamp, algorithm, key_length, and confirmed absence of C_WrapKey or key export operations for each agent signing key", "certificate_inventory export from the private CA listing all active agent certificates with unique Subject Alternative Names, non-wildcard subjects, and non-overlapping validity periods", "api_gateway_mtls_or_dpop_enforcement_config confirming client certificate requirement or DPoP binding is enforced for all agent-facing endpoints, not just the perimeter", "token_validation_log showing proof-of-possession verification events and the count of rejected requests due to missing DPoP proof or absent client certificate" ], "machine_tests": [ "Submit a plain bearer token without a DPoP proof to an AAL2-required endpoint \u2192 assert 401 response with error=proof_of_possession_required", "Attempt to export the private key for a running agent via PKCS#11 C_WrapKey \u2192 assert operation returns CKR_KEY_NOT_WRAPPABLE", "Revoke one agent certificate via CRL or OCSP and submit an authentication request using the revoked certificate \u2192 assert authentication fails within one OCSP/CRL TTL cycle" ], "human_review": [ "Review the key generation procedure to confirm private key material never transits the provisioning pipeline, the CSR is the only outbound artifact, and no documented key export step exists", "Inspect the certificate issuance log to confirm no wildcard subjects and no identical SANs appear across distinct agent instances in the active certificate inventory", "Assess mTLS enforcement configuration at internal service mesh boundaries to confirm proof-of-possession is required end-to-end, not only at the external API gateway" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Generating key pairs in the provisioning pipeline and pushing the private key to the agent runtime, eliminating the proof-of-possession guarantee since the key has transited a system outside the agent's control", "Using symmetric shared secrets such as API keys or HMAC secrets as the primary agent authentication mechanism, which cannot provide true proof of unique cryptographic possession", "Issuing wildcard or shared X.509 certificates across multiple agent instances, defeating per-agent attribution and requiring revocation of all instances when any one is compromised", "Terminating mTLS at the edge load balancer and using plain HTTP internally, leaving all internal service-to-service boundaries unprotected by cryptographic identity binding", "Permitting software-key fallback when an HSM is unavailable for AAL3 agents, eliminating hardware-rooted protection during exactly the failure mode an attacker might deliberately induce" ], "update_status": "current", "layer_code": "II" }, { "id": "II-04", "layer": "II", "plane": "control", "name": "Hardware-Rooted Identity for High-Consequence Agents", "plain": "AI agents authorized to perform legally-binding, financially-material, or hard-to-reverse actions must have their private key generated and stored in a FIPS 140-2 Level 3 or higher hardware security module, with remote attestation confirming the hardware root of trust at provisioning time and on a periodic basis.", "threat": { "tags": [ "identity-spoofing", "credential-compromise" ], "desc": "Software-stored private keys for high-consequence agents are vulnerable to memory extraction, hypervisor-level access, and supply-chain attacks on the runtime environment. An attacker who compromises the host OS or container runtime can extract software-managed keys without any cryptographic evidence of the extraction. Hardware security modules and secure enclaves make key extraction physically infeasible \u2014 the private key is generated inside the hardware boundary, operations are performed inside the boundary, and the key cannot be exported in usable form even by an administrator with full system access." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73.1.7", "title": "Multi-factor cryptographic authenticators \u2014 hardware-based (AAL3)" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Dynamic, strictly enforced authentication and authorization" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Authentication", "title": "Hardware-rooted identity assurance" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-04 Hardware-Rooted Identity for High-Consequence Agents control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/II-04 Hardware-Rooted Identity for High-Consequence Agents control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/II-04 Hardware-Rooted Identity for High-Consequence Agents control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-04 Hardware-Rooted Identity for High-Consequence Agents control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/II-04 Hardware-Rooted Identity for High-Consequence Agents control.", "reviewed_on": "2026-07-01" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds hardware-rooted identity in the Advanced identity tier and Phase 6 hardware-bound credentials.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Provision high-consequence agents with private keys generated inside a FIPS 140-2 Level 3 HSM or a TPM 2.0 / secure enclave. Use remote attestation (TPM quote, Intel TDX attestation, or AWS Nitro attestation) at provisioning time to verify the hardware boundary. Include attestation reports in the registry entry and refresh them on a defined schedule.", "steps": [ "Classify agents by consequence level during the provisioning approval workflow; any agent authorized for financially-material transactions (e.g., > $10K single transaction), legally-binding document signing, access-control-list modification, or actions classified as hard-irreversible must be designated as requiring hardware-rooted identity and routed to an HSM-backed provisioning path.", "Generate the agent's private key inside the HSM or secure enclave boundary using the HSM's key generation API; extract only the public key and the attestation report from the HSM; submit the public key as a CSR to the private CA; store the attestation report in the identity registry as evidence of hardware origin.", "Configure the agent's authentication library to use the PKCS#11 or CNG (Windows) interface to the HSM for all signing operations \u2014 the private key handle, not the key material, is passed to the authentication library; validate at build time that the library does not fall back to software key storage if the HSM is unavailable.", "Schedule quarterly remote attestation renewal: the agent generates a fresh TPM quote or enclave attestation report, submits it to the registry, and the registry updates the attestation_last_verified timestamp; agents that fail attestation renewal are automatically suspended pending investigation." ], "anti_patterns": [ "Using cloud KMS or software-backed secrets managers as a substitute for hardware security modules \u2014 cloud KMS provides key isolation but not the same physical non-extractability guarantee as a dedicated HSM.", "Generating the key pair in software during provisioning and then importing it into the HSM \u2014 key material that has ever existed outside the hardware boundary has no hardware-root-of-trust guarantee.", "Allowing agents to fall back to software-backed key storage when the HSM is unavailable \u2014 this fallback eliminates the protection during exactly the failure mode an attacker might induce." ] }, "validation": { "design_check": [ "Verify that the provisioning policy document lists all consequence-level categories that require hardware-rooted identity and that the list is reviewed annually.", "Confirm that the HSM integration is configured with no key export capability \u2014 the HSM policy should prohibit CKA_EXTRACTABLE=TRUE for agent signing keys.", "Validate that the CI/CD pipeline for high-consequence agents requires an HSM attestation report as a provisioning artifact before the registry entry is created." ], "runtime_test": [ "Attempt to export the private key for a hardware-rooted agent using the PKCS#11 C_WrapKey function and confirm the operation fails with CKR_KEY_NOT_WRAPPABLE.", "Revoke the HSM's attestation certificate and confirm that the agent's next authentication attempt is rejected.", "Submit a provisioning request for a high-consequence agent with a software-generated key pair and confirm the provisioning pipeline rejects it for lack of attestation evidence." ], "evidence": [ "hsm-key-generation-log:HSM audit log showing key generation events for agent signing keys with CKA_EXTRACTABLE=FALSE confirmed [unverified]", "attestation-reports:Remote attestation reports for all hardware-rooted agents stored in the registry, with validity timestamps [unverified]", "consequence-classification-policy:Documented policy classifying consequence levels and mapping them to hardware-root requirements, with annual review history [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Hardware-rooted identity is the technical ceiling of identity assurance for AI agents \u2014 it is the mechanism that makes 'this agent definitely made this action' a statement supported by hardware attestation rather than software policy. Implementation complexity is higher than software-backed keys, but the scope is deliberately narrow: only agents with the highest consequence levels require it.", "actions": [ "Maintain a dedicated HSM provisioning path in the IAM pipeline, separate from the standard software-backed provisioning path, with additional approval gates.", "Integrate TPM or enclave attestation verification into the provisioning API so that the attestation report is validated at registration time, not just stored.", "Test HSM failover behavior in a non-production environment to confirm that agents are suspended rather than falling back to software keys when the HSM is unavailable." ], "failure_signals": [ "High-consequence agents found in the registry without an attestation_report attribute.", "Agent authentication succeeding during HSM maintenance windows \u2014 indicating fallback to software key storage." ] }, "security_architect": { "summary": "Hardware-rooted identity is the architectural response to the threat that a sufficiently privileged attacker in the cloud or on-premises environment can extract software keys. The architecture must treat HSM availability as a hard dependency for high-consequence agents \u2014 not a nice-to-have \u2014 and design availability controls accordingly.", "actions": [ "Specify HSM redundancy requirements (e.g., clustered HSMs across availability zones) for agents whose unavailability would cause unacceptable business impact.", "Include HSM key policies in security design reviews to confirm that CKA_EXTRACTABLE is set to FALSE for all agent signing keys at creation time.", "Design the attestation verification workflow to use a separate, isolated verifier service to prevent an attacker who compromises the agent runtime from also compromising the attestation verification." ], "failure_signals": [ "HSM key policies that permit key export under any condition.", "Attestation verification performed by the same service that relies on the attestation result." ] }, "legal_counsel": { "summary": "Hardware-rooted identity provides the strongest available technical basis for asserting that a signed document or transaction was executed by a specific, authorized AI agent and that the signing key could not have been extracted and misused by an unauthorized party. This is directly relevant to the legal validity of AI-executed contracts and financial transactions.", "actions": [ "Confirm that the hardware-root-of-trust requirement is referenced in the enterprise's AI governance policy and in any AI-specific terms in commercial contracts.", "Verify that the HSM attestation reports and key generation logs are retained as part of the legal evidence package for legally-binding agent actions.", "Assess whether applicable jurisdictions have guidance on the evidentiary weight of HSM-backed digital signatures for AI-executed instruments." ], "failure_signals": [ "Legally-binding agent actions signed with software-backed keys without HSM attestation evidence.", "HSM audit logs not included in the standard evidence package for legally-relevant AI agent actions." ] }, "grc_auditor": { "summary": "Hardware-rooted identity is the control that operationalizes NIST SP 800-63-4 AAL3 for the highest-consequence AI agent identities. Audit focus is on whether the consequence-level classification is being applied consistently, whether HSM key policies prevent export, and whether attestation reports are current.", "actions": [ "Request a list of all agents classified as high-consequence and verify that each has an attestation_report in the registry with a validity date within the defined renewal window.", "Review the HSM key policy for the CA used to issue agent certificates and confirm CKA_EXTRACTABLE=FALSE is enforced.", "Test one agent's quarterly attestation renewal process end-to-end in the audit period to confirm the renewal mechanism functions as documented." ], "metrics": [ "Hardware-root coverage: percentage of high-consequence agents with current HSM attestation reports (target: 100%).", "Attestation freshness: percentage of hardware-rooted agents with attestation renewed within the defined window (target: 100%)." ], "failure_signals": [ "Any high-consequence agent without a current attestation report in the registry.", "HSM key policy that permits export under administrator override conditions." ] }, "it_operations": { "summary": "Hardware-rooted agents have a different availability profile than software-backed agents \u2014 their authentication depends on HSM health and attestation service availability in addition to standard infrastructure. Operations teams must monitor HSM fleet health as a first-class production dependency.", "actions": [ "Add HSM health metrics (key operation latency, queue depth, error rate) to the production monitoring dashboard.", "Document the runbook for HSM failure scenarios, including which high-consequence agents are affected and what the approved operational response is (suspension vs. failover to secondary HSM).", "Test the HSM failover process quarterly in a non-production environment to ensure the procedure remains accurate." ], "failure_signals": [ "HSM health alerts not routed to the production operations team.", "High-consequence agents operational during a documented HSM maintenance window \u2014 indicating unexpected fallback behavior." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Hardware-rooted identity for AI agents is not yet established practice in most enterprises. Initial target is to identify high-consequence agents and provision them with HSM-backed keys; managed state requires automated attestation renewal and HSM health monitoring." }, "capability_risk": { "capability_level": "elevated", "autonomy": "supervised-autonomous", "access_mode": "api-key", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Security Engineering", "Hardware/Infrastructure" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73.1.7", "fit": "direct", "rationale": "SP 800-63B-4 \u00a73.1.7 covers multi-factor cryptographic authenticators, including the hardware-based authenticators AAL3 requires; II-04 applies the hardware-binding requirement to high-consequence AI agent identities by analogy.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "supporting", "rationale": "The CISA Zero Trust Maturity Model Identity pillar's Authentication function identifies phishing-resistant, hardware-backed authentication as the advanced maturity target; II-04 applies hardware-rooted identity to the highest-consequence AI agents.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Roles Anywhere \u2014 HSM Integration", "rationale": "AWS IAM Roles Anywhere supports HSM and TPM-based signing for JWT assertions presented to AWS STS; the private key for the X.509 certificate never leaves the hardware boundary. This provides hardware-rooted identity for high-consequence on-premises AI workloads where cryptographic key custody must be hardware-enforced.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "IAM Roles Anywhere keeps the signing key inside an HSM/TPM, but does not supply the FIPS L3 remote-attestation report the control also requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud IAM \u2014 HSM Service Account Keys", "rationale": "Google Cloud IAM documentation explicitly recommends using an HSM or TPM to generate and manage service account key material for high-value workloads. The HSM or TPM generates an RSA key pair, a self-signed certificate is uploaded as the service account key, and the application uses the HSM signing API to sign JWTs; the private key never exists in cleartext outside the hardware boundary.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP HSM/TPM-generated service-account keys give hardware key residency but not the remote hardware-root attestation the control mandates.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Agent identity and authentication (Advanced: hardware-backed identity with attestation); Part IV Phase 6 \u2014 Hardware-bound credentials for production and sensitive workloads", "fit": "direct", "rationale": "Advanced identity binds credentials to attested hardware (HSM/TPM, remote attestation, confidential computing) so credentials cannot be exfiltrated \u2014 hardware-rooted identity for high-consequence agents.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All AI agents classified as high-consequence (financially-material, legally-binding, or hard-irreversible actions) must have their private signing key generated and permanently resident within a FIPS 140-2 Level 3 or higher HSM, confirmed by a remote attestation report stored in the identity registry. Attestation must be renewed at least quarterly, and agents failing renewal must be automatically suspended pending investigation.", "evidence_required": [ "hsm_key_generation_audit_log showing key generation events for all high-consequence agent signing keys with CKA_EXTRACTABLE=FALSE and CKA_SENSITIVE=TRUE confirmed at creation time", "remote_attestation_reports for all hardware-rooted agents stored in the identity registry, with attestation_last_verified timestamps within the quarterly renewal window", "consequence_classification_policy document mapping consequence level categories to hardware-root requirements with annual review history and named approver", "hsm_key_policy_extract showing the policy profile applied to agent signing keys confirming no administrator override condition permits export" ], "machine_tests": [ "Attempt to export the private key for a hardware-rooted agent via PKCS#11 C_WrapKey with CKA_EXTRACTABLE=FALSE \u2192 assert operation fails with CKR_KEY_NOT_WRAPPABLE", "Submit a provisioning request for a high-consequence agent with a software-generated key pair and no attestation report attached \u2192 assert provisioning pipeline rejects with error=hsm_attestation_required", "Allow a hardware-rooted agent's quarterly attestation renewal deadline to lapse in a test environment \u2192 assert agent lifecycle_status transitions to suspended automatically" ], "human_review": [ "Verify that every agent currently classified as high-consequence has a valid, non-expired remote attestation report in the registry with a validity date within the quarterly renewal window", "Review the HSM key policy extract to confirm CKA_EXTRACTABLE=FALSE is set as a permanent attribute with no administrator override condition that could permit export", "Assess the HSM failover architecture to confirm that no approved software-key fallback path exists and that high-consequence agents are suspended rather than demoted to software-backed keys during HSM maintenance events" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Using cloud KMS or software-backed secrets managers as a substitute for a dedicated hardware security module, which lacks the physical non-extractability guarantee required for AAL3", "Generating the key pair in software and then importing it into the HSM at provisioning time, which permanently destroys the hardware-root-of-trust guarantee since the key material existed outside the hardware boundary", "Allowing agents to fall back to software-backed key storage when the HSM is unavailable, eliminating hardware-rooted protection during exactly the failure mode an attacker might deliberately induce", "Treating quarterly attestation renewal as a low-priority operational task, allowing stale attestation reports to persist while the hardware trust state may have changed", "Scoping hardware-root requirements only to agents in regulated industry sectors rather than applying them uniformly based on the consequence level of the actions performed" ], "update_status": "current", "layer_code": "II" }, { "id": "II-05", "layer": "II", "plane": "control", "name": "Non-Human Identity Separation from Human Identity", "plain": "AI agent identities must exist in a strictly separate namespace from human user identities. No human credential may be used to authenticate an AI agent, and no AI agent may authenticate as a named human user. Separate audit trails must be maintained for human and non-human identity activity.", "threat": { "tags": [ "identity-spoofing", "lateral-movement", "privilege-escalation" ], "desc": "Shared credential namespaces between human users and AI agents create systemic attribution failures: security tools cannot distinguish human from automated activity in audit logs, anomaly detection models trained on human behavior patterns produce high false-negative rates for agent activity, and access reviews conflate the two populations. An agent that compromises a human credential \u2014 or a human account that is repurposed for agent use \u2014 gains all the access rights associated with that human identity, typically including permissions granted based on job function rather than agent capability scope." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63-4 (by analogy)", "title": "NPE/machine identities scoped out \u2014 separate NHI identity plane required" }, { "id": "iso_24760", "section": "\u00a77.2", "title": "Managing identity information \u2014 lifecycle" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Identity Stores", "title": "Non-human identity enumeration and separation" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-02" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/II-05 Non-Human Identity Separation from Human Identity control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish distinct identity namespaces for human users and AI agents in the identity provider. Use a separate organizational unit, directory partition, or identity domain for non-human identities. Route all agent authentication events to a separate audit log stream. Prohibit the use of human credentials in agent runtime environments through technical enforcement, not just policy.", "steps": [ "Create a dedicated identity namespace or organizational unit (OU) for non-human identities in the enterprise identity provider; configure access policies so that identities in the human namespace cannot be authenticated in agent runtime contexts and vice versa \u2014 enforce this through RBAC or ABAC rules that check principal_type as a condition, not through naming conventions alone.", "Audit existing AI agent deployments for any instances where human credentials are in use; replace all human credentials with purpose-provisioned agent identities within a defined remediation window (recommended: 60 days); document any exceptions with a time-bound compensating control and executive sign-off.", "Configure SIEM and audit log pipelines to tag all authentication events with principal_type so that human and agent activity can be separated for analysis; create separate dashboards, alerting thresholds, and anomaly detection models for the two populations.", "Implement a technical control at the credential issuance layer that rejects requests to issue agent credentials bearing a human user's UPN or display name, and rejects requests to issue human credentials to service account namespaces; test this control quarterly by attempting cross-namespace credential requests." ], "anti_patterns": [ "Using a naming convention (e.g., 'svc-agentname') to distinguish agent accounts in the human directory rather than a separate namespace \u2014 naming conventions are not enforced and drift silently.", "Granting human-inherited permissions to agent accounts because it is 'easier than figuring out exactly what the agent needs' \u2014 this creates privilege levels far exceeding the agent's legitimate scope.", "Sharing service account credentials between human users for emergency access and AI agent operations \u2014 this destroys attribution for all actions taken with those credentials." ] }, "validation": { "design_check": [ "Verify that the identity provider configuration creates a structurally separate namespace for non-human identities that cannot be accessed using human authentication flows.", "Confirm that audit log schemas include a principal_type field and that all agent authentication events are tagged non-human.", "Validate that access policies on sensitive resources include principal_type as a condition attribute, enabling different policy treatment for human and agent requestors." ], "runtime_test": [ "Attempt to authenticate to an agent-designated service using a human user credential and confirm the attempt is rejected at the identity provider level.", "Pull a 24-hour sample of authentication events from the audit log and verify that every event has a principal_type tag and that the distribution between human and non-human is consistent with expected values.", "Attempt to provision an agent credential in the human identity namespace and confirm the provisioning pipeline rejects the request." ], "evidence": [ "namespace-config:Identity provider configuration export showing separate OUs or partitions for human and non-human identities [unverified]", "audit-log-sample:30-day sample of authentication events with principal_type tags, showing clean separation [unverified]", "remediation-log:Record of any human credentials replaced with agent credentials during the remediation sweep, with completion dates [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Separation of human and non-human identity namespaces is foundational to making access reviews and anomaly detection reliable. Without it, you cannot efficiently query 'show me all AI agent access to this resource' without manually filtering through mixed audit logs. The separation must be structural, not conventional \u2014 naming patterns drift; directory partitions do not.", "actions": [ "Implement the non-human identity namespace as a structurally separate OU or identity domain with its own provisioning pipeline and access policies.", "Configure automated alerting for any authentication attempt where a human credential is presented to an agent-designated service or vice versa.", "Build the principal_type tag into the standard SIEM parsing rules so that all downstream analytics tools can filter on it without custom per-query logic." ], "failure_signals": [ "Human credentials found in environment variable injection for agent containers.", "Authentication events in the audit log without a principal_type tag." ] }, "security_architect": { "summary": "Non-human identity separation is an architectural prerequisite for effective threat detection in environments where AI agents are active. Mixed identity namespaces cause behavioral baseline models to conflate human and agent activity, producing poor anomaly detection fidelity for both populations.", "actions": [ "Specify principal_type as a required context attribute in the enterprise's authorization policy language so that access policies can express different rules for human and agent requestors.", "Design the SIEM architecture to route human and non-human authentication events to separate detection pipelines with population-appropriate behavioral models.", "Include identity separation verification in the security design review checklist for all new AI agent deployment patterns." ], "failure_signals": [ "UEBA/anomaly detection systems that have no mechanism to distinguish human from agent authentication events.", "Access policies that do not consider principal_type as a relevant attribute." ] }, "legal_counsel": { "summary": "Separation of human and non-human identity namespaces ensures that when an AI agent takes an action, the audit log unambiguously attributes that action to a non-human principal \u2014 not to the human whose credentials might otherwise have been in use. This distinction has legal significance in employment law, fiduciary duty analysis, and regulatory enforcement contexts where the question of whether a human or an automated system made a decision is material.", "actions": [ "Confirm that the enterprise's AI governance policy specifies that AI agents may not authenticate as named human employees.", "Verify that audit log records for high-consequence agent actions include a principal_type field that is captured in the legal evidence package.", "Assess whether any existing contracts or regulatory filings describe AI agent actions in terms that could be confused with human decision-making due to shared credential namespaces." ], "failure_signals": [ "Audit log records for AI-executed transactions that reference a human employee's identity rather than a non-human agent identity.", "AI governance policy documents that do not address the prohibition on agent use of human credentials." ] }, "grc_auditor": { "summary": "Non-human identity separation is a prerequisite control for the reliability of access reviews and audit log analysis. If human and non-human identities share a namespace, access reviews cannot efficiently identify agent access, and audit log analysis cannot isolate agent behavior. This control must be verified structurally, not just by sampling.", "actions": [ "Request an export of all identity provider namespaces and verify that a structurally separate non-human namespace exists with appropriate access boundaries.", "Query the access review system for AI agent identities and confirm they are processed in a separate workflow from human identities with appropriate agent-specific review criteria.", "Sample 20 authentication events tagged as agent-initiated and verify that none reference a human user's UPN or display name as the authenticating principal." ], "metrics": [ "Namespace separation rate: percentage of AI agent identities provisioned in the non-human namespace (target: 100%).", "Human credential usage in agent contexts: count of authentication events in the prior 90 days where a human credential was used in an agent runtime (target: 0)." ], "failure_signals": [ "Any AI agent identity found in the human identity namespace.", "Human credentials found in use in agent runtime environments during the audit period." ] }, "it_operations": { "summary": "Non-human identity separation simplifies operations troubleshooting because agent authentication failures are immediately identifiable as non-human and can be routed to the appropriate team without first determining whether the credential belongs to a person or a service.", "actions": [ "Update the incident classification taxonomy to include 'non-human identity failure' as a distinct category with its own escalation path.", "Configure monitoring alerts for agent authentication failures to route to the platform engineering team rather than the general helpdesk queue.", "Include principal_type in the standard fields exported in security incident reports so that responders can immediately see whether an incident involves human or agent identities." ], "failure_signals": [ "Agent authentication incidents being routed to helpdesk password reset queues instead of platform engineering.", "Incident reports that cannot confirm whether the affected credential belongs to a human or an agent." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many enterprises use the same directory and access review processes for service accounts (which include AI agents) and human users. Target state requires a structurally separate namespace, separate audit pipelines, and detection rules tuned separately for each population." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Security", "IT Operations" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 (applied by analogy)", "fit": "partial", "rationale": "SP 800-63-4 defines identity assurance for human subjects and explicitly excludes machine-to-machine (NPE) authentication from its scope. That scoping boundary is itself the strongest argument for II-05: non-human identities need a separately governed identity plane rather than inheriting human-identity assumptions. Applied by analogy.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "\u00a77.2", "fit": "direct", "rationale": "ISO/IEC 24760-1 \u00a77.2 addresses managing identity information across lifecycle stages; managing human and non-human identities as distinct identity-information populations with separate lifecycle treatment implements this discipline for the NHI plane.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "supporting", "rationale": "The CISA ZTMM Identity pillar's Identity Stores function expects complete enumeration and appropriate governance of non-human identities as a distinct population.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Universal Directory \u2014 Human NHI Separation", "rationale": "Okta explicitly separates human identities from non-human identities (NHIs) in Universal Directory as distinct principal types with separate governance flows, access certification tracks, and policy engines. NHIs including AI agents, service accounts, and API keys are managed under Okta's dedicated NHI governance layer, preventing credential sharing between human and machine principals.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Universal Directory holds AI agents as a distinct NHI principal type separate from humans with separate governance - exactly the separation required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Best Practices \u2014 Separate Human Workload Identity", "rationale": "AWS IAM best practices require using IAM Identity Center for human workforce access and IAM roles (not IAM users) for workloads, ensuring complete separation of human and machine identity planes. Human IAM users must never be used for automated workload access, and workload IAM roles must never be assumable by human principals except via explicit emergency procedures.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS separates humans (Identity Center) from workloads (roles), but by convention rather than a labelled namespace with a principal_type audit field.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud IAM \u2014 Dedicated Service Accounts", "rationale": "Google Cloud IAM best practices require dedicated service accounts per AI application, completely separate from human user accounts, with no human-to-service-account credential sharing. Each workload should have its own service account with narrowly scoped permissions, and service account impersonation by human users should be explicitly controlled via the iam.serviceAccounts.actAs permission.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP dedicated service accounts are structurally distinct from user accounts, but do not by themselves provide the principal_type-tagged audit trail.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II \u2014 Identity and privilege abuse (agents operate with elevated privileges/service accounts; traditional identity systems struggle to accommodate them)", "fit": "partial", "rationale": "Doc notes agents/non-human identities don't fit human identity systems, creating exploitable gaps. Partial: doc diagnoses the mismatch rather than prescribing NHI-from-human separation as a control.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All AI agent identities must reside in a structurally separate namespace or directory partition from human user identities, with technical controls at the identity provider level preventing cross-namespace authentication. Every authentication event in the audit log must carry a principal_type field enabling complete, query-time separation of human and agent activity without manual filtering.", "evidence_required": [ "identity_provider_namespace_config export showing separate OUs, directory partitions, or identity domains for human and non-human principals with enforced access policy boundaries preventing cross-namespace authentication", "audit_log_sample covering 30 days of authentication events showing principal_type tags on all events, with a query confirming zero events lack the principal_type field", "cross_namespace_enforcement_test_results confirming human credentials are rejected when presented to agent-designated services and agent credentials are rejected when presented to human authentication flows", "remediation_record documenting all human credentials replaced with dedicated agent identities during any namespace-separation remediation sweep, with completion dates and responsible owners" ], "machine_tests": [ "Attempt to authenticate to an agent-designated service using a human user credential from the human namespace \u2192 assert identity provider returns 401 with error_code=namespace_violation", "Attempt to provision an agent credential bearing a human UPN or display name in the human identity namespace \u2192 assert provisioning pipeline rejects with error_code=namespace_conflict", "Query 24 hours of authentication events from the SIEM and filter for events where principal_type field is absent or null \u2192 assert zero results returned" ], "human_review": [ "Review identity provider namespace configuration to confirm separation is structural (OU boundary, directory partition, or distinct identity domain) rather than conventional (naming prefix only), which cannot be technically enforced", "Inspect access review workflows to verify agent identities are processed in a separate certification track with agent-appropriate review criteria rather than being included in the human identity access review campaign", "Verify that SIEM behavioral analytics and anomaly detection models are trained and evaluated separately for human and non-human authentication event populations to prevent baseline contamination" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Using naming conventions such as 'svc-agentname' in a shared human directory as a proxy for namespace separation, which provides no technical enforcement and drifts silently as naming practices change", "Granting human-inherited permission sets to agent accounts for convenience rather than defining purpose-specific authorization scopes, creating privilege levels far exceeding the agent's legitimate capability boundary", "Sharing service account credentials between human users for emergency access and AI agent operations simultaneously, destroying attribution for all actions taken during the shared-use period", "Running UEBA and anomaly detection models on merged human and non-human event streams, producing baseline contamination that degrades anomaly detection fidelity for both populations", "Exempting legacy or operationally sensitive agents from namespace separation without a time-bounded compensating control, creating permanent gaps in the separation posture" ], "update_status": "current", "layer_code": "II" }, { "id": "II-06", "layer": "II", "plane": "control", "name": "Accountable Owner Binding", "plain": "Each AI agent identity must have a named, accountable human owner bound to it at provisioning time. Ownership must be re-attested annually at minimum. Agents whose ownership lapses must be automatically suspended until re-attestation is completed. The owner record must include contact information and the authority basis for the owner's ability to authorize the agent's actions.", "threat": { "tags": [ "orphaned-credential", "org-change-lag" ], "desc": "AI agent identities without named human owners accumulate over time as teams reorganize, staff turn over, and projects are deprioritized. Orphaned agents retain their access rights indefinitely because no one is responsible for deprovisioning them, and access review processes typically lack the organizational context to identify who should be accountable. These orphaned identities become persistent access vectors: an attacker who discovers an unmonitored agent with broad permissions has access without any risk of detection through normal ownership-review channels." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63-4 (by analogy)", "title": "Subscriber accountability applied by analogy to agent owner binding" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Reference architecture and requirements \u2014 accountability for identity information" }, { "id": "scim", "section": "RFC 7643 \u00a74.3", "title": "Enterprise User extension \u2014 manager attribute" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-06 Accountable Owner Binding control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/II-06 Accountable Owner Binding control.", "reviewed_on": "2026-07-02" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/II-06 Accountable Owner Binding control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-06 Accountable Owner Binding control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/II-06 Accountable Owner Binding control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Bind a named accountable owner to each agent identity at provisioning time using the SCIM manager attribute or an equivalent structured field. Implement an annual re-attestation workflow that sends the owner a renewal request; failure to respond within 30 days triggers automatic suspension. Integrate with HRIS to detect when an owner leaves the organization and trigger emergency re-assignment.", "steps": [ "Add owner_id, owner_email, owner_authority_basis, and owner_org_unit as required fields in the provisioning form; the owner must be a named individual (not a group or role alias) with explicit authority to authorize the agent's actions per the enterprise's AI governance policy; validate the owner record against HRIS at provisioning time to confirm the individual is an active employee.", "Integrate the identity registry with HRIS through a daily sync event; when an owner's employment status changes to inactive, automatically create a re-assignment task assigned to the owner's manager and set the agent's lifecycle_status to 'ownership-pending'; if re-assignment is not completed within 14 days, automatically set lifecycle_status to 'suspended' and disable the agent's credentials.", "Implement an annual re-attestation workflow: 90 days before the attestation anniversary, send the owner an automated notification listing all agents they own and requesting confirmation that each is still active, properly scoped, and under their accountability; if no response is received within 30 days of the deadline, set the agent to 'suspended' and notify the owner's manager.", "Publish an owner dashboard in the IAM portal that shows each owner their full agent inventory, the last attestation date, the upcoming attestation deadline, and any agents currently in 'ownership-pending' or 'suspended' status due to ownership gaps; make this dashboard accessible to the owner's manager as a delegation view." ], "anti_patterns": [ "Assigning ownership to a group email alias or shared distribution list \u2014 group ownership means no individual is accountable and re-attestation reminders are easily ignored.", "Allowing a manager to attest ownership for all of their direct reports' agents in bulk without reviewing individual agents \u2014 bulk attestation defeats the purpose of individual ownership confirmation.", "Not integrating with HRIS \u2014 ownership binding without real-time awareness of employment changes means orphaned agents go undetected for the full annual cycle." ] }, "validation": { "design_check": [ "Verify that the provisioning form requires a named individual as owner_id (not a group alias) and validates the owner against HRIS before completing provisioning.", "Confirm that the HRIS integration triggers are defined and tested for the employment-status-change scenario.", "Validate that the re-attestation workflow sends notifications 90 days before the deadline and escalates to the owner's manager if no response is received." ], "runtime_test": [ "Simulate a manager departure in a test environment and confirm that the affected agents are placed in 'ownership-pending' status within one HRIS sync cycle.", "Allow one agent's re-attestation deadline to pass in a test environment and confirm it is automatically suspended.", "Attempt to provision an agent without a valid owner_id and confirm the provisioning form rejects the submission." ], "evidence": [ "owner-binding-export:Registry export showing owner_id, owner_email, and last_attested_at for all active agents [unverified]", "hris-sync-log:30-day log of HRIS integration events showing ownership re-assignment triggers [unverified]", "attestation-completion-rate:Annual re-attestation completion statistics for the prior cycle, including suspension counts and resolution times [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Accountable owner binding is the operational mechanism that prevents the accumulation of orphaned agent identities. The binding is only meaningful if it is enforced through automated workflows tied to real organizational data \u2014 HRIS integration is the difference between a control that works and one that is aspirational.", "actions": [ "Implement the HRIS integration as an event-driven process (webhook or daily batch) rather than relying on manual owner updates.", "Build the re-attestation workflow into the IAM platform so that it runs automatically rather than requiring a manual campaign each year.", "Create a reporting view that shows owner binding health across the entire agent fleet: percentage of agents with current attestation, agents in ownership-pending status, and agents approaching attestation deadline." ], "failure_signals": [ "Agents in the registry with owner_id pointing to an inactive HRIS record.", "No re-attestation events recorded in the prior 12 months for agents that have been active for more than a year." ] }, "security_architect": { "summary": "Accountable owner binding is the governance mechanism that ensures every AI agent has a human responsible for its lifecycle. Without it, the proliferation of AI agents in an enterprise outpaces the governance team's ability to track them, and the access review process has no organizational anchor for identifying who should be asked 'does this agent still need this access?'", "actions": [ "Specify that owner binding verification is a required step in the agent access review process, not just in the provisioning workflow.", "Design the SIEM to alert on agents that have been in 'suspended' status for more than 30 days \u2014 these represent unresolved ownership gaps that require escalation.", "Include orphaned agent count as a metric in the quarterly security posture review." ], "failure_signals": [ "Agents with lifecycle_status=active and no re-attestation event in more than 13 months.", "Agents in 'ownership-pending' status for more than 14 days without escalation." ] }, "legal_counsel": { "summary": "Accountable owner binding creates the human accountability chain that is essential for legal and regulatory purposes. When an AI agent takes a high-consequence action, the ability to immediately identify the named individual responsible for that agent and the documented basis for their authority is a fundamental element of governance defensibility.", "actions": [ "Confirm that the owner_authority_basis field references the enterprise policy or governance document that grants the owner authority to deploy agents with the specified capability scope.", "Verify that ownership re-attestation records are retained as part of the governance documentation package for each agent.", "Assess whether any industry-specific regulations require documented human accountability for AI system operations in the enterprise's operating sectors." ], "failure_signals": [ "Agents with owner_authority_basis fields that reference informal arrangements rather than documented policy.", "No ownership record available for an agent involved in a high-consequence incident." ] }, "grc_auditor": { "summary": "Accountable owner binding is the control that makes agent access reviews meaningful \u2014 without a named owner to attest continued business need, access reviews for agent identities are either skipped or rubber-stamped. Audit focus is on whether ownership is current, whether HRIS integration is functioning, and whether re-attestation completion rates are acceptable.", "actions": [ "Request a registry export and identify any agents with owner_id pointing to an inactive HRIS record or with last_attested_at more than 13 months ago.", "Review the re-attestation completion rate for the most recent annual cycle and identify whether any agents with lapsed attestation continued to operate without suspension.", "Sample 10 owner records and verify that the owner_authority_basis field references a specific, current policy document." ], "metrics": [ "Owner binding currency rate: percentage of agents with a current, active owner (target: 100%).", "Attestation completion rate: percentage of annual re-attestations completed before the suspension deadline (target: >95%)." ], "failure_signals": [ "Agents with active credentials whose owner record points to an inactive employee.", "Annual re-attestation completion rate below 90%, indicating the workflow is not functioning effectively." ] }, "it_operations": { "summary": "Accountable owner binding provides the first point of contact for operational issues with an agent: the owner is the person to call when an agent's behavior is unexpected or when a deprovisioning request needs human confirmation. Keeping the owner record current is an operational prerequisite for effective incident response.", "actions": [ "Include the owner's contact information in the operations runbook for each AI agent deployment.", "Configure automated alerts to the owner (and their manager as a secondary contact) for critical agent failures, not just to a generic operations queue.", "Include owner record currency in the quarterly agent health check process." ], "failure_signals": [ "Incidents where the responding engineer cannot reach the documented owner because the contact information is stale.", "Deprovisioning requests stuck in queue because the owner is no longer with the organization and no successor is recorded." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many enterprises track agent ownership in informal documentation or wikis without HRIS integration or automated re-attestation. Target state requires structured owner binding in the registry with automated lifecycle management tied to HRIS." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "HR Integration", "Service Owners" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 (applied by analogy)", "fit": "partial", "rationale": "SP 800-63-4's subscriber accountability model assumes a human subject behind every digital identity. Because the suite scopes out NPEs, II-06 supplies the equivalent accountability for AI agents by binding every agent identity to a named accountable human owner \u2014 applied by analogy, not as a direct 800-63 requirement.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015 specifies requirements and a reference architecture for identity information management, including assignment of responsibility for managed identity information; II-06 implements that accountability by binding each AI agent identity to a named human owner.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC 7643 \u00a74.3", "fit": "supporting", "rationale": "SCIM's Enterprise User schema extension (RFC 7643 \u00a74.3) defines the manager attribute, which can represent owner binding for non-human identities in a standards-compatible way.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta for AI Agents \u2014 Owner Binding", "rationale": "Okta for AI Agents requires assignment of a human accountable owner to every registered agent identity in Universal Directory; ownership is a mandatory attribute and governance workflows (access certifications, access reviews) route to the named owner for approval or certification. Agents without a valid owner mapping are flagged by ISPM as governance violations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta for AI Agents makes a human accountable owner a mandatory attribute and routes certification workflows to that owner - the binding required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Tagging \u2014 Resource Owner Tags", "rationale": "AWS IAM resource tagging best practices require Owner, Team, and Application tags on all IAM roles to bind them to accountable human teams. AWS Organizations Service Control Policies can mandate tag compliance at role creation, and AWS Config rules can detect and alert on roles missing mandatory ownership tags, providing automated owner-binding enforcement.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Owner tags bind an accountable team, but free-text tags lack HRIS verification and auto-suspend-on-lapse enforcement the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 AI governance policies (Document who approves agent deployments)", "fit": "partial", "rationale": "Governance documents deployment approvers/ownership. Partial: doc assigns organizational approval accountability, not a per-identity accountable-owner binding.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every active AI agent identity in the registry must have a named, active individual human owner with a documented authority basis referencing a specific governance policy, verified active via HRIS. Agents whose owner's employment status becomes inactive must automatically enter ownership-pending status within one HRIS sync cycle and must be suspended within 14 days if ownership is not re-assigned.", "evidence_required": [ "registry_owner_binding_export showing owner_id, owner_email, owner_authority_basis, owner_org_unit, and last_attested_at for all active agents, with zero entries referencing inactive HRIS records", "hris_integration_event_log covering 30 days of employment-status-change events and the resulting ownership-pending or re-assignment triggers fired for affected agents", "annual_re_attestation_completion_report showing completion rates, suspension counts, mean time to re-activation, and any agents that operated past their suspension deadline without resolution", "owner_authority_basis_sample showing 10 randomly selected owner records with specific references to named, current governance policy documents that grant authorization authority" ], "machine_tests": [ "Attempt to submit a provisioning form without a valid owner_id field populated \u2192 assert provisioning API rejects with error_code=owner_required", "Set a test agent owner's HRIS employment status to inactive \u2192 assert agent lifecycle_status transitions to ownership-pending within one HRIS sync cycle (max 24 hours)", "Allow an annual re-attestation deadline to lapse for a test agent in a staging environment \u2192 assert agent is automatically suspended and owner's manager receives escalation notification" ], "human_review": [ "Review a sample of 10 agent registry entries and assess whether the owner_authority_basis field references a specific, current, named governance policy rather than informal authorization or verbal agreement", "Examine the annual re-attestation completion statistics for the most recent cycle to determine whether completion rates exceed 95% and whether any agents with lapsed attestation continued operating beyond the suspension deadline", "Verify that the HRIS integration event log shows correct handling of edge cases including simultaneous departures, interim management assignments, and role transfers without creating unclosed ownership gaps" ], "blocking_effect": "requires-review", "normative_status": "voluntary-standard", "anti_patterns": [ "Assigning ownership to a group email alias or shared distribution list rather than a named individual, making no single person accountable and allowing re-attestation reminders to be collectively ignored", "Permitting bulk attestation where a manager confirms all of their direct reports' agents in a single click without reviewing each agent's current scope and continued business need", "Operating without HRIS integration, which means owner departures are only detected at the next annual re-attestation cycle rather than within one sync cycle of the employment status change", "Recording owner_authority_basis as a free-text field referencing informal arrangements, verbal approvals, or generic team mandates rather than a structured reference to a specific governance policy document", "Allowing agents to remain active past the 14-day suspension deadline due to operational pressure without executive sign-off and a documented compensating control with a time-bound remediation plan" ], "update_status": "current", "layer_code": "II" }, { "id": "II-07", "layer": "II", "plane": "control", "name": "Identity Metadata, Capability Manifest and Artifact Binding", "plain": "Each AI agent's identity must be cryptographically bound to a signed capability manifest that records the agent's model version, tool set, system prompt hash, and deployment artifact hash. Any change to these components must trigger a new identity provisioning event. The identity must not survive an artifact change without explicit re-attestation.", "threat": { "tags": [ "identity-spoofing", "credential-compromise" ], "desc": "AI agent identities that are not bound to specific deployment artifacts create the 'same name, different agent' vulnerability: an identity authorized for one model version and tool configuration continues to authenticate after a model update or tool addition has materially changed the agent's capabilities. An attacker who can influence a deployment pipeline can introduce capability changes that are not reflected in the identity record, allowing the modified agent to act under the prior version's authorization scope. Artifact binding ensures that what the identity record says the agent is matches what is actually running." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63-4 (by analogy)", "title": "Attribute integrity applied by analogy to capability manifests" }, { "id": "openid", "section": "JWT claims", "title": "Claims in JWT for identity metadata" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 1", "title": "All data sources and computing services are resources" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/II-07 Identity Metadata, Capability Manifest and Artifact Binding control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/II-07 Identity Metadata, Capability Manifest and Artifact Binding control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/II-07 Identity Metadata, Capability Manifest and Artifact Binding control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-07 Identity Metadata, Capability Manifest and Artifact Binding control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/II-07 Identity Metadata, Capability Manifest and Artifact Binding control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "At provisioning time, generate a signed capability manifest that includes model_id, model_version, tool_set_hash, system_prompt_hash, and deployment_artifact_hash. Store the manifest in the registry and include its hash in the agent's credential (e.g., as a custom claim in the JWT or as an extension in the X.509 certificate). Any change to a manifest field triggers an automatic re-provisioning event.", "steps": [ "Define the capability manifest schema with required fields: model_id, model_version, tool_set (array of tool identifiers with versions), system_prompt_hash (SHA-256 of the system prompt text), deployment_artifact_hash (SHA-256 of the container image digest or deployment package hash), and a manifest_version counter; generate the manifest at build time in the CI/CD pipeline and sign it with the pipeline's signing key.", "Store the signed capability manifest in the identity registry as an attribute of the agent's registry entry; include the manifest_hash (SHA-256 of the entire signed manifest) as a custom claim in the agent's JWT access token or as an OID extension in its X.509 certificate, so that relying parties can verify that the presenting agent matches its registered capability profile.", "Implement a deployment gate that computes the deployment_artifact_hash of the container image or package immediately before deployment and compares it to the hash stored in the registry; if the hashes do not match, block the deployment and create an incident \u2014 this catches unauthorized modifications between the build pipeline and the deployment environment.", "Configure the provisioning system to monitor capability manifest fields for changes; any update to model_version, tool_set, or system_prompt must trigger an automatic re-provisioning workflow that requires the accountable owner to approve the new capability manifest before new credentials are issued \u2014 the old credential is revoked at re-provisioning completion, not before, to avoid unintended availability impact." ], "anti_patterns": [ "Using the agent's name or display name as the identity anchor rather than artifact hashes \u2014 names are human-managed labels that can be reassigned to a different artifact without triggering any identity event.", "Treating capability manifest updates as a configuration change rather than an identity event \u2014 this allows capability creep without identity governance review.", "Storing capability manifest hashes in the registry but not including them in the issued credential \u2014 relying parties cannot verify the match without the claim in the token." ] }, "validation": { "design_check": [ "Verify that the capability manifest schema includes all required fields and that the manifest is signed with a key whose public component is registered in the enterprise's artifact signing trust store.", "Confirm that the deployment gate computes and compares artifact hashes before deployment and that the gate failure mode is 'block deployment' rather than 'log warning'.", "Validate that the provisioning system has event triggers defined for changes to each capability manifest field." ], "runtime_test": [ "Deploy a modified container image (different tag, same agent name) without updating the registry and confirm the deployment gate blocks it.", "Present a credential referencing the prior capability manifest to a relying party that verifies manifest_hash claims and confirm the request is rejected.", "Update the system prompt for an agent and confirm that a re-provisioning workflow is automatically triggered." ], "evidence": [ "capability-manifest-registry:Export of all capability manifests from the registry with signature verification status [unverified]", "deployment-gate-log:90-day log of deployment gate checks showing hash comparison results and any blocked deployments [unverified]", "re-provisioning-events:Log of re-provisioning events triggered by capability manifest changes in the prior quarter [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Capability manifest binding changes the identity model from 'this name maps to this credential' to 'this specific artifact, with this specific capability profile, maps to this credential.' It requires close coordination with ML engineering and DevOps to ensure that every artifact change flows through the identity governance pipeline rather than bypassing it.", "actions": [ "Define the capability manifest schema and the signing key infrastructure in collaboration with ML engineering and platform engineering before the first agent is deployed under this control.", "Build the re-provisioning trigger into the CI/CD pipeline as a webhook or event subscription on the container registry or artifact store.", "Create a policy that explicitly states which capability manifest fields trigger a full re-provisioning (requiring owner approval) versus a simple hash update (automatically applied)." ], "failure_signals": [ "Agents in production with registry entries that reference deployment artifact hashes different from the currently running image digest.", "Model version updates deployed without triggering re-provisioning events." ] }, "security_architect": { "summary": "Capability manifest binding is the control that prevents the identity governance layer from becoming decoupled from the deployment reality. Without it, an identity access review might affirm that 'this agent is authorized to do X' while the deployed artifact has been updated to a version with different capabilities that were never reviewed.", "actions": [ "Specify that the deployment gate hash comparison is a required quality gate in the CI/CD pipeline and that bypassing it requires CISO-level approval with documented justification.", "Design the re-provisioning workflow to require a security review of the capability diff (what changed between the prior and new manifest) as part of the approval process.", "Include capability manifest binding verification in the annual AI agent security review." ], "failure_signals": [ "CI/CD pipelines with deployment gate bypass procedures that do not require CISO approval.", "No capability diff review step in the re-provisioning approval workflow." ] }, "legal_counsel": { "summary": "Capability manifest binding ensures that the authorization record for an AI agent accurately reflects what the agent is capable of at the time it acted. This is critical for legal defensibility: if an agent performs an action that the enterprise asserts was unauthorized, the capability manifest provides evidence of whether the agent's authorization record included or excluded that capability at the relevant time.", "actions": [ "Confirm that re-provisioning events create immutable audit records capturing the prior and new capability manifest, the approver, and the timestamp.", "Verify that capability manifest records are retained as part of the evidence package for all high-consequence agent actions.", "Assess whether the enterprise's AI governance policy requires capability manifest review as part of the approval process for new agent deployments." ], "failure_signals": [ "No immutable record of capability manifest history for an agent involved in a disputed action.", "Re-provisioning events that do not capture the approver identity." ] }, "grc_auditor": { "summary": "Capability manifest binding is the control that ensures the identity registry accurately reflects what is actually deployed. Audit focus is on whether the registry hashes match the running artifacts, whether re-provisioning is triggered by capability changes, and whether the deployment gate is enforced without exception.", "actions": [ "Sample 10 running agents and compare the deployment_artifact_hash in the registry against the actual container image digest in the runtime environment.", "Review the re-provisioning event log for the prior quarter and identify any model version updates or system prompt changes that did not trigger a re-provisioning event.", "Request the deployment gate bypass log and review any instances where the hash comparison was skipped or overridden." ], "metrics": [ "Artifact hash currency rate: percentage of agents where the registry deployment_artifact_hash matches the running image digest (target: 100%).", "Capability change re-provisioning rate: percentage of detected capability changes that triggered a re-provisioning event (target: 100%)." ], "failure_signals": [ "Any agent where the registry hash does not match the running artifact.", "Deployment gate bypasses that were not reviewed and approved through the defined exception process." ] }, "it_operations": { "summary": "Capability manifest binding means that deploying a new model version or updating an agent's tool configuration requires an identity re-provisioning event, not just a container restart. Operations teams need to include identity re-provisioning in the deployment runbook for any agent update that changes model version, tools, or system prompt.", "actions": [ "Update the agent deployment runbook to include a step checking whether the planned change affects a capability manifest field and, if so, initiating the re-provisioning workflow before deploying.", "Monitor for deployment gate failures in the CI/CD pipeline and route alerts to the platform engineering team immediately \u2014 a hash mismatch may indicate an unauthorized change.", "Include capability manifest hash verification in the post-deployment smoke test for all agent deployments." ], "failure_signals": [ "Agent deployments proceeding without a capability manifest check step in the deployment runbook.", "Deployment gate failure alerts not reaching the platform engineering team within 15 minutes of the event." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Capability manifest binding does not exist in most enterprise identity governance programs today. Initial state requires defining the manifest schema and integrating with the provisioning pipeline; defined state requires automated re-provisioning triggers on artifact changes." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "ML Engineering", "DevOps" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 (applied by analogy)", "fit": "partial", "rationale": "SP 800-63-4 requires that attributes bound to a digital identity be established and maintained accurately. The suite scopes out NPEs, so II-07 applies that attribute-integrity discipline by analogy to AI agent capability manifests and deployment artifact bindings.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 1", "fit": "supporting", "rationale": "SP 800-207 \u00a72.1 Tenet 1 treats every data source and computing service as a resource that must be identified and governed; binding a capability manifest and deployment artifact to each agent identity gives the enterprise the resource-level knowledge that tenet presumes.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta for AI Agents \u2014 Capability Manifest", "rationale": "Okta for AI Agents stores capability manifests and deployment artifact hashes as structured attributes in Universal Directory alongside each registered agent identity. Policy engines can reference these declared capabilities at authorization time to enforce that agent actions are consistent with the registered capability scope.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta for AI Agents stores signed capability manifests and deployment-artifact hashes as structured attributes referenced at authorization.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Tagging \u2014 Principal Tags", "rationale": "AWS IAM principal tags attached to roles serve as lightweight capability manifests; policy conditions referencing principal tags (aws:PrincipalTag/Capability, aws:PrincipalTag/ArtifactHash) allow enforcement engines to validate declared purpose at authorization time. This tag-based approach binds the IAM role to its declared deployment artifact.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "AWS principal tags can carry a few attributes but are not a signed capability manifest with model/prompt/artifact hashes or reprovisioning semantics.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 \u2014 Approved/prohibited actions; Part IV Phase 3 \u2014 Assign a unique identity", "fit": "partial", "rationale": "Doc pairs each unique agent identity with documented permitted/denied actions (capability boundaries). Partial: doc does not prescribe binding a signed capability manifest/artifact to the identity record.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/II-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every deployed AI agent must have a signed capability manifest in the identity registry whose deployment_artifact_hash matches the SHA-256 digest of the currently running container image or deployment artifact. Any change to model_id, model_version, tool_set, or system_prompt_hash must trigger a mandatory re-provisioning workflow requiring owner approval before the modified artifact is permitted to authenticate.", "evidence_required": [ "capability_manifest_registry_export showing signed manifests for all active agents with signature_verified status, model_id, model_version, tool_set_hash, system_prompt_hash, and deployment_artifact_hash for each", "deployment_gate_log covering 90 days of artifact hash comparison results at deployment pipeline execution time, including the disposition of any blocked deployments and bypass exceptions", "re_provisioning_event_log for the prior quarter showing all re-provisioning events triggered by capability manifest field changes, with approver identities, capability diffs, and timestamps", "live_artifact_hash_comparison_report comparing the deployment_artifact_hash stored in the registry against the actual running container image digest for all current production agents" ], "machine_tests": [ "Deploy a modified container image with a different image digest without updating the registry manifest \u2192 assert deployment gate blocks with error_code=artifact_hash_mismatch", "Present a credential containing a manifest_hash claim referencing the prior capability manifest version to a relying party configured to verify manifest claims \u2192 assert request is rejected with error_code=capability_manifest_mismatch", "Update an agent's system prompt in the configuration store without initiating re-provisioning \u2192 assert the provisioning monitoring system detects the system_prompt_hash change and automatically triggers a re-provisioning workflow" ], "human_review": [ "Sample 10 running agents and manually compare the deployment_artifact_hash in the registry against the actual container image digest reported by the runtime environment to verify registry accuracy", "Review the re-provisioning event log for the prior quarter to identify any model version updates, tool set changes, or system prompt modifications that were deployed without a corresponding re-provisioning event", "Assess the capability diff review step in the re-provisioning approval workflow to confirm a security assessment of what changed between the prior and new manifest is required as part of the approval process" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Using the agent's display name or service label as the identity anchor rather than cryptographic artifact hashes, allowing capability-changing updates to proceed without triggering identity governance review", "Treating capability manifest field updates as routine configuration changes rather than identity governance events requiring owner approval, which allows capability creep outside the authorization boundary", "Storing capability manifest hashes in the identity registry but not including the manifest_hash as a claim in issued credentials, preventing relying parties from verifying that the presenting agent matches its registered capability profile", "Scoping capability manifest binding only to model_version changes while omitting tool_set and system_prompt changes, which can equally materially alter what the agent is capable of doing", "Permitting deployment gate bypass without requiring CISO-level approval and documented justification, creating an enforcement gap that can be exploited under operational pressure" ], "update_status": "current", "layer_code": "II" }, { "id": "II-08", "layer": "II", "plane": "control", "name": "Identity Registry Integrity and Tamper Evidence", "plain": "The AI agent identity registry must enforce append-only semantics with a cryptographic hash chain, forward every write to an external immutable audit log, and record the identity of the modifying principal for every registry change. Any modification to a registry record must be detectable and attributable.", "threat": { "tags": [ "identity-spoofing", "orphaned-credential" ], "desc": "An identity registry that can be silently modified is not a trustworthy source of truth \u2014 it is a liability. An attacker who gains write access to a mutable registry can alter an agent's authorization scope, replace capability manifest hashes, or remove an agent's entry entirely to erase evidence of its existence. Hash-chained, append-only registries make these modifications detectable: any tampering breaks the hash chain, producing an inconsistency that can be detected by an independent verifier. External audit log forwarding ensures that even if the registry itself is compromised, the record of changes survives in a system the attacker may not control." }, "standard": [ { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Reference architecture and requirements \u2014 audit and integrity of identity records" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 7", "title": "Collect information about current asset state to improve posture" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Audit log integrity and immutability" } ], "sources": [ { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/II-08 Identity Registry Integrity and Tamper Evidence control.", "reviewed_on": "2026-07-02" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/II-08 Identity Registry Integrity and Tamper Evidence control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/II-08 Identity Registry Integrity and Tamper Evidence control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/II-08 Identity Registry Integrity and Tamper Evidence control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/II-08 Identity Registry Integrity and Tamper Evidence control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement the registry as an append-only store where updates create new versioned records rather than overwriting existing ones. Maintain a hash chain over the sequence of registry records so that any insertion, deletion, or modification outside the defined write API breaks the chain. Forward all write events to an external SIEM or immutable log store in real time. Record the modifying principal's identity on every write event.", "steps": [ "Design the registry data model with an immutable record structure: each entry has an entry_id, a version counter, a prev_hash (SHA-256 of the prior entry for the same agent), and a hash of the current entry's content; the registry API enforces that writes always increment the version counter and compute the chain hash \u2014 there is no update-in-place operation in the API surface.", "Configure WORM (Write Once, Read Many) storage for the registry backend, or implement append-only enforcement at the database level (e.g., PostgreSQL row security policies that prohibit DELETE and UPDATE operations for all roles except a restricted archive role); run a periodic integrity check that recomputes the hash chain from the beginning and alerts on any break.", "Integrate the registry write API with the enterprise SIEM using a real-time event stream (Kafka, AWS Kinesis, or equivalent); each write event payload must include: event_time, event_type (create/update/suspend/delete), modifying_principal_id, agent_id, prior_entry_hash, and new_entry_hash; the SIEM must alert on any write event where modifying_principal_id is not a recognized provisioning service account.", "Implement a daily registry integrity verification job that is run by a separate service account with read-only access to the registry; the job recomputes the hash chain for all entries and publishes a signed integrity report to the SIEM; if the chain verification fails for any agent's entry history, the job triggers a P1 incident." ], "anti_patterns": [ "Relying on database access controls alone for registry integrity \u2014 access controls can be bypassed by a sufficiently privileged attacker or through a misconfiguration; cryptographic integrity is the defense-in-depth mechanism.", "Forwarding audit events to a log store that is accessible from the same credential set as the registry \u2014 a compromised registry credential would also allow log tampering.", "Running the integrity verification job under the same service account as the provisioning service \u2014 compromise of the provisioning credential would disable tamper detection." ] }, "validation": { "design_check": [ "Verify that the registry API has no update-in-place or delete operations \u2014 all changes must create new versioned records with hash chain linkage.", "Confirm that the audit log destination is an external SIEM or log store with a separate credential and access boundary from the registry service.", "Validate that the integrity verification job uses a read-only credential that is separate from the provisioning credential." ], "runtime_test": [ "Attempt to issue an UPDATE or DELETE statement directly against the registry database and confirm the operation is rejected by row security policies or storage-level WORM enforcement.", "Modify one registry entry's content in a test environment using direct database access and run the integrity verification job to confirm the hash chain break is detected and alerts are fired.", "Simulate a write event with an unrecognized modifying_principal_id and confirm the SIEM alert fires within one alert latency window." ], "evidence": [ "hash-chain-integrity-report:Most recent signed integrity verification report showing chain validity for all registry entries [unverified]", "audit-log-export:30-day export of registry write events from the external SIEM showing modifying_principal_id for all write events [unverified]", "storage-worm-policy:Database or storage layer configuration showing append-only or WORM enforcement for the registry backend [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Registry integrity is the control that makes the identity registry trustworthy as a source of truth. If the registry can be silently modified, every control that depends on it \u2014 assurance level enforcement, capability manifest verification, owner binding \u2014 is only as reliable as the registry's own integrity. Hash chaining and external audit forwarding are the technical mechanisms that make tampering detectable rather than invisible.", "actions": [ "Design the registry write API with no delete or update-in-place operations from the start \u2014 retrofitting append-only semantics onto a mutable store is significantly harder than building correctly initially.", "Select the external audit log destination before implementing the write API so that the audit forwarding is wired in at the point of first write, not added later.", "Automate the integrity verification job and include its result in the IAM team's weekly health dashboard." ], "failure_signals": [ "Registry entries with no prev_hash linking them to prior versions \u2014 indicating in-place modification.", "Gaps in the audit log sequence for write events \u2014 indicating events that were not forwarded or were deleted." ] }, "security_architect": { "summary": "Registry tamper evidence is the foundational control that makes the entire II-layer trustworthy under adversarial conditions. An attacker who can modify the registry silently can undermine every downstream control. The architecture must treat the registry as a high-value target and apply defense-in-depth: append-only storage, cryptographic hash chain, external audit forwarding, and independent integrity verification.", "actions": [ "Classify the identity registry as a critical security system in the enterprise's security architecture and apply the corresponding hardening requirements: privileged access management, dedicated service accounts, and network micro-segmentation.", "Specify that the external audit log destination for registry write events must be in a separate security domain from the registry \u2014 ideally a managed SIEM with independent access controls.", "Include registry integrity verification coverage in the annual penetration test scope." ], "failure_signals": [ "Registry service account with write access to the SIEM or audit log destination \u2014 this allows covering tracks after tampering.", "Registry integrity verification not included in the last annual penetration test scope." ] }, "legal_counsel": { "summary": "Registry integrity is the foundation of the evidentiary value of identity records. If a registry record can be modified without detection, it cannot be reliably used as evidence of what an agent was authorized to do at a given time. Append-only semantics with hash chain verification provides the technical basis for asserting that a registry record has not been altered since it was written.", "actions": [ "Confirm that the hash chain integrity verification and audit log export are included in the enterprise's standard evidence preservation procedures for AI governance.", "Verify that the registry retention policy specifies that append-only records are never deleted, including after an agent is deprovisioned \u2014 historical records must be retained for the full legal retention period.", "Assess whether the hash chain integrity methodology is documentable in terms that would be comprehensible to a fact-finder in a legal or regulatory proceeding." ], "failure_signals": [ "Registry records for deprovisioned agents deleted rather than marked inactive \u2014 eliminating historical evidence.", "No documented description of the hash chain methodology that could be explained to a non-technical fact-finder." ] }, "grc_auditor": { "summary": "Registry tamper evidence is an auditable control: the hash chain provides a verifiable integrity proof, and the external audit log provides an independent record of who changed what and when. Audit focus is on whether the integrity verification is running and producing clean results, and whether the audit log destination is truly independent from the registry.", "actions": [ "Request the most recent hash chain integrity report and verify it was signed by the verification service's credential and shows no chain breaks.", "Confirm that the external audit log destination has separate access controls from the registry and that the registry service account does not have write or delete access to the audit log.", "Sample 15 registry write events from the external audit log and verify that each records a recognized modifying_principal_id." ], "metrics": [ "Registry integrity pass rate: percentage of daily integrity checks completed without chain break detection (target: 100%).", "Audit log completeness: percentage of registry write events confirmed present in the external audit log via reconciliation (target: 100%)." ], "failure_signals": [ "Any hash chain integrity check failure in the prior quarter that was not resolved within the defined SLA.", "Write events present in the registry but absent from the external audit log \u2014 indicating forwarding failures or potential tampering." ] }, "it_operations": { "summary": "Registry integrity verification is an operational dependency: if the daily integrity job fails silently, tamper events go undetected. Operations teams must monitor the integrity verification job as a production health indicator and treat a failed run with the same urgency as a primary database health alert.", "actions": [ "Add the integrity verification job's completion status and result to the production monitoring dashboard.", "Configure a P1 alert for any failed or incomplete integrity verification run, routing to the security operations team rather than the general operations queue.", "Include the registry audit log forward rate (events successfully forwarded vs. events written) as a real-time metric in the operations dashboard." ], "failure_signals": [ "Integrity verification job silently failing for multiple days without alerting.", "Audit log forward rate dropping below 100% without a triggered alert." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprise identity registries are mutable databases with no cryptographic integrity mechanism. Target state requires append-only semantics with hash chain, external audit forwarding, and automated integrity verification." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IAM Team", "Security Operations", "Platform Engineering" ], "frameworks": [ { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015 includes requirements for audit and for maintaining the integrity of identity information in an identity management system; II-08's tamper-evident registry implements those requirements for AI agent identity records.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 7", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 7 has the enterprise collect as much information as possible about asset state and use it to improve security posture; registry integrity and external audit forwarding keep that collected identity information trustworthy.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "fit": "supporting", "rationale": "The CISA ZTMM Visibility and Analytics cross-cutting capability requires reliable, tamper-evident audit visibility; this control applies that requirement to the identity registry specifically.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail \u2014 Log File Integrity", "rationale": "AWS CloudTrail log file integrity validation uses SHA-256 hashing of each log file and RSA-2048 signing of digest files that reference those hashes, providing cryptographic proof that IAM provisioning event logs have not been tampered with after delivery. The digest chain enables detection of any modification, deletion, or insertion of log records.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail log-file integrity (SHA-256 + RSA-signed digests) covers external audit-log tamper evidence, not the registry hash-chain itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Audit Logs \u2014 Immutable Admin Activity", "rationale": "Google Cloud Audit Logs Admin Activity logs record all IAM write operations (role bindings, policy changes, identity provisioning) and are immutable \u2014 they cannot be disabled or deleted by any customer user regardless of IAM permissions. Admin Activity logs are retained for 400 days in a Google-managed bucket, providing a tamper-evident, durable registry of all identity infrastructure changes.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP immutable Admin Activity logs provide the external tamper-evident audit trail but not the append-only hash-chained registry the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://identity/controls/II-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The identity registry must operate in append-only mode with a cryptographic hash chain linking every record version, such that any insertion, deletion, or out-of-band modification breaks the chain and is detectable by an independent integrity verification job. All write events must appear in an external immutable audit log with the modifying principal identified.", "evidence_required": [ "hash_chain_integrity_report: Signed output from the daily integrity verification job showing chain validity for every registry entry, with verification timestamp and verifying service account ID", "registry_write_event_log: 30-day export from external SIEM of all registry write events including event_time, event_type, modifying_principal_id, agent_id, prior_entry_hash, and new_entry_hash", "storage_worm_policy: Database or storage layer configuration document demonstrating append-only or WORM enforcement \u2014 no DELETE or UPDATE-in-place operations permitted on the registry backend", "audit_log_reconciliation_report: Reconciliation confirming that every registry write event recorded in the registry backend also appears in the external audit log (100% completeness target)", "integrity_job_service_account_policy: Evidence that the integrity verification job runs under a read-only credential separate from the provisioning service account" ], "machine_tests": [ "Issue a direct UPDATE statement against the registry database as the provisioning service account \u2192 assert the operation is rejected with a permission-denied error", "Issue a direct DELETE statement against a registry row in a test environment \u2192 assert the operation is rejected by row-security or storage-level policy", "Modify one registry entry's content field directly in the datastore and execute the integrity verification job \u2192 assert the job produces a chain-break alert and fires a P1 incident notification", "Simulate a registry write event with an unrecognized modifying_principal_id \u2192 assert the SIEM generates an alert within the defined alert-latency SLA" ], "human_review": [ "Review the registry API surface to confirm there are no undocumented update-in-place or delete endpoints that bypass append-only enforcement", "Assess whether the external audit log destination is in a separate security domain from the registry and that the provisioning credential does not have write or delete access to the audit log", "Verify that the hash chain integrity verification methodology is documented in terms clear enough to support explanation in a legal or regulatory proceeding" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Relying on database access controls alone for registry integrity without a cryptographic hash chain \u2014 access controls can be bypassed by a sufficiently privileged attacker, making tampering invisible", "Forwarding registry write events to a log store that is accessible with the same credential as the registry \u2014 a compromised registry credential would allow simultaneous log tampering", "Running the integrity verification job under the same service account as the provisioning service \u2014 compromise of the provisioning credential would disable tamper detection", "Marking registry records as 'deleted' via an in-place status field rather than creating a new versioned record \u2014 this breaks append-only semantics and destroys historical evidence", "Skipping hash chain verification for the initial registry bootstrap records on the assumption that early records are low-risk \u2014 this leaves the foundational chain unvalidated" ], "update_status": "current", "layer_code": "II" }, { "id": "NI-01", "layer": "NI", "plane": "control", "name": "Identity Provisioning Gate", "plain": "Every AI agent identity must pass through an explicit approval workflow before any credential is issued. Provisioning requires a named human sponsor, a declared task scope, a written justification, and \u2014 for personal-in-enterprise agents \u2014 dual approval cross-referenced with Authority PA-02.", "threat": { "tags": [ "orphaned-credential", "identity-spoofing" ], "desc": "Uncontrolled provisioning produces orphaned credentials: AI agents registered without human oversight persist beyond their intended lifecycle, accumulating valid identity artifacts with no owning principal responsible for their revocation. Any automated deployment pipeline that can register a new agent identity without approval can trivially impersonate a trusted agent, because the provisioning channel itself becomes the attack surface. Both failure modes \u2014 credential abandonment and spoofed registration \u2014 are preventable only by inserting a mandatory human-authorized gate before identity creation." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63A-4", "title": "Identity proofing requirements" }, { "id": "scim", "section": "RFC 7644 \u00a73.3", "title": "SCIM resource provisioning \u2014 POST request" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Identity Stores", "title": "Identity lifecycle management" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_nhi_top10_2025", "title": "OWASP Non-Human Identity Top 10 2025", "authority": "OWASP Foundation", "source_type": "standard", "normative_force": "best-practice", "version": "2025", "published_on": "2025-02-01", "retrieved_on": "2026-06-29", "canonical_url": "https://owasp.org/www-project-non-human-identities-top-10/", "license": "open-access", "status": "current", "flagship": false, "source_id": "owasp_nhi_2025", "relationship": "informative_reference", "rationale": "Establishes OWASP Non-Human Identity Top 10 2025 requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "id": "spiffe_spire_spec_1_0", "title": "SPIFFE and SPIRE Specification v1.0", "authority": "CNCF (Cloud Native Computing Foundation)", "source_type": "standard", "normative_force": "best-practice", "version": "1.0", "published_on": "2020-09-01", "retrieved_on": "2026-06-29", "canonical_url": "https://spiffe.io/docs/latest/spiffe-about/overview/", "license": "open-access", "status": "current", "flagship": false, "source_id": "spiffe_spire", "relationship": "informative_reference", "rationale": "Establishes SPIFFE and SPIRE Specification v1.0 requirements informing the apeiris://identity/controls/NI-01 Identity Provisioning Gate control.", "reviewed_on": "2026-07-01" }, { "source_id": "hashicorp_vault_aar_2026", "normative_force": "best-practice", "relationship": "implementation_pattern", "rationale": "Enterprise vault implementation of OAuth 2.0 RAR (RFC 9396) per-request agent authorization \u2014 provides concrete IaC patterns for the controls in this layer.", "reviewed_on": "2026-06-29" } ], "implementation": { "pattern": "Approval-gated provisioning workflow with mandatory justification and scope declaration. Personal-in-enterprise provisioning requires Authority PA-02 approval for enterprise scope before this gate can open. NI-01 enforces the provisioning gate; PA-02 is consulted for capability class authorization.", "steps": [ "Define a provisioning request schema requiring at minimum: principal type (workload, service, personal-in-enterprise), sponsoring human principal identifier, task scope expressed as a resource-and-action enumeration, written business justification, and requested credential lifetime with upper bound. Reject any request that omits a mandatory field before it enters the approval queue.", "Route all provisioning requests through a durable approval workflow. Workload and service agents require a single approver who holds provisioning authority for the declared scope. Personal-in-enterprise agents require dual approval: the direct manager of the sponsoring human and a second approver from the IAM team; the workflow must additionally verify that an Authority PA-02 capability class authorization exists for the requested enterprise scope before either approver can grant the request.", "On approval, emit a signed provisioning receipt that captures: approver identities and timestamps, the granted scope as a structured object, credential lifetime ceiling, and a reference to the PA-02 authorization record where applicable. Write the receipt to the identity audit log atomically with credential issuance \u2014 if the audit log write fails, the credential must not be issued.", "Enforce hard blocking conditions: reject the provisioning request and return a structured error if any mandatory schema field is absent, if the sponsoring principal's own provisioning authority does not cover the declared scope, if the credential lifetime requested exceeds the tier maximum (see NI-03), or if a personal-in-enterprise request lacks a valid PA-02 authorization reference." ], "anti_patterns": [ "Auto-provisioning AI agent identities at container or function deployment time without any human approval step, treating infrastructure deployment as implicit identity authorization.", "Accepting scope declarations such as 'full access', 'admin', or wildcard resource patterns \u2014 open-ended scopes defeat the purpose of the gate and propagate to NI-02 violations downstream.", "Treating CI/CD pipeline service account credentials as equivalent to provisioned agent identities and routing them around the approval gate on the grounds that the pipeline itself is already trusted." ] }, "validation": { "design_check": [ "Confirm the provisioning workflow enforces a dual-approval path for personal-in-enterprise agents and that neither approver can bypass the PA-02 cross-check step.", "Verify the provisioning request schema is enforced server-side and that client-submitted requests missing sponsoring principal, justification, or explicit scope are rejected with a 400-class error before entering the queue.", "Confirm the PA-02 consultation step is wired into the workflow engine such that the approval decision cannot be recorded until a valid PA-02 authorization reference is attached to personal-in-enterprise requests." ], "runtime_test": [ "Attempt to provision an agent identity via the API without supplying a sponsoring human principal identifier; verify the request is rejected before entering the approval queue and that no partial identity record is created.", "Submit a personal-in-enterprise provisioning request through the normal approval flow but omit the Authority PA-02 authorization reference; confirm the workflow blocks issuance even if both approvers grant the request.", "Complete a valid provisioning request end-to-end and verify that a signed provisioning receipt is written to the identity audit log before the credential token is returned to the caller \u2014 confirm the log entry references the approver identities and scope grant." ], "evidence": [ "approval-record:Signed provisioning approval record with approver identities, timestamps, and scope grant for each AI agent identity created in the review period [unverified]", "audit-log:Identity audit log entries linking each provisioning receipt to the credential subsequently issued, with no credentials present that lack a corresponding receipt [unverified]", "workflow-config:Provisioning workflow configuration export showing dual-approval rule enforced for personal-in-enterprise principal type and PA-02 cross-reference step enabled [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-01 is the IAM team's choke point for all agent identity creation. Every agent that enters the enterprise identity store must arrive through this gate \u2014 not through ad-hoc API calls, deployment scripts, or inherited service account cloning.", "actions": [ "Implement the provisioning request schema as a validated API endpoint; return structured validation errors on missing fields rather than silently defaulting.", "Wire the dual-approval workflow for personal-in-enterprise agents into your identity governance platform (e.g., SailPoint, Saviynt, or custom), ensuring the PA-02 lookup is a blocking pre-condition rather than an advisory check.", "Configure the audit log write to be synchronous with credential issuance \u2014 use a transactional write or a saga pattern so that a failed log write rolls back the credential grant." ], "failure_signals": [ "Credential records in the identity store that have no corresponding provisioning receipt in the audit log \u2014 indicates agents were created outside the gate.", "Approval workflow completion timestamps that post-date credential issuance timestamps \u2014 indicates the gate was bypassed and approval was back-filled." ] }, "security_architect": { "summary": "NI-01 closes the uncontrolled-registration attack surface at the identity plane. Without it, the provisioning channel is an unauthenticated write path into the trusted agent registry, and any principal with API access can instantiate a new trusted identity.", "actions": [ "Design the provisioning service as a separate trust boundary from the services that consume agent credentials \u2014 the provisioning endpoint should not be reachable from workload networks without explicit policy allowance.", "Specify the cross-domain handshake with Authority PA-02 in the architecture: define what constitutes a valid PA-02 authorization reference, how the provisioning service verifies it without creating a synchronous runtime dependency on the Authority domain, and how stale authorizations are detected.", "Model the threat scenarios for the dual-approval bypass: a compromised approver account, a compromised workflow engine, and a race condition between approval and credential issuance \u2014 document the mitigating controls for each." ], "failure_signals": [ "Provisioning service reachable from general workload networks without an explicit allow-list policy \u2014 indicates the registration attack surface is wider than the gate.", "No separation between the approval decision record and the credential issuance service, meaning a single compromised component can approve and issue without a second party." ] }, "legal_counsel": { "summary": "NI-01 creates a documented human authorization trail for every AI agent identity in the enterprise. This is the evidentiary foundation for demonstrating that AI system deployments were deliberately authorized \u2014 relevant to AI Act obligations, tort liability, and internal governance accountability.", "actions": [ "Confirm that provisioning receipts are retained for the full agent credential lifecycle plus the organization's legal hold period \u2014 these records may be required in litigation or regulatory inquiry.", "Verify that the sponsoring human principal field creates a clear line of human accountability: the sponsor is the responsible party if the agent causes harm, and this must be communicated to sponsors as part of the approval workflow.", "Review whether personal-in-enterprise agents, where an individual's identity is asserted in enterprise contexts, creates co-mingling risks between personal and enterprise liability \u2014 the dual-approval requirement partially addresses this but may need supplementary contractual treatment." ], "failure_signals": [ "Provisioning records that lack a named human sponsor \u2014 removes the chain of human accountability required for liability attribution.", "Audit log retention shorter than the applicable legal hold period for the regulated data the agent was authorized to access." ] }, "grc_auditor": { "summary": "NI-01 is the first testable control in the identity lifecycle. Audit evidence centers on completeness of the provisioning receipt record relative to the active agent population, and on the integrity of the approval chain for personal-in-enterprise agents.", "actions": [ "Sample active agent identities from the identity store and trace each back to a provisioning receipt \u2014 any agent without a receipt is a control failure requiring immediate investigation.", "For personal-in-enterprise agents, verify that each provisioning record contains references to two distinct approvers and a valid PA-02 authorization; the dual-approval requirement is the key differentiator and the most likely gap in early implementations.", "Review the provisioning workflow configuration to confirm that scope validation is server-enforced, not purely a UI advisory \u2014 test by submitting a malformed request directly to the API endpoint." ], "metrics": [ "Percentage of active agent identities with a corresponding signed provisioning receipt in the audit log (target: 100%)", "Mean time from provisioning request submission to approval decision, broken down by principal type (target: defined SLA met for >95% of requests)" ], "failure_signals": [ "Active agent identities in the identity store without a matching audit log provisioning receipt.", "Personal-in-enterprise agent records with only a single approver identity, indicating the dual-approval rule was not enforced." ] }, "it_operations": { "summary": "NI-01 affects every deployment pipeline and infrastructure automation that creates AI agent identities. Operations teams must understand that agent identity provisioning is no longer a self-service action \u2014 it requires an approved ticket before infrastructure can proceed.", "actions": [ "Update deployment runbooks to include an identity provisioning pre-step: teams must obtain a provisioning receipt before a deployment that introduces a new agent identity can proceed.", "Create a fast-track provisioning path for emergency deployments that still satisfies the approval requirement \u2014 e.g., an on-call approver roster with documented escalation steps \u2014 so that the gate does not become a deployment blocker during incidents.", "Instrument the provisioning workflow with alerting for stuck approval requests (e.g., no action taken within 24 hours) so that operational velocity is not silently degraded by an unresponsive approver." ], "failure_signals": [ "Deployment pipelines that contain logic to create agent identities directly via API without a provisioning workflow step \u2014 indicates the gate is being bypassed at the infrastructure layer.", "Provisioning requests that remain in a pending state beyond the defined SLA, blocking deployments and creating pressure to circumvent the control." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations provision AI agent identities via ad-hoc scripts or CI/CD pipeline steps with no formal approval chain. Target state requires a structured workflow with mandatory schema fields, dual approval for personal-in-enterprise agents, PA-02 cross-reference enforcement, and audit receipts written synchronously with credential issuance." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63A-4", "fit": "direct", "rationale": "SP 800-63A-4 identity proofing requirements establish the approval threshold for provisioning new digital identities \u2014 applied here by analogy to AI agent identities requiring human sponsorship, scope declaration, and documented justification before any credential is issued.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC7644 \u00a73.3", "fit": "direct", "rationale": "SCIM POST resource provisioning model is adapted to agent identity provisioning: structured request payloads with mandatory attributes, server-side validation, and a provisioning receipt equivalent to the 201 Created response body \u2014 all enforced before identity creation.", "source_version": "2.0", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar expects identities to be managed through a governed lifecycle from provisioning through revocation. NI-01 implements the provisioning gate stage of that lifecycle; full lifecycle coverage requires NI-02 through NI-06 in combination.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Lifecycle Management \u2014 Provisioning Gate", "rationale": "Okta's SCIM-based lifecycle management enforces an approval workflow gate before any identity resource is created; Okta Workflows can require human approval, artifact hash validation, and registry entry verification before provisioning an agent identity. Automated provisioning pipelines blocked by Okta's pre-provisioning rules cannot create identities without completing the approval sequence.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta SCIM lifecycle with Workflows enforces a human-approval provisioning gate (sponsor, artifact validation) before identity creation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Organizations SCPs \u2014 Provisioning Restriction", "rationale": "AWS Organizations Service Control Policies can restrict iam:CreateRole and iam:AttachRolePolicy to specific automation pipelines (e.g., CloudFormation service roles), effectively gating all IAM role provisioning to authorized processes. This ensures no agent identity can be created outside the approved provisioning pipeline regardless of individual IAM permissions.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS SCPs restrict role creation to authorized pipelines but do not themselves record the sponsor, task scope and justification approval.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity for AI \u2014 Agent IAM Core provisioning gate", "rationale": "Ping Identity's Agent IAM Core provisions agent identities through a governed workflow that links each agent to a verified human principal and a declared authorization scope before any credentials are issued. Provisioning is gated on owner verification and scope approval, preventing self-registration by autonomous agents.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Ping Agent IAM Core provisions agents through a governed workflow linking a verified human principal and declared scope before credentials issue.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_nhi10", "requirement_id": "NHI2:2025, NHI5:2025", "fit": "direct", "rationale": "OWASP NHI Top 10 2025 NHI2 (Secret Leakage) and NHI5 (Overprivileged NHI) are directly mitigated by a provisioning gate that blocks weak, long-lived, or over-scoped credentials for non-human identities before they are issued.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "spiffe_spire", "requirement_id": "SVID \u00a72", "fit": "direct", "rationale": "SPIFFE SVIDs provide cryptographically attested workload identities issued at runtime; NI-01 provisioning gate should validate SPIFFE-conformant identities for AI agent workloads.", "normative_force": "best-practice", "source_version": "1.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "profiles": [ { "source_id": "openid", "profile": "structured_agent_authorization", "profile_url": "https://apeiris.ai/integration/profiles/structured_agent_authorization.json", "role": "implementation_anchor", "normative_force": "voluntary-standard", "reviewed_on": "2026-06-29" } ], "validation_objective": "Every AI agent identity in the registry must have an associated provisioning approval record containing a named human sponsor, a declared task scope, a written justification, and an approval timestamp that precedes the credential issuance timestamp by at least one workflow step. No credential must exist in the registry without a corresponding completed approval record.", "evidence_required": [ "provisioning_approval_record: Workflow record for each registered agent containing sponsor_id, task_scope_declaration, written_justification, approval_timestamp, approver_id, and approval_status=approved", "agent_registration_log: Registry entry for each agent showing entity_id, registered_at timestamp, and linked approval_record_id \u2014 confirming approval predated credential issuance", "dual_approval_log: For personal-in-enterprise agents, second approver record cross-referencing Authority PA-02 approval and confirming both approvals were obtained before credential issuance", "provisioning_gate_rejection_log: Log of provisioning requests that were blocked due to missing sponsor, incomplete justification, or failed approval \u2014 confirming the gate is enforced" ], "machine_tests": [ "Submit a credential provisioning API request without an approval_record_id \u2192 assert the provisioning API returns 403 with error_code=approval_required", "Submit a provisioning request with an approval_record in pending status \u2192 assert the API returns 403 with error_code=approval_not_complete", "Submit a valid provisioning request with a completed approval record and named sponsor \u2192 assert the agent registration succeeds and the registry entry contains the linked approval_record_id", "Query the registry for all agents registered in the last 30 days and cross-reference with the approval workflow system \u2192 assert zero agents exist without a corresponding completed approval record" ], "human_review": [ "Review a sample of 15 provisioning approval records to verify that sponsor identities are real named employees and that task scope declarations are specific rather than generic", "Assess whether the provisioning gate workflow is genuinely enforced or can be bypassed by infrastructure automation pipelines that self-approve agent registration", "Verify that the dual-approval requirement for personal-in-enterprise agents is applied consistently and that cross-referencing with Authority PA-02 is documented in the approval record" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Allowing automated deployment pipelines to self-register agent identities without a human approval gate \u2014 eliminating the only control that catches orphaned credential creation at source", "Using a generic team or group as the named sponsor rather than a specific named individual \u2014 making ownership accountability untraceable when the agent needs to be deprovisioned", "Accepting a task scope declaration of 'all resources' or 'admin access' as a valid justification \u2014 defeating minimum-privilege enforcement at the point of provisioning", "Treating the dual-approval requirement for personal-in-enterprise agents as optional when the second approver is unavailable \u2014 creating an approval bypass pattern", "Storing provisioning approval records in a system that the provisioning service can write to \u2014 allowing the service to create retroactive approvals for agents already registered without one" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-02", "layer": "NI", "plane": "control", "name": "Credential Issuance and Minimum Privilege", "plain": "When an AI agent credential is issued, its scope must be the narrowest set of permissions that satisfies the declared task \u2014 expressed as fine-grained resource-and-action objects, never as wildcards. The scope ceiling for each resource is determined by that resource's data sensitivity classification.", "threat": { "tags": [ "privilege-escalation", "credential-compromise" ], "desc": "Broad or wildcard credential scopes allow a compromised agent credential to access far more resources than the agent's legitimate task requires. When credentials are over-scoped at issuance, lateral movement and privilege escalation become trivially easy \u2014 an attacker controlling one agent identity gains enterprise-wide access rather than being limited to the narrow resource set the agent actually needed. The harm is compounded by the fact that over-scoped credentials frequently go undetected because the agent never exercises the excess permissions during normal operation, masking the exposure until exploitation occurs. Fine-grained, task-scoped credentials enforce containment at the identity plane, limiting blast radius to the minimum necessary even when a credential is fully compromised." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4", "title": "Authenticator assurance and credential management" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "authorization_details object structure" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 4", "title": "Dynamic policy and least-privilege access" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-02 Credential Issuance and Minimum Privilege control.", "reviewed_on": "2026-07-01" }, { "source_id": "hashicorp_vault_aar_2026", "normative_force": "best-practice", "relationship": "implementation_pattern", "rationale": "Enterprise vault implementation of OAuth 2.0 RAR (RFC 9396) per-request agent authorization \u2014 provides concrete IaC patterns for the controls in this layer.", "reviewed_on": "2026-06-29" } ], "implementation": { "pattern": "Sensitivity-gated minimum-privilege credential issuance with fine-grained scope declaration. Minimum privilege is relative to data sensitivity: apeiris://data/controls/DX-01 classifies each target resource by sensitivity tier; apeiris://data/controls/DX-03 maps each tier to the corresponding credential scope ceiling. NI-02 enforces that no issued credential exceeds the ceiling for its highest-sensitivity target resource.", "steps": [ "At credential issuance time, query apeiris://data/controls/DX-01 to determine the sensitivity tier of each target resource named in the provisioning receipt scope. Map each tier to the maximum allowable credential scope using the scope ceiling matrix defined in DX-03 \u2014 for example, a Tier 3 (confidential) resource may permit read-only access but not write or delete actions regardless of the requesting agent's role.", "Express the issued credential scope using RFC 9396 authorization_details objects rather than opaque string scopes or role names. Each authorization_details object must declare at minimum: type (identifying the resource server), resource_identifier (the specific resource URI or identifier), and actions (an explicit enumeration of permitted HTTP methods or operation names). Arrays of authorization_details objects are permitted for multi-resource tasks but each object must independently satisfy the sensitivity ceiling check.", "Reject any issuance request that contains wildcard scope indicators in any field \u2014 including but not limited to asterisk characters, the strings 'full_access', 'admin', 'superuser', 'all', or any scope string whose action set is not explicitly enumerable. This rejection must occur server-side in the authorization server; client-side validation alone is not sufficient.", "Issue time-bounded credentials with the narrowest scope that satisfies the declared task and log the issuance event with: the task reference from the provisioning receipt, the DX-01 sensitivity tier assigned to each target resource, the scope ceiling applied, and the final authorization_details objects granted. Link the log entry to the provisioning receipt from NI-01." ], "anti_patterns": [ "Issuing a single broad credential for a multi-step agentic workflow to avoid multiple issuance round-trips \u2014 the operational convenience of one credential defeats minimum privilege; use per-step JIT credentials (see NI-04) or narrow composite scopes instead.", "Inheriting scope from the sponsoring human principal's own permissions without re-evaluating each resource against the DX-01/DX-03 sensitivity ceiling \u2014 a human principal's access is governed by HR and role policy, not by agent task scope constraints.", "Using static long-lived API keys whose scopes were set at initial key creation and have never been re-evaluated against current data sensitivity classifications or task requirements, effectively treating the original scope as permanent minimum privilege." ] }, "validation": { "design_check": [ "Review the authorization server configuration to confirm that the scope validation logic is enforced server-side and that the wildcard rejection list is implemented as a deny-by-default pattern (allowed scope terms are enumerated; anything not on the list is rejected).", "Verify that the issuance service has a live integration with the DX-01 sensitivity classification endpoint and that the scope ceiling lookup from DX-03 is consulted for every issuance request \u2014 confirm this path is exercised in integration tests.", "Confirm that the issuance log schema includes fields for sensitivity tier, scope ceiling applied, and the full authorization_details objects granted, and that log entries are written for every issuance event including rejections." ], "runtime_test": [ "Attempt to issue a credential with a wildcard action scope (e.g., actions: ['*']) for a known resource and verify the authorization server returns a rejection with a structured error identifying the wildcard field.", "Issue a credential for a task targeting a Tier 3 (confidential) resource and request write access; verify the issuance is blocked by the DX-03 scope ceiling if write is not permitted at that tier, even when the provisioning receipt otherwise authorizes the agent.", "Issue a valid minimum-privilege credential and verify the issuance log entry contains: the DX-01 sensitivity tier for each target resource, the scope ceiling that was applied, the authorization_details objects as issued, and a reference to the originating provisioning receipt from NI-01." ], "evidence": [ "issuance-log:Credential issuance log entries for the review period showing sensitivity tier, scope ceiling, and authorization_details for each issued credential with no wildcard scope indicators present [unverified]", "rejection-log:Authorization server rejection log showing wildcard scope requests blocked at the server layer during the review period [unverified]", "dx01-integration:Integration test results confirming the issuance service queries DX-01 for every resource named in a provisioning request before issuing a credential [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-02 is implemented in the authorization server, not in the consuming application. The IAM team owns the scope validation logic, the wildcard deny-list, and the DX-01/DX-03 integration. The key engineering challenge is expressing minimum privilege as RFC 9396 authorization_details objects in a system that may currently rely on opaque OAuth scopes.", "actions": [ "Migrate agent credential issuance from opaque OAuth scope strings to RFC 9396 authorization_details objects in the authorization server \u2014 this requires updates to both the token issuance endpoint and the resource server's token introspection or validation logic.", "Implement the DX-01 sensitivity tier lookup as a synchronous call in the issuance path with a configurable timeout and a fail-closed behavior \u2014 if the sensitivity lookup fails or times out, credential issuance must be blocked, not defaulted to a permissive scope.", "Maintain a scope ceiling matrix (derived from DX-03) as a versioned configuration artifact in the IAM platform; changes to the matrix should trigger re-evaluation of any active agent credentials whose scopes were issued under the previous matrix." ], "failure_signals": [ "Active agent credentials in the token store whose authorization_details objects contain action lists that include wildcards or enumerated action sets broader than the DX-03 ceiling for the associated resource tier.", "Issuance log entries missing the sensitivity_tier or scope_ceiling fields, indicating the DX-01 lookup was not performed or its result was not recorded." ] }, "security_architect": { "summary": "NI-02 enforces blast radius containment at the identity layer. Its effectiveness depends on the accuracy of DX-01 sensitivity classifications and the granularity of DX-03 scope ceilings \u2014 a misconfigured sensitivity tier on a high-value resource silently defeats the control.", "actions": [ "Design the DX-01 integration as a read-through cache with a short TTL \u2014 agent credentials should reflect the current sensitivity classification of their target resources, not a stale snapshot from provisioning time.", "Specify the threat model for scope creep: define how an agent's authorization_details can be narrowed post-issuance if a target resource is re-classified to a higher sensitivity tier, and ensure this triggers a credential revocation and re-issuance flow.", "Review the interaction between NI-02 and NI-04 (Just-In-Time issuance): JIT credentials issued per task should inherit the minimum-privilege constraints of NI-02 at each issuance, preventing scope accumulation across task steps." ], "failure_signals": [ "No defined process for re-evaluating active agent credentials when a target resource's DX-01 sensitivity tier is upgraded \u2014 indicates scope ceilings are enforced only at issuance, not continuously.", "Authorization server wildcard rejection logic implemented as client-side validation only, meaning a direct API caller can bypass scope restrictions entirely." ] }, "legal_counsel": { "summary": "NI-02 produces the evidence basis for demonstrating that AI agents were granted only the access necessary for their declared task. In the event of a data breach involving an AI agent, the minimum-privilege log is the primary artifact for establishing whether the agent was operating within its authorized scope.", "actions": [ "Confirm that the credential issuance log is immutable and tamper-evident \u2014 this log may be subpoenaed or requested by regulators following an incident, and any evidence of post-hoc modification would be damaging.", "Review whether the authorization_details objects in issued credentials satisfy data minimization obligations under applicable privacy law \u2014 an agent credential that grants read access to an entire database table when only a single record is required may constitute excess data processing.", "Ensure that the scope ceiling matrix (DX-03) is reviewed and approved by a data governance body, not solely by the IAM team \u2014 the sensitivity classifications that drive scope ceilings have legal implications for data access control." ], "failure_signals": [ "Credential issuance logs that are mutable or stored in systems without access controls on the log data itself \u2014 undermines evidentiary value.", "No documented governance approval process for changes to the DX-03 scope ceiling matrix, meaning access control policy can be widened without legal or compliance review." ] }, "grc_auditor": { "summary": "NI-02 audit centers on two questions: are all active agent credentials within their applicable scope ceilings, and is the wildcard rejection actually enforced at the server layer? Both can be tested directly from log data and authorization server configuration.", "actions": [ "Pull the full active agent credential inventory and cross-reference each credential's authorization_details against the DX-03 scope ceiling for the sensitivity tier of its target resources \u2014 any mismatch is a finding.", "Submit a test wildcard scope request directly to the authorization server API (bypassing any client-side tooling) and verify it is rejected \u2014 this tests enforcement at the correct layer.", "Verify that the issuance log retention period covers the full lifecycle of the longest-lived agent credentials in the environment plus the organization's minimum log retention requirement." ], "metrics": [ "Percentage of active agent credentials with at least one authorization_details object exceeding the DX-03 scope ceiling for its target resource's sensitivity tier (target: 0%)", "Number of wildcard scope rejection events logged per review period (trend metric \u2014 a sudden drop may indicate the rejection logic stopped firing)" ], "failure_signals": [ "Agent credentials in the active inventory whose action lists include verbs not permitted by the DX-03 ceiling for the associated resource sensitivity tier.", "Issuance log entries for credentials issued without a recorded DX-01 sensitivity lookup result, indicating the ceiling check was not performed." ] }, "it_operations": { "summary": "NI-02 affects how deployment teams request credentials for new agent deployments. Operations must translate agent task requirements into explicit resource-and-action enumerations \u2014 vague 'admin access' requests will be rejected by the authorization server.", "actions": [ "Update deployment templates and agent manifest formats to include an explicit authorization_details section that enumerates each target resource and the specific actions required \u2014 this becomes the input to the NI-01 provisioning request schema.", "Establish a process for requesting scope expansion when a deployed agent's task requirements expand beyond its issued scope: this requires a new provisioning request through NI-01, not an ad-hoc credential re-issuance.", "Instrument agent workloads to log permission-denied errors at the resource layer \u2014 these signals indicate that an agent's issued scope is insufficient for its task and require a scope re-evaluation rather than a blanket scope expansion." ], "failure_signals": [ "Operational runbooks that instruct teams to request 'full access' or 'admin' credentials for agent deployments rather than task-specific resource enumerations.", "High rate of permission-denied errors from deployed agents combined with no corresponding scope re-evaluation requests \u2014 indicates agents are operating at the edge of their scope and the scope was not correctly estimated at provisioning time." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprise environments issue AI agent credentials with role-based or string-scope OAuth tokens that do not reflect individual task resource requirements. Target state requires authorization server support for RFC 9396 authorization_details objects, a live DX-01 sensitivity integration, and server-enforced wildcard rejection. Migration from opaque scopes to structured authorization_details is the primary implementation challenge." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "platform-engineer" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4", "fit": "direct", "rationale": "SP 800-63B-4's authenticator assurance levels govern the strength of credentials; NI-02 pairs that assurance discipline with a minimum-scope ceiling so agent credentials carry only the permissions the declared task requires, aligned with the assurance level appropriate for the resource sensitivity.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "direct", "rationale": "RFC 9396 authorization_details objects provide the structured, machine-readable format for expressing fine-grained credential scopes. NI-02 mandates their use as the canonical scope representation for AI agent credentials, replacing opaque scope strings.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 4", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 4 (access to resources is determined by dynamic policy) is operationalized by NI-02's requirement to evaluate each credential issuance against current data sensitivity classifications and apply the minimum scope ceiling at the moment of issuance.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Best Practices \u2014 Least Privilege", "rationale": "AWS IAM best practices require granting only the permissions required to perform a specific task at credential issuance time. AWS IAM Access Analyzer generates findings when policies are over-permissioned relative to actual usage, enabling automated least-privilege validation during credential review. IAM condition keys (aws:RequestTag, aws:ResourceTag) allow fine-grained scoping below the role level.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS least-privilege and Access Analyzer support minimal scoping but do not enforce the no-wildcard, sensitivity-ceiling constraints the control sets.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud IAM Best Practices \u2014 Least Privilege Roles", "rationale": "Google Cloud IAM best practices require using the most restrictive predefined role or creating custom roles with exactly the permissions required. Workload Identity Federation issues credentials scoped to the service account's IAM bindings, and IAM Conditions can further restrict access to specific resources, times, or request attributes, enabling fine-grained least-privilege enforcement at credential issuance.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP restrictive/custom roles and WIF-scoped credentials support least privilege but not the data-sensitivity scope ceiling the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta for AI Agents \u2014 Minimum Privilege", "rationale": "Okta for AI Agents enforces least-privilege policies at credential issuance time by scoping short-lived tokens to the authorization scope declared in the agent's Universal Directory registration. The OAuth Client Credentials flow with explicit scope parameters ensures the issued token can only access the resources declared in the pre-approved authorization scope.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta scopes short-lived tokens to the declared authorization scope, but does not enforce the no-wildcard, sensitivity-classification ceiling.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Service authentication; Part III \u2014 Access control and privilege management (Least Agency, minimum permissions per role)", "fit": "direct", "rationale": "Credentials issued via an identity provider with minimum necessary permissions per role (deny-by-default RBAC) \u2014 credential issuance with minimum privilege.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "profiles": [ { "source_id": "openid", "profile": "structured_agent_authorization", "profile_url": "https://apeiris.ai/integration/profiles/structured_agent_authorization.json", "role": "implementation_anchor", "normative_force": "voluntary-standard", "reviewed_on": "2026-06-29" } ], "validation_objective": "Every AI agent credential in the registry must have an associated scope declaration containing only explicit resource-and-action pairs (no wildcards), where each resource's permitted action set does not exceed the ceiling defined by that resource's data sensitivity classification. No credential may be issued with a broader scope than declared in the provisioning approval.", "evidence_required": [ "credential_scope_declaration: Structured scope object for each issued credential listing explicit resource_id, permitted_actions[], and sensitivity_ceiling for each resource \u2014 with no wildcard entries", "sensitivity_classification_registry: Current data sensitivity classification for each resource referenced in agent credential scopes, used to verify that permitted actions do not exceed the sensitivity ceiling", "scope_enforcement_log: Record of credential issuance requests that were rejected or scoped-down because the requested scope exceeded the sensitivity ceiling for one or more resources", "credential_scope_audit_report: Periodic report comparing issued credential scopes against the minimum required for declared task scope \u2014 identifying any credential with excess permissions" ], "machine_tests": [ "Request credential issuance with a wildcard scope ('*' or 'all') \u2192 assert the provisioning API returns 400 with error_code=wildcard_scope_prohibited", "Request credential issuance with a resource-action pair that exceeds the sensitivity ceiling for that resource \u2192 assert the API rejects the request with error_code=scope_exceeds_sensitivity_ceiling", "Issue a credential with explicit minimum-privilege scope for a declared task and attempt an action outside that scope using the issued credential \u2192 assert the resource server returns 403 with error_code=scope_insufficient", "Query all credentials issued in the last 30 days and check each scope declaration for wildcard entries \u2192 assert zero credentials contain wildcard resource or action specifications" ], "human_review": [ "Review a sample of 15 credential scope declarations against the declared task scope in the provisioning approval record to verify the scope is genuinely the minimum required", "Assess whether the data sensitivity classification registry is current and whether its ceiling policies accurately reflect current data governance requirements", "Verify that the scope enforcement logic treats an absent sensitivity classification as a blocking condition rather than defaulting to permissive access" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Issuing credentials with wildcard resource or action scopes as a convenience to avoid scope enumeration \u2014 this defeats the entire minimum-privilege principle and grants unbounded access", "Using the same generic credential scope for all agents of a given type regardless of their specific declared task \u2014 aggregating privilege beyond what any individual task requires", "Defaulting to the highest sensitivity ceiling for resources whose classification is unknown rather than blocking until classification is established", "Granting read-and-write scope to resources when the declared task only requires read \u2014 over-provisioning because the team anticipates future needs", "Treating scope declarations as advisory rather than enforced \u2014 allowing the agent runtime to request additional permissions at execution time without re-approval" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-03", "layer": "NI", "plane": "control", "name": "Credential Lifetime and Forced Rotation", "plain": "AI agent credentials must have a bounded maximum lifetime determined by the risk level of their authorized scope. Rotation is triggered not only on a time schedule but also on security events, task completion, and deployment updates \u2014 whichever comes first.", "threat": { "tags": [ "credential-compromise", "orphaned-credential" ], "desc": "Long-lived credentials dramatically extend the window of exposure after a compromise event. An AI agent credential valid for weeks or months provides an attacker persistent access long after the initial breach \u2014 and periodic rotation without event-triggered rotation leaves the full gap between review cycles exposed. Orphaned agent credentials are a specific compounding risk: when an agent is decommissioned, its long-lived credential may remain valid in a secrets store or cached token, providing a re-entry path with no active owner. Short maximum TTLs limit the exploitation window even when rotation events are missed; event-triggered rotation closes the gap when a security event is detected mid-lifetime." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a74", "title": "Authenticator event management \u2014 expiration, revocation, re-issuance" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 3", "title": "Per-session access grants and short session lifetimes" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Authentication", "title": "Credential lifecycle and revocation" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-03 Credential Lifetime and Forced Rotation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/NI-03 Credential Lifetime and Forced Rotation control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-03 Credential Lifetime and Forced Rotation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-03 Credential Lifetime and Forced Rotation control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/NI-03 Credential Lifetime and Forced Rotation control.", "reviewed_on": "2026-07-01" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds short-lived credential lifetime / forced rotation in Phase 6 and the Service authentication tier.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Risk-tiered maximum credential lifetime with event-triggered forced rotation. Privileged and consequential-action agents receive a maximum TTL of one hour; standard workload agents receive a maximum of twenty-four hours; low-risk read-only agents may receive up to seven days. Rotation is forced on any of: expiry, detected security event, agent task completion, or deployment update affecting the agent image or configuration.", "steps": [ "Define a credential lifetime tier matrix keyed on the risk classification of the agent's authorized scope: Tier 1 (privileged or consequential-action credentials \u2014 any credential authorized to make state-changing calls on sensitive systems, financial transactions, or access Tier 3 data) receives a maximum TTL of 3600 seconds; Tier 2 (standard workload credentials) receives a maximum TTL of 86400 seconds; Tier 3 (low-risk read-only credentials scoped to non-sensitive resources) receives a maximum TTL of 604800 seconds. These ceilings are hard limits enforced by the authorization server at issuance \u2014 the issuance request cannot override them.", "Implement event-triggered rotation by subscribing the credential management service to four event classes: (a) security events (threat alerts, anomaly detections, or behavioral flags from NI-05 or downstream security tooling); (b) task completion signals from the agentic orchestration layer; (c) deployment update events for the agent's container image, function package, or configuration; (d) sponsoring principal deactivation events from the HR or identity lifecycle system. On receiving any of these events, the credential management service must revoke all active credentials for the affected agent identity and issue a fresh set if the agent remains authorized.", "Enforce short-lived token preference over long-lived API keys: the authorization server must default to issuing JWT bearer tokens with embedded expiry claims rather than opaque API keys. Where legacy systems require API key format, implement a credential broker that issues short-lived synthetic API keys backed by regularly rotated master secrets, and log each synthetic key issuance with the same audit trail as JWT issuance.", "Run a scheduled credential age scan at least every six hours: identify any active agent credentials whose issued_at timestamp plus the applicable tier TTL ceiling has elapsed and trigger revocation for each. Log the reason for revocation (schedule expiry vs. event trigger) to enable audit differentiation. Alert on any credential that passes its tier ceiling without being rotated \u2014 this indicates a gap in the event subscription or the scheduled scan." ], "anti_patterns": [ "Setting long TTLs for agent credentials on the grounds that the agent is 'trusted' or 'internal' \u2014 trust level does not reduce the exposure window if the credential is compromised; TTLs must be set by risk tier of the authorized scope, not by perceived trustworthiness of the agent.", "Implementing rotation only on a calendar schedule (e.g., 90-day rotation) without event-triggered rotation, leaving the full interval between rotation events as an unmitigated exposure window after a compromise.", "Caching issued credentials in application memory or environment variables beyond their expiry time, allowing an agent to continue operating with an expired credential because the resource server's token validation is lenient about clock skew or expiry enforcement." ] }, "validation": { "design_check": [ "Review the authorization server configuration to confirm that the TTL ceiling matrix is enforced server-side and that issuance requests cannot supply an exp claim or lifetime parameter that exceeds the tier ceiling for the credential's risk classification.", "Verify that the credential management service has active subscriptions to all four event classes (security events, task completion, deployment updates, principal deactivation) and that each subscription triggers a revocation call \u2014 confirm this in the event routing configuration, not just in documentation.", "Confirm that the scheduled credential age scan is configured to run at least every six hours and that its output is written to the same audit log as event-triggered revocations, with a reason code distinguishing the two revocation paths." ], "runtime_test": [ "Issue a Tier 1 (privileged) credential and attempt to set its lifetime to 7200 seconds (two hours); verify the authorization server caps the TTL at 3600 seconds and returns the credential with the capped expiry.", "Simulate a security event for an agent with an active credential and verify that the credential management service revokes the credential within the defined SLA (target: under 60 seconds from event receipt) and that a revocation record is written to the audit log.", "Allow a Tier 3 credential to expire without explicit revocation; verify that the resource server rejects a token validation request for the expired credential and that the rejection is logged \u2014 confirm there is no grace period that extends token acceptance beyond the exp claim." ], "evidence": [ "credential-inventory:Active agent credential inventory showing issued_at, exp, tier classification, and risk level for all credentials in the review period, with no credential exceeding its tier TTL ceiling [unverified]", "revocation-log:Credential revocation log entries for the review period with reason codes differentiating schedule-expiry, event-triggered, and manual revocations [unverified]", "event-subscription-config:Event routing configuration showing active subscriptions to security event, task completion, deployment update, and principal deactivation event classes with revocation handler mapped [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-03 requires the IAM team to operate a credential lifecycle management service that actively monitors credential age and responds to external events \u2014 not just a passive token issuance service. The four event subscriptions and the scheduled scan are the operational core of this control.", "actions": [ "Implement the TTL ceiling matrix as a policy object in the authorization server (e.g., an OAuth server policy rule or a token customization hook) that intercepts the issuance request and overrides any exp parameter that exceeds the tier ceiling.", "Build or configure the event subscription integrations using a durable event bus (e.g., Kafka, EventBridge, or Pub/Sub) rather than synchronous webhooks \u2014 revocation on security events must be reliable even under load, and a synchronous webhook can drop events under failure conditions.", "Implement a dead-letter queue and alert for failed revocation events \u2014 a revocation that fails silently leaves a credential active past its authorized lifetime, which is a worse outcome than a delayed revocation." ], "failure_signals": [ "Active credentials in the token store with issued_at timestamps older than their tier TTL ceiling \u2014 indicates the scheduled scan missed them or the event subscriptions failed to trigger revocation.", "Event subscription health checks showing disconnected or lagging consumers for any of the four event classes \u2014 indicates revocation events may be dropped under the current configuration." ] }, "security_architect": { "summary": "NI-03 reduces the blast radius of credential compromise by shrinking the exposure window. Its effectiveness depends on two things: the TTL ceilings being enforced without bypass paths, and the event-triggered revocation path being low-latency and reliable.", "actions": [ "Model the worst-case exposure window for each credential tier: for Tier 1 credentials, the exposure window is at most one hour from compromise to expiry \u2014 verify this matches the threat tolerance for the systems those credentials can access.", "Identify all paths by which an agent could obtain a new credential after revocation \u2014 if the agent can self-re-provision, forced rotation is ineffective. The re-provisioning path must require the NI-01 approval gate even for renewal.", "Review the token validation configuration on resource servers to confirm they enforce the exp claim strictly and do not implement clock skew tolerances that effectively extend the TTL beyond the issued value." ], "failure_signals": [ "Resource servers configured with clock skew tolerances greater than 60 seconds on token expiry validation \u2014 effectively extends the credential lifetime beyond the issued TTL ceiling.", "Agent runtimes that implement credential auto-renewal without going through the NI-01 provisioning gate \u2014 creates a self-service re-provisioning path that bypasses lifetime enforcement." ] }, "legal_counsel": { "summary": "NI-03 directly addresses a regulatory expectation present in multiple frameworks: that access credentials, particularly for automated systems, must not persist indefinitely. The revocation log is also a key artifact for demonstrating that compromised credentials were promptly retired.", "actions": [ "Confirm that the revocation log is retained for the full period required by applicable breach notification and incident response regulations \u2014 in the event of a breach, the time between compromise and revocation will be a central question.", "Review whether the seven-day maximum TTL for Tier 3 read-only credentials is consistent with the data minimization and access control requirements of applicable privacy law for the data those credentials can read.", "Verify that the event-triggered revocation path for principal deactivation (e.g., employee termination) satisfies any regulatory requirement for prompt revocation of access upon departure \u2014 most frameworks require revocation within one business day." ], "failure_signals": [ "Revocation log retention period shorter than the applicable incident response record-keeping requirement for the regulated data in scope.", "No documented maximum interval between principal deactivation event and credential revocation for agent credentials sponsored by the departing principal \u2014 creates a compliance gap for access revocation upon termination requirements." ] }, "grc_auditor": { "summary": "NI-03 audit focuses on two populations: credentials that are active but should have been rotated, and revocation events that should have occurred but did not. Both are directly testable from the credential inventory and revocation log.", "actions": [ "Pull the full active credential inventory and compute age for each credential; flag any credential older than its tier TTL ceiling as a finding requiring immediate revocation and root-cause analysis.", "Sample the revocation log for the review period and verify that a representative set of security events, task completions, deployment updates, and principal deactivations each produced corresponding revocation entries within the defined SLA.", "Test the scheduled credential age scan by reviewing its execution log: confirm it ran at least every six hours during the review period and that its output was written to the audit log." ], "metrics": [ "Percentage of active agent credentials within their tier TTL ceiling at time of audit (target: 100%)", "Mean time from trigger event (security event, task completion, deployment update, principal deactivation) to credential revocation (target: under 60 seconds for security events, under 5 minutes for other event classes)" ], "failure_signals": [ "Active credentials with issued_at timestamps that exceed the applicable tier TTL ceiling \u2014 indicates rotation enforcement has failed for at least one revocation trigger.", "Gaps in the scheduled scan execution log greater than six hours \u2014 indicates the scan did not run during that window and any TTL-expired credentials in that period were not caught." ] }, "it_operations": { "summary": "NI-03 requires operations teams to build agent workloads that handle credential expiry and renewal gracefully, without storing credentials in ways that outlive their authorized TTL. The most common operational failure is credential caching in environment variables or mounted secrets that are not refreshed on rotation.", "actions": [ "Update agent runtime configurations to pull credentials from a secrets management system (e.g., HashiCorp Vault, AWS Secrets Manager) using dynamic secrets with automatic renewal, rather than injecting credentials as static environment variables at container start.", "Implement graceful re-authentication handling in agent workloads: when a resource server returns a 401 Unauthorized response on an expired credential, the agent should request a new credential through the authorized issuance path rather than failing permanently or caching and retrying the expired token.", "Add credential expiry monitoring to the agent observability stack: alert when a deployed agent's active credential has less than 20% of its TTL remaining, giving operations time to investigate re-issuance before the credential expires in production." ], "failure_signals": [ "Agent containers that read credentials from environment variables injected at deployment time with no mechanism to refresh them on rotation \u2014 means rotation events do not take effect until the container is restarted.", "Agent workloads that retry 401 responses with the same expired credential rather than triggering re-authentication \u2014 indicates the graceful re-authentication path is not implemented." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most AI agent deployments use static API keys or long-lived service account tokens with no automated rotation. Target state requires a risk-tiered TTL ceiling enforced at the authorization server, event-triggered revocation wired to at least the security event and principal deactivation channels, and a scheduled scan running at least every six hours. Migration from static API keys to dynamic short-lived tokens is the primary infrastructure challenge." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a74", "fit": "direct", "rationale": "SP 800-63B-4 \u00a74 (authenticator event management) establishes expiration, revocation, and re-issuance handling for authenticators. NI-03 applies these requirements to AI agent credentials, adding event-triggered revocation triggers specific to the agentic deployment lifecycle (task completion, deployment update).", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 3", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 3 grants access to individual resources on a per-session basis \u2014 access does not persist beyond the session. NI-03 operationalizes this for agent credentials by mandating short TTL ceilings by risk tier and requiring re-authentication on each new task rather than relying on persistent sessions.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar's Authentication function covers credential lifecycle expectations, including rotation and revocation. NI-03 implements the revocation and rotation components, with TTL ceilings and event triggers tailored to AI agent risk profiles.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Secrets Manager \u2014 Automated Rotation", "rationale": "AWS Secrets Manager automates credential rotation through a four-step Lambda lifecycle (createSecret, setSecret, testSecret, finishSecret) that generates new credentials, updates the target system, validates functionality, and promotes the new value \u2014 all without service interruption. AWS Well-Architected SEC02-BP03 requires storing all machine credentials in a managed vault with automated rotation rather than static long-term secrets.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Secrets Manager automates scheduled and event rotation, but not the task-completion/deployment triggers or risk-tier lifetime ceiling required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Workload Identity Federation \u2014 Short Lived Tokens", "rationale": "Google Cloud Workload Identity Federation issues access tokens with a maximum lifetime of one hour by default, enforcing short credential lifetimes for all workloads. Google Cloud IAM documentation explicitly deprecates long-lived service account keys and recommends WIF as the replacement, eliminating the rotation problem by making credentials so short-lived that rotation is automatic.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP WIF short-lived (1h) tokens bound credential lifetime, but the control also requires multi-trigger rotation the mechanism does not provide.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Short-lived, identity-provider-issued credentials as baseline; Part III \u2014 Service authentication (tokens expiring in minutes)", "fit": "direct", "rationale": "Token lifetimes measured in minutes with automated refresh; static/long-lived keys treated as already-compromised \u2014 credential lifetime and forced rotation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent credential must have an expiry timestamp that does not exceed the maximum lifetime permitted for its authorized risk tier, and the credential rotation system must demonstrate that rotation is triggered on schedule, on security events, on task completion, and on deployment updates \u2014 whichever occurs first. No credential may remain active beyond its maximum lifetime without renewal through the provisioning gate.", "evidence_required": [ "credential_lifetime_record: For each active credential, a record showing issued_at, expires_at, risk_tier, and maximum_lifetime_for_tier \u2014 confirming expires_at does not exceed the tier-maximum", "rotation_event_log: Log of all credential rotation events in the past 30 days, each with rotation_trigger (scheduled/security-event/task-complete/deployment-update), prior_credential_id, new_credential_id, and rotation_timestamp", "security_event_rotation_record: Evidence that each security event (anomalous access, incident declaration, ownership change) triggered a credential rotation within the defined SLA", "expired_credential_rejection_log: Log showing that requests presenting credentials past their expiry timestamp were rejected with 401 responses \u2014 confirming expiry enforcement at runtime" ], "machine_tests": [ "Present a credential with exp=now-60s to a protected resource endpoint \u2192 assert the resource server returns 401 with error=token_expired", "Trigger a simulated security event against an agent in a test environment \u2192 assert a rotation event appears in the rotation event log within the defined security-event SLA", "Issue a credential with the maximum permitted lifetime for a high-risk-tier agent and attempt renewal-free use past the expiry \u2192 assert rejection with error=token_expired", "Query the credential registry for all credentials where expires_at > issued_at + max_lifetime_for_tier \u2192 assert zero results (no over-lifetime credentials exist)" ], "human_review": [ "Review the maximum lifetime thresholds for each risk tier and assess whether they reflect current threat intelligence and business risk appetite", "Assess the security-event rotation trigger logic to verify it covers the full set of triggering conditions (anomalous access, incident declaration, ownership change, deployment update) and not just scheduled rotation", "Verify that the forced rotation process does not allow a grace period that extends the effective lifetime beyond the stated tier maximum" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Issuing credentials with no expiry (non-expiring tokens) for agent service accounts on the assumption that rotation is operationally difficult \u2014 creating permanent standing credentials with no forced revocation path", "Using only scheduled rotation without event-triggered rotation \u2014 leaving credentials valid after a security event for the full remaining lifetime", "Setting maximum lifetime thresholds as soft warnings rather than hard enforcement cutoffs \u2014 allowing agents to continue operating on expired credentials during 'grace periods'", "Treating task completion as a rotation trigger only for JIT credentials but not for standing credentials \u2014 failing to capture the task-completion rotation requirement for longer-lived credentials", "Rotating credentials by issuing a new credential before revoking the prior one, then failing to revoke the prior credential \u2014 creating a window where both are valid" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-04", "layer": "NI", "plane": "control", "name": "Just-In-Time Credential Issuance", "plain": "AI agent credentials are issued at the moment a specific task is dispatched and revoked immediately on task completion or failure. No standing credentials exist between task executions \u2014 there is nothing stored in the agent runtime for an attacker to steal.", "threat": { "tags": [ "credential-compromise", "privilege-escalation" ], "desc": "Standing long-lived credentials for AI agents create a persistent attack surface that exists whether or not the agent is actively executing a task. If an agent's stored credential is exfiltrated from a secrets store, container environment, or memory, it remains valid until expiry or explicit revocation \u2014 neither of which happens reliably without JIT enforcement. JIT issuance eliminates the standing credential entirely: the credential is created at task dispatch, bound to the specific task context, and revoked at task completion, so the exposure window is precisely the duration of the task. An attacker who exfiltrates a JIT credential between tasks finds nothing; an attacker who intercepts one mid-task faces a credential valid only for the remaining task duration and only for the specific resources the task was authorized to access." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4", "title": "Authenticator binding and issuance" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 3", "title": "Per-session access \u2014 dynamic credential issuance and revocation" }, { "id": "openid", "section": "RFC 9396 \u00a76", "title": "authorization_details in the token request" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-04 Just-In-Time Credential Issuance control.", "reviewed_on": "2026-07-01" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds JIT credential issuance in Phase 6 JIT access and the Advanced privilege-scoping tier.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Task-dispatch-triggered credential issuance with automatic revocation on task termination. The agentic orchestration layer requests a credential from the identity provider at the moment it dispatches a task to an agent. The credential is bound to the task identifier and the specific authorization_details for that task's resource requirements. On task completion, failure, or timeout, the orchestration layer sends a revocation request to the identity provider and the credential is immediately invalidated.", "steps": [ "Integrate the agentic orchestration layer with the identity provider's token issuance endpoint so that task dispatch is the trigger for credential issuance. The task dispatch payload must include: the agent identity reference (from NI-01), the task identifier (a unique, non-replayable string), the target resources and actions expressed as RFC 9396 authorization_details objects (subject to NI-02 scope ceilings), and a requested TTL that does not exceed the NI-03 tier ceiling for the credential's risk level. The identity provider issues a task-bound JWT whose claims include the task_id and whose exp is set to the lesser of the requested TTL and the tier ceiling.", "Pass the issued credential to the agent runtime as an in-memory injection at task dispatch time rather than storing it in a secrets manager, environment variable, or persistent volume. The credential must not be written to disk, logged in plaintext, or cached in the orchestration layer. Implement the injection mechanism as a runtime secret mount with an in-memory backing (e.g., a tmpfs mount or an in-process credential provider that re-fetches from the identity provider on each task).", "Implement task completion hooks in the orchestration layer that trigger credential revocation: on task success, on task failure, on task timeout (using a dead-man's-switch timer equal to the task's maximum expected duration), and on orchestration layer shutdown. Each hook must call the identity provider's token revocation endpoint (RFC 7009 or equivalent) with the task_id and credential reference. Log the revocation event, the trigger type, and the task_id.", "Implement a reconciliation scan that runs every five minutes and compares active credentials in the identity provider's token store against active tasks in the orchestration layer. Any credential whose task_id does not correspond to an active task must be revoked immediately and an alert generated. This scan catches credentials that were not revoked due to hook failure \u2014 it is the safety net that enforces JIT guarantees even when the primary revocation path fails." ], "anti_patterns": [ "Issuing a task-bound credential but injecting it as an environment variable into a long-running container \u2014 the credential persists in the container environment beyond the task and may survive task completion, defeating JIT semantics.", "Implementing JIT issuance only for new task types while allowing legacy agent deployments to continue using standing credentials, creating a split enforcement model that attackers can exploit by targeting legacy agents.", "Relying solely on TTL expiry as the revocation mechanism for JIT credentials rather than implementing an explicit revocation call on task completion \u2014 this means a credential remains valid for the full TTL period even after the task it was issued for has finished, undermining the JIT guarantee." ] }, "validation": { "design_check": [ "Review the orchestration layer's task dispatch implementation to confirm that credential issuance is called synchronously at dispatch time and that the issued credential is injected into the agent runtime via an in-memory mechanism rather than written to persistent storage.", "Verify that all four task termination hook types (success, failure, timeout, shutdown) are implemented and each calls the token revocation endpoint \u2014 check both the hook registration code and the revocation endpoint call, not just documentation.", "Confirm the reconciliation scan is scheduled to run at least every five minutes and that its output is written to the audit log with a distinct reason code for reconciliation-triggered revocations." ], "runtime_test": [ "Dispatch a task and inspect the orchestration layer's storage layer (environment variables, secrets mounts, persistent volumes) to verify no credential is stored outside of in-memory runtime injection \u2014 confirm the credential is not present in the container's environment after task completion.", "Dispatch a task, capture the task-bound JWT, allow the task to complete, and then attempt to use the captured JWT against the resource server \u2014 verify the token is rejected with a 401 response, confirming that task completion triggered revocation and the credential is no longer valid.", "Simulate a hook failure (e.g., make the revocation endpoint return a 500 error on task completion) and verify that the five-minute reconciliation scan detects the orphaned credential, revokes it, and logs an alert." ], "evidence": [ "orchestration-log:Task dispatch log entries showing credential issuance at dispatch time and revocation at task termination, with task_id linking dispatch and revocation events for each task in the review period [unverified]", "reconciliation-log:Reconciliation scan execution log showing runs at minimum every five minutes during the review period, with entries for any orphaned credentials detected and revoked [unverified]", "storage-inspection:Evidence from a runtime inspection (e.g., container env dump or secrets mount listing) showing no persistent credential storage for any active agent deployment [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-04 requires the IAM team to expose a task-scoped token issuance API that the orchestration layer can call at dispatch time, and to support the full RFC 7009 token revocation flow triggered by task lifecycle events. The primary engineering challenge is the reconciliation scan \u2014 it must query both the identity provider's token store and the orchestration layer's task registry atomically enough to avoid false positives.", "actions": [ "Expose a dedicated JIT issuance endpoint on the authorization server that accepts a task_id, agent identity reference, and authorization_details payload. Bind the task_id as a custom JWT claim so that the reconciliation scan can correlate active tokens to active tasks without additional state.", "Implement the RFC 7009 token revocation endpoint and ensure it supports revocation by task_id in addition to by token value \u2014 this allows the orchestration layer to revoke all credentials for a given task even if it did not retain the token value after injection.", "Design the reconciliation scan to query the identity provider's active token index filtered by token type 'task-bound' and cross-reference each token's task_id claim against the orchestration layer's active task list via a read-only API call. Revoke any token whose task_id is not in the active list." ], "failure_signals": [ "Task-bound JWTs in the identity provider's active token store whose task_id values do not correspond to any active task in the orchestration layer \u2014 indicates either hook failures or tasks that completed without triggering revocation.", "Reconciliation scan execution gaps greater than five minutes in the scan log \u2014 indicates the safety net is not running at the required frequency." ] }, "security_architect": { "summary": "NI-04 eliminates the standing credential attack surface for AI agents. Its security guarantee is only as strong as the revocation path's reliability \u2014 architect for fail-closed revocation so that a failure in the hook or the reconciliation scan does not leave credentials active beyond task completion.", "actions": [ "Design the credential injection mechanism to be pull-based from the agent runtime rather than push-based from the orchestration layer \u2014 an agent that requests its own task credential at startup from an in-process credential provider can re-request on expiry, and the provider can enforce that no credential is issued if the task_id is not in the active task list.", "Specify the threat model for credential interception in transit from the orchestration layer to the agent runtime \u2014 mTLS on the injection channel and in-memory-only credential storage are necessary but not sufficient if the agent runtime itself can be compromised; model what a runtime compromise exposes and whether the task-bound scope limits the damage.", "Review the interaction between NI-04 and NI-02 scope constraints: confirm that task-bound credentials issued via JIT still go through the DX-01/DX-03 sensitivity ceiling check, so that JIT issuance does not create a fast path around minimum-privilege enforcement." ], "failure_signals": [ "JIT credential injection implemented as environment variable injection into a long-running container \u2014 the credential persists in the process environment and is accessible to any process in the container namespace for the container's lifetime.", "No timeout-based dead-man's-switch for long-running tasks \u2014 a task that hangs indefinitely holds its credential indefinitely, defeating the JIT exposure-window guarantee." ] }, "legal_counsel": { "summary": "NI-04 provides the strongest available technical evidence that AI agent access to sensitive resources was time-limited to the duration of specific authorized tasks. The task-dispatch and revocation log creates a complete audit trail of when each agent had access to what, with millisecond-level precision.", "actions": [ "Confirm that the orchestration log retaining task dispatch and credential revocation events is treated as an evidentiary record with appropriate access controls \u2014 write access should be restricted to the orchestration layer service account and the IAM team, with no delete capability for the retention period.", "Review whether the task_id binding in JIT credentials constitutes a data processing record under applicable privacy law \u2014 if the task_id encodes personal data processing context, the credential issuance log itself may be subject to data subject access request obligations.", "Assess whether the JIT model satisfies the 'need-to-know' and 'least privilege' access control requirements of applicable data protection regulations more rigorously than alternative models, and document this assessment for regulatory submissions." ], "failure_signals": [ "Orchestration logs with delete capability granted to the engineering team, undermining the evidentiary integrity of the access record.", "No defined retention period for the JIT issuance and revocation log \u2014 creates uncertainty about whether the access record will be available if needed for litigation or regulatory inquiry after the fact." ] }, "grc_auditor": { "summary": "NI-04 is one of the most directly testable identity controls: the claim is that no standing credentials exist, which can be verified by inspecting the active token store between tasks. The reconciliation scan execution log is the primary audit artifact for continuous enforcement.", "actions": [ "Between task dispatch cycles, query the identity provider's active token store for task-bound credentials and verify the count is zero \u2014 this directly tests the 'no standing credentials' guarantee during idle periods.", "Pull the reconciliation scan log for the review period and verify: run frequency is at least every five minutes, no execution gaps exceed the maximum interval, and any orphaned credentials detected were revoked within one scan cycle.", "Sample ten task lifecycle sequences from the orchestration log and verify for each that: (a) a credential was issued within 5 seconds of task dispatch, (b) a revocation event was logged within 30 seconds of task termination, and (c) the task_id matches across the issuance, execution, and revocation log entries." ], "metrics": [ "Count of active task-bound credentials in the identity provider's token store at time of audit during an idle period (target: 0)", "Percentage of task lifecycle sequences in the review period with a corresponding credential revocation event logged within 30 seconds of task termination (target: >99.9%)" ], "failure_signals": [ "Non-zero count of task-bound credentials in the active token store during a verified idle period \u2014 indicates standing credentials exist contrary to the JIT guarantee.", "Task lifecycle sequences in the orchestration log with no corresponding credential revocation event \u2014 indicates hook failures are not being caught by the reconciliation scan." ] }, "it_operations": { "summary": "NI-04 requires a change to how agent workloads receive credentials. The operational model shifts from 'inject credentials at deployment time and the agent uses them indefinitely' to 'the orchestration layer issues a credential at task dispatch and the agent runtime consumes it for that task only.' This affects deployment templates, agent startup sequences, and failure handling.", "actions": [ "Update agent deployment templates to remove all credential injection at deployment time (static environment variables, mounted secrets, pre-configured API keys). The agent runtime must be architected to request credentials from the orchestration layer or an in-process credential provider at task startup rather than reading them from the environment.", "Implement a task timeout and dead-man's-switch in the orchestration layer for every task type: define the maximum expected duration, set a timer at dispatch, and trigger credential revocation and task termination if the timer expires before task completion \u2014 this prevents hung tasks from holding credentials indefinitely.", "Add operational runbooks for the case where a JIT credential issuance fails at task dispatch: define whether the task should be retried (with a new credential request) or failed and what the escalation path is \u2014 the orchestration layer must not proceed with a task that does not have a valid issued credential." ], "failure_signals": [ "Agent deployment manifests that still reference static credential mounts or environment variable injection \u2014 indicates the JIT migration is incomplete for those agent types.", "Tasks in the orchestration layer with no defined timeout or dead-man's-switch configuration \u2014 means a hung task will hold its JIT credential indefinitely, violating the core JIT guarantee." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "JIT credential issuance requires orchestration layer integration with the identity provider that most organizations have not built for AI agent workloads. The initial state is typically static API keys or long-lived service account tokens. Target state requires the orchestration layer to call the issuance endpoint at task dispatch, implement all four revocation hooks, and operate the reconciliation scan. The reconciliation scan is the most commonly skipped component and should be treated as a hard requirement for the control to be considered implemented." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer", "security-architect" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4", "fit": "direct", "rationale": "SP 800-63B-4's authenticator binding requirements tie authenticators to a subscriber account at issuance. NI-04 applies the binding principle to task context: credentials are bound to a specific task identifier and issued at task dispatch, making the credential's validity semantically tied to the task's active status rather than a calendar TTL.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 3", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 3 grants access on a per-session basis rather than through persistent standing sessions. NI-04 implements this at the task level for AI agents: credentials are issued dynamically at task dispatch and revoked at task termination, with no standing credential between tasks.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a76", "fit": "direct", "rationale": "RFC 9396 \u00a76 defines the authorization_details parameter in the token request, allowing the JIT issuance call to express precise task-specific resource and action requirements at the moment of issuance. NI-04 requires this structured scope expression so the issued task-bound credential reflects only the resources needed for that specific task dispatch.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS STS \u2014 Assume Role Session Policies", "rationale": "AWS STS AssumeRole with inline session policies enables JIT credential issuance scoped to the specific task: the caller requests a temporary credential with a session policy that restricts permissions to exactly what the current task requires, with a session duration matched to the task length (as short as 15 minutes). Credentials cannot be renewed without a new AssumeRole call with fresh authorization.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "AWS STS AssumeRole with inline session policies issues task-scoped temporary credentials on dispatch with no standing credential - JIT as required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Cross App Access \u2014 Identity Assertion Authorization Grant (ID-JAG)", "rationale": "Okta Cross App Access issues short-lived, task-scoped tokens on demand via the Identity Assertion Authorization Grant, an OAuth token-exchange profile. The agent requests a token specifying the exact resource scope for the current interaction; the resulting ID-JAG resource token is valid only for that interaction and cannot be reused for subsequent tasks without a new exchange.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Cross App Access (ID-JAG) issues short-lived task-scoped tokens on demand per interaction, matching the JIT no-standing-credential requirement.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud WIF \u2014 STS Token Exchange", "rationale": "Google Cloud Workload Identity Federation's Security Token Service (STS) token exchange endpoint issues short-lived access tokens on demand, replacing static service account keys with JIT credentials. External workloads exchange their identity provider tokens for Google access tokens that are valid for 1 hour and automatically expire, enforcing JIT issuance without manual credential management.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "GCP WIF STS token exchange issues short-lived tokens on demand, replacing static keys - the just-in-time issuance model the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Just-in-time (JIT) access; Part III \u2014 Privilege scoping (JIT/JEA with automatic expiration)", "fit": "direct", "rationale": "JIT access grants credentials only when needed, scoped to specific resources for defined durations, and revokes on completion \u2014 just-in-time credential issuance.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent task execution must be backed by a credential issued no earlier than task dispatch time and revoked no later than task completion or task failure, with no standing credential persisting between task executions for the same agent. The credential store in the agent runtime must be empty outside of an active task execution window.", "evidence_required": [ "jit_credential_issuance_log: Log of task dispatch events paired with credential issuance events, showing task_id, agent_id, credential_issued_at, and task_dispatched_at \u2014 confirming issuance at or after dispatch", "credential_revocation_log: Log of credential revocation events for each task, showing credential_id, task_id, revoked_at, and revocation_trigger (task_complete/task_failed) \u2014 confirming revocation at task boundary", "runtime_credential_scan_report: Periodic scan of agent runtime environments confirming no stored credentials exist in the runtime outside of an active task execution window", "standing_credential_absence_report: Evidence that the agent runtime has no persistent credential store \u2014 confirming credentials are held only in ephemeral memory during task execution" ], "machine_tests": [ "Inspect the agent runtime credential store between task executions \u2192 assert the credential store is empty or contains no valid, non-expired credentials", "Issue a JIT credential for task T1 and attempt to use it after task T1 completes \u2192 assert the resource server returns 401 with error=token_revoked or error=token_expired", "Dispatch a task and verify the credential issuance timestamp is within 5 seconds of the task dispatch timestamp \u2192 assert credential_issued_at >= task_dispatched_at for 100% of tasks", "Simulate a task failure mid-execution and verify the JIT credential is revoked within the defined failure-revocation SLA \u2192 assert revocation_log entry appears within SLA window" ], "human_review": [ "Review the agent runtime architecture to confirm there is no persistent credential cache, keychain, or secret store that retains credentials between task executions", "Assess the task failure handling path to verify that credential revocation is triggered by both successful completion and all failure modes \u2014 not only clean exits", "Verify that the JIT issuance mechanism does not allow credential pre-fetching before task dispatch, which would create a window of standing credential exposure" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Caching JIT credentials in the agent runtime between tasks to reduce issuance latency \u2014 creating standing credentials that defeat the entire JIT security model", "Issuing JIT credentials with a lifetime significantly longer than the expected task duration on the assumption that tasks may run long \u2014 leaving credentials valid long after task completion", "Triggering credential revocation only on clean task completion and not on task failure or exception \u2014 leaving valid credentials in the runtime after a failed execution", "Using the same credential for multiple sequential tasks dispatched to the same agent rather than issuing a fresh credential per task \u2014 aggregating task exposure under a single credential", "Pre-issuing credentials before task dispatch confirmation to avoid issuance latency \u2014 creating a window where a credential exists but no authorized task has been dispatched" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-05", "layer": "NI", "plane": "control", "name": "Identity Deprovisioning and Revocation", "plain": "Revoke all AI agent credentials immediately upon decommissioning, ownership change, or security event, and verify revocation has propagated to all dependent systems within a defined SLA.", "threat": { "tags": [ "orphaned-credential", "org-change-lag" ], "desc": "Orphaned credentials \u2014 valid credentials belonging to decommissioned AI agents \u2014 provide attackers with persistent access to enterprise resources long after the agent that legitimately held them has been retired. Organizational changes such as employee departures or role changes create a lag window where agent credentials delegated under that principal's authority remain active, enabling scope that no longer reflects the current authorization state. Without explicit SLA enforcement on revocation propagation, dependent systems may continue to honor stale credentials for hours or days. Org-change-triggered scope reduction is especially dangerous because the agent's credential is technically valid; the only signal that it is illegitimate is the change in the sponsoring principal's group membership." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a74", "title": "Authenticator revocation" }, { "id": "scim", "section": "RFC 7644 \u00a73.6", "title": "DELETE resource deprovisioning" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Identity Stores", "title": "Identity lifecycle termination" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-01" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-05 Identity Deprovisioning and Revocation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Event-driven deprovisioning pipeline with cascaded scope revocation and propagation SLA enforcement", "steps": [ "Wire decommissioning events (deployment shutdown, pipeline deletion, principal departure, security incident) to an automated revocation trigger that calls the identity provider's credential revocation endpoint within 60 seconds of event receipt.", "For org-change events, query the identity graph to enumerate all agent identities delegated under the affected principal or group; issue scope-reduction or full revocation for each identity without waiting for the next scheduled access review cycle. References apeiris://authority/controls/PA-01 \u2014 organizational hierarchy changes trigger immediate scope re-evaluation cascaded to all agent identities under affected principals.", "After issuing revocation, poll dependent systems (API gateways, resource servers, token introspection endpoints) to confirm revocation propagation; raise an alert and escalate if propagation SLA (60 seconds for critical, 15 minutes for standard) is exceeded.", "Emit a signed deprovisioning receipt to the identity audit log referencing the triggering event, all revoked credential identifiers, propagation confirmation timestamps, and residual-risk rating if any dependent system failed to confirm." ], "anti_patterns": [ "Relying solely on token expiry to decommission agent credentials, allowing a window up to the full TTL after the trigger event.", "Treating periodic access reviews (weekly or monthly) as the primary mechanism for handling org-change-triggered scope reduction.", "Issuing revocations to the identity provider without verifying propagation to downstream resource servers or API gateways." ] }, "validation": { "design_check": [ "Confirm decommissioning event pipeline is wired to automated revocation with sub-60-second SLA for critical identities.", "Verify org-change events from HR or directory systems trigger agent scope re-evaluation without requiring a manual review cycle.", "Confirm propagation verification step is implemented and raises an alert when dependent systems fail to confirm within SLA." ], "runtime_test": [ "Decommission a test agent and verify its credential is revoked within 60 seconds at the token introspection endpoint.", "Simulate a principal group membership change and verify all delegated agent scopes for that group are reduced within the defined TTL.", "Inject a propagation failure (block a dependent system from receiving the revocation) and confirm an escalation alert fires within the SLA window." ], "evidence": [ "revocation-log:Signed revocation receipt with credential IDs, triggering event, and propagation confirmation timestamps [unverified]", "propagation-report:Dependency system confirmation receipts showing revocation acknowledged within SLA [unverified]", "org-change-audit:Audit log entry linking principal group-membership change to downstream agent scope reduction events [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-05 closes the deprovisioning gap by treating every triggering event \u2014 decommission, ownership change, security incident, org change \u2014 as requiring immediate automated revocation rather than scheduled cleanup. The propagation SLA and verification step ensure the revocation is real, not just an IDP-level record update that downstream systems have not yet received.", "actions": [ "Wire deployment shutdown hooks to call the identity provider revocation endpoint synchronously before teardown completes.", "Build an org-change event consumer that traverses the identity delegation graph and issues scope-reduction calls for all affected agent identities.", "Implement a propagation poller that checks revocation state at each dependent resource server and pages on-call if SLA is breached." ], "failure_signals": [ "Decommissioned agent credentials still passing token introspection at a resource server 10 minutes after the decommission event.", "No revocation events in the identity audit log for a principal whose directory group membership changed last week." ] }, "security_architect": { "summary": "The critical design decision in NI-05 is that revocation must be event-driven, not expiry-driven. Relying on TTL to clear orphaned credentials accepts a breach window equal to the credential lifetime \u2014 potentially hours for standard credentials. The propagation verification loop is what converts a logical revocation into an operational revocation across a distributed token infrastructure.", "actions": [ "Design the deprovisioning event bus to be durable and at-least-once \u2014 a revocation trigger that fails silently is indistinguishable from no revocation at all.", "Require resource servers to support token introspection or short-lived access tokens with low max-age so propagation verification is possible without active push.", "Model the org-change cascade as a graph traversal: principal \u2192 all delegated agents \u2192 all resource grants \u2014 and ensure the cascade completes atomically or generates an incomplete-cascade alert." ], "failure_signals": [ "Identity provider shows a credential as revoked but the resource server continues accepting it \u2014 indicating the resource server is not consulting introspection or has a stale cache.", "Org-change events are delivered to the HR system but no corresponding revocation events appear in the identity audit log." ] }, "legal_counsel": { "summary": "Orphaned credentials following an employee departure represent a data access control failure that may constitute a breach of fiduciary duty, violate employment separation terms, or trigger breach notification obligations if the orphaned credential is subsequently used to access personal data. NI-05 provides the documented revocation process that demonstrates reasonable controls were in place.", "actions": [ "Ensure employment separation checklists explicitly reference AI agent credential revocation as a required step alongside system access removal.", "Require propagation confirmation receipts to be retained for a minimum of 24 months as evidence of prompt revocation in the event of a later dispute or regulatory inquiry.", "Review cross-organizational agent delegation agreements to confirm counterparty obligations to revoke downstream agent credentials upon notice of principal departure." ], "failure_signals": [ "Employee offboarding checklist does not reference AI agent credential revocation.", "Legal hold on a departed employee's account does not extend to AI agent credentials that were delegated under that employee's authority." ] }, "grc_auditor": { "summary": "NI-05 is the control that most auditors will probe first when reviewing AI agent identity lifecycle, because orphaned credentials are a well-documented audit finding and because org-change-triggered gaps are often invisible in point-in-time access reviews. The propagation SLA and receipt evidence provide the testable artifacts an auditor needs.", "actions": [ "Sample decommissioning events from the past 90 days and verify each has a corresponding signed revocation receipt in the audit log.", "Test the org-change trigger by querying the directory for group membership change events and cross-referencing the identity audit log for corresponding scope-reduction events within the defined TTL.", "Review the propagation confirmation reports to identify any instances where dependent systems failed to confirm revocation within SLA and assess whether compensating controls were applied." ], "metrics": [ "Mean time from decommissioning trigger to confirmed propagation across all dependent systems (target: <60s for critical, <15m for standard).", "Percentage of org-change events that triggered a corresponding agent scope-reduction within the defined TTL without requiring manual intervention (target: 100%)." ], "failure_signals": [ "Audit sample reveals decommissioned agent credentials with no corresponding revocation receipt in the identity audit log.", "Propagation confirmation reports show dependent systems consistently confirming revocation 30+ minutes after the IDP-level revocation, indicating a structural propagation gap." ] }, "it_operations": { "summary": "Operations owns the event wiring that makes NI-05 work. Without reliable event delivery from deployment systems, HR systems, and security incident platforms to the revocation trigger, the control exists on paper but fails in production. The propagation SLA monitoring must be part of the standard operations dashboard, not a one-time audit check.", "actions": [ "Integrate deployment teardown scripts with the identity provider revocation API so credential revocation is a mandatory step in the shutdown sequence, not a post-hoc cleanup task.", "Subscribe to directory group membership change events and route them to the org-change cascade handler; confirm the subscription is durable and will replay missed events on reconnect.", "Add revocation propagation SLA compliance to the identity operations dashboard and configure alerts for any breach within 5 minutes of the SLA deadline." ], "failure_signals": [ "Deployment teardown completes successfully but no revocation call appears in identity provider logs.", "Operations dashboard shows no revocation propagation metrics \u2014 indicating the monitoring hook was never implemented." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations revoke AI agent credentials only during manual offboarding processes, missing the org-change trigger entirely. Target state requires automated event-driven revocation with propagation SLA enforcement and audit receipts." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer", "it-operations" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a74", "fit": "direct", "rationale": "SP 800-63B-4 \u00a74 defines authenticator revocation and event-management requirements \u2014 applied here to AI agent credentials with explicit SLA enforcement and propagation verification beyond the base IdP revocation record.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC7644 \u00a73.6", "fit": "direct", "rationale": "SCIM DELETE operation provides the structured deprovisioning model; NI-05 extends it with SLA enforcement, propagation verification, and org-change cascade requirements.", "source_version": "2.0", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar's lifecycle expectations cover identity termination; NI-05 adds the org-change cascade and propagation SLA that the maturity model describes at a policy level but does not specify operationally.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Lifecycle Management \u2014 Deprovisioning", "rationale": "Okta SCIM deprovisioning sets active=false on agent identity resources, immediately revoking token issuance while preserving audit records for compliance. Okta for AI Agents includes a kill switch that prevents any new token requests from a deactivated agent identity; SCIM-based deprovisioning propagates revocation to all integrated applications simultaneously.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta SCIM deactivation and kill switch stop new token issuance, but do not verify revocation propagated to every dependent cache within an SLA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Role Deletion Revocation", "rationale": "AWS IAM role deletion or permission policy detachment immediately prevents new STS credentials from being issued with those permissions. For already-issued temporary credentials, AWS provides a mechanism to revoke active sessions on a role by attaching a deny-all policy with a condition on token issue time, invalidating all credentials issued before the revocation timestamp.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS role deletion and session revocation stop credential use, but do not confirm SLA-bound propagation to all dependent systems.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity for AI \u2014 Agent Gateway revocation", "rationale": "Ping Identity's Agent Gateway enforces runtime revocation of agent identity credentials; when an agent identity is deactivated in Agent IAM Core, the Agent Gateway's continuous authorization layer immediately begins rejecting all policy decisions for that identity, ensuring revocation takes effect before any cached credentials expire.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Ping Agent Gateway continuous authorization rejects every policy decision immediately on deactivation, enforcing runtime revocation propagation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Agent identity and authentication (certificate lifecycle management including rotation and revocation; CRL/OCSP); Part III \u2014 Automated response (revoke credentials)", "fit": "direct", "rationale": "Enterprise identity implements certificate revocation (CRL/OCSP) and automated response revokes credentials pending investigation \u2014 identity deprovisioning and revocation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "When an AI agent is decommissioned, changes ownership, or is subject to a security event, all associated credentials must be revoked within the defined SLA and revocation must be verified to have propagated to every dependent system \u2014 including token introspection endpoints, resource server caches, and federation trust registries \u2014 within the propagation window. No deprovisioned agent may successfully authenticate after the revocation SLA expires.", "evidence_required": [ "revocation_event_record: Record for each deprovisioning event showing agent_id, revocation_trigger, revoked_at timestamp, and list of credential_ids revoked", "propagation_verification_report: Evidence that revocation propagated to all dependent systems \u2014 token introspection endpoints, resource server caches, federation registries \u2014 within the defined propagation SLA", "post_revocation_rejection_log: Log showing that authentication attempts using revoked credentials after the revocation SLA returned 401 with error=token_revoked or error=invalid_client", "deprovisioning_completeness_checklist: Completed checklist for each deprovisioning event confirming all credential types (tokens, API keys, service account credentials, federation trust entries) were revoked" ], "machine_tests": [ "Deprovision a test agent and immediately attempt authentication with its previously valid credential \u2192 assert the response is 401 with error=token_revoked within the revocation SLA", "Deprovision a test agent and wait for the propagation window, then query each dependent system's token introspection endpoint \u2192 assert all return active=false for the revoked credential", "Simulate a security event trigger and measure time from event detection to credential revocation timestamp \u2192 assert revocation_at - event_detected_at is within the security-event revocation SLA", "Query the registry for agents with status=decommissioned and cross-reference with the token introspection endpoint \u2192 assert zero decommissioned agents have active=true credentials" ], "human_review": [ "Review a sample of 10 recent deprovisioning events and verify the deprovisioning completeness checklist was completed, including all credential types and dependent systems", "Assess whether the revocation propagation SLA is achievable across all dependent systems \u2014 particularly federated resource servers in different administrative domains that may have token caching", "Verify that ownership-change events trigger full deprovisioning of the prior owner's credentials and re-provisioning under the new owner, rather than merely updating the owner field in the registry" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Revoking the primary token while leaving API keys, service account credentials, or federation trust entries active \u2014 partial deprovisioning that leaves a persistent access path for the decommissioned agent", "Relying on token expiry as the revocation mechanism rather than active revocation \u2014 leaving credentials valid for their full remaining lifetime after a security event", "Failing to verify revocation propagation to dependent resource servers that cache token validation results \u2014 allowing a deprovisioned agent to authenticate from cache for the cache duration", "Treating deprovisioning as a registry status update only without issuing active revocation signals to dependent systems \u2014 creating a gap between registry state and enforcement state", "Using a deprovisioning SLA measured in days rather than minutes for security-event triggers \u2014 allowing a compromised credential to remain valid for an operationally meaningful period after the event" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-06", "layer": "NI", "plane": "control", "name": "Ghost Identity Detection and Remediation", "plain": "Continuously detect AI agent identities that have valid credentials but no active deployment backing them, and enforce remediation within defined SLAs before those ghost credentials can be exploited.", "threat": { "tags": [ "orphaned-credential", "identity-spoofing" ], "desc": "Ghost agents \u2014 provisioned identities whose associated deployments have been retired without triggering the credential revocation path \u2014 represent an invisible attack surface. Because the credential is technically valid, it will pass authentication checks at any resource server; an attacker who discovers a ghost credential gains the full scope of the original agent without any behavioral signal that the access is illegitimate. Ghost identities accumulate over time in environments with frequent deployment cycles and incomplete lifecycle hooks, and they are rarely discovered through standard access reviews because the agent appears as a valid provisioned identity with no explicit decommission record." }, "standard": [ { "id": "iso_24760", "section": "\u00a77", "title": "Managing identity information \u2014 lifecycle" }, { "id": "scim", "section": "RFC 7644 \u00a73.4.2", "title": "Query resources \u2014 filtering and enumeration" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Identity Stores", "title": "Identity lifecycle termination" } ], "sources": [ { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/NI-06 Ghost Identity Detection and Remediation control.", "reviewed_on": "2026-07-02" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/NI-06 Ghost Identity Detection and Remediation control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-06 Ghost Identity Detection and Remediation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-06 Ghost Identity Detection and Remediation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-06 Ghost Identity Detection and Remediation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Continuous reconciliation scan correlating identity registry against live deployment inventory with automated ghost classification and SLA-gated remediation", "steps": [ "Run a continuous reconciliation job (minimum hourly) that queries the identity registry for all provisioned AI agent identities and cross-references each against the live deployment inventory; flag any identity whose associated deployment is absent, stopped, or deleted as a candidate ghost identity.", "Apply a ghost classification decision tree: if no active deployment record exists within the retention window AND no explicit decommission event was recorded, classify as ghost-confirmed with a remediation SLA of 48 hours for critical-scope credentials or 7 days for standard-scope credentials.", "For each ghost-confirmed identity, automatically revoke credentials and open a remediation ticket with the sponsoring principal's team; require acknowledgment within 24 hours and a root-cause analysis explaining why the lifecycle hook did not fire.", "Track ghost identity rate over rolling 30-day windows and feed the metric into the NI layer maturity dashboard; persistent ghost accumulation indicates a lifecycle hook failure requiring architectural remediation rather than one-off cleanups." ], "anti_patterns": [ "Relying on annual access reviews to discover ghost identities rather than continuous reconciliation against the live deployment inventory.", "Treating a ghost identity as low-priority because its credential scope appears narrow \u2014 ghost credentials at any scope provide authentication primitives usable in reconnaissance or chained attacks.", "Closing ghost remediation tickets without a root-cause analysis, allowing the lifecycle hook failure to recur indefinitely." ] }, "validation": { "design_check": [ "Confirm reconciliation job runs at least hourly and compares identity registry against an authoritative live deployment inventory source.", "Verify ghost classification decision tree distinguishes between intentional decommission (explicit revocation event) and silent retirement (no event), applying SLA only to the latter.", "Confirm remediation ticket workflow requires root-cause analysis completion before the ticket can be closed." ], "runtime_test": [ "Retire a test deployment without triggering the decommission lifecycle hook and verify the reconciliation job classifies the associated identity as ghost-confirmed within one reconciliation cycle.", "Confirm that after ghost classification, the credential is revoked and a remediation ticket is opened within the defined SLA.", "Inject a persistent ghost (recurring silent retirements) and verify the ghost identity rate metric increases and triggers the architectural-remediation escalation threshold." ], "evidence": [ "reconciliation-report:Hourly reconciliation scan output showing identity-to-deployment correlation results and ghost classification decisions [unverified]", "remediation-ticket:Ghost identity remediation ticket with root-cause analysis and credential revocation confirmation [unverified]", "ghost-rate-metric:Rolling 30-day ghost identity rate dashboard extract showing trend and threshold compliance [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-06 requires the identity registry and the deployment inventory to be continuously reconciled \u2014 two systems that are typically maintained by different teams (IAM and platform engineering) and are rarely integrated. The engineering challenge is making the deployment inventory queryable in a way the reconciliation job can trust.", "actions": [ "Build or integrate an API that provides an authoritative, near-real-time view of active AI agent deployments queryable by the reconciliation job.", "Implement ghost classification logic as a pure function with deterministic output so results are auditable and reproducible across reconciliation cycles.", "Automate credential revocation on ghost-confirmed classification rather than routing through a human review step \u2014 manual review introduces delay that negates the SLA." ], "failure_signals": [ "Reconciliation job queries a stale deployment inventory cache rather than a live source, producing false negatives for ghost candidates.", "Ghost remediation tickets accumulate without root-cause analysis entries, indicating the ticket workflow is being bypassed." ] }, "security_architect": { "summary": "Ghost identities are a structural artifact of decoupled identity and deployment lifecycle management. NI-06 treats them as an ongoing detection problem rather than an onboarding gap, accepting that some ghosts will always exist and focusing on minimizing their dwell time and scope exposure.", "actions": [ "Design the identity registry to store a deployment reference ID at provisioning time, making the reconciliation join unambiguous and resistant to naming collisions.", "Require deployment platforms to expose a lifecycle event stream (deployed, updated, retired) that the reconciliation job can consume rather than polling a point-in-time inventory snapshot.", "Model the ghost rate metric as a leading indicator of NI-05 lifecycle hook failures \u2014 a rising ghost rate signals decommissioning process breakdown before it reaches the scale of a security incident." ], "failure_signals": [ "Identity registry does not store deployment reference IDs, forcing the reconciliation job to rely on naming convention matching \u2014 which is brittle and produces false negatives.", "Ghost rate metric is not tracked or reviewed, leaving the signal invisible to the team." ] }, "legal_counsel": { "summary": "Ghost identities with access to personal data or regulated systems may constitute unauthorized access if the credential holder is no longer a current principal with a legitimate business purpose. Legal should ensure ghost identity SLAs are documented and enforced, and that the remediation record provides evidence of prompt response.", "actions": [ "Confirm that the 48-hour remediation SLA for critical-scope ghost identities is documented in the identity governance policy and referenced in the organization's data access control standard.", "Ensure ghost remediation records are retained for audit purposes and available for regulatory inspection, particularly for credentials that touched regulated data during the ghost window.", "Advise on whether ghost credential use during the dwell window requires breach notification assessment under applicable data protection law." ], "failure_signals": [ "No documented SLA for ghost identity remediation in the identity governance policy.", "Ghost remediation records are not retained beyond the remediation ticket closure date, leaving no evidence of the response timeline for future regulatory review." ] }, "grc_auditor": { "summary": "Ghost identity detection rate and dwell time are two of the most operationally meaningful metrics in the NI layer. Auditors should sample ghost identity events from the past quarter and verify SLA compliance on remediation, root-cause completion, and credential revocation timing.", "actions": [ "Pull all ghost-confirmed identity events from the past 90 days and calculate mean dwell time (time from last active deployment to ghost classification).", "Verify that each ghost remediation ticket has a completed root-cause analysis entry and that the root cause was addressed \u2014 not just the credential revoked.", "Assess the 30-day ghost identity rate trend for evidence of lifecycle hook improvement or degradation over time." ], "metrics": [ "Mean ghost identity dwell time from silent deployment retirement to credential revocation (target: <48h for critical, <7d for standard).", "Percentage of ghost remediation tickets with completed root-cause analysis closed within SLA (target: 100%)." ], "failure_signals": [ "Ghost remediation tickets older than 7 days with no root-cause analysis entry.", "Ghost identity rate trend is stable or increasing rather than decreasing, indicating lifecycle hook failures are not being addressed structurally." ] }, "it_operations": { "summary": "Operations is the team most likely to silently retire deployments without triggering lifecycle hooks \u2014 because deployment teardown is a performance-sensitive path and identity revocation is seen as a cleanup task. NI-06 makes the cost of that pattern visible through the ghost rate metric and the remediation ticket burden.", "actions": [ "Add identity revocation calls to the standard deployment teardown runbook as a mandatory step, not a post-teardown task.", "Subscribe to the ghost classification alert stream and route notifications to the on-call rotation for the owning team, not just to a generic IAM inbox.", "Review the ghost rate metric weekly in operations stand-up to identify deployment pipeline stages that are consistently producing ghosts." ], "failure_signals": [ "Deployment teardown runbook does not include an identity revocation step.", "Ghost classification alerts are routed to a shared inbox that is not actively monitored by any on-call rotation." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Ghost identity detection is typically absent from AI agent identity programs; organizations discover ghosts only during annual access reviews or post-incident forensics. Target managed state requires continuous automated reconciliation with SLA-enforced remediation and a tracked ghost rate metric." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer", "it-operations" ], "frameworks": [ { "framework": "iso_24760", "requirement_id": "\u00a77", "fit": "direct", "rationale": "ISO/IEC 24760-1 \u00a77 covers managing identity information across its lifecycle, including termination \u2014 NI-06 operationalizes the detection of identities that have not completed lifecycle termination correctly.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC 7644 \u00a73.4.2", "fit": "partial", "rationale": "SCIM's query operations (RFC 7644 \u00a73.4.2) provide the standard model for enumerating and filtering provisioned identities; NI-06 extends this with cross-system reconciliation against a live deployment inventory not covered by SCIM alone.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "adjacent", "rationale": "The CISA ZTMM Identity pillar's lifecycle termination expectation covers deliberate deprovisioning; NI-06 addresses the failure mode where termination did not occur, which the model does not specify but which Zero Trust assumes will be detected and remediated.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Access Analyzer \u2014 Unused Access Findings", "rationale": "AWS IAM Access Analyzer Unused Access findings identify IAM roles with permissions that have not been exercised in 90 days and flag service accounts with no recorded activity, enabling systematic detection and remediation of ghost identities. The findings include last-used timestamps and unused permission details to support prioritized remediation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Access Analyzer unused-access findings detect stale/unused roles as a proxy, but not credentials lacking active-deployment backing.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta ISPM \u2014 Unmanaged Agent Discovery", "rationale": "Okta Identity Security Posture Management (ISPM) continuously discovers unmanaged, unregistered service accounts and AI agents across the identity estate, flagging them for human review and mandatory registration. ISPM's risk scoring prioritizes ghost identities with elevated privileges for immediate remediation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta ISPM discovers unmanaged/unregistered agents, related to ghost detection but not the valid-credential-without-deployment cross-reference.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 AI governance policies (Address Shadow AI); Part II \u2014 Identity and privilege abuse", "fit": "partial", "rationale": "Doc's Shadow AI (tools/agents used without IT approval) is the ghost-identity risk. Partial: doc does not prescribe an orphaned-credential / ghost-identity detection mechanism.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The system must continuously maintain a ghost identity detection scan that identifies any AI agent credential that is valid and non-expired but has no active, confirmed deployment backing it, and must demonstrate that every detected ghost identity is either remediated (revoked or re-associated with an active deployment) or escalated within the defined remediation SLA \u2014 with no ghost identity remaining unresolved beyond that SLA.", "evidence_required": [ "ghost_detection_scan_report: Most recent scan report listing all credentials cross-referenced against active deployment registry, identifying credentials with no active deployment backing, and scan_timestamp", "remediation_event_log: Log of all ghost identity remediation events showing ghost_credential_id, detected_at, remediation_action (revoked/re-associated), remediated_at, and time_to_remediate", "deployment_registry_snapshot: Current snapshot of all confirmed active agent deployments used as the reference for ghost detection cross-referencing", "sla_compliance_report: Report showing percentage of detected ghost identities remediated within the defined SLA in the past 30 days \u2014 target 100% within SLA" ], "machine_tests": [ "Terminate an agent deployment without triggering the deprovisioning workflow in a test environment, then run the ghost detection scan \u2192 assert the orphaned credential appears in the ghost detection report within one scan cycle", "Inject a test ghost credential (valid credential with no deployment record) and verify the detection scan identifies it \u2192 assert detection occurs within one scan cycle and an alert is generated", "Measure time from ghost identity detection to remediation event for all ghost identities detected in the past 30 days \u2192 assert 100% of detections were remediated within the defined SLA", "Query the credential registry for all credentials with status=active and cross-reference against the deployment registry \u2192 assert zero active credentials exist with no matching active deployment record" ], "human_review": [ "Review the ghost detection scan logic to verify it covers all credential types \u2014 tokens, API keys, service account credentials, and federation trust entries \u2014 not only primary OAuth tokens", "Assess whether the deployment registry used as the cross-reference source is kept current and reflects actual running deployments, not just intended deployments", "Verify that the remediation SLA is appropriate for the risk tier of ghost credentials \u2014 high-privilege ghost identities should have a shorter SLA than low-privilege ones" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Running ghost detection only on a weekly or monthly schedule rather than continuously \u2014 leaving orphaned credentials valid for extended periods between scans", "Treating ghost identity detection as a reporting-only control without an enforced remediation SLA \u2014 producing lists of ghost identities that accumulate without action", "Cross-referencing only against the intended deployment registry (what should be running) rather than the actual runtime deployment registry (what is confirmed running) \u2014 missing agents that were deployed then silently terminated", "Scoping ghost detection only to credentials issued through the formal provisioning gate and missing credentials issued through shadow IAM processes or direct API calls", "Using credential last-use timestamp as a proxy for active deployment \u2014 a ghost credential that was recently stolen and used would appear 'active' by this metric while having no legitimate deployment" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-07", "layer": "NI", "plane": "control", "name": "Credential Storage and Secrets Hygiene", "plain": "Prohibit storage of AI agent credentials in any unprotected location \u2014 model prompts, environment variables, code repositories, or logs \u2014 and require all secrets to be stored in an approved secrets management system with encryption at rest and retrieval audit logging.", "threat": { "tags": [ "credential-compromise", "lateral-movement" ], "desc": "AI agent credentials stored in plaintext environment variables, embedded in container images, or included in model context windows are routinely exposed through log aggregation, image registry scanning, and prompt injection attacks. Once an agent credential is present in a logging system or code repository, it is effectively public \u2014 it may persist in version history, log archives, or backup systems for years after the immediate exposure is remediated. Lateral movement from a compromised credential is particularly damaging when the credential carries broad scope, because the attacker can impersonate the agent across every resource the agent was authorized to access without triggering behavioral anomaly detection." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "Authenticator requirements \u2014 protection of secrets" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Strict enforcement for credential access" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Authentication", "title": "Credential protection" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-07 Credential Storage and Secrets Hygiene control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/NI-07 Credential Storage and Secrets Hygiene control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-07 Credential Storage and Secrets Hygiene control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-07 Credential Storage and Secrets Hygiene control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/NI-07 Credential Storage and Secrets Hygiene control.", "reviewed_on": "2026-07-01" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds credential storage / secrets hygiene in Phase 6 credential isolation.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Secrets-manager-first credential delivery with pre-commit scanning, runtime injection controls, and retrieval audit logging", "steps": [ "Define an approved secrets storage list (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) and enforce policy that all AI agent credentials must be stored in an approved secrets manager at provisioning time \u2014 no credential is ever written to disk, environment variable, or container image directly.", "Integrate pre-commit and CI/CD pipeline scanning (e.g., git-secrets, truffleHog, Gitleaks) to detect any credential strings committed to code repositories or configuration files; block the commit or pipeline stage on detection and require manual review before the branch can merge.", "At runtime, inject credentials into the agent process via the secrets manager's in-memory injection mechanism (e.g., Vault agent sidecar, AWS SDK credential provider chain) so the credential is never written to the filesystem or exposed as a process environment variable readable by co-resident processes.", "Enable audit logging for every credential retrieval from the secrets manager, including: requesting entity, credential identifier, timestamp, and source IP; alert on retrieval patterns inconsistent with the agent's declared task schedule or frequency." ], "anti_patterns": [ "Passing credentials to AI agent containers as Docker environment variables defined in a compose file or Kubernetes manifest stored in version control.", "Including credentials in the system prompt or context window of model API calls on the assumption that the model will not log or expose them.", "Rotating credentials by updating the value in the environment variable at rest rather than rotating the secret in the secrets manager and letting the injection mechanism refresh it." ] }, "validation": { "design_check": [ "Confirm all credential issuance paths write credentials to an approved secrets manager rather than to environment variables or configuration files.", "Verify pre-commit and CI/CD scanning is active on all repositories containing agent configuration or deployment manifests.", "Confirm runtime credential injection uses the secrets manager SDK or sidecar mechanism and that no credential value is written to the container filesystem or exposed as a process environment variable." ], "runtime_test": [ "Attempt to deploy an agent with a hardcoded credential in its environment manifest and verify the pipeline scan blocks the deployment.", "Retrieve a credential from the secrets manager using an identity not associated with the agent's declared task schedule and confirm an anomaly alert fires.", "Inspect the runtime environment of a live agent process and verify no credential values are present in process environment variables or on-disk files." ], "evidence": [ "secrets-manager-audit:Credential retrieval audit log from the approved secrets manager showing all retrievals linked to authorized agent identities [unverified]", "scan-report:CI/CD pipeline scan report showing zero credential-string detections across all merged commits in the review period [unverified]", "deployment-manifest-review:Review record confirming no credential values are present in any environment variable definition in deployment manifests [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-07 requires the credential delivery path to be redesigned from the most common pattern (environment variable injection at container start) to a secrets-manager-first pattern where credentials are never written outside the secrets manager's boundary. The engineering investment is in the injection plumbing, not in policy.", "actions": [ "Migrate all agent deployment configurations from environment-variable credential injection to secrets manager SDK or sidecar-based injection.", "Audit all existing agent container images for embedded credentials using a registry scanner and remediate any findings before the next deployment cycle.", "Implement a retrieval anomaly detection rule in the secrets manager audit log that pages when a credential is retrieved outside its expected task window." ], "failure_signals": [ "Agent deployment manifests in version control contain environment variable definitions with names matching credential patterns (e.g., API_KEY, SECRET, TOKEN).", "Secrets manager audit log shows credential retrievals from IP addresses not associated with the agent's declared deployment environment." ] }, "security_architect": { "summary": "The most common credential hygiene failure in AI agent deployments is not malicious \u2014 it is developers choosing the path of least resistance, which is environment variables. NI-07 requires the platform to make the secure path the easy path by providing a well-documented secrets injection pattern that requires no additional developer effort beyond what environment variables require.", "actions": [ "Publish a golden-path secrets injection template for each supported runtime (container, serverless, VM) so developers have a copy-paste secure credential delivery pattern.", "Require secrets manager integration as a deployment gate in the CI/CD platform so deployments without a valid secrets manager binding fail before reaching production.", "Design the retrieval audit log alert rules collaboratively with the IAM team to avoid alert fatigue from expected retrieval patterns (scheduled tasks, burst workloads)." ], "failure_signals": [ "No golden-path secrets injection template exists, leaving developers to invent their own patterns \u2014 which revert to environment variables under time pressure.", "Deployment gate for secrets manager integration is advisory rather than blocking, allowing non-compliant deployments to proceed with a warning." ] }, "legal_counsel": { "summary": "Credentials stored in code repositories may be subject to discovery in litigation and may expose the organization to liability if they provide access to third-party systems under contractual credential protection obligations. NI-07's repository scanning requirement is a minimum control for demonstrating reasonable care.", "actions": [ "Review vendor contracts and API access agreements for credential protection requirements and confirm NI-07 controls satisfy those requirements.", "Ensure the secrets hygiene policy is documented and signed off at the data security policy level, not just as an engineering guideline, so it is enforceable in employment and vendor contexts.", "Assess whether credential exposure events (even if credentials are rotated promptly) require breach notification under applicable law or contract terms." ], "failure_signals": [ "No documented credential protection standard in the organization's security policy \u2014 NI-07 is implemented only as an informal engineering practice.", "Vendor API access agreements require credential protection controls that the organization cannot demonstrate are in place." ] }, "grc_auditor": { "summary": "Credential storage hygiene is one of the most directly auditable controls in the NI layer \u2014 the evidence is either in the repository scan reports and secrets manager audit logs, or it is absent. Auditors should focus on whether the controls are actually blocking non-compliant deployments or merely detecting them after the fact.", "actions": [ "Review CI/CD pipeline scan configurations to confirm they are blocking rather than warning on credential detections.", "Sample secrets manager audit logs for the past 90 days and verify all retrievals are linked to known authorized agent identities with expected retrieval patterns.", "Scan a sample of deployment manifests and container image configurations for hardcoded or environment-variable credential patterns as a spot-check against the pipeline scan." ], "metrics": [ "Number of credential-string detections in CI/CD pipeline scans per month (target: zero reaching merge).", "Percentage of AI agent credential retrievals from the secrets manager linked to an authorized task execution event in the same time window (target: 100%)." ], "failure_signals": [ "CI/CD pipeline scan is configured in warning mode rather than blocking mode, allowing credential-containing commits to merge.", "Secrets manager audit log shows retrievals with no corresponding task execution events \u2014 indicating out-of-band credential use." ] }, "it_operations": { "summary": "Operations teams are often the ones who introduce credential hygiene failures under pressure \u2014 copying credentials into environment variables to debug a failing deployment, or hardcoding a key to unblock a production incident. NI-07 requires those workarounds to be explicitly prohibited in runbooks and for the secrets manager injection to be robust enough that it is the natural first option in an incident.", "actions": [ "Remove all instructions from deployment runbooks that suggest using environment variables as a credential delivery mechanism \u2014 replace with the approved secrets manager injection pattern.", "Train on-call engineers on emergency secrets access procedures (break-glass vault access) so that incident response does not require bypassing the secrets manager.", "Monitor the secrets manager retrieval audit log as part of the daily operations review to catch anomalous retrieval patterns before they escalate." ], "failure_signals": [ "On-call runbooks contain instructions to copy credentials into environment variables as a troubleshooting step.", "Secrets manager retrieval audit log is not included in the daily operations review, leaving anomalous patterns undetected until the next security review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "The majority of AI agent deployments use environment variable credential injection as the default pattern. Target state requires secrets manager injection as the only approved mechanism, enforced by a blocking CI/CD gate and validated by runtime inspection." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "platform-engineer", "iam-team", "security-architect" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "direct", "rationale": "SP 800-63B-4 \u00a73's authenticator requirements include protecting authenticator secrets in storage and handling \u2014 NI-07 applies these protection standards to AI agent credentials across all storage contexts.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 6's strictly enforced, dynamic authentication and authorization requires that access to credential material itself be controlled and audited; NI-07 implements this through secrets manager gating and retrieval audit logging.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar's credential protection expectations align with NI-07's prohibition on unprotected storage; NI-07 adds specific storage location prohibitions and a mandatory secrets manager requirement not detailed in the model.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Well-Architected SEC02-BP03 \u2014 Secrets Management", "rationale": "AWS Well-Architected Security Pillar SEC02-BP03 requires storing all machine credentials in a managed vault such as AWS Secrets Manager with automated rotation, centralized access logging, and IAM-controlled retrieval. Secrets must never be stored in source code, environment variables, or unencrypted configuration files; Secrets Manager audit logs record every retrieval event.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "AWS Secrets Manager (SEC02-BP03) stores machine credentials in a managed vault with rotation and retrieval logging - the hygiene the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Secret Manager \u2014 Credential Hygiene", "rationale": "Google Cloud Secret Manager provides centralized credential storage with IAM-controlled access, automatic version rotation, and Cloud Audit Log entries for every access event. Google SAIF requires that AI system credentials never be stored in code or configuration files; Secret Manager integration is the prescribed pattern for all workload credential storage.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "GCP Secret Manager centralizes credential storage with IAM access, version rotation and per-access audit logs, satisfying the secrets-hygiene requirement.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Credential isolation (credentials never in code or configuration files; inject at runtime from secrets management)", "fit": "direct", "rationale": "Doc requires per-agent credentials injected at runtime from secrets management that logs access and supports emergency revocation; secrets in a lockfile are trivially found \u2014 credential storage and secrets hygiene.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All AI agent credentials \u2014 API keys, client secrets, certificates, and bearer tokens \u2014 must be stored exclusively in an approved secrets management system. No credential may appear in environment variables, container image layers, configuration files, code repositories, log streams, or model context windows at rest or in transit.", "evidence_required": [ "secrets_manager_audit_log showing all agent credential reads with agent_id, secret_arn, and access_timestamp, confirming zero direct environment-variable-based credential reads", "ci_cd_pipeline_scan_report confirming no credential patterns detected in Dockerfiles, Helm values, or application configs across all build stages", "pre_commit_hook_scan_log showing credential pattern detection active on all agent-related repositories with zero unblocked violations in the audit window", "credential_rotation_record listing each agent credential with last_rotated timestamp, rotation_frequency_policy, and next_rotation_due date" ], "machine_tests": [ "Inspect running agent container environment variables \u2192 assert no credential patterns (API_KEY, SECRET, TOKEN, PASSWORD) found in env output", "Scan container image layers for credential patterns using a secrets scanner \u2192 assert zero high-severity secrets findings across all image layers", "Revoke secrets manager access for a test agent and invoke it \u2192 assert agent fails with secrets_manager_access_denied rather than falling back to a hardcoded credential", "Search application log output for known credential format patterns \u2192 assert zero matches in log aggregation output for the past 7 days" ], "human_review": [ "Review the approved secrets manager list and confirm all agent credential storage paths are registered, with no exceptions granted to individual teams", "Assess log aggregation configuration to verify credential masking patterns are active and validated against known credential formats", "Verify rotation policy documents specify maximum credential lifetimes per credential type and are enforced through automated rotation jobs with alerting on missed rotations" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Injecting agent API keys as plaintext environment variables in Kubernetes pod specs or docker-compose files where they are readable by any process in the container", "Storing agent private keys or client secrets in application configuration files committed to version-controlled repositories, persisting the exposure indefinitely in git history", "Logging full Authorization header values in HTTP access logs, exposing bearer tokens to every system that reads the log aggregation stream", "Embedding credential values directly in agent model system prompts or context windows where they appear in inference traces and output records", "Reusing a single shared service account credential across multiple distinct agent identities instead of issuing per-agent isolated secrets" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-08", "layer": "NI", "plane": "control", "name": "Break-Glass Identity and Emergency Access", "plain": "Define and enforce a controlled break-glass identity path for emergency AI agent access, requiring dual authorization, strict time limits, automatic post-use revocation, and mandatory incident review for every activation.", "threat": { "tags": [ "privilege-escalation", "credential-compromise" ], "desc": "Break-glass access paths are among the most exploited privilege escalation vectors in enterprise environments because they are designed to bypass normal controls \u2014 making them high-value targets for both external attackers and malicious insiders. Without strict dual-authorization, time limits, and automatic revocation, a break-glass credential once activated may remain valid indefinitely, converting a temporary emergency mechanism into a persistent privileged backdoor. The absence of a separate break-glass identity namespace means emergency access overlaps with production identity controls, obscuring the emergency activation in normal access logs and making it difficult to detect unauthorized break-glass use through behavioral monitoring." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4", "title": "Authenticator assurance and lifecycle" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Access Management", "title": "Emergency access governance" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/NI-08 Break-Glass Identity and Emergency Access control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/NI-08 Break-Glass Identity and Emergency Access control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/NI-08 Break-Glass Identity and Emergency Access control.", "reviewed_on": "2026-07-02" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/NI-08 Break-Glass Identity and Emergency Access control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/NI-08 Break-Glass Identity and Emergency Access control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Dual-authorized, time-boxed break-glass identity with separate namespace, automatic post-use revocation, and mandatory incident ticket", "steps": [ "Establish a separate break-glass identity namespace (e.g., bg-agent-[environment]) with distinct credential identifiers, separate audit log stream, and no overlap with production AI agent identities; provision break-glass identities in advance with narrow scope defined for the specific emergency scenario each is intended to address.", "Require dual authorization from two independent approvers (security on-call and the requesting principal's manager or a designated deputy) before any break-glass credential is activated; implement the authorization as an approval workflow with a tamper-evident record and a maximum approval window of 15 minutes before the request expires and must be resubmitted.", "Enforce a hard credential expiry of 4 hours from activation regardless of task completion status; implement the expiry at the identity provider level (not as a manual cleanup task) so the credential self-destructs without depending on the activating engineer to remember to revoke it.", "On every activation, automatically open an incident ticket referencing the break-glass identity ID, activation timestamp, approver identities, declared emergency justification, and intended scope; require the incident ticket to include a post-incident review entry within 48 hours of deactivation, assessing whether the activation was necessary and whether process changes can reduce future break-glass reliance." ], "anti_patterns": [ "Sharing a single break-glass credential across multiple engineers or teams rather than issuing individual break-glass identities per activation to maintain individual accountability.", "Setting the break-glass credential TTL to 24 hours or longer because 4 hours is not enough time to resolve complex incidents \u2014 a signal that the underlying incident response process needs redesign, not the break-glass TTL.", "Closing break-glass incident tickets without completing the post-incident review, treating emergency access as a normal operational event rather than a process exception requiring root-cause analysis." ] }, "validation": { "design_check": [ "Confirm break-glass identities are provisioned in a separate namespace with distinct audit log stream, and that no production agent identity shares the break-glass namespace prefix.", "Verify dual-authorization workflow cannot be bypassed by a single approver \u2014 confirm the workflow engine enforces the two-approver requirement at the technical level, not as a policy expectation.", "Confirm break-glass credential expiry is enforced at the identity provider level with a maximum 4-hour TTL that cannot be extended without reinitiating the dual-authorization workflow." ], "runtime_test": [ "Activate a break-glass identity with a single approver and verify the authorization workflow rejects the activation.", "Activate a break-glass identity with dual approval and verify: (a) a credential is issued with a 4-hour maximum TTL, (b) an incident ticket is automatically opened within 60 seconds of activation, (c) the credential self-revokes at TTL expiry without manual action.", "Attempt to extend a break-glass credential TTL beyond 4 hours without reinitiation and verify the extension is rejected." ], "evidence": [ "bg-activation-log:Break-glass identity audit log showing activation event with dual approver identities, timestamp, and declared justification [unverified]", "incident-ticket:Automatically opened incident ticket for each break-glass activation with post-incident review entry completed within 48 hours [unverified]", "expiry-verification:Identity provider log confirming break-glass credential self-revocation at TTL expiry without manual intervention [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "NI-08 requires the break-glass identity path to be a first-class provisioned mechanism \u2014 not an ad-hoc process of temporarily elevating a production credential. The engineering work is in the authorization workflow, the separate namespace, and the IDP-enforced TTL that makes manual revocation unnecessary.", "actions": [ "Provision break-glass identity templates for each environment and scenario class (data access, network access, deployment rollback) in advance so activation does not require on-the-fly identity creation under incident pressure.", "Implement the dual-authorization workflow in the identity management system rather than as an out-of-band approval process (Slack message, email chain) to ensure tamper-evident records.", "Wire the identity provider credential TTL enforcement so the break-glass credential self-revokes at 4 hours without depending on any post-incident manual step." ], "failure_signals": [ "Break-glass activations show single-approver entries in the authorization log.", "Break-glass credentials are still valid in the identity provider more than 4 hours after activation with no re-authorization record." ] }, "security_architect": { "summary": "The architectural risk in break-glass systems is that they accumulate entropy over time \u2014 justified exceptions that were never fully revoked, shared credentials that were never individualized, TTLs that were quietly extended. NI-08 addresses this by making the break-glass path self-enforcing: dual auth, IDP-enforced TTL, automatic incident ticket \u2014 nothing depends on post-incident discipline.", "actions": [ "Design the break-glass namespace to be lexicographically distinct from production namespaces so behavioral monitoring rules can apply different anomaly thresholds to break-glass activations.", "Implement a break-glass activation rate monitor that alerts when activations exceed a baseline (e.g., more than 3 activations per 30-day window per environment) as a signal of structural process failure.", "Require that the post-incident review assess whether the break-glass activation could have been avoided by improving the standard operational process \u2014 feed findings back into the process improvement backlog." ], "failure_signals": [ "Break-glass activations are increasing in frequency over time without a corresponding increase in declared incidents \u2014 indicating break-glass is being used as a convenience mechanism rather than a true emergency path.", "Break-glass credential identifiers are not distinguishable from production credential identifiers in behavioral monitoring logs." ] }, "legal_counsel": { "summary": "Break-glass access to AI agent capabilities \u2014 particularly capabilities that touch personal data or execute consequential business actions \u2014 may require contemporaneous logging and post-incident documentation to satisfy regulatory obligations around access control and incident response. NI-08's mandatory incident ticket and post-incident review provide this documentation.", "actions": [ "Confirm that break-glass activation records are retained for the full retention period required by applicable data protection regulations (typically 3 to 7 years depending on jurisdiction and data type).", "Review whether break-glass activations that accessed personal data require breach notification assessment, particularly where the access was not part of a declared emergency.", "Ensure employment agreements and acceptable use policies explicitly address break-glass access obligations \u2014 including the prohibition on sharing break-glass credentials and the mandatory post-incident review." ], "failure_signals": [ "Break-glass activation records are not subject to the same retention policy as standard access logs.", "No employment policy language addresses break-glass access obligations \u2014 leaving engineers without clear guidance on acceptable use." ] }, "grc_auditor": { "summary": "Break-glass controls are a classic audit test point because they represent a designed exception to normal controls. Auditors should verify that every activation in the review period has a dual-authorization record and a completed post-incident review, and should flag any activation without both as a control failure.", "actions": [ "Pull all break-glass activation events from the past 12 months and verify each has: dual approver identities, a declared justification, a maximum 4-hour TTL, an automatic incident ticket, and a completed post-incident review.", "Test the dual-authorization enforcement by attempting to activate a break-glass identity with a single approver in a non-production environment.", "Review the break-glass activation rate trend and assess whether increasing frequency indicates structural process failure warranting a formal process improvement recommendation." ], "metrics": [ "Percentage of break-glass activations with completed post-incident reviews within 48 hours of deactivation (target: 100%).", "Mean break-glass credential lifetime from activation to confirmed revocation (target: 4 hours or less)." ], "failure_signals": [ "Break-glass activation events in the audit log with a single approver entry, indicating dual-authorization was not enforced.", "Post-incident review entries are absent or trivial (one-line entries) for activations that accessed sensitive data or executed consequential actions." ] }, "it_operations": { "summary": "Operations teams are the primary users of break-glass access, and they are also the most likely to develop workarounds when the break-glass process is seen as too slow for a production incident. NI-08 must be designed so that the dual-authorization step takes less than 5 minutes in a real incident \u2014 if it takes longer, engineers will bypass it.", "actions": [ "Test the dual-authorization workflow under simulated incident conditions to verify it can be completed in under 5 minutes with on-call staffing levels.", "Document the break-glass activation procedure in the incident response runbook with step-by-step instructions that can be followed under incident stress.", "After every break-glass activation, complete the post-incident review entry within 48 hours \u2014 do not delegate this to a follow-up task that gets deprioritized when the incident is resolved." ], "failure_signals": [ "Incident response runbook does not include break-glass activation instructions, forcing engineers to improvise the process under incident pressure.", "Post-incident review entries are consistently filed 5 or more days after activation rather than within 48 hours, indicating the follow-up discipline is not established." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations lack a formal break-glass identity path for AI agents \u2014 emergency access is handled by temporarily elevating a production credential or sharing a service account, with no dual authorization, no TTL enforcement, and no post-incident review requirement. Target defined state requires the full NI-08 mechanism to be implemented and exercised in drills." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "it-operations" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4", "fit": "partial", "rationale": "SP 800-63B-4's authenticator lifecycle requirements provide the baseline for credential issuance, protection, and revocation \u2014 NI-08 applies these to the break-glass scenario with additional dual-authorization and TTL enforcement requirements.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Access Management", "fit": "adjacent", "rationale": "The CISA ZTMM Identity pillar's Access Management function expects access to be governed and time-bound; NI-08 addresses the emergency access scenario where elevated access must be provisioned temporarily and terminated with equal rigor.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Privileged Access \u2014 Break Glass", "rationale": "Okta Privileged Access (OPA) provides break-glass emergency access workflows with MFA requirements, configurable time-limited access windows (e.g., 2 hours), multi-level approval chains, and full audit logging of all access events. Break-glass credentials are stored in OPA's encrypted vault with policy-controlled access, and all access is logged for forensic reconstruction.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Privileged Access break-glass provides multi-level approval, time-limited windows, auto-revocation and full audit - the emergency path required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Break Glass Role", "rationale": "AWS IAM break-glass patterns use dedicated IAM roles with MFA-required conditions (aws:MultiFactorAuthPresent: true) and a maximum session duration of one hour; CloudWatch alarms and CloudTrail alerts notify security teams immediately on any AssumeRole call to the break-glass role. AWS Organizations SCPs can restrict break-glass role assumption to specific principals with specific MFA devices.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS break-glass roles with MFA, 1h sessions and alerts cover much, but MFA alone is not the multi-party dual authorization the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part V \u2014 Establish emergency change procedures in advance; Part III \u2014 Privilege scoping (dynamic elevation)", "fit": "partial", "rationale": "Doc requires pre-decided emergency authorization (rotate a credential, take a service offline) and dynamic privilege elevation similar to an admin-password prompt. Partial: doc does not describe a break-glass identity per se.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/NI-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Break-glass identities must reside in a dedicated namespace separate from production agents, be disabled by default, require multi-party authorization to activate, and automatically deactivate after a configured maximum session duration. Every activation must trigger immediate alert delivery to a named security officer and produce a dedicated isolated audit log entry.", "evidence_required": [ "break_glass_identity_registry listing each break-glass identity with namespace_prefix, default_state=disabled, max_session_duration, approver_quorum_count, and assigned_security_officer", "multi_party_approval_record for each break-glass activation showing at least two approver identities, approval timestamps, and documented justification", "break_glass_audit_log stream that is separate from the production agent log stream, showing all activation events, actions taken during the session, and deactivation events with session_duration", "alert_delivery_receipt confirming security officer notification was sent within 5 minutes of each break-glass activation event" ], "machine_tests": [ "Attempt to invoke a break-glass identity without multi-party approval \u2192 assert 403 response with error=insufficient_approvers", "Activate a test break-glass identity and allow max_session_duration to elapse \u2192 assert identity is automatically deactivated and subsequent use returns 401 with error=session_expired", "Verify break-glass identity namespace prefix does not overlap with any production agent identity namespace \u2192 assert zero naming collisions across both namespaces", "Confirm break-glass activation event appears in the dedicated audit log stream within 60 seconds and log stream is distinct from production agent stream \u2192 assert event.stream_id != production_stream_id" ], "human_review": [ "Review the break-glass runbook to confirm it defines activation criteria, required approvers, permitted actions during the session, and mandatory post-incident review requirements", "Assess the separation between the break-glass namespace and production agent namespaces to verify no agent identity can be promoted to break-glass status without explicit re-provisioning through the break-glass registry", "Verify that each past break-glass session log was reviewed within 24 hours of activation and findings were documented in an incident or change record" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Storing break-glass credentials in the same identity namespace as production agents, making it impossible to distinguish emergency access from normal agent operations in audit logs", "Requiring only a single approver for break-glass activation, enabling insider threat scenarios where one compromised account grants full emergency access", "Granting break-glass identities persistent broad access rather than time-bounded session credentials with automatic expiry after the configured maximum session duration", "Routing break-glass activation audit events into the same log stream as production agent activity, losing the ability to isolate and triage emergency access events during incident review", "Failing to notify a security officer at activation time, allowing break-glass sessions to run undetected for extended periods without oversight" ], "update_status": "current", "layer_code": "NI" }, { "id": "NI-09", "layer": "NI", "plane": "lifecycle", "name": "Non-Human Identity Layer Evidence Package", "plain": "Compile a quarterly non-human identity layer evidence package consolidating artifacts from NI-01 through NI-08 to demonstrate that non-human identity provisioning, credential lifecycle, and break-glass access controls are current, complete, and audit-ready. The package is a required input to IC-08 (IdentityAttestation) production.", "threat": { "tags": [ "governance-evidence-gap", "attestation-unverifiable", "audit-readiness-deficit" ], "desc": "Without periodic structured compilation of non-human identity layer evidence, the IdentityAttestation (IC-08) rests on assertions from individual controls rather than compiled, reviewed, and signed evidence. Layer-level gaps are only visible through compilation." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review of AI management system at planned intervals" }, { "id": "nist_rmf", "section": "GOVERN 1.5", "title": "Ongoing monitoring and periodic review of the risk management process and its outcomes" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management system for high-risk AI providers" } ], "sources": [ { "id": "iso_27001_2022", "title": "ISO/IEC 27001:2022 \u2014 Information Security Management System", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "certification-standard", "version": "2022", "published_on": "2022-10-25", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/27001", "license": "proprietary", "status": "current", "flagship": true, "source_id": "iso_27001", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27001:2022 \u2014 Information Security Management System requirements informing the apeiris://identity/controls/NI-09 Non-Human Identity Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_100_1", "title": "NIST AI 100-1: Artificial Intelligence Risk Management Framework", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 100-1: Artificial Intelligence Risk Management Framework requirements informing the apeiris://identity/controls/NI-09 Non-Human Identity Layer Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a quarterly evidence compilation process for the Non-Human Identity layer. Collect required artifacts from NI-01 through NI-08. Review completeness and identify gaps. Produce a signed evidence package for IC-08 IdentityAttestation input.", "steps": [ "Define the NI-layer evidence package schema: required_artifacts[], acceptance_criteria[], gap_register, package_owner, and review_signatories.", "For each control in NI-01 through NI-08, define required evidence artifacts and freshness criteria.", "Compile artifacts quarterly: generate or collect required evidence and stage for structured review.", "Conduct a review session to evaluate completeness, identify gaps, and assign remediation owners.", "Produce a signed non-human identity layer evidence package and submit it as input to IC-08 IdentityAttestation production.", "Retain the package as an immutable record for audit and regulatory review." ] }, "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001 \u00a79.3 requires management review at planned intervals. NI-09 provides the structured review artifact for the Non-Human Identity layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.5", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.5 requires ongoing monitoring and periodic review of the risk management process and its outcomes, with clear organizational responsibilities. NI-09 instantiates that periodic review at the Non-Human Identity layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Art. 17 requires a quality management system. NI-09 is the QMS artifact for the Non-Human Identity layer.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://identity/controls/NI-09", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A complete, machine-readable evidence package for the NI control layer must exist, covering all NI-01 through NI-08 controls, and must be producible on demand without manual data assembly. The package must carry a hash and signature that allow an external attestation verifier to confirm integrity and completeness at the point of production.", "evidence_required": [ "ni_layer_evidence_manifest listing each NI control ID, associated artifact name, artifact_url, collection_timestamp, and completeness_status for every control in the layer", "agent_registry_export in machine-readable format covering all registered agent identities with registration_date, credential_type, last_rotated, and ceiling_policy_id", "credential_lifecycle_summary report showing issuance, rotation, and revocation events for all agent credentials within the audit window", "ni_control_validation_results document with per-control design_check and operational_check outcomes, assessment dates, and assessor identity" ], "machine_tests": [ "Request the NI layer evidence package via the integration API \u2192 assert response contains artifact entries for all eight NI controls with non-null collection_timestamp values", "Validate the evidence package JSON schema against the apeiris-control-core evidence schema \u2192 assert zero schema validation errors" ], "human_review": [ "Review the evidence package for completeness, confirming every NI control has an associated artifact and no control shows evidence_status=missing or evidence_status=stale", "Assess whether the evidence collection process is fully automated and repeatable without manual data assembly, and document any manual steps that introduce integrity risk", "Verify the evidence package carries a valid cryptographic signature and that the declared integrity hash can be independently recomputed against the artifact content" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Manually assembling the evidence package ad hoc at audit time rather than collecting artifacts continuously from automated sources throughout the audit period", "Including evidence artifacts without collection timestamps or methodology references, making it impossible to verify the evidence reflects system state at a specific point in time", "Allowing individual control owners to self-certify their own control evidence without cross-validation from an independent source or automated verification check", "Producing a narrative PDF evidence package instead of machine-readable structured data, preventing automated verification by downstream attestation consumers" ], "update_status": "current", "lenses": { "iam_engineer": { "summary": "This package consolidates the Non-Human Identity layer, so what you assemble is the service-account and agent lifecycle record: the agent registry export, credential issuance-rotation-revocation history, ceiling policies, and break-glass usage from NI-01 through NI-08. It must be producible on demand from the integration API without manual data assembly, and it must validate against the apeiris-control-core evidence schema. The recurring failure this exposes is orphaned credentials that exist in the IdP but not in any registry entry.", "actions": [ "Automate the agent_registry_export so it returns every registered non-human identity with registration_date, credential_type, last_rotated, and ceiling_policy_id in machine-readable form.", "Generate the credential_lifecycle_summary directly from issuance, rotation, and revocation events across the audit window rather than compiling it by hand.", "Build the package producer to emit artifact entries for all eight NI controls with non-null collection timestamps and to hash and sign the result.", "Reconcile the registry export against the IdP's active credential list so orphaned or unregistered credentials surface as a gap.", "Validate the assembled package against the apeiris-control-core evidence schema in the producer and fail the build on any schema error." ] }, "security_architect": { "summary": "NI-09 is the point where the non-human identity layer becomes attestable: it feeds IC-08 IdentityAttestation and blocks deployment if incomplete. Its integrity depends on the underlying NI controls actually producing fresh, signed artifacts, so a stale or partial credential-lifecycle record silently weakens every claim IC-08 makes about service-account governance. Design the package so completeness and freshness are machine-checkable, not asserted.", "actions": [ "Require the package to carry a hash and signature so an external verifier can confirm integrity and completeness at the point of production.", "Make credential-lifecycle freshness a defined acceptance criterion so aging rotation or revocation data is flagged rather than accepted.", "Treat the registry-to-IdP reconciliation result as a security signal and ensure unresolved orphaned credentials block package sign-off.", "Confirm the NI-09 package is a required, verified input to IC-08 and cannot be bypassed when the attestation is produced." ] }, "legal_counsel": { "summary": "The NI-layer package is the retained record proving the enterprise governed the full lifecycle of its non-human identities: how service-account and agent credentials were issued, rotated, and revoked over the audit window. Because it is signed and immutable, it is the artifact you would rely on to show that a given agent's credential was authorized and current at the time it acted. Its evidentiary weight comes from the signature and the immutable retention, not from the underlying spreadsheets.", "actions": [ "Confirm the signed package is retained as an immutable record for a period consistent with audit and regulatory retention obligations.", "Verify the credential_lifecycle_summary is sufficient to establish, after the fact, that a specific agent credential was valid and authorized at a given time.", "Ensure the package owner and review signatories are named so accountability for the attestation input is attributable.", "Check that the ceiling policies recorded per agent map to documented authorization limits the enterprise can defend." ] }, "grc_auditor": { "summary": "For NI-09 the evidence is the ni_layer_evidence_manifest plus the four required artifacts, chief among them the agent registry export and the credential lifecycle summary. Confirm the manifest lists every NI-01 through NI-08 control with a named artifact, URL, timestamp, and completeness status, and that the package can be produced on demand rather than assembled for the audit. The presence of a signature and clean schema validation is what distinguishes a real package from a compiled snapshot.", "actions": [ "Request the NI layer evidence package via the integration API and confirm it returns artifact entries for all eight NI controls with non-null collection timestamps.", "Validate the package against the apeiris-control-core evidence schema and confirm zero validation errors.", "Cross-reference the agent_registry_export against the credential_lifecycle_summary to confirm rotation and revocation events reconcile with registered agents.", "Verify the ni_control_validation_results record per-control design and operational check outcomes with assessment dates and a named assessor." ] }, "it_operations": { "summary": "You own the quarterly production of the NI package as a scheduled job, and the registry and credential-lifecycle feeds behind it. The operational risk is orphaned credentials: service accounts and agent credentials that keep working in the IdP after the agent is gone. Your reconciliation between the registry and the live credential store is what catches them, and a failed or skipped compilation blocks deployment downstream.", "actions": [ "Schedule the quarterly package compilation and alert if it fails or misses the window, since an absent package blocks deployment at IC-08.", "Run automated registry-to-IdP reconciliation on a recurring cadence and route orphaned or unregistered credentials to an owner for revocation.", "Ensure credential rotation and revocation events are captured into the lifecycle feed as they happen so the summary is current at quarter close.", "Own the runbook for regenerating and re-signing the package when a gap is remediated mid-quarter." ] } }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "maturity": { "current": "initial", "target": "defined", "notes": "Layer-level evidence compilation is rare; most organizations assemble identity audit evidence ad hoc at audit time. Target state is an automated quarterly Non-Human Identity package with signed integrity, a maintained gap register, and direct feed into IC-08 attestation production." }, "implementers": [ "IAM Team", "GRC / Internal Audit", "Platform Engineering" ], "validation": { "design_check": [ "Verify the Non-Human Identity evidence package schema defines required artifacts for every NI-01 through NI-08 control, with acceptance criteria and freshness windows per artifact.", "Confirm package assembly is automated from authoritative sources (registry exports, IdP and pipeline logs) rather than manually collated documents.", "Validate that the package is signed and hash-chained so downstream consumers (IC-08 attestation production) can verify integrity and completeness." ], "runtime_test": [ "Request the current Non-Human Identity evidence package via the integration API and confirm every NI-layer control contributes at least one artifact with a collection timestamp inside the freshness window.", "Tamper with one staged artifact and confirm the package integrity check fails and the package is rejected as IC-08 input.", "Simulate a missing artifact for one control and confirm the gap register records it with an assigned owner and remediation date." ], "evidence": [ "evidence-package:Signed quarterly Non-Human Identity layer evidence package with per-control artifact manifest [unverified]", "gap-register:Gap register entries for the prior four quarters with remediation owners and closure dates [unverified]", "review-signoff:Quarterly review sign-off records naming the reviewing owners and their dispositions [unverified]" ] }, "layer_code": "NI", "lens_enrichment": "ap42 2026-07-08" }, { "id": "DE-01", "layer": "DE", "plane": "control", "name": "Delegation Chain Documentation", "plain": "Require every AI agent action to be traceable to a complete, signed, and auditable delegation chain documenting every principal in the path from the authorizing human through all intermediate agents to the acting agent.", "threat": { "tags": [ "delegation-abuse", "identity-spoofing" ], "desc": "Without a documented and verifiable delegation chain, there is no authoritative record of which human principal authorized which AI agent action \u2014 making it impossible to determine whether an agent acted within sanctioned bounds or whether its authorization was fabricated, forged, or stale. Delegation chains that are not cryptographically signed can be manipulated in transit or in storage, enabling an attacker to insert fraudulent authorization legs that appear legitimate. Personal-in-enterprise scenarios introduce additional chain complexity: both the human-to-agent delegation and the enterprise scope authorization must be documented and verified independently, because neither alone is sufficient proof of legitimate authority." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Federation Assurance Levels \u2014 applied by analogy to delegation lineage" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "authorization_details as delegation context" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 4", "title": "Dynamic policy with full delegation lineage" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-02" }, { "id": "rfc_9700_oauth_bcp", "title": "OAuth 2.0 Security Best Current Practice (RFC 9700)", "authority": "IETF OAuth Working Group", "source_type": "standard", "normative_force": "best-practice", "version": "RFC 9700", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9700", "license": "open-access", "status": "current", "flagship": false, "source_id": "rfc_9700_oauth_bcp", "relationship": "informative_reference", "rationale": "Establishes OAuth 2.0 Security Best Current Practice (RFC 9700) requirements informing the apeiris://identity/controls/DE-01 Delegation Chain Documentation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Cryptographically signed delegation chain token propagated through all agent hops, verifiable by any resource server without calling back to the issuing authority", "steps": [ "At each delegation step, issue a signed delegation token (e.g., JWT with act and may_act claims per RFC 8693 semantics) that includes: delegator identity, delegate identity, granted scope subset, task reference, expiry, and a cryptographic sha256 reference to the prior token in the chain; require each token to be signed by the delegating principal's identity key.", "For personal-in-enterprise delegations, require two separate signed tokens: one documenting the human-to-agent delegation (signed by the human principal's identity key) and one documenting the enterprise scope authorization (signed by the authority service referencing apeiris://authority/controls/PA-02); both must be present and valid for the chain to be considered complete.", "Propagate the full delegation chain (all tokens, not just the most recent) in the Authorization header of every API call made by the acting agent so resource servers can verify the complete lineage without calling back to a central chain registry.", "Store a tamper-evident copy of each delegation chain in the delegation audit log at the time the chain is first constructed; log every subsequent use of the chain with a reference to the chain ID, the resource accessed, and the acting agent identity." ], "anti_patterns": [ "Passing only the acting agent's credential to resource servers without the full delegation chain, leaving resource servers unable to verify the authorization lineage.", "Documenting the delegation chain in a mutable database record rather than in cryptographically signed tokens, making the chain vulnerable to retroactive modification.", "Treating personal-in-enterprise delegations as equivalent to workload delegations and documenting only the human-to-agent leg without the enterprise scope authorization token." ] }, "validation": { "design_check": [ "Confirm delegation token schema includes delegator identity, delegate identity, scope subset, task reference, expiry, and cryptographic reference to the prior chain token.", "Verify personal-in-enterprise delegation requires two distinct signed tokens (human-to-agent and enterprise scope) and that resource server validation logic enforces both are present.", "Confirm the full delegation chain (all tokens) is propagated in API call headers rather than just the acting agent's credential." ], "runtime_test": [ "Submit an API request from a delegated agent with only the acting agent's credential (no chain tokens) and verify the resource server rejects it.", "Construct a personal-in-enterprise delegation chain with only the human-to-agent token (missing enterprise scope token) and verify the resource server rejects it.", "Tamper with a delegation token signature and verify the resource server rejects the chain on signature verification failure." ], "evidence": [ "delegation-chain-log:Delegation audit log entries showing complete chains with all token references for each agent action in the review period [unverified]", "chain-validation-report:Resource server token validation logs showing full chain verification (not just acting-agent credential check) for each API request [unverified]", "personal-enterprise-audit:Sample of personal-in-enterprise delegation chains showing both human-to-agent and enterprise scope tokens present and valid [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Your responsibility is to design and operate the delegation token issuance and chain propagation infrastructure. The entire auditability of AI agent actions depends on the chain being present, complete, and cryptographically sound at every hop.", "actions": [ "Implement JWT delegation tokens with act and may_act claims per RFC 8693 semantics, including delegator identity, delegate identity, granted scope subset, task reference, expiry, and a sha256 reference to the parent token in each issued token.", "Design the chain propagation mechanism so resource servers receive the full token chain in the Authorization header rather than just the acting agent's credential \u2014 this typically requires changes to both the SDK used by agents and the middleware on every resource server.", "Build and maintain the delegation audit log that stores a tamper-evident (append-only, hash-chained) copy of each chain at construction time and records every subsequent use with chain ID, resource accessed, and acting agent identity." ], "failure_signals": [ "Resource server access logs show requests arriving with only the acting agent's bearer token and no delegation chain tokens.", "Delegation audit log entries reference chain IDs that cannot be resolved to stored chain records, indicating chains were not persisted at construction time." ] }, "security_architect": { "summary": "The delegation chain is the trust anchor for all AI agent authorization decisions. Without it, every agentic action is effectively unaudited. Your role is to define the chain trust model and ensure it is enforced at every layer \u2014 not just at issuance.", "actions": [ "Define the chain trust model: specify which signing key types are acceptable for each hop (hardware-backed keys for human principals, service identity keys for agents), and publish the trust policy in the identity domain specification.", "Design the defense-in-depth verification architecture: authorization service validates chain at issuance, resource server validates chain at runtime \u2014 ensuring a compromised authorization service cannot silently skip chain validation.", "Define the personal-in-enterprise chain structure: specify the two-token requirement (human-to-agent leg plus enterprise scope leg) and document the validation algorithm resource servers must implement, including the cross-reference to apeiris://authority/controls/PA-02." ], "failure_signals": [ "Threat model or architecture review reveals a path where a resource server accepts agent actions without validating the full delegation chain.", "Personal-in-enterprise deployments produce single-token chains that combine human-to-agent and enterprise scope authorization in a single token, making them inseparable and unauditable independently." ] }, "legal_counsel": { "summary": "Delegation chain documentation is your primary evidence artifact for demonstrating that AI agent actions were authorized by an identified human principal within a defined scope. Without complete, signed chains, you cannot prove in a dispute or regulatory inquiry that the action was sanctioned.", "actions": [ "Review the delegation chain schema to confirm it captures the identity of the authorizing human principal in a form that is legally attributable \u2014 a reference to a verified identity credential, not just a system username or internal ID.", "Confirm that delegation audit logs are retained for a period consistent with applicable legal hold obligations and that chain records cannot be deleted by the system or its operators during the retention period.", "Assess whether the two-token requirement for personal-in-enterprise delegations is sufficient to establish that the enterprise's scope authorization was independently obtained \u2014 relevant for data processing agreements and employment law jurisdictions that distinguish personal and organizational actions." ], "failure_signals": [ "Delegation chain records reference agent system identifiers but not verified human principal identifiers, making it impossible to trace an action to a specific natural person for legal attribution.", "Delegation audit log retention period is shorter than the statute of limitations for claims arising from AI agent actions in the organization's operating jurisdictions." ] }, "grc_auditor": { "summary": "DE-01 is your primary evidence source for demonstrating that AI agent actions were authorized through a documented, auditable principal chain. Every control in the delegation layer depends on chain completeness \u2014 a gap here undermines all downstream attestation.", "actions": [ "Sample delegation audit log entries and verify that each entry references a complete chain with all token records present and that chain signatures validate against the recorded public keys.", "Test personal-in-enterprise chain completeness by selecting a sample of agent actions performed in personal context and confirming that both the human-to-agent token and the enterprise scope token are present and signed.", "Verify that chain records are immutable after creation \u2014 attempt to modify a chain record and confirm the audit system detects and alerts on the modification attempt." ], "metrics": [ "Percentage of agent actions in the review period with complete, validatable delegation chains in the audit log (target: 100%)", "Mean time to detect and alert on chain record modification attempts (target: less than 5 minutes)" ], "failure_signals": [ "Audit log sample reveals agent actions with no associated delegation chain record, indicating the chain was never persisted.", "Chain signature validation fails for a subset of records, indicating either key rotation gaps or chain record tampering." ] }, "it_operations": { "summary": "Your day-to-day role is to operate the delegation token issuance infrastructure, monitor chain propagation health, and respond to chain validation failures in production \u2014 chain failures silently degrade to unauthorized agent actions if not caught at the resource layer.", "actions": [ "Monitor chain propagation metrics: track the percentage of API calls arriving at resource servers with complete delegation chain headers versus those arriving with only the acting agent's credential, and alert when the ratio drops below 99%.", "Maintain the delegation signing key rotation schedule: ensure keys are rotated on the defined cadence, old public keys remain accessible in the key registry for validation of tokens issued before rotation, and all rotation events are logged.", "Establish runbook procedures for delegation chain failures: define escalation paths for chain validation failures, broken chain alerts, and personal-in-enterprise chain incompleteness, including the fallback to human execution when chain construction fails." ], "failure_signals": [ "Chain propagation monitoring shows a recurring pattern of API calls arriving without chain tokens from specific agent types or orchestration platforms, indicating those platforms do not implement chain propagation.", "Key rotation events are not reflected in the key registry within the defined SLA window, causing chain validation failures for tokens issued by the new key before the registry update." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most AI agent deployments propagate only the acting agent's credential to resource servers, leaving no delegation lineage auditable at the resource level. Target state requires the full chain to be verifiable without central registry calls." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "platform-engineer" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "partial", "rationale": "SP 800-63C-4 \u00a72 defines Federation Assurance Levels for federated assertions. FALs govern assertion protection and presentation rather than delegation lineage, so DE-01 applies the federation-assurance discipline by analogy: each delegation hop is documented and verifiable the way 63C expects assertions to be.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "direct", "rationale": "RFC 9396 authorization_details provide the structured claim format for encoding delegation context at each hop of the chain, enabling machine-readable verification of authorization lineage.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 4", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 4 determines access by dynamic policy evaluated per request; DE-01's documented delegation chain supplies the lineage input to that policy. The tenet does not prescribe a specific chain token structure or the two-token personal-in-enterprise requirement.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Cross Account Role Chaining", "rationale": "AWS IAM role trust policy chaining creates an auditable delegation chain; every AssumeRole API call is logged in CloudTrail with the complete principal chain, source identity, session duration, and session policies. The CloudTrail record enables reconstruction of the full delegation path for any credential used in an incident.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail records AssumeRole principal chains but not a cryptographically signed delegation-token chain reconstructable from any leaf token.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity for AI \u2014 Agent IAM Core delegation chain", "rationale": "Ping Identity's Agent IAM Core documents delegation chains as first-class data structures; each delegation step is recorded with the delegating principal, delegated scope, depth counter, and expiry. The Agent Gateway validates the complete delegation chain before issuing any downstream credential, rejecting chains with missing documentation or unauthorized delegators.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Ping Agent IAM Core records delegation chains as first-class structures (principal, scope, depth, expiry) and the Gateway validates the full chain.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "oauth_bcp", "requirement_id": "RFC 9700 \u00a72.1, \u00a72.1.2", "fit": "direct", "rationale": "OAuth 2.0 Security BCP (RFC 9700) \u00a72.1 requires exact redirect URI matching and \u00a72.1.2 removes the implicit grant \u2014 hardening the authorization flows on which documented AI agent delegation chains are built.", "normative_force": "best-practice", "source_version": "RFC 9700", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II \u2014 Unscoped privilege inheritance; Part IV Phase 6 \u2014 Explicit trust boundaries", "fit": "direct", "rationale": "Doc requires documenting and verifying multi-agent trust relationships (often dynamic/implicit) and explicit trust boundaries \u2014 delegation chain documentation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every agent delegation token must carry a cryptographically verifiable chain linking delegator identity, delegate identity, authorized scope subset, task reference, expiry, and a hash reference to the prior chain token. The complete chain must be reconstructable from any leaf token back to the originating principal without gaps.", "evidence_required": [ "delegation_token_schema_definition showing delegator_id, delegate_id, scope_subset, task_ref, expiry, prior_token_hash, and chain_depth as required non-nullable fields", "delegation_chain_audit_log with entries for each delegation event including all required schema fields and the cryptographic signature from the issuing authorization service", "chain_reconstruction_test_result showing a complete end-to-end chain trace from a leaf delegate back to the originating principal for at least three distinct task executions with no gaps", "non_repudiation_verification_record confirming each token in a sample of chains carries a verifiable signature from the issuing authorization service's signing key" ], "machine_tests": [ "Submit delegation request missing the prior_token_hash field \u2192 assert authorization service returns 400 with error=missing_chain_reference", "Reconstruct the delegation chain for a completed task execution \u2192 assert all chain links resolve to signed tokens with no gaps and the chain terminates at the originating principal", "Submit delegation token with scope_subset containing elements absent from the parent token \u2192 assert authorization service returns 403 with error=scope_escalation_attempt", "Verify delegation chain signature validity for five sampled chains \u2192 assert all token signatures verify against the issuing authorization service's published public key" ], "human_review": [ "Review the delegation token schema against the DE-01 required field list and confirm all fields are present, non-nullable, and validated server-side at issuance time", "Assess delegation chain documentation for a representative set of high-risk task executions to confirm non-repudiation evidence is present at every chain link", "Verify that chain reconstruction tooling is available to auditors and produces a human-readable chain trace without requiring direct access to internal databases or application state" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Issuing delegation tokens without a cryptographic reference to the prior chain token, making it impossible to reconstruct the full delegation lineage after the fact", "Storing delegation chain records only in application logs rather than in a tamper-evident chain store, allowing chain reconstruction to fail if logs are rotated or truncated", "Allowing the requesting agent to assert the chain_depth or prior_token_hash values in the request body rather than having the authorization service compute and set these fields", "Omitting the task_ref field from delegation tokens, making it impossible to determine which specific task authorized a given delegation during post-incident review", "Accepting delegation tokens without validating the cryptographic signature, allowing forged or replayed chain references to pass chain validation" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-02", "layer": "DE", "plane": "control", "name": "Scope Boundary Enforcement", "plain": "Enforce that no AI agent can authorize actions beyond its own authorized scope, and that delegated scope is always the intersection of the parent scope and the explicitly granted subset \u2014 never a union.", "threat": { "tags": [ "privilege-escalation", "delegation-abuse" ], "desc": "Scope escalation through delegation occurs when a child agent is granted scope that its parent principal does not itself hold \u2014 or when delegation logic computes the child's effective scope as the union of the parent scope and the grant rather than the intersection. This allows an attacker who controls a lower-privilege agent to construct a delegation chain that accumulates scope across multiple hops, arriving at a final scope that no single principal in the chain was individually authorized to grant. The intersection rule is the only delegation model that is mathematically safe against scope accumulation through chaining; any other model (union, maximum, default-to-parent) creates an exploitable path to privilege escalation." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Federation Assurance Levels \u2014 controlled-assertion analogy for scope constraints" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "authorization_details scope constraint" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Strict enforcement for scope boundaries" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/DE-02 Scope Boundary Enforcement control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Intersection-only scope computation enforced at the authorization service before any delegation token is issued", "steps": [ "Implement scope intersection computation in the authorization service as the canonical mechanism for evaluating delegation grants: when an agent requests to delegate scope S_grant to a child agent, the authorization service computes S_child = intersection(S_parent, S_grant) and issues the child token with S_child \u2014 rejecting any request where S_grant contains elements not present in S_parent.", "Represent all scopes as structured sets (e.g., RFC 9396 authorization_details objects with explicit resource and action fields) rather than opaque strings, so the intersection computation operates on comparable structured elements rather than string matching that can be circumvented by naming variants.", "Log every delegation scope computation with inputs (S_parent, S_grant) and output (S_child) at the authorization service level, enabling post-hoc audit of scope reduction decisions and detection of any attempts to submit S_grant values that exceed S_parent.", "Implement a resource server-side scope verification check that rejects requests where the acting agent's scope claim exceeds the scope of any token in its delegation chain, as a defense-in-depth layer against authorization service bugs or chain replay attacks." ], "anti_patterns": [ "Computing child scope as union(S_parent, S_grant) on the assumption that an explicit grant adds scope rather than selecting from the parent's existing scope.", "Using opaque string scope values (e.g., 'read:all') that cannot be structurally compared and where intersection is computed by string matching against a scope registry that can be inconsistently maintained.", "Skipping resource-server-side scope verification on the grounds that the authorization service already enforced the intersection, eliminating the defense-in-depth layer that catches authorization service bugs or replay attacks." ] }, "validation": { "design_check": [ "Confirm authorization service implements scope computation as intersection(S_parent, S_grant) and rejects any S_grant that contains elements not present in S_parent.", "Verify scopes are represented as structured objects (not opaque strings) enabling unambiguous intersection computation across all subsystems that participate in delegation.", "Confirm resource server-side scope verification is implemented as a defense-in-depth layer independent of the authorization service." ], "runtime_test": [ "Request a delegation token with S_grant containing a scope element not present in S_parent and verify the authorization service rejects it with a scope-exceeded error.", "Construct a multi-hop delegation chain and verify that scope at each hop is strictly a subset of or equal to the scope at the preceding hop, with no scope accumulation across hops.", "Submit an API request with a forged token claiming scope exceeding the chain's computed ceiling and verify the resource server rejects it at the defense-in-depth validation layer." ], "evidence": [ "scope-computation-log:Authorization service log showing intersection computation inputs and outputs for each delegation grant in the review period [unverified]", "escalation-rejection-log:Authorization service rejection log showing all S_grant-exceeds-S_parent attempts blocked during the review period [unverified]", "resource-server-audit:Resource server scope verification log confirming defense-in-depth checks are active and no over-scope requests were accepted [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Scope intersection is a core authorization service invariant \u2014 your implementation must guarantee that no delegation token can be issued with scope exceeding the issuing principal's own scope. This requires structural enforcement in the token issuance path, not documentation or convention.", "actions": [ "Refactor the delegation token issuance path in the authorization service to implement intersection(S_parent, S_grant) as the canonical scope computation, replacing any existing logic that assigns S_grant directly to the child token without comparing to S_parent.", "Implement structured scope representation using RFC 9396 authorization_details objects with explicit resource and action fields across all delegation-aware subsystems, retiring any opaque string scope values that cannot be structurally intersected.", "Add a resource-server-side scope ceiling check that validates the acting agent's scope does not exceed the scope of any token in its delegation chain, implemented independently from the authorization service to provide defense-in-depth." ], "failure_signals": [ "Authorization service source code review reveals a delegation code path that assigns S_grant to the child token without intersecting with S_parent.", "Resource server scope validation logic trusts the acting agent's scope claim without verifying it against the chain's computed scope ceiling." ] }, "security_architect": { "summary": "The intersection rule is the only delegation model that is mathematically safe against scope accumulation through chaining. Your architecture must make union computation structurally impossible, not merely prohibited by policy \u2014 policy constraints can be bypassed, structural constraints cannot.", "actions": [ "Define the scope algebra in the identity domain specification: document the intersection rule, the structured scope representation requirement, and the prohibition on opaque string scopes \u2014 making these architectural constraints that all vendors and integrators must satisfy.", "Design the multi-layer scope enforcement architecture: authorization service enforces intersection at issuance, resource server enforces scope ceiling at runtime \u2014 ensuring no single point of failure can enable scope escalation.", "Conduct a threat model specifically for scope escalation through multi-hop chains: enumerate all delegation paths in the system architecture and verify the intersection rule is applied at every hop, not just at the first delegation from the human principal." ], "failure_signals": [ "Threat model reveals a delegation path where scope computation is delegated to the requesting agent rather than computed authoritatively by the authorization service.", "Scope representation uses opaque strings in some subsystems and structured objects in others, creating an intersection computation inconsistency that could be exploited by targeting subsystems using string-based scopes." ] }, "legal_counsel": { "summary": "Scope boundary enforcement directly determines the legal perimeter of AI agent authorization. Scope escalation through delegation is the mechanism by which an agent could perform actions that were never actually authorized by a human principal \u2014 creating significant liability for unauthorized computer access and breach of data governance obligations.", "actions": [ "Review the authorization service specification to confirm the intersection rule is defined as a binding system requirement \u2014 not merely a recommended practice \u2014 ensuring it is enforceable as a contractual obligation with technology vendors.", "Confirm that scope escalation detection (the authorization service rejection log) is retained as a legal evidence artifact, because scope escalation attempts may constitute unauthorized computer access under applicable law in the organization's operating jurisdictions.", "Assess whether the structured scope representation (RFC 9396 authorization_details) is sufficient to establish a legally clear record of what specific resources and actions were actually authorized for a given agent delegation, relevant for incident response and regulatory inquiry." ], "failure_signals": [ "Authorization service vendor contract does not include a binding commitment to intersection-only scope computation, leaving scope enforcement as a configuration convention that could be changed without legal consequence.", "Scope escalation rejection logs are not retained as legal evidence artifacts and are subject to routine log rotation that would destroy them before legal hold obligations apply." ] }, "grc_auditor": { "summary": "DE-02 is the control that prevents delegation from becoming a privilege escalation vector. Your audit must verify that scope computation is enforced structurally at the authorization service, not just documented as policy \u2014 and that the defense-in-depth layer at resource servers is independently active.", "actions": [ "Test intersection enforcement directly: construct a delegation request where S_grant contains a scope element not present in S_parent and submit it to the authorization service, confirming rejection with a specific scope-exceeded error code.", "Review authorization service scope computation code or configuration to verify intersection(S_parent, S_grant) is the implemented algorithm, not S_grant assignment or union computation.", "Sample multi-hop delegation chains from the review period and verify that scope at each subsequent hop is a strict subset of or equal to scope at the preceding hop \u2014 confirming no scope accumulation occurred across any chain." ], "metrics": [ "Percentage of scope escalation attempt rejections (S_grant not subset of S_parent) that are captured in the rejection log (target: 100%)", "Percentage of delegation chains in the review period where each hop's scope is a verified subset of the preceding hop's scope (target: 100%)" ], "failure_signals": [ "Authorization service rejection log shows zero scope escalation rejections during the review period despite a known test escalation attempt, indicating the rejection log is not capturing failures.", "Multi-hop chain audit reveals scope at hop N equals or exceeds scope at hop N-1 for any chain, indicating intersection enforcement is not applied at every hop." ] }, "it_operations": { "summary": "Your operational role is to monitor scope enforcement health, respond to scope escalation alerts, and maintain the structured scope registry that the authorization service uses for intersection computation \u2014 a stale registry creates gaps in scope validation.", "actions": [ "Operate the scope escalation alert: configure the authorization service to fire a real-time alert for every scope escalation rejection (S_grant not subset of S_parent), with the requesting agent identity and the specific out-of-scope elements logged for each event.", "Maintain the structured scope registry: ensure all valid scope elements are defined as RFC 9396 authorization_details objects in the registry and that the registry is the authoritative, version-controlled source for the authorization service's intersection computation.", "Establish a security-reviewed change process for scope registry updates: require documented security team approval for any addition of new scope elements, and verify that new elements do not create unexpected intersection outcomes in existing delegation chains before deploying to production." ], "failure_signals": [ "Scope escalation alert fires but no associated rejection log entry is present, indicating the alert and enforcement mechanisms are out of sync.", "Scope registry updates are applied in production without security review, resulting in new scope elements that inadvertently expand the effective scope of existing delegations." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Authorization services in most environments implement delegation as scope assignment (the agent gets what the grant says) rather than scope intersection (the agent gets the intersection of what the grant says and what the parent holds). Implementing intersection-first computation typically requires changes to the authorization service core logic." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer", "security-architect" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "partial", "rationale": "SP 800-63C-4 \u00a72's Federation Assurance Levels govern assertion strength; they do not specify delegation scope reduction. DE-02's intersection-only scope rule is an agentic-delegation control, cited here as an analogy to 63C's controlled-assertion model.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "direct", "rationale": "RFC 9396 authorization_details provide the structured scope representation that enables unambiguous intersection computation across delegation hops, replacing opaque string scopes with machine-comparable structured objects.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 6 requires strictly enforced, dynamic authorization before access; DE-02's intersection-only scope computation implements that enforcement decision for delegated scopes. The tenet does not address multi-hop delegation scope computation specifically.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta Authorization Server \u2014 Scope Boundary Enforcement", "rationale": "Okta authorization servers enforce OAuth scope boundaries at token issuance; machine-to-machine Client Credentials flows must explicitly declare the scopes required, and the authorization server issues tokens scoped only to pre-approved API resources. Dynamic scope validation ensures agents cannot request scopes beyond their registered authorization boundary.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta authorization servers limit tokens to pre-approved scopes but do not clearly compute delegated scope as parent-intersection at each hop.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Permission Boundaries", "rationale": "AWS IAM permission boundaries set a hard ceiling on permissions grantable to any role or user, preventing privilege escalation beyond the declared scope boundary. Even if an agent or operator attaches a broader policy, the permission boundary limits effective permissions to the declared scope. AWS Well-Architected requires permission boundaries for all delegated role creation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "AWS permission boundaries set a hard ceiling so effective permissions are the intersection of boundary and policy, never a union - as the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "PingFederate \u2014 Scope Reduction Enforcement", "rationale": "PingFederate enforces scope reduction at every delegation step; delegated credentials can never carry more scope than the delegating principal holds. The runtime authorization engine validates scope inheritance at each step and rejects requests where the requested scope would exceed the delegator's current scope, preventing scope amplification through delegation chains.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "PingFederate enforces scope reduction at every delegation step so delegated credentials never exceed the delegating principal - intersection semantics.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 \u2014 Scope limits / Least Agency", "fit": "direct", "rationale": "Scope limits constrain which systems/data/resources an agent (and its delegate) can access, even within permitted actions \u2014 scope boundary enforcement.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The authorization service must compute every delegated scope as the strict mathematical intersection of the parent grant's authorized scope and the requested scope. Any delegation request that includes scope elements absent from the parent grant must be rejected before a token is issued, with no wildcard overrides, admin bypass paths, or allow-list exceptions.", "evidence_required": [ "scope_computation_audit_log showing, for each delegation event, parent_scope set, requested_scope set, and computed granted_scope with the intersection result", "scope_rejection_log capturing all rejected delegation requests with the specific scope elements that triggered rejection and the requesting agent_id", "authorization_service_policy_definition confirming the scope enforcement algorithm is implemented as strict set intersection with no wildcard override capability", "scope_boundary_test_results from automated tests covering valid subset, escalating, and empty-intersection scope request combinations" ], "machine_tests": [ "Submit delegation request where requested_scope includes one element not present in parent grant \u2192 assert authorization service returns 403 with error=scope_escalation_attempt and logs the violation", "Submit delegation request where requested_scope is a proper subset of the parent grant \u2192 assert authorization service issues token with granted_scope exactly equal to requested_scope", "Submit delegation request with empty requested_scope \u2192 assert authorization service returns 400 with error=empty_scope_not_permitted", "Issue a delegation token and attempt to access a resource outside the granted scope \u2192 assert resource server returns 403 with error=scope_insufficient" ], "human_review": [ "Review the scope enforcement algorithm implementation to confirm it uses set intersection and contains no bypass conditions, wildcard scope values, or administrative skip paths", "Assess the scope rejection log for the past 30 days to identify patterns of attempted scope escalation and verify each attempt was blocked and flagged for investigation", "Verify scope string definitions are unambiguous and non-overlapping, so no two scope strings grant implicit access to the same resource through string-matching side effects" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Implementing scope enforcement as a deny-list check rather than a strict intersection, so newly introduced scope values are implicitly granted until explicitly blocked", "Using wildcard scope values such as 'admin:*' that grant implicit access to sub-scopes not enumerated in the parent grant", "Computing the granted scope at resource access time rather than at token issuance time, creating a window where scope boundaries change between token issue and resource use", "Allowing the requesting agent to specify the granted_scope field in the request body and trusting it without recomputing the intersection from the parent grant", "Defaulting to the full parent scope when the delegation request omits a scope field, rather than requiring explicit scope specification on every delegation request" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-03", "layer": "DE", "plane": "control", "name": "Delegation Depth Limits", "plain": "Enforce a maximum delegation chain depth and require human re-authorization before the hard limit is reached, with the gate determined by action irreversibility and scope magnitude rather than hop count alone.", "threat": { "tags": [ "delegation-abuse", "privilege-escalation" ], "desc": "Unbounded delegation depth allows an orchestration system to chain agent-to-agent delegations indefinitely, progressively diluting the original human authorization until the acting agent at the end of the chain is performing actions with no meaningful traceability to any human decision. Deep chains also complicate revocation \u2014 revoking the root delegation does not immediately propagate to all downstream agents if the chain is long and distributed across multiple execution contexts. A hard hop limit of 4 with irreversibility-based and scope-magnitude-based intermediate gates provides a practical bound on chain depth while preserving flexibility for legitimate multi-agent workflows." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 4", "title": "Dynamic policy gating for multi-hop delegation" }, { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Federation Assurance Levels \u2014 assurance vocabulary for re-authorization gates" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/DE-03 Delegation Depth Limits control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-03 Delegation Depth Limits control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-03 Delegation Depth Limits control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-03 Delegation Depth Limits control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/DE-03 Delegation Depth Limits control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Hop-count enforcement with irreversibility-based intermediate gate and hard 4-hop ceiling enforced at the authorization service", "steps": [ "Track delegation depth as an explicit field in the delegation token (e.g., depth: 2 for the second delegation hop from the root human principal); require the authorization service to increment the depth field at each delegation step and reject any delegation request that would result in depth greater than 4.", "Implement an irreversibility gate at each delegation step: before issuing a delegation token, evaluate the proposed actions against an irreversibility classifier (e.g., write operations to production data, financial transactions, configuration changes) and require synchronous human re-authorization if the action class is irreversible and depth is 3 or greater.", "Implement a scope-magnitude gate in parallel with the irreversibility gate: if the acting agent's scope at depth 2 or greater exceeds a defined magnitude threshold (e.g., access to more than a defined count of resources, or to resources classified above a defined sensitivity tier per apeiris://data/controls/DX-01), require human re-authorization regardless of hop count.", "Log every delegation depth evaluation with the current depth, the irreversibility classification of the proposed actions, and the gate decision (pass, require re-auth, block) to enable post-hoc analysis of chains approaching the hard limit and to provide evidence for re-authorization events." ], "anti_patterns": [ "Setting the hard hop limit to an arbitrary high number (e.g., 10) to avoid disrupting existing multi-agent workflows, eliminating the practical safety constraint the limit is designed to provide.", "Applying depth limits only to the delegation chain and not to re-delegation events within a single execution context, such as an agent spawning sub-agents within its own runtime without creating new delegation tokens.", "Treating the irreversibility gate as advisory \u2014 notifying the human principal but allowing the action to proceed before approval is received \u2014 rather than requiring synchronous re-authorization before the delegation token is issued." ] }, "validation": { "design_check": [ "Confirm delegation token schema includes an explicit depth field that is incremented by the authorization service at each hop and cannot be decremented or overridden by the requesting agent.", "Verify irreversibility classifier is implemented as a separate service dependency and is referenced by the authorization service gate logic at depth 3 or greater.", "Confirm scope-magnitude threshold is defined in the identity domain configuration and enforced at the authorization service level independent of the hop-count gate." ], "runtime_test": [ "Construct a delegation chain with 5 hops and verify the authorization service rejects the fifth delegation request with a depth-exceeded error.", "Construct a 3-hop chain where the third hop requests an irreversible action (e.g., a production data write) and verify the authorization service requires human re-authorization before issuing the token.", "Construct a 2-hop chain where the second hop's scope exceeds the defined magnitude threshold and verify the authorization service requires re-authorization even though the depth is below the irreversibility gate threshold." ], "evidence": [ "depth-evaluation-log:Authorization service log showing depth field values, gate decisions, and re-authorization events for all delegation chains in the review period [unverified]", "hard-limit-rejection-log:Authorization service rejection log showing all depth greater than 4 requests blocked during the review period [unverified]", "re-auth-events:Human re-authorization events triggered by irreversibility or scope-magnitude gates, with human approver identity and approval timestamps [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Your responsibility is to implement the depth tracking field in the delegation token, enforce the 4-hop hard limit at the authorization service, and build the re-authorization trigger that gates on irreversibility and scope-magnitude \u2014 these are separate mechanisms that must both be active.", "actions": [ "Add a depth field to the delegation token schema and implement authorization service logic to increment it at each hop, starting at 1 for the first delegation from the human principal \u2014 and enforce rejection of any delegation request that would result in depth exceeding 4.", "Implement the irreversibility classifier as a service dependency of the authorization service: before issuing any delegation token at depth 3 or greater, call the classifier with the proposed action set and block token issuance pending human re-authorization if any action is classified as irreversible.", "Implement the scope-magnitude gate: define the magnitude threshold in the identity domain configuration and evaluate it at delegation time for any chain at depth 2 or greater, requiring human re-authorization if the threshold is exceeded regardless of irreversibility classification." ], "failure_signals": [ "Delegation token schema does not include a depth field, meaning depth is inferred at validation time from chain length \u2014 creating a race condition where depth can be misrepresented by omitting chain tokens.", "Irreversibility classifier is implemented as an advisory notification to a human operator rather than a synchronous gate that blocks token issuance until explicit human approval is received." ] }, "security_architect": { "summary": "Delegation depth limits are the structural control that prevents multi-agent orchestration from becoming an unbounded trust extension mechanism. Your role is to define the depth model, the gate criteria, and the re-authorization workflow \u2014 and to ensure that depth spoofing is structurally impossible.", "actions": [ "Define the depth model in the identity domain specification: document the depth counter semantics (counting from the human principal as depth 0), the 4-hop hard limit, the conditions that trigger intermediate re-authorization, and publish it as an architectural constraint that all orchestration platforms must satisfy.", "Design the re-authorization workflow: specify how human re-authorization is solicited (synchronous push notification or in-context approval UI), the minimum information the human must see before approving (chain depth, action class, scope magnitude, resource identifiers), and the maximum wait time before the delegation request is abandoned.", "Assess the attack surface for depth gate bypass: enumerate scenarios where an attacker could reset depth (e.g., by re-issuing a root delegation at depth 0 from a compromised agent) and define technical controls \u2014 such as binding the depth field to the chain root token's signature \u2014 that prevent depth spoofing." ], "failure_signals": [ "Re-authorization workflow design allows the requesting agent to supply the irreversibility classification of its own proposed actions, creating a trivial bypass where the agent claims all actions are reversible.", "Depth field is a client-supplied value in the delegation request rather than being computed and enforced by the authorization service, enabling depth spoofing by any agent." ] }, "legal_counsel": { "summary": "Delegation depth limits establish the structural boundary beyond which AI agent actions cannot claim to be covered by a human authorization decision. Actions taken by agents at or beyond the depth limit without re-authorization create legal exposure regardless of the acting agent's nominal scope \u2014 the original human authorization does not extend indefinitely through an unlimited chain.", "actions": [ "Review the re-authorization workflow to confirm that human re-authorization events are captured as legal evidence artifacts: the human identity, the information presented, the specific decision made, and the decision timestamp must all be recorded in tamper-evident form.", "Assess whether the 4-hop hard limit is consistent with the organization's duty of care obligations in relevant jurisdictions \u2014 particularly in sectors where human-in-the-loop requirements are specified for AI decision-making, such as EU AI Act Article 14 for high-risk AI systems.", "Confirm that the depth limit applies to agentic actions taken under the organization's enterprise delegation authority, so that agents operating in personal-in-enterprise context do not inherit a pre-existing deep chain from the enterprise scope authorization." ], "failure_signals": [ "Re-authorization event records do not capture the information presented to the human approver, making it impossible to demonstrate that informed consent was obtained rather than a blind rubber-stamp approval.", "Depth limit policy documentation carves out exceptions for specific agent types or orchestration platforms without a documented legal and risk basis for each exception." ] }, "grc_auditor": { "summary": "DE-03 provides the control that bounds agentic autonomy through delegation chain length. Your audit must verify that depth tracking is enforced in the delegation token as a tamper-evident field, that the hard limit is tested and enforced, and that re-authorization events are genuine approvals with adequate information.", "actions": [ "Test the hard limit directly: construct a delegation chain with 5 hops and submit the fifth delegation request to the authorization service, confirming rejection with a depth-exceeded error code logged in the rejection log.", "Sample re-authorization events from the review period and verify each event record contains: the triggering gate (irreversibility or scope-magnitude), the chain depth at which it triggered, the human approver identity, the information presented, and the approval timestamp.", "Review depth evaluation logs for the review period and verify that all delegation chains reaching depth 3 or greater have a corresponding gate evaluation record, confirming the gate logic is invoked for every qualifying chain, not only when the gate triggers a failure." ], "metrics": [ "Percentage of delegation chains at depth 3 or greater in the review period with a documented gate evaluation record (target: 100%)", "Number of depth greater than 4 rejection events in the review period \u2014 any non-zero value indicates agents are routinely hitting the hard limit and the orchestration design may need restructuring" ], "failure_signals": [ "Depth evaluation log shows no gate evaluation events for chains at depth 3 or greater, indicating the gate logic is not being invoked for qualifying chains.", "Re-authorization events show approvals with sub-second decision times, indicating the human approver did not meaningfully review the re-authorization request before approving." ] }, "it_operations": { "summary": "Your operational role includes monitoring delegation depth distributions in production, responding to hard-limit rejections that block agent task execution, and operating the re-authorization notification system that contacts human approvers in real time.", "actions": [ "Monitor the distribution of delegation chain depths in production: track the count of chains at each depth level (1 through 4) and alert if the proportion of chains at depth 3 or greater increases significantly week-over-week, which may indicate orchestration designs approaching the limit.", "Operate the re-authorization notification system: ensure push notifications or approval requests reach the designated human approver within the defined SLA (e.g., 60 seconds), and implement fallback escalation to a secondary approver if the primary approver is unresponsive within the wait window.", "Maintain the irreversibility classifier taxonomy: keep action classifications current as new agent capabilities are deployed, and coordinate with the security team when new action types are first introduced to ensure they are classified before agents can request delegations to perform them." ], "failure_signals": [ "Re-authorization notification system shows approvals being granted at a rate above 95% \u2014 potentially indicating approvers are approving all requests without meaningful review, which should trigger a process review.", "Irreversibility classifier taxonomy has not been updated in more than 30 days despite new agent action types being deployed, indicating a gap in classifier coverage that could cause irreversible actions to be misclassified as reversible." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Multi-agent orchestration systems rarely track delegation depth explicitly; chain length is de facto determined by the number of agent-to-agent calls the orchestrator makes without any token-level depth counter. Target state requires depth to be a tracked, enforced token field with gated re-authorization at defined thresholds." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "platform-engineer" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 4", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 4 requires access determined by dynamic policy \u2014 continuous evaluation rather than standing authorization; depth-based intermediate re-authorization gates re-invoke that policy evaluation at each delegation hop.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "partial", "rationale": "SP 800-63C-4 addresses federation assurance, not hop counts; no 800-63 volume prescribes delegation depth limits. DE-03 cites the FAL model only as the assurance vocabulary its intermediate re-authorization gates use.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS STS \u2014 Role Chaining Session Policy", "rationale": "AWS STS role chaining session policies can only restrict, never expand, permissions at each step; this implicit depth constraint prevents scope amplification through delegation chains. AWS recommends limiting role chaining to two hops and enforcing this through SCPs that restrict sts:AssumeRole actions on derived session credentials.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS STS role-chaining restricts-only and a recommended two-hop limit constrain depth, but there is no enforced monotonic depth field with re-auth gate.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity Runtime Identity \u2014 Delegation Depth Limit", "rationale": "Ping Identity's Runtime Identity Standard explicitly limits delegation depth to prevent unbounded delegation chains. The Agent Gateway tracks a delegation depth counter in the token claims and rejects any delegation request that would exceed the configured maximum depth, preventing recursive agent spawning from amplifying authorization scope.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Ping Runtime Identity tracks a delegation-depth counter in token claims and the Gateway rejects any delegation exceeding the limit - the control exactly.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II \u2014 Unscoped privilege inheritance (manager to worker delegation); Part IV Phase 3 \u2014 Scope limits / Least Agency (compartmentalize into multiple agents)", "fit": "partial", "rationale": "Doc warns against passing full access context down a delegation chain and recommends compartmentalization. Partial: doc does not prescribe an explicit delegation-depth limit.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every delegation token must carry an authorization-service-set depth field that increments monotonically at each hop. The system must enforce a configured maximum delegation depth and reject any delegation request that would cause the chain depth to exceed the limit, preventing unbounded recursive delegation regardless of token lifetime.", "evidence_required": [ "delegation_depth_policy_definition specifying the maximum allowed chain depth value and confirming enforcement occurs at the authorization service, not the client or resource server", "delegation_token_sample_set showing the depth field present and correctly incremented across a multi-hop delegation chain, with a request at max_depth resulting in rejection", "depth_limit_rejection_log capturing all delegation attempts that exceeded the maximum depth with chain_id, current_depth, and requesting agent_id", "authorization_service_configuration record showing the max_delegation_depth parameter value applied globally with no per-agent or per-task overrides permitted" ], "machine_tests": [ "Issue delegation tokens up to max_depth and then attempt one additional delegation \u2192 assert authorization service returns 403 with error=delegation_depth_limit_exceeded", "Submit a delegation request with the depth field manually set to 0 in the client request \u2192 assert authorization service ignores the client-provided value and sets depth to the server-computed chain length", "Issue a chain of delegations at max_depth \u2212 1 \u2192 assert the depth field in each token increments monotonically and equals the computed chain length", "Attempt to construct a delegation cycle where agent A delegates to B and B delegates back to A \u2192 assert authorization service returns error=delegation_cycle_detected" ], "human_review": [ "Review the maximum delegation depth configuration and assess whether the configured limit is appropriate for the organization's multi-agent workflow complexity without enabling unbounded recursive delegation", "Assess the depth field enforcement implementation to confirm the authorization service sets the depth value and the field cannot be omitted or overridden by the requesting client", "Verify that no exception path exists for administrative or break-glass identities to exceed the configured depth limit without a formal policy change recorded in the policy change log" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Allowing the requesting agent to supply the depth value in the delegation request body, enabling agents to set depth to 0 or a low value to reset the counter and create unbounded chains", "Setting the maximum delegation depth to an excessively large value such as 100 that provides no practical protection against recursive delegation attacks", "Omitting the depth field from delegation tokens entirely and relying solely on time-based expiry to bound delegation chain length", "Enforcing depth limits only at the resource server rather than at the authorization service, allowing arbitrarily deep chains to be created and only failing at consumption time", "Exempting administrative or emergency delegation flows from depth limits, creating an exploitable path for privilege escalation through unconstrained administrative delegation chains" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-04", "layer": "DE", "plane": "control", "name": "Task-Scoped Delegation", "plain": "Require all AI agent delegations to be bound to a specific task type, target resources, and expiry time \u2014 prohibiting open-ended standing delegations and requiring re-authorization for any scope extension.", "threat": { "tags": [ "delegation-abuse", "privilege-escalation" ], "desc": "Standing delegations \u2014 delegations not bound to a specific task or expiry \u2014 are the delegation equivalent of wildcard credentials: they authorize any action within the scope, at any time, indefinitely. An attacker who gains control of an agent with a standing delegation can use it to perform actions far beyond the original legitimate purpose without any time constraint or task boundary. Task-scoped delegations with explicit expiry force re-authorization for every distinct task execution, ensuring that authorization is current and specific to each actual use case rather than a historical grant that may no longer reflect the principal's intent or the organization's current policy." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 3", "title": "Per-session resource authorization" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "Rich authorization requests with task context" }, { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Federation Assurance Levels \u2014 bounded-assertion analogy for task scoping" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/DE-04 Task-Scoped Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-04 Task-Scoped Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-04 Task-Scoped Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-04 Task-Scoped Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/DE-04 Task-Scoped Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "databricks_omnigent_2026", "title": "Databricks Omnigent \u2014 Contextual Policies", "authority": "Databricks", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026-07-07", "published_on": "2026-07-07", "retrieved_on": "2026-07-07", "canonical_url": "https://www.databricks.com/blog/contextual-policies-omnigent-using-session-state-better-govern-ai-agents", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_omnigent_2026", "relationship": "supporting_guidance", "rationale": "Omnigent's intent-based authorization sets an agent's permissions from the user's initial prompt under the principle of least privilege \u2014 a task-scoped delegation pattern.", "reviewed_on": "2026-07-07" } ], "implementation": { "pattern": "Task-bound delegation token with mandatory task_type, resource_set, and expiry fields \u2014 enforced at issuance by the authorization service and at runtime by the agentic verifier", "steps": [ "Define a delegation request schema that requires three mandatory fields beyond identity: task_type (a controlled vocabulary term from the task registry describing the work being authorized), resource_set (an explicit enumeration of target resource identifiers or a scoped resource query against a bounded resource group), and expiry (an absolute timestamp no more than 24 hours in the future for standard tasks and 1 hour for consequential tasks as defined in the task registry).", "Require the authorization service to validate that task_type maps to a known class in the task registry and that resource_set is consistent with the scope ceiling for that task class; reject delegation requests with open-ended resource_set values (e.g., wildcard patterns) and require the requestor to enumerate specific resources or use a bounded resource group query.", "Publish the task_type, resource_set, and expiry fields as verifiable claims in the delegation token so they are available to resource servers and the agentic verifier at apeiris://agentic/controls/AA-06 for runtime validation \u2014 enabling the agentic verifier to confirm the agent is acting within its declared autonomy tier and within the task's authorized resource set.", "Require re-authorization for any scope extension: if an agent needs to access a resource not in its original resource_set or to extend its delegation expiry, it must initiate a new full delegation request through the authorization workflow with a human approval step rather than self-extending its existing token." ], "anti_patterns": [ "Issuing a single delegation covering all tasks an agent is expected to perform over its deployment lifetime, rather than issuing per-task delegations at execution time when the specific task and resources are known.", "Accepting task_type values of 'general-operations' or 'any-task' that do not constrain the authorization to a specific work type, effectively converting a nominally task-scoped token into a standing delegation.", "Allowing agents to extend their own delegation expiry through a self-service API call or token refresh mechanism without a new human authorization event, eliminating the re-authorization requirement for expired tasks." ] }, "validation": { "design_check": [ "Confirm delegation request schema enforces task_type, resource_set, and expiry as required fields and the authorization service rejects requests missing any of them or providing open-ended values.", "Verify authorization service validates task_type against the controlled task registry and rejects open-ended resource_set values including wildcards and resource-type-level patterns.", "Confirm delegation token includes task_type, resource_set, and expiry as verifiable claims accessible to resource servers and the agentic verifier at apeiris://agentic/controls/AA-06." ], "runtime_test": [ "Submit a delegation request with task_type set to 'general-operations' and verify the authorization service rejects it as an invalid controlled vocabulary term.", "Submit a delegation request with resource_set set to a wildcard pattern and verify the authorization service rejects it as an open-ended resource set.", "Attempt to use a delegation token to access a resource not present in its resource_set and verify the resource server rejects the request at the resource_set validation layer." ], "evidence": [ "task-delegation-log:Authorization service log showing task_type, resource_set, and expiry validation results for all delegation requests in the review period [unverified]", "agentic-verifier-audit:AA-06 verifier log showing task scope and expiry validation events linked to delegation token claims for each agent action in the review period [unverified]", "re-auth-events:Re-authorization events triggered by scope extension requests, confirming no self-extension path is available and each extension required a new human-authorized delegation token [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Your core task is to implement per-task delegation issuance at the orchestration layer: every time a task is dispatched to an agent, a new delegation token must be requested, validated, and issued with task_type, resource_set, and expiry bound to that specific task execution \u2014 not inherited from a standing deployment-time credential.", "actions": [ "Design the delegation request API to require task_type, resource_set, and expiry as mandatory request parameters, with the authorization service rejecting any request that omits them or provides open-ended values, and returning structured error responses that identify the specific invalid field.", "Integrate delegation token issuance into the task dispatch workflow in the orchestration layer: modify the task queue or scheduler so that delegation token request, validation, and issuance is part of the standard task dispatch sequence before any agent receives a task assignment.", "Implement and maintain the task type registry as a security-critical configuration artifact: define the controlled vocabulary of valid task_type values, each with associated resource constraint rules and maximum expiry durations, and version-control the registry with security team review required for any additions." ], "failure_signals": [ "Task dispatch logs show agents being activated without a corresponding delegation token issuance event in the review period, indicating some task dispatch paths bypass the delegation workflow entirely.", "Authorization service accepts task_type values not present in the task type registry, indicating registry validation is not enforced at the issuance path." ] }, "security_architect": { "summary": "Task-scoped delegation is the structural mechanism that implements least-privilege at the task level rather than the agent level. Your architecture must ensure that scoping is enforced at issuance (authorization service), at runtime (resource server), and during agentic execution (agentic verifier at apeiris://agentic/controls/AA-06) with no bypass path between layers.", "actions": [ "Define the three-layer task scope enforcement architecture in the identity domain specification: authorization service validates task_type and resource_set at issuance, resource server validates the acting agent's resource_set claim at runtime, and the agentic verifier at apeiris://agentic/controls/AA-06 validates task_type and expiry against the declared autonomy tier \u2014 document all three layers and their interdependencies.", "Design the task type registry as a security control: specify the governance process for adding new task types including security review, resource constraint definition, maximum expiry limits, and the registry ownership \u2014 ensure the registry is treated as a security-critical configuration artifact with change audit trail.", "Assess the self-extension attack surface: enumerate all API paths through which an agent could extend its own delegation expiry or resource_set without human re-authorization and confirm that each path is closed at the authorization service, with the closure tested and documented." ], "failure_signals": [ "Architecture review reveals resource servers that trust the acting agent's resource_set claim without validating it against the issued delegation token, allowing an agent to self-assert an expanded resource set at runtime.", "Task type registry governance process allows orchestration systems or agents to register new task types programmatically without security team review, enabling task type inflation that weakens the vocabulary constraint." ] }, "legal_counsel": { "summary": "Task-scoped delegation creates the legal record that an AI agent was authorized to perform a specific type of task on a specific set of resources at a specific time. This specificity is essential for demonstrating that the agent did not exceed its authorization and for responding to regulatory inquiries or legal claims arising from agent actions.", "actions": [ "Review the task type registry and confirm that each task type definition is specific enough to constitute a meaningful authorization boundary \u2014 generic task types such as 'data-processing' that cover all data operations are insufficient to establish that a specific action was within the scope of a specific task authorization.", "Confirm that delegation token records including task_type, resource_set, and expiry are retained in tamper-evident form for the full legal hold period and that the records are structured so they can be produced as discoverable evidence in response to a regulatory inquiry or litigation.", "Assess the re-authorization requirement for scope extensions: confirm that the prohibition on self-extension is implemented at the authorization service level (not just by policy) and that any scope extension requires a new delegation token with a new human authorization event, ensuring no undocumented or unauthorized scope expansion can occur." ], "failure_signals": [ "Delegation token records are stored in a mutable database without a write-once or cryptographic immutability guarantee, making them potentially inadmissible as evidence of original authorization scope in a legal proceeding.", "Task type definitions are so broadly drafted that they could be argued to authorize actions far beyond the specific task performed, weakening the legal case that the agent acted within the boundaries of its authorization." ] }, "grc_auditor": { "summary": "DE-04 is the control that makes AI agent delegation specific and time-bound rather than open-ended. Your audit must verify that every agent action in the review period can be traced to a task-scoped delegation token that was valid (not expired) at the time of the action, and that no standing or open-ended delegations exist in the active token registry.", "actions": [ "Scan the authorization service's active delegation token registry for any token with task_type values that are not in the controlled registry vocabulary, or with resource_set values that use wildcard patterns, flagging each as a control failure requiring immediate remediation.", "Sample agent action logs from the review period and for each action verify: task_type matches the class of action performed, the resource accessed is present in the token's resource_set, and the action timestamp falls before the token's expiry.", "Verify that scope extension events result in new delegation tokens rather than modifications to existing tokens: review the delegation token issuance log for tokens with the same chain lineage and confirm each successive token was issued through a full re-authorization workflow with a human approval event." ], "metrics": [ "Percentage of active delegation tokens in the review period with specific task_type values from the controlled registry (target: 100%)", "Percentage of agent actions in the review period where the accessed resource is confirmed within the associated token's resource_set (target: 100%)" ], "failure_signals": [ "Authorization service active token registry contains tokens with expiry dates more than 24 hours in the future for standard task types, indicating the expiry ceiling defined in the task registry is not being enforced at issuance.", "Agent action logs contain actions performed after the associated delegation token's expiry timestamp, indicating resource server expiry validation is not implemented or is not enforced for all request paths." ] }, "it_operations": { "summary": "Your operational role is to monitor task delegation token health \u2014 issuance rates, expiry patterns, and resource_set utilization \u2014 and to respond to delegation failures that block agent task execution without silently allowing agents to fall back to standing credentials.", "actions": [ "Monitor delegation token issuance rates per agent type and per task type: alert on significant deviations from baseline (e.g., an agent type suddenly requesting delegation for task types outside its normal operational profile), which may indicate orchestration compromise, misconfiguration, or an agent attempting to expand its task scope.", "Operate the delegation expiry enforcement monitoring: track the time between token issuance and first use, and alert on tokens that are issued but never used within their expiry window \u2014 this pattern may indicate delegation requests being made speculatively at agent startup rather than at task dispatch time.", "Establish runbook procedures for task delegation failures: define the escalation path when an agent cannot obtain a delegation token for a required task (including fallback to human execution of the task), and ensure the operations team can distinguish between a delegation policy rejection (correct behavior) and an authorization service outage (requires incident response)." ], "failure_signals": [ "Delegation token issuance logs show a single token being reused across multiple distinct task executions over an extended period, indicating the token was issued as a standing delegation at agent startup rather than issued per task at dispatch time.", "Re-authorization request queue shows requests accumulating without approval over multiple hours, indicating the human approver notification system has failed and agent task execution is silently blocked rather than properly escalated." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI agent delegation in most environments is issued at deployment time for the agent's expected operational scope rather than at task execution time for specific tasks. Implementing per-task delegation requires the orchestration layer to issue delegation requests at task dispatch \u2014 a significant but necessary architectural change that requires coordination between the IAM team and the platform engineering team." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "platform-engineer", "security-architect" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 3", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 3 grants access per session to individual resources; task-scoped delegation with explicit resource_set and expiry implements this requirement at the agentic task level, enforcing least privilege for every task execution.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "direct", "rationale": "RFC 9396 authorization_details directly support task-scoped delegation through structured resource and action fields that bound the delegation to specific resources and operations, providing the claim format for task_type and resource_set.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "partial", "rationale": "SP 800-63C-4 \u00a72 defines Federation Assurance Levels, and 63C's bounded-assertion model (audience restriction, limited validity) is the closest federation analogue to task-scoped delegation; the standard does not itself address task-level scoping for agents.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS STS \u2014 Session Policies Task Scoped", "rationale": "AWS STS AssumeRole with inline session policies enables task-scoped temporary credential issuance: the caller passes a session policy that restricts the role's permissions to exactly the resources required for the specific task, with a session duration matched to the task. This creates fine-grained task delegation without requiring new IAM roles per task.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "AWS STS session policies bind temporary credentials to the specific task resources and expiry, prohibiting open-ended standing delegation as required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Cross App Access \u2014 task-scoped resource tokens (RFC 8693 token exchange)", "rationale": "Okta Cross App Access (built on RFC 8693 OAuth Token Exchange via the Identity Assertion Authorization Grant) enables task-scoped delegation by allowing an agent to request a resource token specifying the exact audience and scope for the current task. The resulting token is bound to the declared task scope and cannot be reused for other tasks, enforcing task-level delegation boundaries.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Cross App Access (RFC 8693) issues resource tokens scoped to the exact audience and scope for the current task - task-scoped delegation as required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Privilege scoping (Dynamic privilege adjustment based on task requirements); Part IV Phase 3 \u2014 Scope limits / Least Agency", "fit": "direct", "rationale": "Elevate permissions only when a specific task requires them and return to baseline after completion \u2014 task-scoped delegation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every delegation token must be bound to a specific task_type, a bounded resource_set, and a defined expiry. The authorization service must reject any delegation request that omits any of these fields or that provides an open-ended resource specification. Resource servers must enforce the task_type and resource_set boundaries at the access layer.", "evidence_required": [ "delegation_token_schema_definition showing task_type, resource_set, and expiry as required non-nullable fields with validation rules that reject wildcard or open-ended resource_set values", "task_scoped_token_sample_set covering at least three distinct task types, showing token fields and confirming each resource_set is bounded to the resources required for that specific task", "delegation_rejection_log capturing requests denied due to missing task_type, missing resource_set, missing expiry, or open-ended resource_set specification", "resource_server_enforcement_log showing enforcement of task_type and resource_set boundaries at the resource access layer, including denied requests for out-of-scope resources" ], "machine_tests": [ "Submit delegation request omitting the task_type field \u2192 assert authorization service returns 400 with error=missing_required_field:task_type", "Submit delegation request with resource_set set to '*' or containing a wildcard pattern \u2192 assert authorization service returns 400 with error=open_ended_resource_set_not_permitted", "Issue a valid task-scoped token and use it to access a resource outside the declared resource_set \u2192 assert resource server returns 403 with error=resource_out_of_task_scope", "Issue a task-scoped token, allow expiry to elapse, then attempt to use it \u2192 assert resource server returns 401 with error=token_expired" ], "human_review": [ "Review delegation request schema enforcement to confirm task_type, resource_set, and expiry are validated server-side and cannot be bypassed by the requesting agent", "Assess a sample of delegation tokens issued in the past 30 days to verify resource_set values are specific to individual task contexts rather than broad operational permission sets", "Verify that task type definitions are maintained in a central task registry and delegation requests must reference a valid registered task_type, preventing arbitrary self-declared task context claims" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Issuing long-lived delegation tokens scoped to broad resource sets rather than short-lived tokens bound to the specific resources needed for a single task execution", "Allowing 'default' or 'general' task types that map to wide resource sets, effectively bypassing task-scoping by using a catch-all task category as a workaround", "Setting delegation token expiry to the same maximum lifetime as the parent credential rather than to the expected duration of the specific task being delegated", "Trusting the requesting agent to self-declare task_type and resource_set values without validating them against an authoritative task registry at the authorization service", "Implementing task-scoped delegation only at the application layer without resource server enforcement, so tokens can be used against out-of-scope resources if the application layer is bypassed" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-05", "layer": "DE", "plane": "control", "name": "User Consent for Delegated AI Action", "plain": "Require explicit, informed, action-specific consent from the human principal before any consequential AI agent action is executed on their behalf, with consent records retained and auditable.", "threat": { "tags": [ "delegation-abuse", "identity-spoofing" ], "desc": "Blanket consent \u2014 where a human principal grants an AI agent permission to act on their behalf across a broad class of actions in a single approval \u2014 is a delegation abuse vector because it authorizes far more than any individual decision-moment requires, and the human principal typically has no ongoing visibility into which specific actions are being taken under that blanket grant. Identity spoofing occurs when an AI agent represents to a resource server that a human principal has consented to a specific action when in fact only a broad blanket consent exists \u2014 the agent is misrepresenting the scope of the consent. For personal-in-enterprise scenarios, blanket personal consent does not substitute for enterprise authorization; both must be obtained independently and neither can be assumed from the other." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63A-4", "title": "Identity proofing for consent binding" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "Authorization details as consent declaration" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-05 User Consent for Delegated AI Action control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-05 User Consent for Delegated AI Action control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/DE-05 User Consent for Delegated AI Action control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy (RSP) v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy (RSP) requirements informing the apeiris://identity/controls/DE-05 User Consent for Delegated AI Action control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Action-class-specific consent collection with signed consent records, personal-in-enterprise dual-gate, and retention-backed audit trail", "steps": [ "Define a consent taxonomy mapping each consequential action class (e.g., financial transaction, data export, configuration change, external communication) to a required consent specificity level; require consent to be collected at the action-class level at minimum, and at the specific-action level for irreversible actions above a defined materiality threshold.", "Collect consent through an authenticated interaction with the human principal \u2014 not through pre-checked defaults, silent renewals, or consent bundled into onboarding agreements \u2014 and issue a signed consent record containing: principal identity, action class, specific resources (if applicable), agent identity, consent timestamp, consent method, and expiry.", "For personal-in-enterprise scenarios, require two independent authorizations before proceeding: the human principal's signed consent record (DE-05 scope) and an enterprise authorization token from the Authority service confirming the principal is permitted to delegate this capability class to an AI agent at this materiality level (apeiris://authority/controls/PA-02 scope); block the action if either is absent.", "Retain all consent records in an immutable consent log indexed by principal identity, action class, and agent identity; provide the principal with an accessible record of all current and historical consent grants and a mechanism to withdraw consent at any time, with withdrawal triggering an immediate delegation revocation cascade through DE-08." ], "anti_patterns": [ "Treating a one-time onboarding consent form as sufficient authorization for all future AI agent actions on the principal's behalf regardless of action type or materiality.", "Collecting consent from the enterprise IT administrator rather than the individual human principal who will be the subject of the AI agent's actions.", "Using implicit consent (the principal signed up for the service and the terms of service mention AI agents) as a substitute for explicit action-class consent for consequential actions." ] }, "validation": { "design_check": [ "Confirm consent collection mechanism requires an authenticated principal interaction for each action class, not a one-time blanket consent.", "Verify personal-in-enterprise consent workflow enforces both user consent and PA-02 enterprise authorization as independent prerequisites before the action is authorized.", "Confirm consent withdrawal mechanism exists and is wired to a delegation revocation cascade through DE-08." ], "runtime_test": [ "Attempt to execute a consequential action with a blanket consent record (no action class specified) and verify the authorization service rejects it.", "Attempt to execute a personal-in-enterprise action with user consent but no PA-02 enterprise authorization and verify the action is blocked.", "Withdraw consent for an active delegation and verify the DE-08 revocation cascade fires within the defined propagation SLA." ], "evidence": [ "consent-log:Signed consent records for all consequential AI agent actions in the review period, indexed by principal, action class, and agent identity [unverified]", "dual-gate-audit:Authorization service log showing PA-02 enterprise authorization check as a required step for each personal-in-enterprise consent evaluation [unverified]", "withdrawal-cascade-log:DE-08 revocation events triggered by consent withdrawals, with propagation confirmation timestamps [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "DE-05 requires the consent collection mechanism to be an authenticated, asynchronous interaction with the principal \u2014 not a passive checkbox at onboarding. Engineering the consent UI and the signed consent record issuance is the primary implementation challenge; the dual-gate for personal-in-enterprise scenarios requires coordination with the Authority service.", "actions": [ "Build an authenticated consent collection UI that presents action-class-specific language and issues a signed consent record on approval, linked to the requesting agent identity.", "Integrate the PA-02 enterprise authorization check into the personal-in-enterprise consent flow so both gates are evaluated in a single authorization request to the combined identity and authority service.", "Wire consent withdrawal events to the DE-08 revocation cascade so the delegation is terminated within the propagation SLA defined in DE-08." ], "failure_signals": [ "Consent records in the consent log contain only a principal identity and a timestamp \u2014 no action class, no agent identity, no expiry.", "Personal-in-enterprise actions proceed with only a user consent record and no PA-02 enterprise authorization token present in the authorization chain." ] }, "security_architect": { "summary": "Consent specificity is the core architectural decision in DE-05. Blanket consent and blanket revocation are easy to implement but create either excessive restriction or insufficient protection. The consent taxonomy \u2014 mapping action classes to specificity requirements \u2014 is the artifact that makes the control both usable and auditable.", "actions": [ "Design the consent taxonomy collaboratively with legal, compliance, and product teams so specificity requirements reflect both regulatory obligations and practical usability constraints.", "Model consent as a first-class identity artifact (signed record with an identity, expiry, and revocation endpoint) rather than as a database flag that can be toggled without audit trail.", "Design the PA-02 dual-gate as a policy evaluation call rather than a hardcoded branch, so enterprise authorization requirements can be updated without code changes." ], "failure_signals": [ "Consent taxonomy is defined only in policy documentation and not referenced by the authorization service logic \u2014 meaning the consent check is performed at the UI level only and can be bypassed by direct API calls.", "PA-02 enterprise authorization check is implemented as an advisory step rather than a blocking gate." ] }, "legal_counsel": { "summary": "DE-05 maps directly to GDPR Article 7 (conditions for consent) and to common law agency principles requiring informed consent for delegated action. The signed consent record with action-class specificity is the artifact that demonstrates lawful basis for AI agent action when challenged.", "actions": [ "Review consent record schema against GDPR Article 7 requirements: freely given, specific, informed, and unambiguous indication of the data subject's wishes \u2014 ensure all four criteria are met.", "Confirm that the consent collection mechanism for actions involving signing, authentication, or legally binding declarations meets the applicable formality requirements in each operating jurisdiction (e.g., electronic signature rules), with counsel review for EU-regulated contexts.", "Establish a consent record retention policy that satisfies both the regulatory retention minimum (typically 3 years from last action) and the organization's litigation hold requirements." ], "failure_signals": [ "Consent records do not include the specific action class or agent identity, making it impossible to demonstrate that consent was specific rather than blanket.", "No documented process for responding to a data subject access request that includes all AI agent action consent records linked to that subject." ] }, "grc_auditor": { "summary": "Consent specificity and the personal-in-enterprise dual-gate are the two audit focus points in DE-05. Auditors should sample consequential actions from the review period and verify each has a signed action-class-specific consent record and, for personal-in-enterprise cases, a corresponding PA-02 enterprise authorization token.", "actions": [ "Sample 20 consequential AI agent actions from the audit period and retrieve the corresponding consent records; verify each record specifies the action class, agent identity, and expiry \u2014 not a blanket consent reference.", "For the subset of sampled actions involving personal-in-enterprise scenarios, verify both a signed user consent record and a PA-02 enterprise authorization token are present and unexpired at the time of the action.", "Review the consent withdrawal log for the audit period and verify each withdrawal triggered a DE-08 revocation event within the propagation SLA." ], "metrics": [ "Percentage of consequential AI agent actions with an action-class-specific signed consent record (target: 100%).", "Mean time from consent withdrawal submission to confirmed delegation revocation via DE-08 cascade (target: within the DE-08 propagation SLA of 60 seconds for consequential delegations)." ], "failure_signals": [ "Sampled consent records reference a blanket consent grant from the principal's onboarding agreement rather than an action-class-specific consent interaction.", "Consent withdrawal events have no corresponding DE-08 revocation entries, indicating the withdrawal-to-revocation cascade is not implemented." ] }, "it_operations": { "summary": "Operations teams are rarely involved in consent collection \u2014 that is an IAM and product responsibility. But they own the delegation revocation cascade that fires on consent withdrawal, and they need to ensure the DE-08 propagation mechanism is operational and monitored.", "actions": [ "Verify the consent withdrawal endpoint is operational and that withdrawal events are routed to the DE-08 revocation cascade without manual intervention.", "Include consent withdrawal revocation events in the identity operations dashboard alongside other revocation event types so anomalous withdrawal rates are visible.", "Document the consent withdrawal processing path in the incident response runbook so the team knows how to respond if the cascade fails to fire after a withdrawal." ], "failure_signals": [ "Consent withdrawal endpoint returns a success response but no DE-08 revocation event fires \u2014 indicating the withdrawal is recorded but not acted upon.", "Consent withdrawal events are not visible in the identity operations dashboard, leaving the operations team blind to principal-initiated delegation terminations." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Consent for AI agent action is almost universally implemented as a blanket onboarding agreement rather than action-class-specific consent. Target defined state requires a signed consent record per action class per agent, with retention, withdrawal, and a functioning dual-gate for personal-in-enterprise scenarios." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "legal-counsel" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63A-4", "fit": "partial", "rationale": "SP 800-63A-4 identity proofing establishes the assurance baseline for binding a consent event to a verified identity \u2014 applied here so consent records are linked to a proofed principal identity rather than a self-asserted claim.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "partial", "rationale": "RFC 9396 authorization_details objects provide the structured consent declaration format \u2014 expressing action type, resource, and scope in a machine-readable form that aligns with action-class-specific consent requirements.", "source_version": "RFC 9396", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta OAuth \u2014 User Consent Framework", "rationale": "Okta's OAuth consent framework requires end-user approval before delegating access to applications (including AI agents) acting on their behalf. Consent grants are auditable, revocable via the end-user dashboard, and scoped to specific permissions declared by the client. Incremental consent allows agents to request only the permissions needed for the current task.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta OAuth consent records auditable, revocable end-user approval at grant time, but is scope-level rather than the per-action consent the control needs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Claude's Constitution \u2014 operator and user permission hierarchy", "rationale": "Anthropic's published constitution for Claude defines a principal hierarchy (Anthropic, operator, user) in which agents act on users' behalf only within what users have permitted: agents should not take actions users would prohibit if aware, and high-consequence delegated actions call for explicit user consent gates. DE-05 operationalizes that consent gate for delegated AI action.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic constitution establishes a normative principal-permission hierarchy but produces no action-specific signed consent record the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 \u2014 Escalation triggers; Part II \u2014 Unscoped privilege inheritance (executes without verifying the original user's intent)", "fit": "partial", "rationale": "Escalation triggers require approval for sensitive delegated actions; the confused-deputy failure is executing without verifying original user intent. Partial: doc does not prescribe explicit user consent capture for delegated action.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The system must require and record an action-class-specific signed consent record from the authenticated human principal before executing any consequential AI agent action on their behalf. For personal-in-enterprise scenarios, both a signed user consent record and a PA-02 enterprise authorization token must be present and unexpired as independent prerequisites before the action proceeds.", "evidence_required": [ "signed_consent_record per action-class with required fields: principal_identity, action_class, agent_identity, consent_timestamp, consent_method, expiry, and digital signature \u2014 confirming consent was specific and authenticated", "consent_log showing all consequential AI agent actions in the review period indexed by principal identity, action class, and agent identity, with no entries lacking a signed action-class-specific consent reference", "dual_gate_authorization_log showing PA-02 enterprise authorization check as a blocking prerequisite for each personal-in-enterprise consent evaluation in the review period", "withdrawal_cascade_log showing DE-08 revocation events triggered by consent withdrawals in the review period, with confirmed propagation timestamps within the configured SLA" ], "machine_tests": [ "Submit consequential action request with blanket consent record containing no action_class field \u2192 assert authorization service returns 403 with error_code=consent_specificity_insufficient", "Submit personal-in-enterprise action with valid signed user consent record but no PA-02 enterprise authorization token \u2192 assert action is blocked with error_code=enterprise_authorization_missing", "Withdraw consent for active delegation and measure time to DE-08 revocation event \u2192 assert revocation fires within the configured propagation SLA of \u226460 seconds", "Attempt consequential action with expired signed consent record \u2192 assert authorization service returns 403 with error_code=consent_expired" ], "human_review": [ "Review the consent collection workflow for completeness: verify it requires an authenticated principal interaction for each action class and cannot be bypassed by direct API calls to the authorization service", "Assess the consent taxonomy to confirm action class specificity requirements reflect applicable regulatory obligations (GDPR Art. 7) and current business operations for AI agent delegation", "Verify the consent withdrawal-to-revocation cascade is documented in the incident response runbook and confirmed operational through periodic end-to-end testing" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Collecting a one-time onboarding consent form and treating it as authorization for all future AI agent actions regardless of action type, materiality, or the passage of time", "Requiring enterprise IT administrator approval as a substitute for individual human principal consent for actions taken on behalf of that specific principal", "Implementing consent collection only at the UI layer, allowing direct API calls to the authorization service to bypass the consent gate entirely", "Combining user consent collection and enterprise PA-02 authorization into a single shared approval step, making it impossible to demonstrate that each requirement was independently satisfied", "Storing consent records as mutable database boolean flags without timestamps, agent identity, action class, or digital signature, making retrospective verification impossible" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-06", "layer": "DE", "plane": "control", "name": "Cross-Organizational Delegation Governance", "plain": "Require mutual trust agreements, documented scope, liability assignment, and audit rights before any AI agent delegation crosses an organizational boundary.", "threat": { "tags": [ "delegation-abuse", "federation-bypass" ], "desc": "Cross-organizational delegation creates a delegation authority gap: the delegating organization has visibility into the chain up to the boundary, but the receiving organization's enforcement of the delegated scope may differ from the delegator's expectations, and the delegating organization may have no contractual basis to audit whether the delegated scope was honored. Federation bypass occurs when cross-organizational delegation is treated as equivalent to federated authentication \u2014 allowing a delegated agent to access resources in the receiving organization as if it had been natively provisioned, bypassing the receiving organization's own identity governance controls. Without a mutual trust agreement defining scope, breach notification obligations, and audit rights, the delegating organization has no enforceable mechanism to ensure the delegation is used as intended." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a73.5", "title": "Federation trust agreements \u2014 cross-organization" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Reference architecture and requirements \u2014 cross-organizational identity federation" }, { "id": "eidas2", "section": "Art. 6", "title": "Mutual recognition of electronic identification means" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-06 Cross-Organizational Delegation Governance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/DE-06 Cross-Organizational Delegation Governance control.", "reviewed_on": "2026-07-02" }, { "id": "eidas2_reg_2024_1183", "title": "Regulation (EU) 2024/1183 \u2014 eIDAS 2.0", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1183", "published_on": "2024-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401183", "license": "public-domain", "status": "current", "flagship": false, "source_id": "eidas2_2024_1183", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1183 \u2014 eIDAS 2.0 requirements informing the apeiris://identity/controls/DE-06 Cross-Organizational Delegation Governance control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-06 Cross-Organizational Delegation Governance control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/DE-06 Cross-Organizational Delegation Governance control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Contract-backed cross-org delegation with explicit trust anchor, scope schedule, liability assignment, and audit rights clause", "steps": [ "Before establishing any cross-organizational delegation, execute a written mutual trust agreement (MTA) specifying: the identity of both organizations, the scope of delegation (expressed as a structured scope schedule, not a narrative description), the liability assignment for actions taken under the delegation, the breach notification obligation (maximum 72 hours), and the audit rights of the delegating organization over the receiving organization's use of the delegated scope.", "Represent the MTA as a machine-readable trust anchor document (e.g., signed JSON-LD policy document or OpenID Federation entity statement) stored in both organizations' trust registries; require all cross-org delegation tokens to include a reference to the MTA identifier so resource servers can verify the delegation is authorized under an active agreement.", "Distinguish cross-org delegation from cross-org federation in the authorization model: federation establishes authentication trust (organization B trusts organization A's identity assertions); delegation establishes action authorization (organization A's agent is permitted to act within organization B's systems up to the scope defined in the MTA). Enforce both independently \u2014 a federated identity does not automatically carry delegation scope, and a delegation token does not authenticate the agent's identity without a separate federation trust.", "Require quarterly MTA review: confirm the scope schedule reflects current operational needs, assess whether any security events in the review period require scope reduction, and confirm the receiving organization's audit log contains complete records of all actions taken under the delegation during the quarter." ], "anti_patterns": [ "Treating a vendor contract or SLA as a sufficient substitute for an explicit delegation scope schedule \u2014 vendor contracts define service obligations, not authorization scope for AI agent actions.", "Conflating cross-org federation (authentication trust) with cross-org delegation (action authorization), and issuing cross-org delegation tokens to any agent that presents a federated identity token without a separate MTA-backed authorization check.", "Establishing cross-org delegation without audit rights in the MTA, leaving the delegating organization unable to verify whether the delegated scope was honored in the receiving organization." ] }, "validation": { "design_check": [ "Confirm a signed MTA exists for every active cross-organizational delegation and that the MTA contains a structured scope schedule, liability assignment, breach notification obligation, and audit rights clause.", "Verify cross-org delegation tokens include an MTA reference identifier and that resource servers in the receiving organization validate the MTA reference against the trust registry.", "Confirm the authorization model distinguishes cross-org federation from cross-org delegation and enforces both independently." ], "runtime_test": [ "Attempt to issue a cross-org delegation token without a matching MTA reference in the trust registry and verify the authorization service rejects it.", "Present a valid federated identity token (no delegation token) to a cross-org resource server and verify it is not treated as sufficient authorization for delegated actions.", "Retrieve the receiving organization's audit log for the most recent quarter and verify it contains records of all actions taken under the delegation by the delegating organization's agents." ], "evidence": [ "mta-registry:Trust registry entries showing signed MTAs for all active cross-organizational delegations with scope schedules and expiry dates [unverified]", "cross-org-delegation-tokens:Sample of cross-org delegation tokens showing MTA reference identifiers validated against the trust registry [unverified]", "receiving-org-audit-log:Receiving organization audit log extract for the most recent quarter showing complete records of delegated agent actions [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "DE-06 requires the authorization service to perform two independent checks for cross-org delegation requests: verify the MTA reference in the delegation token is valid and current in the trust registry, and verify the requested scope is within the scope schedule attached to that MTA. Neither check alone is sufficient.", "actions": [ "Build cross-org delegation token validation to query the trust registry for the MTA reference and compare the requested scope against the MTA scope schedule before issuing the resource access token.", "Implement the federation-vs-delegation distinction in the resource server access control layer: a federated identity token grants authentication, not authorization for delegated actions.", "Automate MTA expiry monitoring with advance notice to both organizations 30 days before expiry, preventing delegation outages when MTAs are not renewed in time." ], "failure_signals": [ "Cross-org resource server access control logic treats a federated identity token as sufficient authorization for delegated actions without checking for a delegation token referencing an active MTA.", "MTA expiry monitoring is not implemented \u2014 cross-org delegations expire silently and are discovered only when agents begin receiving authorization failures." ] }, "security_architect": { "summary": "The critical design distinction in DE-06 is that federation and delegation are orthogonal trust relationships. Collapsing them \u2014 treating a federated identity as implicitly authorized to act \u2014 is the most common cross-org security failure in AI agent deployments. The architecture must enforce both checks, at different layers, with independent evidence.", "actions": [ "Design the cross-org authorization model as a two-pass evaluation: pass 1 authenticates the agent's identity (federation trust), pass 2 authorizes the agent's action (delegation trust with MTA reference check). Never short-circuit pass 2 based on pass 1 success.", "Represent the MTA scope schedule as a structured policy artifact that the authorization service can evaluate programmatically \u2014 not as a narrative clause in a contract that humans must interpret.", "Model cross-org delegation breach notification as an automated event rather than a manual process: if the receiving organization's audit log detects an out-of-scope action by a delegated agent, automated notification fires to the delegating organization within the 72-hour MTA obligation." ], "failure_signals": [ "Authorization service performs only identity verification for cross-org requests and does not check for an MTA-backed delegation token.", "MTA scope schedules are maintained only as PDF attachments to contracts, not as machine-readable policy artifacts." ] }, "legal_counsel": { "summary": "DE-06 is the control that legal counsel is most directly responsible for \u2014 the MTA must contain enforceable liability assignment, clear breach notification obligations, and audit rights that will survive a dispute over whether the delegation was used as authorized. The scope schedule is a legal artifact as much as a technical one.", "actions": [ "Draft or review the MTA template to ensure it contains: explicit scope schedule by reference to the technical delegation scope document, liability assignment for unauthorized actions by delegated agents, a 72-hour breach notification obligation with defined notification contacts, and unrestricted audit rights for the delegating organization.", "Confirm the MTA is executed by signatories with authority to bind both organizations to delegation authorization terms \u2014 not just operational contacts.", "Establish a legal hold protocol for MTA records and associated delegation audit logs in the event of a dispute over cross-org delegation use." ], "failure_signals": [ "MTA contains only narrative scope description without a structured scope schedule \u2014 making it impossible to determine programmatically whether a specific action was within scope.", "Liability assignment clause in the MTA is silent on AI agent actions, covering only actions by human employees of the receiving organization." ] }, "grc_auditor": { "summary": "DE-06 introduces cross-organizational complexity into the audit scope \u2014 the auditor must assess not only the delegating organization's controls but also the receiving organization's compliance with the MTA audit rights provision. A complete DE-06 audit requires access to both trust registries and both organizations' delegation audit logs.", "actions": [ "Enumerate all active cross-organizational delegations by querying the trust registry and verify each has a current signed MTA with a structured scope schedule.", "For each active cross-org delegation, exercise the MTA audit rights by requesting the receiving organization's delegation audit log for the most recent quarter and verifying it covers all delegated agent actions.", "Assess whether any security events in the past 12 months triggered the 72-hour breach notification obligation and whether that obligation was met." ], "metrics": [ "Percentage of active cross-org delegations with a signed, current MTA referencing a structured scope schedule (target: 100%).", "Number of cross-org breach notification obligations triggered in the past 12 months and percentage met within 72 hours (target: 100%)." ], "failure_signals": [ "Active cross-org delegation tokens reference MTA IDs that are no longer in the trust registry \u2014 indicating expired agreements are still being used.", "Receiving organization denies audit log access under the MTA audit rights provision \u2014 indicating either the right is not in the agreement or the receiving organization is non-compliant." ] }, "it_operations": { "summary": "Operations teams are responsible for the operational continuity of cross-org delegations \u2014 monitoring MTA expiry, maintaining trust registry entries, and escalating scope disputes. The cross-org delegation trust registry must be treated as critical operational infrastructure, not a one-time configuration artifact.", "actions": [ "Add MTA expiry dates to the operational monitoring dashboard with 30-day and 7-day advance alerts, and confirm the MTA renewal process is documented in the operational runbook.", "Maintain the trust registry as a change-controlled configuration artifact with documented approval requirements for adding, modifying, or removing MTA entries.", "Establish a point of contact at each receiving organization for operational escalation of scope disputes or delegation failures, and document these contacts in the cross-org delegation runbook." ], "failure_signals": [ "Trust registry entries are not change-controlled \u2014 entries can be added or modified without approval, making the registry an unreliable source of truth for active MTAs.", "No MTA expiry monitoring is in place \u2014 cross-org delegation failures are discovered only when agents begin receiving authorization rejections." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Cross-organizational AI agent delegation is typically handled informally \u2014 an API key is shared, a service account is provisioned in the receiving organization, or a federated identity is treated as implicitly authorized to act. Target defined state requires an MTA-backed trust registry and the two-pass authorization model implemented in the resource server." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "iam-team", "security-architect", "legal-counsel" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a73.5", "fit": "partial", "rationale": "SP 800-63C-4 \u00a73.5 requires documented trust agreements between federation parties defining responsibilities and permitted uses; DE-06 extends that trust-agreement discipline from federated authentication to cross-organizational agent delegation.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015's reference architecture covers federation of identity information between organizations and the agreements governing it \u2014 DE-06 operationalizes that cross-organizational trust through the MTA and trust registry model.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eidas2", "requirement_id": "Art. 6", "fit": "adjacent", "rationale": "eIDAS 2 Article 6 establishes mutual recognition of notified electronic identification means across member states, providing the regulatory model for recognizing identities asserted under another party's scheme; DE-06 applies analogous governance principles to cross-organizational AI agent delegation independent of EU regulatory scope.", "source_version": "2024/1183", "reviewed_on": "2026-07-02", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Cross Account Trust Policies", "rationale": "AWS IAM cross-account role assumption with condition-bound trust policies (aws:PrincipalOrgID, aws:PrincipalAccount) enables governed cross-organizational delegation. AWS Organizations SCPs can restrict which external account principals may assume roles in member accounts, ensuring all cross-organizational delegation is explicitly authorized through trust policy governance.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS cross-account trust conditions enforce which external principals may assume roles, but not the mutual-trust-agreement liability/audit governance.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity \u2014 Federated Cross Org Authorization", "rationale": "Ping Identity's federated authorization model supports cross-organizational agent delegation with runtime enforcement of scope constraints; external agent identities receive only explicitly authorized scopes through the Agent Gateway's policy engine. Cross-org delegation chains are validated for completeness and authorization at every hop.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Ping federated authorization enforces cross-org scope at runtime, but not the signed mutual-trust-agreement and audit-rights governance the control needs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every active cross-organizational AI agent delegation must be backed by a signed Mutual Trust Agreement containing a structured machine-readable scope schedule, liability assignment, breach notification obligation, and audit rights clause. The receiving organization's authorization service must validate the MTA reference in every cross-org delegation token against the trust registry as a blocking gate, and must enforce that federated identity trust and delegation authorization are evaluated as independent checks.", "evidence_required": [ "trust_registry_extract listing all active cross-org delegation MTAs with fields: mta_identifier, scope_schedule_reference, signed_date, expiry, and next_re_evaluation_date for each active cross-org delegation", "cross_org_delegation_token_sample showing MTA reference identifiers present in tokens and validated against the trust registry for at least 10 sampled cross-org delegation requests", "receiving_org_audit_log extract for the most recent quarter showing complete records of all delegated agent actions under each active MTA, demonstrating audit rights were exercised", "mta_document for each active cross-org delegation containing a signed structured scope schedule, liability assignment clause, breach notification obligation (\u226472 hours), and audit rights provision" ], "machine_tests": [ "Issue cross-org delegation token without a matching MTA reference in the trust registry \u2192 assert authorization service returns 401 with error_code=mta_reference_not_found", "Present valid federated identity token with no delegation token to a cross-org resource endpoint requiring delegated authorization \u2192 assert resource server returns 403 with error_code=delegation_token_required", "Submit cross-org delegation token referencing an MTA with an expired validity date \u2192 assert authorization service rejects the request with error_code=mta_expired" ], "human_review": [ "Review the MTA for each active cross-org delegation to confirm the scope schedule is machine-readable and references a structured technical delegation scope document rather than a narrative clause", "Assess whether the authorization model enforces federation and delegation as independent evaluation passes, with separate evidence required for each, and that passing federation does not implicitly satisfy delegation authorization", "Verify quarterly MTA review process has been executed for all active cross-org delegations within the past 12 months, with evidence that each receiving organization's audit log was reviewed" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating a vendor SLA or master service agreement as an adequate substitute for a structured machine-readable delegation scope schedule in the MTA", "Accepting any federated identity token as implicitly authorized for cross-org delegated actions without requiring a separate MTA-backed delegation token as an independent authorization check", "Establishing cross-org delegation agreements without an explicit audit rights clause, removing the delegating organization's ability to verify scope compliance by the receiving organization", "Maintaining MTA scope schedules as narrative PDF clauses rather than machine-readable structured policy artifacts that the authorization service can evaluate programmatically", "Allowing cross-org delegation tokens to remain valid and accepted by resource servers after the underlying MTA has expired or been terminated" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-07", "layer": "DE", "plane": "control", "name": "Delegation Audit Trail", "plain": "Maintain an immutable, tamper-evident audit trail of all delegation events \u2014 grant, use, extension, and revocation \u2014 with each entry linked to the identities of all principals in the delegation chain.", "threat": { "tags": [ "delegation-abuse", "lateral-movement" ], "desc": "Delegation abuse is rarely detectable in real time \u2014 the abuse signal emerges in retrospective analysis of the delegation event sequence. Without an immutable audit trail linking every delegation grant, use, and revocation to the chain of principals, it is impossible to reconstruct whether an agent's actions were within its authorized delegation or whether the delegation itself was obtained through abuse of the provisioning or consent mechanisms. Lateral movement through delegation chains is particularly difficult to detect without full chain logging, because each individual hop appears authorized in isolation \u2014 only the complete sequence reveals the lateral movement pattern." }, "standard": [ { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Reference architecture and requirements \u2014 audit for identity management" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 7", "title": "Collect and analyze monitoring data" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Identity visibility and analytics" } ], "sources": [ { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/DE-07 Delegation Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/DE-07 Delegation Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/DE-07 Delegation Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-07 Delegation Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/DE-07 Delegation Audit Trail control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Append-only delegation event log with cryptographic chaining, structured schema enforcement, and query-accessible audit API", "steps": [ "Define a structured delegation event schema with required fields for each event type: for grant events (delegator_id, delegate_id, chain_id, scope, resource_target, expiry, approval_reference, timestamp); for use events (chain_id, delegate_id, resource_accessed, action_performed, outcome, timestamp); for extension events (chain_id, original_expiry, new_expiry, re_authorization_reference, timestamp); for revocation events (chain_id, revoking_principal_id, revocation_trigger, revocation_scope, timestamp, propagation_confirmation).", "Implement the audit log as an append-only store with cryptographic chaining (each entry includes a hash of the preceding entry) so any tampering with historical records is detectable; store the log in an infrastructure layer that is inaccessible to the application tier that generates the events \u2014 requiring a separate write-only ingest path and a separate read API.", "Require every delegation token to include the chain_id as a claim, and require every resource server to emit a use event to the delegation audit log for each access attempt (authorized or rejected), linking the event to the chain_id in the token so the full access pattern under each delegation chain is reconstructable.", "Expose a delegation audit query API accessible to authorized auditors and security tooling, supporting queries by: chain_id, delegate identity, delegator identity, resource target, time window, event type, and outcome; support export in structured formats (JSON-L, CSV) for integration with SIEM and GRC tooling." ], "anti_patterns": [ "Logging only grant and revocation events but not use events \u2014 leaving the audit trail unable to reconstruct which resources were accessed under each delegation chain.", "Storing the delegation audit log in the same database as the application data it governs, making it vulnerable to tampering by any principal with database write access.", "Implementing the audit log as a mutable table where log entries can be updated or deleted by privileged administrators, even for correction purposes \u2014 any mutability negates the tamper-evidence property." ] }, "validation": { "design_check": [ "Confirm delegation event schema enforces all required fields for each event type and rejects incomplete entries at the ingest layer.", "Verify the audit log is implemented as an append-only store with cryptographic chaining and is hosted in an infrastructure layer separate from the application tier.", "Confirm a delegation audit query API exists supporting the minimum required query dimensions (chain_id, identity, resource, time window, event type, outcome)." ], "runtime_test": [ "Emit a grant event with a missing required field and verify the ingest layer rejects it.", "Attempt to modify a historical audit log entry through any available API and verify the modification is rejected.", "Reconstruct the full access record for a test delegation chain (all grant, use, and revocation events) using the audit query API and verify completeness against a known test sequence." ], "evidence": [ "audit-log-integrity:Cryptographic chain verification report for the delegation audit log confirming no entries have been modified or deleted [unverified]", "event-completeness-sample:Sample of delegation chains from the review period with all grant, use, extension, and revocation events present [unverified]", "query-api-test:Audit query API test results confirming all required query dimensions return complete, accurate results [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "DE-07's engineering constraint \u2014 the audit log must be hosted in a separate infrastructure layer inaccessible to the application tier \u2014 is the requirement most likely to be deprioritized under time pressure. Without infrastructure separation, the append-only guarantee is a convention, not a technical enforcement. Implement the ingest path as a write-only webhook or message queue, and the storage layer as a dedicated log store with no delete API.", "actions": [ "Design the delegation event ingest path as a write-only message queue (e.g., Kafka, Kinesis) with the log store as a consumer \u2014 no direct write access from the application tier to the log store.", "Implement cryptographic chaining at the log store consumer layer so each entry's hash is computed over the entry content plus the preceding entry's hash, enabling tamper detection without a separate integrity service.", "Build the delegation audit query API with role-based access controls that allow security and GRC roles to query without granting any write or delete access." ], "failure_signals": [ "Delegation audit log is implemented as a table in the same database as the application data, accessible to any principal with database admin privileges.", "Audit query API exposes an update or delete endpoint, even if protected by an admin role \u2014 the endpoint's existence negates the append-only property." ] }, "security_architect": { "summary": "The delegation audit trail is the primary evidence source for post-incident analysis, lateral movement detection, and delegation abuse investigation. Its forensic value depends entirely on completeness (all event types, all chains) and integrity (tamper-evident). The use-event requirement \u2014 resource servers emitting to the audit log on every access \u2014 is the hardest architectural requirement to enforce consistently across a distributed system.", "actions": [ "Require resource servers to emit delegation use events as a mandatory middleware step, not an optional add-on \u2014 implement it as a request interceptor that fires before the response is returned to the caller.", "Design the chain_id claim to be globally unique and non-guessable (e.g., UUID v4 or a cryptographic random value) so chain_id-based queries do not leak information about delegation volume or sequencing.", "Integrate delegation audit log anomaly detection with the security operations center: flag chains with unusual use frequency, unusual resource access patterns, or use events after the chain's declared expiry." ], "failure_signals": [ "Resource server access logs exist but are not linked to delegation chain_ids \u2014 making it impossible to reconstruct which delegation authorized each resource access.", "Delegation use events are emitted only for successful accesses, not for rejections \u2014 hiding failed lateral movement attempts from the audit record." ] }, "legal_counsel": { "summary": "The delegation audit trail is the primary evidence artifact for demonstrating that AI agent actions were authorized, bounded, and traceable to a human principal. Its legal value depends on the tamper-evidence property being demonstrable \u2014 cryptographic chaining and infrastructure separation are the technical basis for that demonstration.", "actions": [ "Establish a retention policy for delegation audit records that satisfies the longest applicable regulatory retention requirement across all jurisdictions where the system operates (typically 3 to 7 years).", "Confirm that the tamper-evidence mechanism (cryptographic chaining) is documented in sufficient technical detail to support expert testimony if the audit records are challenged in litigation or regulatory proceedings.", "Define the legal hold protocol for delegation audit records associated with known or suspected incidents \u2014 ensure hold notices reach the log store administrator before any automated retention deletion runs." ], "failure_signals": [ "No documented retention policy for delegation audit records \u2014 records may be deleted by automated cleanup before the applicable regulatory retention period expires.", "Tamper-evidence mechanism is not documented, making it difficult to demonstrate the integrity of audit records in a legal or regulatory proceeding." ] }, "grc_auditor": { "summary": "The delegation audit trail is the primary sampling source for GRC audit of all DE-layer controls. An auditor who can query the delegation audit log by chain_id, identity, and time window has the evidence they need to assess DE-01 through DE-08 compliance without requiring separate evidence collection for each control.", "actions": [ "Verify the delegation audit log covers all event types (grant, use, extension, revocation) and that no event type is missing for sampled chains.", "Test the tamper-evidence property by verifying the cryptographic chain against the log store's own integrity report.", "Use the delegation audit query API to reconstruct 5 complete delegation chains from the review period and verify each chain's documented scope matches the use events recorded under that chain." ], "metrics": [ "Percentage of delegation chains in the review period with complete event records (grant plus all use events plus revocation) [target: 100%].", "Delegation audit log integrity verification pass rate (cryptographic chain checks) [target: 100% \u2014 any failure is a critical finding]." ], "failure_signals": [ "Sampled delegation chains have use events but no corresponding grant event \u2014 indicating the grant logging is incomplete or the use events are from an unauthorized delegation.", "Cryptographic chain verification fails for any portion of the audit log \u2014 indicating tampering or storage corruption requiring immediate escalation." ] }, "it_operations": { "summary": "The delegation audit log is critical infrastructure for post-incident response. Operations must ensure the log ingest path is monitored for failures, the log store has sufficient retention capacity, and the query API is available to security teams during incidents when response time is critical.", "actions": [ "Monitor the delegation event ingest path (message queue consumer) with alerting on processing lag, consumer failure, or rejected events \u2014 a silent ingest failure means events are lost permanently.", "Ensure the log store retention and capacity are managed as infrastructure capacity items: project event volume based on delegation activity and confirm storage capacity supports the full retention period.", "Test the audit query API performance under load during a non-incident period so you know its response time characteristics before you need it during an active incident." ], "failure_signals": [ "Message queue consumer for delegation events has an unmonitored dead-letter queue \u2014 failed events accumulate silently without operations awareness.", "Audit query API times out for queries spanning more than 30 days \u2014 making historical analysis impractical during an incident." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Delegation events are typically logged in application logs alongside other operational events, without structured schema, cryptographic integrity, or queryable API. Target managed state requires a structured, tamper-evident, append-only delegation audit log with a full event schema and a query API accessible to security and GRC functions." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "platform-engineer", "iam-team", "security-architect" ], "frameworks": [ { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015 specifies audit requirements for identity information management \u2014 DE-07 extends that audit-trail discipline to delegation-specific events with cryptographic integrity enforcement.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 7", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 7's collect-and-use-information tenet establishes monitoring as a Zero Trust foundation; DE-07 implements the delegation-specific event collection component of that tenet.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "fit": "partial", "rationale": "The CISA ZTMM Visibility and Analytics cross-cutting capability requires logging of identity events for behavioral analysis; DE-07 provides the delegation event data that feeds those analytics.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail \u2014 Assume Role Audit Trail", "rationale": "AWS CloudTrail logs every STS AssumeRole event with the full principal chain, source identity, session duration, inline session policy, and session context, creating a complete, queryable delegation audit trail. CloudTrail Insights can detect anomalous delegation patterns (e.g., unusual role chain depth or frequency) that deviate from established baselines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "CloudTrail logs every AssumeRole with the full principal chain, source identity and session policy - a complete, queryable delegation audit trail.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta System Log \u2014 Token Exchange Audit", "rationale": "Okta System Log records every OAuth token exchange event including the delegating principal, client ID, requested scopes, granted scopes, and approval decision. This log enables complete reconstruction of the delegation chain for any issued token, supporting both forensic investigation and access certification audit.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta System Log records every token exchange with delegating principal, scopes and decision, enabling full delegation-chain reconstruction as required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Explicit trust boundaries (log all inter-agent communications); Part III \u2014 Action logging", "fit": "direct", "rationale": "Doc requires logging all inter-agent communications and flagging unusual delegation patterns \u2014 the delegation audit trail.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The delegation audit system must maintain an append-only, cryptographically chained log of all delegation events (grant, use, extension, revocation) where each entry is schema-validated and linked to all principals in the delegation chain. No historical entry may be modified or deleted through any available interface, and the complete event history for any delegation chain must be reconstructable from a single query to the audit query API.", "evidence_required": [ "delegation_audit_log_integrity_report showing cryptographic chain verification results confirming no entries have been modified or deleted since log inception, with verification timestamp", "event_completeness_sample covering at least 5 delegation chains from the review period with all expected event types (grant, use, extension or absence thereof, revocation) present and schema-conformant", "infrastructure_separation_evidence confirming the audit log store is hosted in a separate infrastructure tier inaccessible to the application layer via a different IAM policy, network segment, or storage account", "audit_query_api_test_results confirming all required query dimensions (chain_id, delegate identity, delegator identity, resource target, time window, event type, outcome) return complete and accurate results" ], "machine_tests": [ "Submit delegation grant event with missing required field delegate_id to the ingest endpoint \u2192 assert ingest layer returns 400 with error_code=schema_validation_failed and no partial entry is written to the log", "Attempt to update or delete a historical audit log entry via any available API surface including admin endpoints \u2192 assert the operation returns an error indicating the log is immutable", "Issue a test delegation chain, access a resource under it, then revoke it; query the audit API by chain_id \u2192 assert all event types (grant, use, revocation) are present, timestamp-ordered, and schema-valid" ], "human_review": [ "Review the infrastructure architecture diagram to verify the audit log store is physically and logically separate from the application database and inaccessible using application-tier credentials or roles", "Assess the delegation event schema against the required field definitions for each event type and confirm the ingest layer rejects schema-incomplete entries before any partial write occurs", "Verify the audit log retention policy satisfies the longest applicable regulatory retention requirement across all jurisdictions the system operates in, and that automated deletion does not run before retention expiry" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Storing the delegation audit log in the same database as the application data it governs, where any principal with database admin access can modify or delete audit entries", "Logging only grant and revocation events while omitting use events, making it impossible to reconstruct which resources were accessed under each delegation chain", "Implementing the audit log as a mutable table where privileged administrators can update entries for correction purposes, negating the tamper-evidence property entirely", "Emitting delegation events without cryptographic chaining, making retroactive tampering undetectable because there is no integrity check linking entries to each other", "Combining audit log write and delete permissions in the same role, allowing the same credentials that ingest events to also remove them" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-08", "layer": "DE", "plane": "control", "name": "Delegation Revocation Propagation", "plain": "Ensure that delegation revocation propagates immediately to all downstream agents in the chain, with propagation completion verified within 60 seconds for consequential delegations and confirmed by receipt from each dependent system.", "threat": { "tags": [ "delegation-abuse", "orphaned-credential" ], "desc": "A delegation revocation that is recorded at the root authorization service but has not yet propagated to downstream agents leaves those agents with valid tokens they can continue to use until the revocation reaches them \u2014 creating a propagation window during which unauthorized actions can be taken under a revoked delegation. In distributed agent architectures with long delegation chains, propagation failures may be silent: the revocation appears complete at the root but one or more downstream agents never receives it, converting what should be a temporary propagation gap into a permanent orphaned delegation. Orphaned delegations from revocation propagation failures are difficult to detect because the downstream agent's token was legitimately issued \u2014 only comparison against the current revocation state reveals the orphan." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a74", "title": "Authenticator revocation" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "Authorization state and revocation" }, { "id": "scim", "section": "RFC 7644 \u00a73.6", "title": "Deprovisioning cascade" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/DE-08 Delegation Revocation Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/DE-08 Delegation Revocation Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "scim_rfc7644", "title": "RFC 7644 \u2014 SCIM 2.0 Protocol", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes RFC 7644 \u2014 SCIM 2.0 Protocol requirements informing the apeiris://identity/controls/DE-08 Delegation Revocation Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/DE-08 Delegation Revocation Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/DE-08 Delegation Revocation Propagation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Graph-traversal revocation cascade with propagation SLA enforcement and per-node receipt confirmation", "steps": [ "At revocation initiation, traverse the delegation chain graph to enumerate all downstream agents holding tokens derived from the revoked delegation; issue revocation notifications to each downstream agent's identity provider and resource server in parallel, not sequentially, to minimize propagation latency.", "Require each downstream system to issue a propagation receipt confirming revocation has been applied at the token validation layer (not just acknowledged at the notification layer); collect receipts via a callback endpoint or by polling the downstream system's token introspection endpoint within the propagation SLA (60 seconds for consequential delegations, 15 minutes for standard delegations).", "If any downstream system fails to issue a propagation receipt within the SLA, classify the delegation as partially-revoked and immediately: block all new requests under that chain_id at the root authorization service, alert the security operations center, and initiate an escalated remediation flow targeting the non-responding system.", "Record the full propagation event in the DE-07 delegation audit log as a revocation event with propagation receipts from each downstream system, propagation latency per system, and partial-revocation status if applicable; feed partial-revocation events into the delegation health dashboard as a leading indicator of revocation infrastructure failure." ], "anti_patterns": [ "Treating the root authorization service revocation record as equivalent to successful propagation without verifying that downstream systems have applied the revocation at the token validation layer.", "Implementing propagation as a sequential chain traversal (revoke A, wait for A's receipt, then revoke B) rather than parallel notification \u2014 sequential propagation multiplies latency by the chain depth.", "Silently accepting partial propagation (some downstream systems received the revocation, some did not) without triggering an alert and remediation flow." ] }, "validation": { "design_check": [ "Confirm the revocation cascade implements parallel notification to all downstream systems rather than sequential traversal.", "Verify propagation receipt collection is implemented at the token validation layer (introspection check or callback confirmation) rather than at the notification acknowledgment layer.", "Confirm partial-revocation detection is implemented and triggers an alert to the security operations center within 5 minutes of SLA breach." ], "runtime_test": [ "Revoke a test delegation chain and measure propagation time from revocation initiation to confirmed receipt at the furthest downstream system \u2014 verify it is within the 60-second SLA for consequential delegations.", "Simulate a propagation failure by blocking a downstream system from receiving the revocation notification and verify the partial-revocation alert fires and the chain_id is blocked at the root authorization service.", "After a full revocation with confirmed propagation receipts, verify that a downstream agent attempting to use its now-revoked token receives a rejection from the resource server." ], "evidence": [ "propagation-receipt-log:Delegation audit log showing revocation events with per-downstream-system propagation receipts and latency measurements [unverified]", "partial-revocation-alerts:Security operations center alert log showing partial-revocation events with escalation timestamps [unverified]", "sla-compliance-report:Rolling report of revocation propagation latency by delegation chain and downstream system, showing SLA compliance rate [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "DE-08 requires the revocation infrastructure to be aware of the full delegation chain graph \u2014 not just the immediate child delegates. Building the chain graph traversal requires the identity service to maintain a queryable graph of delegation relationships, not just a flat list of issued tokens.", "actions": [ "Implement the delegation chain graph as a queryable data structure in the identity service, updated on every delegation grant and revocation event, so the full set of downstream systems can be enumerated in a single query at revocation time.", "Build the propagation receipt collector as a parallel async process with a timeout \u2014 issue all downstream notifications in a single batch, then collect receipts concurrently rather than waiting for each one sequentially.", "Implement a dead-letter queue for failed propagation notifications so receipts can be retried without losing track of which systems have and have not confirmed." ], "failure_signals": [ "Revocation cascade is implemented as a sequential loop over downstream systems \u2014 propagation latency scales linearly with chain depth rather than being bounded by the slowest single system.", "Delegation chain graph is not maintained as a queryable structure \u2014 chain traversal at revocation time requires scanning all issued tokens, which is prohibitively slow for large-scale deployments." ] }, "security_architect": { "summary": "The partial-revocation scenario is the most dangerous failure mode in DE-08: it is a silent failure that leaves some downstream agents acting under a revoked delegation while the revocation appears complete at the root. The architecture must treat partial-revocation as an active security incident, not a background cleanup task.", "actions": [ "Design the partial-revocation response as an immediate chain_id block at the root authorization service rather than an eventual-consistency cleanup \u2014 any new request under a partially-revoked chain_id must be rejected until all receipts are confirmed.", "Model the propagation SLA as a hard requirement enforced by a deadline-based scheduler, not a soft target measured in retrospect \u2014 the SLA timer starts at revocation initiation, not at notification delivery.", "Require downstream resource servers to support token introspection or short-lived token maximum ages so propagation can be verified without requiring a dedicated callback endpoint from every system." ], "failure_signals": [ "Partial-revocation events are handled by a background cleanup job rather than triggering an immediate chain_id block \u2014 leaving a window where new requests under the partially-revoked chain can proceed.", "Propagation SLA compliance is measured by averaging latency across all downstream systems, masking individual systems that are chronically late." ] }, "legal_counsel": { "summary": "A delegation revocation that fails to propagate may create liability if actions are taken under the revoked delegation during the propagation gap \u2014 particularly if the revocation was triggered by a security event, a principal departure, or a consent withdrawal. DE-08's propagation receipt requirement provides the evidence basis for demonstrating that revocation was diligently pursued.", "actions": [ "Confirm the propagation receipt log is retained alongside the revocation event record so the full timeline (initiation, notification, receipt, partial-revocation if applicable) is available for evidentiary purposes.", "Review whether the organization's incident response plan addresses partial-revocation scenarios \u2014 specifically, whether partial-revocation triggers breach notification assessment under applicable law if the non-revoked delegation was used to access personal data during the propagation gap.", "Ensure employment agreements and service contracts with downstream organizations reference the revocation propagation obligation so the receiving organization is contractually bound to acknowledge revocation notifications promptly." ], "failure_signals": [ "Revocation records document the initiation event but not the propagation receipts \u2014 making it impossible to prove revocation was operationally complete by any specific time.", "Service contracts with downstream organizations do not reference revocation notification obligations \u2014 leaving the organization without contractual recourse if a downstream system fails to propagate a revocation." ] }, "grc_auditor": { "summary": "DE-08 has two distinct audit points: SLA compliance (did all downstream systems confirm revocation within the required window?) and partial-revocation handling (were partial-revocation events treated as security incidents and resolved promptly?). Both require evidence from the propagation receipt log, not just the root revocation record.", "actions": [ "Pull all revocation events from the DE-07 audit log for the past 90 days and calculate per-system and per-chain propagation latency; identify any systems that chronically miss the SLA.", "For any partial-revocation events in the review period, verify the security operations center alert fired within 5 minutes of SLA breach and the chain_id was blocked at the root authorization service before the alert was resolved.", "Verify that the propagation receipt log is linked to the corresponding DE-07 revocation event record so the complete revocation timeline is auditable from a single evidence source." ], "metrics": [ "Percentage of revocation propagation completions within the 60-second SLA for consequential delegations (target: 99.5% \u2014 allowing for genuine infrastructure outages).", "Number of partial-revocation events in the review period that were not resolved within 1 hour of detection (target: zero)." ], "failure_signals": [ "Revocation events in the DE-07 audit log have no corresponding propagation receipt entries \u2014 indicating propagation confirmation is not implemented.", "Partial-revocation events were resolved by background cleanup rather than immediate chain_id block \u2014 indicating the security response to partial-revocation is inadequate." ] }, "it_operations": { "summary": "Revocation propagation is a time-critical operation \u2014 the 60-second SLA means operations cannot rely on batch processes or delayed queue consumers. The propagation infrastructure must be monitored with the same priority as production transaction processing, and failures must trigger immediate escalation.", "actions": [ "Monitor the revocation propagation pipeline with alerting on SLA breach within 30 seconds of the deadline \u2014 leaving 30 seconds of response time before the security operations center needs to be notified.", "Include partial-revocation event counts in the daily operations review and treat any non-zero count as requiring a root-cause analysis entry before the next review.", "Test revocation propagation infrastructure health monthly using a synthetic delegation chain: revoke the chain and measure end-to-end propagation latency to confirm SLA compliance without waiting for a real revocation event." ], "failure_signals": [ "Revocation propagation monitoring triggers an alert only after the SLA has been breached \u2014 leaving no time to intervene before the security operations center must be notified of a partial-revocation.", "Monthly synthetic revocation tests are not performed \u2014 propagation infrastructure health is unknown until a real revocation event reveals a failure." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Revocation propagation is rarely implemented beyond the root IDP revocation record. Most environments rely on token expiry to eventually enforce revocation in downstream systems. Target managed state requires full chain traversal, parallel notification, receipt collection, SLA enforcement, and partial-revocation incident response." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise" ], "implementers": [ "platform-engineer", "iam-team", "security-architect" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a74", "fit": "direct", "rationale": "SP 800-63B-4 \u00a74 authenticator event-management requirements establish the obligation to revoke and the expectation that revocation is effective \u2014 DE-08 adds the propagation verification and SLA enforcement that the standard assumes will be implemented.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "adjacent", "rationale": "RFC 9396 authorization_details provides the authorization state model that DE-08 must revoke; DE-08's propagation requirements address the distributed revocation challenge that RFC 9396 does not specify.", "source_version": "RFC 9396", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "scim", "requirement_id": "RFC7644 \u00a73.6", "fit": "partial", "rationale": "SCIM \u00a73.6 DELETE operation deprovisioning model provides the structural precedent for cascaded revocation across dependent systems \u2014 DE-08 extends this to delegation chain propagation with SLA enforcement and receipt confirmation.", "source_version": "2.0", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Role Session Revocation", "rationale": "AWS IAM role session revocation attaches a deny-all policy with a DateLessThan condition on aws:TokenIssueTime, immediately invalidating all active STS sessions for the role issued before the revocation timestamp. Downstream services using those credentials will receive authorization errors on their next API call, propagating revocation without requiring notification to each consumer.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS deny-all-by-token-issue-time invalidates a role sessions immediately, but does not confirm 60s propagation receipts to downstream agents.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta OAuth \u2014 Token Revocation Propagation", "rationale": "Okta token revocation propagates through the OAuth token introspection endpoint (RFC 7662); resource servers configured to use introspection will immediately see revoked token status on the next request. Okta's event hooks can push revocation events to downstream systems that maintain token caches, enabling near-real-time revocation propagation across distributed service consumers.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta introspection surfaces revoked status on next request, but does not guarantee the 60-second per-system propagation receipts the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/DE-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "When a consequential delegation is revoked, all downstream agents holding derived tokens must have their revocation confirmed by per-system propagation receipt within 60 seconds of revocation initiation. Any delegation chain where propagation receipts are not fully confirmed within the SLA must be classified as partially-revoked and all new requests under that chain_id must be blocked at the root authorization service before the security operations center alert fires.", "evidence_required": [ "propagation_receipt_log showing per-downstream-system revocation confirmation events with timestamps and latency measurements for all consequential delegation revocations in the review period", "sla_compliance_report showing revocation propagation latency distribution by delegation chain and downstream system, with SLA compliance rate for consequential delegations (target: \u226599.5%)", "partial_revocation_incident_log showing all instances where propagation receipts were not received within SLA, including security operations center alert timestamp, chain_id block timestamp, and resolution record", "delegation_chain_graph documentation showing the queryable data structure maintained by the identity service to enumerate all downstream dependents at revocation time" ], "machine_tests": [ "Revoke a test consequential delegation chain and measure time from revocation initiation to confirmed propagation receipt at the furthest downstream system \u2192 assert \u226460 seconds", "Block a designated downstream system from receiving its revocation notification and measure time to partial-revocation alert and chain_id block at root authorization service \u2192 assert alert fires within 5 minutes and new requests under the chain_id are rejected before alert resolution", "After full propagation confirmation, submit a resource request from a downstream agent using its now-revoked token \u2192 assert resource server returns 401 with error_code=token_revoked" ], "human_review": [ "Review the delegation chain graph implementation to confirm it is maintained as a queryable data structure supporting full downstream-dependent enumeration in a single query at revocation time, not a scan of all issued tokens", "Assess the partial-revocation incident response procedure to confirm it mandates immediate chain_id blocking at the root authorization service as the first action, not a background cleanup task", "Verify propagation SLA thresholds are codified as hard deadlines enforced by a deadline-based scheduler that fires before the SLA expires, not retrospective latency metrics reviewed after the fact" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating the root authorization service revocation record as proof of successful propagation without collecting per-downstream-system receipt confirmations at the token validation layer", "Implementing the revocation cascade as a sequential traversal of downstream systems, multiplying total propagation latency by chain depth rather than issuing parallel notifications", "Classifying partial revocation as a background cleanup task rather than an active security incident requiring immediate chain_id blocking at the root authorization service", "Relying on token expiry as the primary mechanism for downstream revocation enforcement rather than explicit propagation with receipt confirmation within the defined SLA", "Maintaining the delegation relationship model as a flat list of issued tokens rather than a queryable chain graph, making full downstream enumeration impractical for large-scale deployments" ], "update_status": "current", "layer_code": "DE" }, { "id": "DE-09", "layer": "DE", "plane": "lifecycle", "name": "Delegation Layer Evidence Package", "plain": "Compile a quarterly delegation layer evidence package consolidating artifacts from DE-01 through DE-08 to demonstrate that delegation chains are documented, scoped, and revocation propagation is verifiable. The package is a required input to IC-08 (IdentityAttestation) production.", "threat": { "tags": [ "governance-evidence-gap", "attestation-unverifiable", "audit-readiness-deficit" ], "desc": "Without periodic structured compilation of delegation layer evidence, the IdentityAttestation (IC-08) rests on assertions from individual controls rather than compiled, reviewed, and signed evidence. Layer-level gaps are only visible through compilation." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review of AI management system at planned intervals" }, { "id": "nist_rmf", "section": "GOVERN 1.5", "title": "Ongoing monitoring and periodic review of the risk management process and its outcomes" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management system for high-risk AI providers" } ], "sources": [ { "id": "iso_27001_2022", "title": "ISO/IEC 27001:2022 \u2014 Information Security Management System", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "certification-standard", "version": "2022", "published_on": "2022-10-25", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/27001", "license": "proprietary", "status": "current", "flagship": true, "source_id": "iso_27001", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27001:2022 \u2014 Information Security Management System requirements informing the apeiris://identity/controls/DE-09 Delegation Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_100_1", "title": "NIST AI 100-1: Artificial Intelligence Risk Management Framework", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 100-1: Artificial Intelligence Risk Management Framework requirements informing the apeiris://identity/controls/DE-09 Delegation Layer Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a quarterly evidence compilation process for the Delegation layer. Collect required artifacts from DE-01 through DE-08. Review completeness and identify gaps. Produce a signed evidence package for IC-08 IdentityAttestation input.", "steps": [ "Define the DE-layer evidence package schema: required_artifacts[], acceptance_criteria[], gap_register, package_owner, and review_signatories.", "For each control in DE-01 through DE-08, define required evidence artifacts and freshness criteria.", "Compile artifacts quarterly: generate or collect required evidence and stage for structured review.", "Conduct a review session to evaluate completeness, identify gaps, and assign remediation owners.", "Produce a signed delegation layer evidence package and submit it as input to IC-08 IdentityAttestation production.", "Retain the package as an immutable record for audit and regulatory review." ] }, "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001 \u00a79.3 requires management review at planned intervals. DE-09 provides the structured review artifact for the Delegation layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.5", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.5 requires ongoing monitoring and periodic review of the risk management process and its outcomes, with clear organizational responsibilities. DE-09 instantiates that periodic review at the Delegation layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Art. 17 requires a quality management system. DE-09 is the QMS artifact for the Delegation layer.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://identity/controls/DE-09", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A quarterly delegation layer evidence package must be compiled, reviewed by designated signatories from security and compliance functions, and signed by the package owner, incorporating required artifacts from DE-01 through DE-08 controls. The signed package must be formally submitted as an input to IC-08 IdentityAttestation production before the attestation is issued, and any identified gaps must be recorded in a gap register with assigned remediation owners and target dates.", "evidence_required": [ "signed_delegation_layer_evidence_package for the current quarter with fields: package_owner, review_signatories, package_production_timestamp, required_artifacts list, and gap_register", "de_layer_artifact_checklist confirming presence, freshness, and acceptance criteria status for required evidence artifacts from each of DE-01 through DE-08", "gap_register entries with fields: control_id, gap_description, remediation_owner, target_date, and resolved_date where applicable \u2014 no entry may be older than 90 days without a resolved_date or an escalation note", "ic08_attestation_input_record confirming the signed DE-layer evidence package was submitted as input to the IC-08 IdentityAttestation production process in the same quarter, with submission timestamp" ], "machine_tests": [ "Query the evidence package store for the current quarter \u2192 assert a signed DE-layer package exists with package_owner, review_signatories array (\u22652 members), package_production_timestamp, and artifact_checklist fields all present", "Inspect gap_register entries in the most recent package \u2192 assert each entry contains remediation_owner and target_date, and that no entry is older than 90 days without a resolved_date" ], "human_review": [ "Review the evidence package completeness against the DE-layer artifact checklist and confirm all required artifacts from DE-01 through DE-08 are present, within freshness criteria, and meet defined acceptance criteria", "Assess the gap register for carry-over items from prior quarters and confirm each open gap has an active remediation owner and a target date that has not lapsed without documented extension approval", "Verify the signed evidence package was formally submitted to and accepted by the IC-08 attestation production process in the same quarter and that the attestation was not issued before the package was received" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing a narrative executive summary in lieu of a structured evidence package with referenced artifacts, an acceptance criteria schema, and a formal gap register", "Compiling the delegation layer evidence package after the IC-08 IdentityAttestation has already been issued, rather than as a required prerequisite input to attestation production", "Treating gap register entries as informational documentation rather than binding remediation commitments with named owners and enforced target dates", "Allowing the package owner to self-certify completeness without independent review signatories from security and compliance functions outside the team producing the controls" ], "update_status": "current", "lenses": { "iam_engineer": { "summary": "This package consolidates the Delegation layer, so the substance you assemble is the delegation record: chain depth and scope from DE-01 through DE-08, and evidence that revocation propagates through every link. The package requires at least two review signatories and a gap_register where no entry may age past 90 days without a resolved_date or an escalation note. The delegation-specific risk is a revoked grant at the top of a chain that never propagates to the agents acting under it.", "actions": [ "Assemble the de_layer_artifact_checklist confirming presence, freshness, and acceptance status for each DE-01 through DE-08 artifact.", "Include evidence that revocation propagation was tested across delegation chains, not just that grants were issued.", "Enforce a review_signatories array of at least two members drawn from security and compliance before the package is signed.", "Build the gap_register so every entry carries control_id, gap_description, remediation_owner, and target_date, and flag any entry older than 90 days without a resolved_date.", "Record the ic08_attestation_input_record with a submission timestamp confirming the signed DE package reached IC-08 in the same quarter." ] }, "security_architect": { "summary": "DE-09 makes the delegation layer attestable and blocks deployment when incomplete. The property it must prove is that authority granted through delegation is bounded in scope and revocable in fact, which means revocation-propagation evidence is the load-bearing artifact. A deep or unscoped delegation chain whose revocation does not reach the leaf agents is the failure this package is meant to surface before IC-08 relies on it.", "actions": [ "Require the package to demonstrate delegation-chain scope limits and depth, not merely list active delegations.", "Make verified revocation propagation an acceptance criterion so an untested or partial propagation is recorded as a gap.", "Enforce the two-signatory review as a segregation-of-duties control on the delegation attestation input.", "Confirm the DE-09 package is a required, verified input to IC-08 and that unresolved delegation gaps block the attestation." ] }, "legal_counsel": { "summary": "Delegation is where legal accountability can blur, because an agent may act under authority passed down a chain from a human principal. The signed DE package is the record that establishes who delegated what scope to whom, and that the authority could be and was revoked when required. Its value in a dispute is showing the delegated authority was bounded and traceable rather than open-ended.", "actions": [ "Confirm the package records delegation scope in terms that map to documented authorization limits the enterprise can defend.", "Verify revocation-propagation evidence is retained so it can be shown that a withdrawn authority actually ceased to be exercisable.", "Ensure gap_register entries older than 90 days without resolution carry a documented escalation, since an unresolved delegation gap is an accountability exposure.", "Check that review signatories and package owner are named so responsibility for the delegation attestation is attributable." ] }, "grc_auditor": { "summary": "For DE-09 the evidence is the signed delegation-layer package with its artifact checklist, the gap_register, and the IC-08 input record. The two auditable disciplines specific to this layer are the two-signatory review and the 90-day gap-aging rule. Confirm the signatory array has at least two members from different functions and that no gap entry has aged past 90 days without a resolved_date or escalation.", "actions": [ "Query the current-quarter package and confirm a signed DE package exists with package_owner, a review_signatories array of at least two members, a production timestamp, and the artifact checklist.", "Inspect gap_register entries and confirm each has a remediation_owner and target_date, with no entry older than 90 days lacking a resolved_date.", "Verify the de_layer_artifact_checklist confirms freshness and acceptance status for every DE-01 through DE-08 control.", "Confirm the ic08_attestation_input_record shows the signed package was submitted in the same quarter as the attestation." ] }, "it_operations": { "summary": "You run the quarterly delegation-package compilation and coordinate the two-signatory review that has to happen before sign-off. The operational discipline unique to this layer is the gap_register clock: entries must not age past 90 days without a resolved_date or escalation, so you track and chase remediation owners. A missed compilation or an unsigned package blocks deployment at IC-08.", "actions": [ "Schedule the quarterly delegation package compilation and the review session, and alert if either slips the window.", "Track gap_register entries against the 90-day threshold and escalate any that approach it without resolution.", "Ensure revocation events across delegation chains are captured into the evidence feed so propagation can be demonstrated at compile time.", "Coordinate the two required signatories from security and compliance and re-sign the package when a gap is remediated mid-quarter." ] } }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "maturity": { "current": "initial", "target": "defined", "notes": "Layer-level evidence compilation is rare; most organizations assemble identity audit evidence ad hoc at audit time. Target state is an automated quarterly Delegation package with signed integrity, a maintained gap register, and direct feed into IC-08 attestation production." }, "implementers": [ "IAM Team", "GRC / Internal Audit", "Platform Engineering" ], "validation": { "design_check": [ "Verify the Delegation evidence package schema defines required artifacts for every DE-01 through DE-08 control, with acceptance criteria and freshness windows per artifact.", "Confirm package assembly is automated from authoritative sources (registry exports, IdP and pipeline logs) rather than manually collated documents.", "Validate that the package is signed and hash-chained so downstream consumers (IC-08 attestation production) can verify integrity and completeness." ], "runtime_test": [ "Request the current Delegation evidence package via the integration API and confirm every DE-layer control contributes at least one artifact with a collection timestamp inside the freshness window.", "Tamper with one staged artifact and confirm the package integrity check fails and the package is rejected as IC-08 input.", "Simulate a missing artifact for one control and confirm the gap register records it with an assigned owner and remediation date." ], "evidence": [ "evidence-package:Signed quarterly Delegation layer evidence package with per-control artifact manifest [unverified]", "gap-register:Gap register entries for the prior four quarters with remediation owners and closure dates [unverified]", "review-signoff:Quarterly review sign-off records naming the reviewing owners and their dispositions [unverified]" ] }, "layer_code": "DE", "lens_enrichment": "ap42 2026-07-08" }, { "id": "IF-01", "layer": "IF", "plane": "data", "name": "Identity Federation Trust Framework", "plain": "Establishes the trust anchors, vetting process, and federation policy that determine which external identity providers are permitted to authenticate AI agents accessing enterprise resources.", "threat": { "tags": [ "federation-bypass", "identity-spoofing" ], "desc": "Without a formally vetted set of trust anchors, an adversary can present tokens issued by an unrecognized or compromised external IdP and gain access to enterprise resources. Federation bypass occurs when the trust boundary is implicit rather than explicitly enumerated: any IdP that can produce a syntactically valid OIDC token is accepted, including attacker-controlled providers. Identity spoofing occurs when an external agent presents fabricated claims (principal type, capability manifest, organizational affiliation) that cannot be verified against a vetted trust anchor. The consequence is unauthorized access with no attribution path and no revocation mechanism." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72, \u00a73.5", "title": "Federation Assurance Levels and trust agreements" }, { "id": "openid", "section": "OpenID Connect Discovery 1.0", "title": "OpenID Provider metadata and discovery" }, { "id": "eidas2", "section": "Arts. 19a, 21, 24", "title": "Requirements for (qualified) trust service providers" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" }, { "id": "eidas2_reg_2024_1183", "title": "Regulation (EU) 2024/1183 \u2014 eIDAS 2.0", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1183", "published_on": "2024-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401183", "license": "public-domain", "status": "current", "flagship": false, "source_id": "eidas2_2024_1183", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1183 \u2014 eIDAS 2.0 requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" }, { "id": "oidc_federation_1_0", "title": "OpenID Connect Federation 1.0", "authority": "OpenID Foundation", "source_type": "standard", "normative_force": "best-practice", "version": "1.0", "published_on": "2024-03-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openid.net/specs/openid-federation-1_0.html", "license": "open-access", "status": "current", "flagship": false, "source_id": "oidc_federation_1_0", "relationship": "informative_reference", "rationale": "Establishes OpenID Connect Federation 1.0 requirements informing the apeiris://identity/controls/IF-01 Identity Federation Trust Framework control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain an explicit, version-controlled trust anchor registry that enumerates permitted external IdPs with their vetting status, trust level assignment (FAL1/FAL2), and re-evaluation schedule. All federation flows must check the incoming issuer (iss) against this registry as a blocking gate before token validation proceeds.", "steps": [ "Define the trust anchor registry schema: issuer URI, display name, vetting evidence reference (SOC 2 Type II report ID, ISO 27001 certificate, or equivalent), assigned FAL level, trust level effective date, and next re-evaluation date. Store in version control with mandatory code review for any changes.", "Establish the trust anchor vetting process: require SOC 2 Type II (or ISO 27001 or NIST CSF Tier 3 equivalent) before onboarding any external IdP at FAL2. For FAL1, require at minimum a current security questionnaire and legal agreement. Document the vetting evidence reference in the registry entry.", "Implement issuer validation as a blocking pre-check in all token processing paths: reject tokens whose iss claim does not match a registered trust anchor entry at the correct FAL level for the requested access tier. Log all rejections with the presented issuer value.", "Enforce PKCE (Proof Key for Code Exchange, RFC 7636) for all authorization code flows regardless of client type. Enforce audience restrictions on all tokens: the aud claim must explicitly name the target resource server, not use a wildcard or omit the field.", "Set token lifetime limits by FAL level in the authorization server configuration: FAL1 access tokens max 1 hour; FAL2 access tokens max 15 minutes for access paths involving consequential actions (data writes, external communications, financial operations). Refresh token lifetime max 24 hours at both levels.", "Schedule annual re-evaluation of all trust anchors: reverify vetting evidence, confirm IdP is still operating under the same security controls, and update the registry entry with the new reviewed-on date. Downgrade or remove trust anchor entries that cannot be reverified." ], "anti_patterns": [ "Accepting tokens from any issuer that can produce a valid JWKS \u2014 this is implicit trust, not a trust framework, and allows any attacker-controlled IdP to issue accepted tokens.", "Using a single FAL level for all access types regardless of action materiality \u2014 consequential actions require FAL2 with shorter token lifetimes, not the same configuration as read-only access.", "Treating the trust anchor registry as a configuration file managed by a single engineer without review controls \u2014 changes to the trust anchor set are security-critical and must require peer review and audit logging." ] }, "validation": { "design_check": [ "Confirm the trust anchor registry exists as a version-controlled artifact with a defined schema, required vetting evidence fields, and FAL level assignments for each registered IdP [ref:nist_800_63_4].", "Verify that all authorization server and token validation configurations enforce issuer validation against the registry as a blocking pre-check, not a logging-only step [ref:cisa_zt_maturity_v2].", "Inspect the re-evaluation schedule: confirm every trust anchor has a next-review date no more than 12 months from its last vetting date, and that the process for lapsing or removing an unverified trust anchor is documented [ref:eidas2_reg_2024_1183]." ], "runtime_test": [ "Present a token with a valid JWT signature from an issuer URI not in the trust anchor registry; confirm the resource server returns 401 and logs the rejected issuer [ref:nist_800_63_4].", "Attempt an authorization code flow without PKCE from a public client; confirm the authorization server rejects the request with an error indicating PKCE is required [ref:nist_800_63_4].", "Issue a FAL2 access token and attempt to use it after its configured lifetime (max 15 minutes for consequential access); confirm the resource server returns 401 and does not accept the expired token [ref:cisa_zt_maturity_v2]." ], "evidence": [ "identity:trust-anchor-registry \u2014 version-controlled trust anchor registry listing all permitted external IdPs with FAL level, vetting evidence references, and re-evaluation dates [unverified]", "identity:issuer-rejection-log \u2014 sample of audit log entries showing rejected tokens with presented issuer URI and timestamp, confirming blocking behavior is operational [unverified]", "identity:vetting-evidence-pack \u2014 SOC 2 Type II reports, ISO 27001 certificates, or equivalent documents for each FAL2 trust anchor demonstrating the vetting process was executed [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The trust anchor registry is an IAM infrastructure artifact that must be enforced at the token validation layer. Every federation flow has a blocking check against the registry before any token claims are processed.", "actions": [ "Implement registry lookup as the first step in the token validation middleware \u2014 before signature verification, before claim extraction", "Configure PKCE as a mandatory parameter in the authorization server for all public and confidential clients on authorization code flows", "Set per-FAL token lifetime limits in authorization server configuration and verify they are enforced in integration tests" ], "failure_signals": [ "Token validation logs show accepted tokens from issuers not in the trust anchor registry", "Authorization server accepts authorization code flows without the code_challenge parameter" ] }, "security_architect": { "summary": "The trust framework design must enforce explicit enumeration of trusted issuers. Implicit trust (accept any valid JWKS) is an architectural defect that collapses the federation boundary. FAL level assignment must reflect action materiality, not blanket policy.", "actions": [ "Define FAL level assignment criteria: which access paths require FAL2 (short-lived tokens, stronger vetting) versus FAL1", "Design the trust anchor registry as a central control plane artifact with change management controls equal to firewall rule changes", "Review token lifetime configuration across all resource servers to confirm FAL-based limits are consistently enforced" ], "failure_signals": [ "No documented criteria distinguishing FAL1 from FAL2 access paths \u2014 all external federation uses the same configuration", "Trust anchor changes can be made by modifying a configuration file without a review workflow" ] }, "legal_counsel": { "summary": "eIDAS 2.0 creates cross-border identity recognition obligations for EU-context deployments. Trust anchor vetting must include legal agreement review confirming the external IdP's compliance obligations, data processing terms, and liability allocation.", "actions": [ "Confirm that each external IdP in the trust anchor registry has a signed legal agreement covering data processing obligations and liability for authentication failures", "Verify that eIDAS 2.0 qualified trust service provider status is confirmed (not self-asserted) for any IdP used in EU public sector or regulated private sector contexts", "Review the annual re-evaluation process to confirm that legal agreement renewal is part of the vetting cycle, not just technical security assessment" ], "failure_signals": [ "Trust anchor registry entries reference only technical vetting evidence with no legal agreement reference", "EU-context federation relies on non-qualified trust services for regulated service access" ] }, "grc_auditor": { "summary": "The trust anchor registry is a primary audit artifact. Every external IdP permitted to authenticate AI agents must have a traceable vetting record. Annual re-evaluation provides the review cadence regulators expect for third-party identity dependencies.", "actions": [ "Inspect the trust anchor registry for completeness: every IdP used in production federation must have an entry with vetting evidence reference and re-evaluation date", "Sample 3-5 trust anchor entries and trace the vetting evidence (SOC 2 report, ISO 27001 cert) to confirm the documents exist, are current, and cover the relevant control domains", "Verify that the re-evaluation schedule has been executed: no trust anchor should have a last-reviewed date more than 12 months ago" ], "metrics": [ "Percentage of active trust anchor entries with current vetting evidence (target: 100%)", "Number of trust anchor entries with overdue re-evaluation (target: zero)" ], "failure_signals": [ "Trust anchor registry has entries with no vetting evidence reference or with expired evidence", "Production federation flows use an IdP not present in the trust anchor registry" ] }, "it_operations": { "summary": "Trust anchor changes must go through a change management workflow. Token lifetime configuration must be validated in each environment. PKCE enforcement requires authorization server configuration to be consistent across environments.", "actions": [ "Add trust anchor registry changes to the change management process with approval requirements equivalent to firewall rule changes", "Validate PKCE enforcement configuration is consistent across development, staging, and production authorization server instances", "Monitor the issuer rejection log for unexpected spikes that may indicate an IdP configuration change or an active federation bypass attempt" ], "failure_signals": [ "Authorization server configuration differs between environments, allowing implicit trust in non-production that would be exploitable in production", "No alerting on issuer rejection log events \u2014 bypass attempts go undetected" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations allow federation without an explicit trust anchor registry \u2014 accepting any IdP that can produce valid JWKS. Achieving 'defined' requires enumerating permitted issuers, assigning FAL levels, documenting vetting evidence, and enforcing the registry as a blocking gate." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "cloud-native", "universal-enterprise", "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Architecture", "Legal/Compliance" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72, \u00a73.5", "fit": "direct", "rationale": "SP 800-63C-4 \u00a72 defines Federation Assurance Levels and \u00a73.5 requires documented trust agreements between IdPs and RPs. IF-01 implements the trust-anchor vetting and FAL assignment process those sections specify, including verifying the identity provider before accepting federated assertions.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eidas2", "requirement_id": "Arts. 19a, 21, 24", "fit": "direct", "rationale": "eIDAS 2 Articles 19a, 21, and 24 set the requirements for (qualified) trust service providers \u2014 security obligations, initiation of qualified services, and verification duties. IF-01's vetting process for EU-context trust anchors must confirm qualified trust service status and these TSP obligations for regulated access contexts.", "source_version": "2024/1183", "reviewed_on": "2026-07-02", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Identity Stores", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar's Identity Stores function covers integrating and governing identity stores, including federated identity providers, and expects trusted providers to be explicitly enumerated. IF-01 implements this; continuous validation behaviors are addressed in IF-06.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Universal Directory \u2014 Federation Trust Config", "rationale": "Okta Universal Directory federation supports SAML 2.0 and OIDC trust establishment with IdP metadata validation, certificate pinning, and signed assertion verification to prevent trust relationship manipulation. Federation trust entries require explicit approval and are versioned, enabling audit of all trust configuration changes.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta federation config validates IdP metadata, pins certs and verifies assertions, but not the vetted trust-anchor registry with FAL and re-eval cadence.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity Runtime Identity \u2014 Trust Framework", "rationale": "Ping Identity's Identity for AI runtime identity standard establishes trust between agent identity domains through cryptographic token binding and audience-validated assertions rather than implicit trust. Each cross-domain interaction requires presentation of a cryptographically verifiable identity claim, ensuring trust is earned through proof rather than inherited from network proximity.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Ping runtime identity establishes cross-domain trust via token binding and audience validation, but not the versioned vetted trust-anchor registry.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Identity Provider Federation", "rationale": "AWS IAM supports SAML 2.0 and OIDC identity provider federation with explicit trust configuration requiring the IdP's certificate/JWKS endpoint and audience constraint. Trust relationships are governed through IAM identity provider resources with explicit trust condition keys (saml:aud, token.actions.githubusercontent.com), limiting federation to explicitly configured identity domains.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS SAML/OIDC IdP federation configures technical trust (cert/JWKS, audience) but not the vetting-evidence trust-anchor registry with re-evaluation dates.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "oidc_federation", "requirement_id": "\u00a79 (Entity Configuration)", "fit": "direct", "rationale": "OpenID Federation 1.0 defines trust chain resolution for federated identity providers; Entity Configuration retrieval is specified in \u00a79. IF-01 trust frameworks should adopt its entity configuration and trust-mark constructs.", "normative_force": "best-practice", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://identity/controls/IF-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every external identity provider used in production to authenticate AI agents must have a corresponding entry in the version-controlled trust anchor registry with current vetting evidence, an assigned FAL level, and a next re-evaluation date no more than 12 months in the future. All token processing paths must reject tokens whose issuer (iss) claim does not match a registered trust anchor entry as a blocking gate executed before any token claims are processed or signature verification proceeds.", "evidence_required": [ "trust_anchor_registry export showing all registered external IdPs with fields: issuer_uri, display_name, vetting_evidence_reference, assigned_fal_level, trust_level_effective_date, next_re_evaluation_date \u2014 with no production IdP absent from the registry", "issuer_rejection_log sample from the review period showing rejected tokens with presented issuer URI, timestamp, and rejection reason, confirming the blocking gate is operational and logging correctly", "vetting_evidence_pack for each FAL2 trust anchor containing SOC 2 Type II report, ISO 27001 certificate, or equivalent security evidence covering the review period and produced by an independent auditor", "annual_re_evaluation_records confirming each trust anchor was reviewed within the past 12 months with verification that vetting evidence remains current" ], "machine_tests": [ "Submit token with a valid JWT signature from an issuer URI not present in the trust anchor registry \u2192 assert resource server returns 401 and audit log records the rejected issuer URI", "Initiate authorization code flow without the code_challenge parameter \u2192 assert authorization server returns 400 with error=invalid_request and does not issue an authorization code", "Issue FAL2 access token and attempt to use it 16 minutes after issuance (beyond the 15-minute maximum lifetime for consequential access) \u2192 assert resource server returns 401 with error=token_expired" ], "human_review": [ "Review the trust anchor registry to confirm every IdP used in production federation has a current entry with unexpired vetting evidence references and a next re-evaluation date within 12 months of the most recent review", "Assess the trust anchor vetting process for FAL2 IdPs to confirm SOC 2 Type II or equivalent independent assurance evidence is required, verified, and on file before any external IdP is onboarded", "Verify change management controls for the trust anchor registry: confirm all modifications require peer review by a second IAM engineer and are recorded in the audit log as security-critical configuration changes" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Accepting tokens from any issuer that can present a syntactically valid JWKS endpoint, creating implicit universal trust without a formally vetted and enumerated trust anchor registry", "Applying the same FAL1 configuration to all access paths regardless of action materiality, eliminating the protection that short-lived FAL2 tokens provide for consequential operations", "Managing the trust anchor registry as a configuration file modifiable by a single engineer without peer review, making unauthorized trust relationship additions undetectable until the next audit", "Treating trust anchor vetting as a one-time onboarding activity rather than requiring annual re-evaluation with refreshed independent security evidence from each registered IdP", "Conflating PKCE enforcement with trust anchor validation and treating one as a compensating control for the absence of the other" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-02", "layer": "IF", "plane": "data", "name": "OIDC/OAuth Federation Configuration", "plain": "Specifies the required OIDC and OAuth 2.0 configuration for AI agent federation: scope definitions, token lifetime limits, audience restrictions, PKCE enforcement, and rich authorization request requirements.", "threat": { "tags": [ "federation-bypass", "credential-compromise" ], "desc": "Misconfigured OIDC/OAuth settings are the most common entry point for federation attacks. Implicit flow enables token interception in the redirect URI. Missing audience restrictions allow tokens issued for one service to be replayed against another. Excessively long token lifetimes extend the window of exploitation after credential compromise. Absent PKCE allows authorization code interception attacks against public clients. Without RFC 9396 Rich Authorization Requests, an agent receives broad scope grants that exceed what the specific action requires, violating least-privilege at the authorization layer." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Federation Assurance Levels \u2014 assertion protection (FAL2)" }, { "id": "openid", "section": "RFC 9396 \u00a73", "title": "OAuth 2.0 Rich Authorization Requests \u2014 authorization_details in the authorization request" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 3", "title": "Per-request authorization verification" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-01" }, { "id": "fapi_2_0_security_profile", "title": "Financial-grade API Security Profile 2.0", "authority": "OpenID Foundation FAPI Working Group", "source_type": "standard", "normative_force": "best-practice", "version": "2.0", "published_on": "2024-01-10", "retrieved_on": "2026-06-29", "canonical_url": "https://openid.net/specs/fapi-2_0-security-profile.html", "license": "open-access", "status": "current", "flagship": false, "source_id": "fapi_2_0_security_profile", "relationship": "informative_reference", "rationale": "Establishes Financial-grade API Security Profile 2.0 requirements informing the apeiris://identity/controls/IF-02 OIDC/OAuth Federation Configuration control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Configure OIDC and OAuth 2.0 authorization servers with explicit prohibitions on implicit flow, mandatory PKCE for all authorization code flows, audience-restricted tokens scoped to specific resource server identifiers, and RFC 9396 Rich Authorization Requests for consequential action authorization.", "steps": [ "Disable the implicit flow (response_type=token) in all authorization server configurations. This is non-negotiable \u2014 implicit flow tokens are returned in the URL fragment, cannot be refreshed, and expose tokens to browser history and referrer headers. Any existing implicit flow clients must be migrated to authorization code with PKCE.", "Mandate PKCE (RFC 7636) for all authorization code flow clients including confidential clients. Configure the authorization server to reject authorization requests missing code_challenge and code_challenge_method=S256. Treat plain code challenge method as equivalent to no PKCE \u2014 require S256.", "Implement RFC 9396 Rich Authorization Requests (RAR) for all AI agent authorization flows that involve consequential actions. The authorization_details object must declare the specific action type, resource identifier, and scope of authority being requested. Reject authorization requests for consequential actions that do not include authorization_details.", "Configure token audience restriction: every access token must include an aud claim containing the specific resource server URI(s) it is valid for. Wildcard audiences (aud: '*' or aud: omitted) must be rejected. Resource servers must validate the aud claim and reject tokens where aud does not include their own URI.", "Set token lifetime limits by access sensitivity: access tokens for consequential actions (data writes, external communications, financial operations, configuration changes) maximum 15 minutes; access tokens for read-only operations maximum 1 hour; refresh tokens maximum 24 hours. Configure refresh token rotation on each use.", "Define AI agent OAuth scopes explicitly in the authorization server configuration: scope names must be specific action-typed identifiers (e.g., agent:email:send:external, agent:data:read:customer-crm) rather than broad resource-level grants (e.g., email, crm). Document every scope in a scope registry with its permitted actions and data access." ], "anti_patterns": [ "Retaining implicit flow support for legacy AI agent clients while enforcing authorization code + PKCE for new clients \u2014 legacy clients with implicit flow are an active attack surface regardless of new client compliance.", "Using broad OAuth scopes (read, write, admin) rather than action-typed scopes \u2014 broad scopes mean a compromised token grants far more than the specific task requires, multiplying the impact of any credential compromise.", "Setting access token lifetime to 1 hour uniformly across all access types \u2014 consequential action tokens must be 15 minutes maximum; applying the same lifetime to both eliminates the security benefit of short-lived tokens for high-impact actions." ] }, "validation": { "design_check": [ "Inspect authorization server configuration to confirm implicit flow is disabled and authorization code flow requires PKCE with code_challenge_method=S256 [ref:nist_800_63_4].", "Review the scope registry to confirm AI agent scopes are action-typed (not broad resource grants) and that the RFC 9396 authorization_details schema is defined for each consequential action type [ref:rfc_9396].", "Verify token lifetime configuration: access tokens for consequential action paths must be 15 minutes or less; confirm this is enforced in the authorization server, not just documented [ref:nist_800_63_4]." ], "runtime_test": [ "Attempt an authorization request with response_type=token (implicit flow); confirm the authorization server returns an error and does not issue a token [ref:nist_800_63_4].", "Submit an authorization code flow request without code_challenge; confirm the server rejects the request. Submit with code_challenge_method=plain; confirm rejection [ref:nist_800_63_4].", "Obtain a consequential-action access token and attempt to use it against a resource server whose URI is not in the token's aud claim; confirm the resource server returns 401 [ref:nist_sp_800_207]." ], "evidence": [ "identity:authserver-config-review \u2014 authorization server configuration extract showing implicit flow disabled, PKCE required, and token lifetime settings per access type [unverified]", "identity:scope-registry \u2014 documented list of all AI agent OAuth scopes with action-type definitions and authorized data access per scope [unverified]", "identity:rar-schema-definition \u2014 RFC 9396 authorization_details schema definitions for each consequential action type supported by the authorization server [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "OIDC/OAuth configuration is the technical implementation of the authorization policy. Implicit flow must be off, PKCE must be on, audience restrictions must be enforced at the resource server, and RAR schemas must be defined for every consequential action type before AI agents are onboarded.", "actions": [ "Audit current authorization server configuration against each required setting: implicit flow status, PKCE enforcement, audience restriction, token lifetimes", "Implement RFC 9396 authorization_details validation in resource server middleware for consequential action endpoints", "Create and maintain the scope registry as a living document reviewed on each agent onboarding" ], "failure_signals": [ "Authorization server configuration shows implicit flow enabled even for specific client types", "Resource server middleware does not validate the aud claim \u2014 accepts any valid JWT signature" ] }, "security_architect": { "summary": "OAuth configuration decisions compound: each permissive setting (implicit flow, broad scopes, long lifetimes, absent audience restriction) multiplies attack surface. The configuration must be treated as a security control set, not a developer convenience layer.", "actions": [ "Define a baseline authorization server configuration standard and enforce it via infrastructure-as-code \u2014 no configuration drift between environments", "Design scope taxonomy before any AI agent is onboarded: action-typed scopes are an architectural decision that cannot be easily retrofitted", "Review the authorization_details schema for each consequential action type to ensure it captures the minimum information needed for policy evaluation" ], "failure_signals": [ "Scope taxonomy uses broad resource grants rather than action-typed identifiers \u2014 cannot distinguish read from write at the scope level", "Different environments (staging vs production) have different authorization server configurations allowing implicit flow in non-production" ] }, "legal_counsel": { "summary": "Token scope definitions and authorization_details structures determine what AI agents are legally authorized to do on behalf of principals. Broad OAuth scopes create legal exposure: an agent acting under a broad scope grant may perform actions the principal did not specifically authorize.", "actions": [ "Review the scope registry to confirm each scope's permitted actions align with the delegation agreements and terms of service governing AI agent use", "Confirm that authorization_details structures for consequential actions capture enough specificity to support legal attribution (who authorized what action on what resource at what time)", "Verify that refresh token lifetime limits align with session expiry expectations in any applicable user consent agreements" ], "failure_signals": [ "Scope definitions are too broad to distinguish authorized from unauthorized actions \u2014 legal attribution is impossible after an incident", "Refresh token lifetime exceeds the duration covered by user consent for agent access" ] }, "grc_auditor": { "summary": "OAuth configuration directly determines the attack surface for AI agent credential compromise. Auditors should verify the configuration against the required settings and confirm there is no drift between the documented standard and the operational configuration.", "actions": [ "Pull the current authorization server configuration and compare each required setting (implicit flow disabled, PKCE required, audience restricted, token lifetimes) against the IF-02 standard", "Verify the scope registry is current and that no AI agent in production uses a scope that is not in the registry with a documented justification", "Confirm RFC 9396 authorization_details is implemented for all consequential action paths \u2014 not just documented as a future requirement" ], "metrics": [ "Number of active AI agent clients using implicit flow (target: zero)", "Percentage of consequential action endpoints with RFC 9396 authorization_details validation enforced (target: 100%)" ], "failure_signals": [ "Authorization server configuration has not been reviewed against the IF-02 standard in the current audit period", "Active AI agent clients have broader scope grants than their current task requires" ] }, "it_operations": { "summary": "Token lifetime configuration affects operational behavior: agents using short-lived consequential-action tokens will need more frequent token refresh flows. Ensure the refresh flow is implemented correctly and that token expiry does not cause silent failures in agent workflows.", "actions": [ "Verify that AI agent implementations handle token expiry and refresh correctly \u2014 silent 401 errors indicate missing refresh logic", "Monitor refresh token usage patterns for anomalies: excessive refresh frequency may indicate a compromised token being used from multiple locations", "Ensure authorization server configuration is managed via infrastructure-as-code with environment parity checks" ], "failure_signals": [ "AI agent workflows fail silently when access tokens expire \u2014 no retry or refresh logic implemented", "Refresh token rotation is not enabled \u2014 a stolen refresh token can be used indefinitely without detection" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most OAuth deployments still support implicit flow for legacy compatibility and use broad scope grants. Achieving 'defined' requires disabling implicit flow, implementing action-typed scopes, enforcing PKCE across all flows, and implementing RFC 9396 RAR for consequential action paths." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "cloud-native", "universal-enterprise", "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "IAM Team", "Platform Engineering", "API Security" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "direct", "rationale": "SP 800-63C-4 \u00a72 defines Federation Assurance Level requirements, including assertion protection and lifetime expectations that IF-02 implements through OIDC/OAuth configuration.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396", "fit": "direct", "rationale": "RFC 9396 Rich Authorization Requests is directly implemented by IF-02's requirement for authorization_details in consequential action authorization flows.", "source_version": "RFC 9396", "reviewed_on": "2026-06-28", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 3", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 3 grants access on a per-session basis with authorization evaluated per request. IF-02's audience restriction and short-lived token requirements directly enable that model; full per-request evaluation also requires runtime behavioral controls beyond IF-02's scope.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta OIDC \u2014 Dynamic Client Registration", "rationale": "Okta supports OIDC Dynamic Client Registration (RFC 7591) for automated federation onboarding of AI agents with explicit scope grants. Okta recommends private_key_jwt as the preferred client authentication method for machine clients, providing asymmetric cryptographic authentication rather than shared secrets. All client registrations are auditable through the Okta System Log.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta DCR with private_key_jwt covers client onboarding and auth, one part of the required PKCE/audience/no-implicit/RAR configuration set.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "PingFederate \u2014 OIDC Audience Validation", "rationale": "PingFederate enforces OIDC audience (aud) and scope validation on every issued token; tokens presented to unintended resource servers are rejected because the aud claim is bound to the specific resource at issuance. This prevents token forwarding attacks in multi-agent chains where a token issued for one resource could be replayed at another.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "PingFederate enforces audience and scope validation on every token, covering the audience-restriction element among the config items required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "fapi_2_0", "requirement_id": "\u00a75.3.2 (Requirements for authorization servers)", "fit": "direct", "rationale": "FAPI 2.0 Security Profile \u00a75.3.2 sets the requirements for authorization servers \u2014 mandating PAR, PKCE (\u00a75.3.2.2), and sender-constrained tokens for high-value delegated authorization \u2014 the reference bar for AI identity federation in financial and regulated contexts.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Service authentication (OAuth 2.0); Part IV Phase 6 \u2014 Just-in-time (JIT) access", "fit": "partial", "rationale": "Doc uses OAuth 2.0 / IdP-issued tokens as the auth baseline. Partial: doc does not address OIDC/OAuth federation trust configuration between organizations.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IF-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The authorization server must have implicit flow disabled, PKCE with code_challenge_method=S256 enforced for all authorization code flows, all access tokens audience-restricted to specific resource server URIs, and RFC 9396 authorization_details required for consequential action authorization requests. Access tokens issued for consequential action paths must have a maximum lifetime of 15 minutes as enforced by the authorization server configuration.", "evidence_required": [ "authserver_configuration_extract showing: implicit_flow=disabled, pkce_required=true with code_challenge_method=S256 mandatory for all clients, and per-access-type token_lifetime settings (consequential actions \u2264900 seconds, read-only operations \u22643600 seconds)", "scope_registry documenting all AI agent OAuth scopes with action-typed identifiers, permitted data access per scope, and RFC 9396 authorization_details schema definitions for each consequential action type", "audience_validation_test_log showing resource server 401 responses to tokens whose aud claim does not include the target resource server URI, confirming audience restriction is enforced at the resource server layer", "rar_implementation_evidence showing authorization_details validation is enforced as a blocking gate for consequential action authorization requests, not an optional parameter" ], "machine_tests": [ "Submit authorization request with response_type=token (implicit flow) \u2192 assert authorization server returns 400 with error=unsupported_response_type and does not issue any token", "Submit authorization code flow request without code_challenge parameter \u2192 assert authorization server returns 400 with error=invalid_request; repeat with code_challenge_method=plain \u2192 assert same rejection", "Present consequential-action access token to resource server whose URI is absent from the token aud claim \u2192 assert resource server returns 401 with error=invalid_token", "Issue consequential-action access token and wait 16 minutes, then attempt resource access \u2192 assert resource server returns 401 with error=token_expired" ], "human_review": [ "Review the scope registry for specificity: confirm no AI agent in production holds a scope broader than required for its current task and that action-typed scope identifiers are used throughout rather than broad resource-level grants", "Assess RFC 9396 authorization_details schema definitions for each consequential action type to confirm they capture sufficient detail for legal attribution of who authorized which action on which resource at what time", "Verify authorization server configuration is managed via infrastructure-as-code with environment parity checks confirming that staging and production configurations are equivalent for all security-relevant settings" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Retaining implicit flow support for legacy AI agent clients while enforcing PKCE for new clients, leaving legacy clients as an active token interception attack surface regardless of new client compliance", "Using broad OAuth scope identifiers such as read, write, or admin rather than action-typed identifiers, making it impossible to enforce least-privilege at the scope evaluation layer", "Setting a uniform access token lifetime for all access types and applying the 1-hour read-only lifetime to consequential action paths, eliminating the security benefit of short-lived tokens for high-impact operations", "Implementing RFC 9396 authorization_details as an optional parameter that agents may omit for consequential actions rather than requiring it as a blocking gate in the authorization flow", "Allowing different authorization server configurations between development, staging, and production environments, creating security properties in production that cannot be validated before deployment" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-03", "layer": "IF", "plane": "data", "name": "Cross-Organizational Agent Authentication", "plain": "Ensures that AI agents from external organizations are authenticated against a verified trust anchor before receiving any access, with audience-restricted tokens and mandatory trust chain verification.", "threat": { "tags": [ "federation-bypass", "identity-spoofing", "lateral-movement" ], "desc": "Cross-organizational agent authentication is the highest-risk federation scenario because the enterprise has no direct control over the external organization's identity infrastructure. An attacker who compromises an external organization's IdP can issue tokens for agents that appear legitimate. Without mandatory trust chain verification, an agent can present a token signed by an intermediate CA that is not traced back to a vetted trust anchor. Without audience restriction, a token issued for one cross-org service can be replayed against another. Lateral movement follows when an external agent that successfully authenticates against one resource uses the same token to probe adjacent resources." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "FAL2 assertion strength for cross-org federation" }, { "id": "oidc_federation", "section": "Trust chain (OpenID Federation 1.0)", "title": "Trust chain resolution and verification" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Never trust implicitly; always verify" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-03 Cross-Organizational Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/IF-03 Cross-Organizational Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IF-03 Cross-Organizational Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IF-03 Cross-Organizational Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IF-03 Cross-Organizational Agent Authentication control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Require cryptographic trust chain verification for all external organization agent tokens before any resource access is granted. The verification must confirm: the issuing IdP traces to a vetted trust anchor, the token audience restricts to the specific resource, and the agent identity carries a complete capability manifest and delegation scope declaration.", "steps": [ "Require every external organization agent token to include: issuer (iss) traceable to a registered trust anchor, audience (aud) restricted to the specific resource server URI, subject (sub) identifying the agent's unique identity within the external org, azp (authorized party) identifying the external org's client registration, and a custom claim declaring the agent's capability manifest, principal type, and delegation scope.", "Implement trust chain verification: for each incoming external agent token, retrieve the issuing IdP's discovery document, verify the signing key traces to the registered trust anchor (not just to any well-formed JWKS), and confirm the issuer metadata has not changed since last verified. Cache verified chain results for the duration of a short validation cache TTL (max 5 minutes).", "Validate the agent capability manifest claim on every request: the manifest must declare the agent's authorized tools, action classes, and data access scope. The resource server must confirm the requested action falls within the declared manifest before processing. A request that exceeds the declared capability manifest must be rejected with a specific error.", "Enforce principal type verification: external agent tokens must declare principal type (workload, personal, personal-in-enterprise) in the token claims. For personal-in-enterprise agents, require both the human principal identity binding and the enterprise delegation scope claim. Reject tokens that omit principal type.", "Require audience-restricted tokens for every cross-org access: the aud claim must name the specific resource server identifier, not a wildcard or org-level audience. Implement audience validation at the resource server as a blocking check \u2014 not just logging.", "Log every cross-org agent authentication event with: external org identifier, agent sub claim, trust anchor used, capability manifest hash, principal type declared, access granted/denied verdict, and timestamp. Feed these events to the audit reconciliation process in IF-08." ], "anti_patterns": [ "Accepting cross-org tokens on the basis of a valid signature alone without verifying the trust chain back to a registered trust anchor \u2014 this is the most common federation bypass path.", "Treating capability manifest validation as optional or advisory \u2014 an external agent that can exceed its declared manifest has effectively gained unauthorized access and the deviation will not be detected at the access layer.", "Allowing the same cross-org token to be reused across multiple resource servers because audience validation is absent or permissive \u2014 enables lateral movement after a single successful authentication." ] }, "validation": { "design_check": [ "Confirm that the external agent token validation middleware enforces trust chain verification (not just signature verification) with the trust anchor registry as the root of trust [ref:nist_800_63_4].", "Verify that the capability manifest claim is defined in the token schema and that resource servers implement manifest-based authorization as a blocking check [ref:nist_sp_800_207].", "Inspect the principal type claim requirements: confirm that personal-in-enterprise type tokens must carry both human principal binding and enterprise delegation scope claims, and that tokens missing principal type are rejected [ref:nist_800_63_4]." ], "runtime_test": [ "Present an external agent token signed by an intermediate CA that does not trace to a registered trust anchor; confirm the resource server rejects the token with a trust chain error [ref:nist_800_63_4].", "Submit a request from an external agent for an action that exceeds the declared capability manifest; confirm the resource server rejects the request with a manifest authorization error [ref:nist_sp_800_207].", "Attempt to replay a valid cross-org token issued for resource server A against resource server B (different URI); confirm resource server B rejects the token on audience mismatch [ref:nist_sp_800_207]." ], "evidence": [ "identity:cross-org-auth-log \u2014 audit log sample of cross-organizational agent authentication events showing trust anchor used, capability manifest hash, and grant/deny verdict per event [unverified]", "identity:trust-chain-verification-config \u2014 configuration showing trust chain verification is implemented as a blocking step separate from signature verification [unverified]", "identity:capability-manifest-schema \u2014 defined schema for the capability manifest token claim showing required fields: authorized tools, action classes, data access scope, and manifest hash [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Cross-org agent authentication requires token validation logic that goes beyond standard JWT verification. Trust chain verification, capability manifest validation, and principal type enforcement must each be implemented as discrete, blocking middleware components.", "actions": [ "Implement trust chain verification as a separate middleware step from JWT signature verification \u2014 the signing key must trace to the trust anchor registry", "Define the capability manifest claim schema and implement manifest-based authorization at resource server middleware", "Create per-external-org onboarding documentation specifying the required token claim structure" ], "failure_signals": [ "Token validation middleware uses a generic OIDC library with no trust chain verification \u2014 accepts any valid JWKS endpoint", "No capability manifest claim defined or validated \u2014 external agents can request any action their scope nominally permits" ] }, "security_architect": { "summary": "Cross-org agent authentication is the boundary between the enterprise trust model and external trust models. The architecture must treat every external agent as untrusted until each layer of verification passes. No single validation step is sufficient.", "actions": [ "Design the cross-org authentication flow as a sequence of blocking gates: trust chain \u2192 audience \u2192 principal type \u2192 capability manifest \u2192 requested action within manifest", "Define the blast radius of a compromised external IdP: which resources would be accessible, how long before discovery, what revocation mechanism exists", "Review all API gateway and service mesh configurations for external agent traffic to confirm trust chain and manifest validation are present in every path" ], "failure_signals": [ "API gateway validates JWT signature but delegates trust chain verification to downstream services \u2014 inconsistent enforcement creates bypass paths", "No defined process for revoking access when an external org's IdP is compromised" ] }, "legal_counsel": { "summary": "Cross-org agent authentication creates legal questions about liability when an external agent acts within the enterprise. The capability manifest and delegation scope claims must align with the legal agreements between organizations governing AI agent access.", "actions": [ "Confirm that cross-org agent access agreements specify the permitted action classes and that these align with the capability manifest claim requirements", "Verify that the external org's AI agent governance policies cover the agents being federated \u2014 not just the organization's human identity policies", "Establish incident response agreements covering who is liable and who leads response when a cross-org agent authentication failure enables unauthorized access" ], "failure_signals": [ "Cross-org access agreements predate AI agent deployment and do not address agent-specific access or capability limits", "No incident response agreement covering cross-org agent authentication failures" ] }, "grc_auditor": { "summary": "Cross-org agent authentication events must be audit-logged with enough detail to reconstruct what each external agent was authorized to do and what it actually did. The trust chain verification record must be independently traceable.", "actions": [ "Confirm cross-org authentication audit logs include: external org identifier, agent sub, trust anchor, capability manifest hash, principal type, and grant/deny verdict", "Sample 5-10 cross-org authentication events and trace each one: verify the trust anchor cited in the log matches a current registry entry with valid vetting evidence", "Verify that capability manifest validation rejections are logged separately from authentication failures \u2014 these are authorization failures and require different treatment" ], "metrics": [ "Number of cross-org agent authentication events with incomplete audit fields (target: zero)", "Number of capability manifest validation failures in the last 30 days (baseline and trend)" ], "failure_signals": [ "Cross-org authentication audit logs do not include trust anchor or capability manifest references", "No distinct log classification between authentication failures and capability manifest authorization failures" ] }, "it_operations": { "summary": "Cross-org agent authentication failures can arise from trust anchor updates, token clock skew, or capability manifest version mismatches. Operational runbooks must distinguish between infrastructure failures and active security rejections.", "actions": [ "Create runbooks for the three most common cross-org authentication failure types: trust anchor not found, token expired/clock skew, capability manifest claim missing", "Monitor trust chain verification cache hit rates \u2014 a sudden increase in cache misses may indicate IdP configuration changes at the external org", "Test cross-org authentication flows in staging after every trust anchor registry update to confirm no regressions" ], "failure_signals": [ "Cross-org agent authentication failures are classified as generic 401 errors in monitoring with no distinction between trust chain, audience, and manifest failures", "No runbook exists for cross-org authentication failures \u2014 operations team escalates all failures to IAM team without triage" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most cross-org federation implementations validate JWT signatures and basic claims but do not implement trust chain verification or capability manifest validation. Achieving 'managed' requires all blocking validation gates and structured audit logging of cross-org events." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "cloud-native", "universal-enterprise", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Architecture", "Enterprise Architecture" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "direct", "rationale": "SP 800-63C-4 \u00a72 FAL2 requirements apply to cross-organizational federation. IF-03 implements FAL2-level trust chain verification, audience restriction, and assertion strength requirements for external agent authentication.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 6 requires that all access requests from external entities be dynamically verified against policy before access is granted, with no implicit trust. IF-03 implements this through blocking trust chain verification and capability manifest authorization.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar's Authentication function requires explicit verification of external identity assertions. IF-03 implements this at the cross-org agent level; the pillar additionally covers human identity federation aspects outside IF-03's scope.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Cross Account Role Assume Conditions", "rationale": "AWS IAM cross-account role assumption with explicit condition-bound trust policies (aws:PrincipalOrgID to restrict to organizational accounts, aws:PrincipalAccount for specific account allowlisting) enables governed cross-organizational agent authentication without credential sharing. Every cross-account AssumeRole call is logged in CloudTrail in both the trusting and trusted accounts.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS cross-account conditions restrict which external org principals may assume roles, but not full trust-chain plus capability-manifest validation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity \u2014 Cross Organization Agent Auth", "rationale": "Ping Identity's federated authorization model supports cross-organizational agent authentication with runtime scope enforcement through the Agent Gateway. Cross-domain token assertions are validated for completeness, cryptographic integrity, and scope authorization before access is granted; external agent identities cannot exceed the permissions explicitly granted in the cross-org trust configuration.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Ping Gateway validates cross-domain assertions for integrity and audience, covering most of the blocking sequence but not the capability-manifest check.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Explicit trust boundaries; Part III \u2014 Agent identity and authentication (mutual TLS between production services)", "fit": "partial", "rationale": "Doc requires explicit trust boundaries and attested mutual TLS for service-to-service (including cross-boundary) calls. Partial: doc does not address federated cross-organizational agent authentication protocols.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IF-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All external organization agent tokens must pass a sequential blocking validation: trust chain verification back to a registered trust anchor, audience restriction to the specific resource server URI, principal type declaration present, and requested action confirmed within the declared capability manifest. Any token or request failing any single validation step must be denied before resource access is granted.", "evidence_required": [ "cross_org_auth_log with fields: external_org_id, agent_sub, trust_anchor_used, capability_manifest_hash, principal_type_declared, and grant/deny verdict for each authentication event", "trust_chain_verification_config showing trust chain verification is implemented as a blocking middleware step separate from JWT signature verification", "capability_manifest_schema defining required fields: authorized_tools, action_classes, data_access_scope, and manifest_hash, with resource server enforcement confirmed as a blocking check", "principal_type_enforcement_record confirming tokens omitting principal_type claim are rejected at validation middleware with a specific error code" ], "machine_tests": [ "Present external agent token signed by intermediate CA not in trust anchor registry \u2192 assert resource server returns 401 with error=trust_chain_verification_failed", "Submit request from external agent for action class not declared in its capability manifest claim \u2192 assert resource server returns 403 with error=capability_manifest_authorization_failed", "Replay valid cross-org token with aud=resource-server-A against resource-server-B (different URI) \u2192 assert resource server B returns 401 with error=audience_mismatch", "Submit external agent token with principal_type claim absent \u2192 assert token validation middleware rejects with error=missing_principal_type before any resource processing" ], "human_review": [ "Review trust anchor registry and vetting process documentation to confirm each registered trust anchor was assessed against defined vetting criteria before registration and that vetting records are retained", "Assess cross-org authentication audit logs for completeness: confirm each log event includes trust_anchor_used, capability_manifest_hash, and principal_type fields as required fields, not optional", "Verify cross-org access agreements with each external organization specify the required token claim structure including capability manifest declaration and principal type, and align with the capability manifest validation requirements" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Accepting cross-org tokens based on valid JWT signature alone without verifying the signing key traces to a registered trust anchor \u2014 allows any externally-operated IdP to issue tokens for cross-org access without vetting", "Treating capability manifest validation as optional or advisory rather than a blocking authorization gate \u2014 external agents can request any action within nominal scope without manifest enforcement, with deviations only logged", "Allowing the same cross-org token to authenticate against multiple resource servers because audience validation is absent or uses a wildcard aud claim \u2014 enables lateral movement after a single successful cross-org authentication", "Registering trust anchors in a shared allowlist without a documented vetting process \u2014 allows unvetted external IdPs to gain trust anchor status without security review", "Logging cross-org authentication events without the trust_anchor_used field \u2014 audit records cannot confirm which trust anchor was used and cannot detect trust anchor substitution attacks after the fact" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-04", "layer": "IF", "plane": "data", "name": "DID-Based Cryptographic Agent Identity", "plain": "Governs the use of W3C Decentralized Identifiers for AI agents that must authenticate across organizational boundaries where no mutually trusted central identity provider exists.", "threat": { "tags": [ "federation-bypass", "identity-spoofing" ], "desc": "In cross-organizational scenarios where no single IdP is trusted by both parties, the absence of a cryptographic identity mechanism creates an authentication vacuum. Without DID-based identity, organizations must either stand up a new shared IdP (operationally complex and a new single point of failure), use email or API key exchange (unverifiable at scale), or deny the federation entirely. An attacker in this gap can present fabricated organizational credentials that cannot be cryptographically verified. DID resolves this by allowing each organization to anchor agent identities in its own DNS (DID:Web) or as self-contained key material (DID:Key), with verification that does not require either party to trust the other's IdP." }, "standard": [ { "id": "w3c_did", "section": "\u00a74\u2013\u00a75", "title": "DID documents \u2014 data model and core properties (verification methods, services)" }, { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "FAL assurance vocabulary applied by analogy to decentralized identity" }, { "id": "openid", "section": "SIOPv2", "title": "Self-Issued OpenID Provider v2 \u2014 DID-verified self-issued assertions" } ], "sources": [ { "id": "w3c_did_v1_0", "title": "W3C Decentralized Identifiers (DID) v1.0", "authority": "World Wide Web Consortium (W3C)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2022-07-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.w3.org/TR/did-core/", "license": "W3C Document License", "status": "current", "flagship": false, "source_id": "w3c_did", "relationship": "implementation_pattern", "rationale": "Establishes W3C Decentralized Identifiers (DID) v1.0 requirements informing the apeiris://identity/controls/IF-04 DID-Based Cryptographic Agent Identity control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-04 DID-Based Cryptographic Agent Identity control.", "reviewed_on": "2026-07-01" }, { "id": "eidas2_reg_2024_1183", "title": "Regulation (EU) 2024/1183 \u2014 eIDAS 2.0", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1183", "published_on": "2024-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401183", "license": "public-domain", "status": "current", "flagship": false, "source_id": "eidas2_2024_1183", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1183 \u2014 eIDAS 2.0 requirements informing the apeiris://identity/controls/IF-04 DID-Based Cryptographic Agent Identity control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IF-04 DID-Based Cryptographic Agent Identity control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IF-04 DID-Based Cryptographic Agent Identity control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Use W3C DID as the federation option for cross-organizational agent authentication where no shared central IdP exists. DID:Web for organizational agent identities (DNS-anchored, revocable, production-proven); DID:Key for ephemeral agents (self-contained, no external resolution required). Workload identity (SPIFFE/SVID, cloud managed identity, mTLS with short-lived certs) remains the preferred default for enterprise cloud-native AI; DID is applied specifically in the no-shared-IdP cross-org case.", "steps": [ "Determine applicability: apply DID only when both conditions are true \u2014 (1) the federation involves two organizations with no shared trusted IdP, and (2) the cross-org interaction requires cryptographic identity verification that a simple API key cannot provide. For cloud-native enterprise AI with a shared enterprise IdP (Azure AD, Okta, AWS IAM), use workload identity federation, not DID.", "Select DID method by use case: DID:Web for organizational AI agents that represent a durable organizational identity (the DID Document is hosted at a well-known URI under the org's DNS-controlled domain \u2014 e.g., did:web:vendor.example.com:agents:procurement-agent). DID:Key for ephemeral task agents (the DID is derived from the agent's temporary key pair, requires no external resolution, and expires with the key).", "Construct the DID Document for organizational agents with required fields: id (the DID), controller (the organization's controlling DID or key), verificationMethod (array of public keys with key ID, type, and public key material), authentication (reference to verification method used for authentication assertions), and service (array of service endpoints including the agent's capability manifest endpoint).", "Implement DID resolution with cache-and-fallback: resolve DID:Web documents via HTTPS GET to the .well-known DID configuration, cache the resolved document for up to 5 minutes to tolerate transient network partition. Cache must not survive beyond the document's TTL or 24 hours, whichever is shorter. If resolution fails and no valid cache exists, deny authentication \u2014 do not fall back to a weaker method.", "Bind agent actions to DID-based proofs: every consequential cross-org agent action must be accompanied by a DID-linked proof (a signature over the action payload using the agent's verification method key). The receiving party verifies the proof against the resolved DID Document before accepting the action.", "Track DID Document versioning: when an agent's verification method keys are rotated, the DID Document must be updated and the new version must be resolvable before the old keys expire. The transition window (old key still valid while new key is being deployed) must not exceed 24 hours." ], "anti_patterns": [ "Defaulting to DID for all enterprise AI agents including those in cloud-native environments with a shared enterprise IdP \u2014 this adds resolution complexity and operational burden without security benefit; workload identity is the correct pattern for shared-IdP environments.", "Using DID:Key for durable organizational agent identities \u2014 DID:Key encodes the public key directly in the DID and cannot be revoked; use DID:Web for any agent identity that must support key rotation and revocation.", "Treating DID resolution failure as a fallback signal to use weaker authentication \u2014 authentication must fail closed; a failed DID resolution must deny access, not trigger a credential downgrade." ] }, "validation": { "design_check": [ "Confirm that DID is applied only in the documented no-shared-IdP cross-org scenarios and that workload identity is used for all cloud-native enterprise scenarios with a shared IdP [ref:w3c_did_v1_0].", "Verify DID Document structure for organizational agents: required fields (id, controller, verificationMethod, authentication, service) must all be present and populated [ref:w3c_did_v1_0].", "Inspect DID resolution implementation: confirm cache TTL does not exceed 24 hours and that resolution failure results in authentication denial, not fallback to weaker methods [ref:nist_800_63_4]." ], "runtime_test": [ "Resolve a DID:Web document and verify the returned document matches the expected schema with all required fields; then take the DID:Web endpoint offline and confirm that authentication using the cached document succeeds within TTL but fails after TTL expiry [ref:w3c_did_v1_0].", "Attempt to authenticate using a DID:Key that has been removed from the organizational DID:Web document; confirm the verifying party rejects the authentication attempt [ref:w3c_did_v1_0].", "Submit a consequential cross-org action with a missing or invalid DID-linked proof; confirm the receiving service rejects the action before processing [ref:nist_800_63_4]." ], "evidence": [ "identity:did-applicability-decision \u2014 documented decision record for each cross-org federation relationship specifying why DID was selected over workload identity or other methods [unverified]", "identity:did-document-inventory \u2014 inventory of organizational agent DID Documents with controller, verification methods, and key rotation schedule for each [unverified]", "identity:did-resolution-config \u2014 resolver configuration showing cache TTL settings and fail-closed behavior on resolution failure [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "DID is an additional federation option, not a replacement for workload identity. Implement DID:Web for organizational agents in no-shared-IdP cross-org contexts; keep workload identity (SPIFFE, managed identity, mTLS) as the default for everything else. The implementation complexity of DID is only justified when it solves a real problem.", "actions": [ "Document each deployment's IdP landscape to determine which cross-org relationships lack a shared trusted IdP and therefore qualify for DID", "Implement DID:Web document hosting under the organization's own DNS-controlled domain with a documented key rotation procedure", "Implement DID resolution with fail-closed semantics and short cache TTL" ], "failure_signals": [ "DID is being deployed for cloud-native workloads that already have workload identity available \u2014 unnecessary complexity with no security benefit", "DID:Key is used for organizational agent identities that must persist beyond a single task \u2014 cannot be revoked" ] }, "security_architect": { "summary": "DID:Web is the pragmatic cross-org federation option when no shared IdP exists. The architecture must define precisely when DID applies, not leave it as a general-purpose identity option that might be applied inconsistently.", "actions": [ "Define the decision criteria for DID vs. workload identity vs. OIDC federation in the identity architecture documentation \u2014 these criteria must be specific enough to be applied without case-by-case security review", "Design the DID Document update and key rotation process as an operational workflow with defined SLAs to prevent authentication outages during key rotation", "Review the blast radius of a compromised organizational agent DID:Web domain \u2014 what actions could an attacker take by substituting a malicious DID Document?" ], "failure_signals": [ "No defined criteria distinguishing when to use DID vs. workload identity \u2014 each implementation decides independently", "Key rotation SLA not defined \u2014 a compromised verification method key has no defined response timeline" ] }, "legal_counsel": { "summary": "eIDAS 2.0's European Digital Identity Wallet framework (Art. 5a) accommodates decentralized, cryptographically verifiable credentials, giving DID-based identity a plausible recognition pathway in EU contexts. For EU-regulated cross-org federation, confirm whether the DID method and controller organization meet applicable eIDAS 2.0 requirements before relying on DID for regulated access.", "actions": [ "Review whether the planned DID deployment for EU-context cross-org federation must align with eIDAS 2.0 requirements for electronic identification means and the EUDI Wallet framework (Art. 5a)", "Confirm that the DID controller organization's legal identity is traceable and that the DID Document hosting domain is under verifiable organizational control", "Assess whether DID-based authentication satisfies the authentication assurance level required by applicable regulations for the access being granted" ], "failure_signals": [ "DID used in EU-regulated contexts without assessment of whether the method meets eIDAS 2.0 recognition requirements", "DID Document hosted on a domain that is not verifiably controlled by the claiming organization" ] }, "grc_auditor": { "summary": "DID-based authentication introduces novel audit requirements: the DID Document is the identity record, and its version history is the audit trail for key changes. Auditors must confirm DID Document change history is retained and traceable.", "actions": [ "Confirm that DID Document versioning history is retained and that each key rotation event is logged with the old key reference, new key reference, and rotation timestamp", "Verify that the applicability decision for DID (documented in evidence) was reviewed against the criteria in IF-04 and approved by the security architecture function", "Sample 2-3 cross-org DID-based authentication events and trace the DID resolution to the current DID Document to confirm the resolved document matches what was in use at the time of the event" ], "metrics": [ "Number of organizational agent DID Documents with overdue key rotation (past defined rotation schedule)", "Number of DID resolution failures resulting in authentication denials (operational baseline)" ], "failure_signals": [ "DID Document version history is not retained \u2014 cannot reconstruct what keys were active during a past authentication event", "Applicability decision for DID not documented \u2014 cannot confirm the selection was deliberate rather than default" ] }, "it_operations": { "summary": "DID:Web document hosting and key rotation are operational concerns. The DID Document endpoint must be available and correctly served. Key rotation must be coordinated to prevent authentication outages.", "actions": [ "Monitor DID Document endpoint availability and alert on any HTTP non-200 response \u2014 a DID:Web outage will cause all cross-org authentication using that DID to fail", "Implement key rotation as a pre-planned operational procedure with a defined overlap window (new key active before old key expires) and rollback plan", "Test DID resolution cache behavior: confirm that a DID:Web endpoint outage within cache TTL does not cause authentication failures for currently-cached resolutions" ], "failure_signals": [ "DID Document endpoint has no uptime monitoring \u2014 outages are discovered when cross-org authentication failures begin", "Key rotation procedure requires manual steps that have no documented runbook \u2014 rotation outages are likely" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "DID is emerging in enterprise AI federation. Most organizations have not yet needed it because cross-org federation has been handled by bilateral OIDC agreements. As AI agent networks expand beyond org boundaries with no shared IdP, DID becomes necessary. Achieving 'defined' requires documented applicability criteria, DID Document hosting infrastructure, and key rotation procedures." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "federated-enterprise", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "IAM Team", "Platform Engineering", "Enterprise Architecture" ], "frameworks": [ { "framework": "w3c_did", "requirement_id": "\u00a74\u2013\u00a75", "fit": "direct", "rationale": "W3C DID Core defines DID documents in \u00a74\u2013\u00a75 (data model, verification methods and relationships, service endpoints), DID resolution in \u00a77, and DID method requirements in \u00a78 \u2014 the constructs IF-04 directly implements.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "partial", "rationale": "SP 800-63C-4 \u00a72's FAL model provides the assurance vocabulary for evaluating federated assertions; 63C does not address decentralized identity directly, so IF-04 maps DID-based cross-org authentication onto FAL levels by analogy.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eidas2", "requirement_id": "Art. 5a", "fit": "adjacent", "rationale": "eIDAS 2.0 Article 5a establishes the European Digital Identity Wallet, whose architecture accommodates decentralized, cryptographically verifiable credentials compatible with DID-based identity. IF-04 notes this alignment for EU-context deployments; the full eIDAS 2.0 qualified attestation requirements are addressed in IF-05.", "source_version": "2024/1183", "reviewed_on": "2026-07-02", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ping_identity", "requirement_id": "PingOne Credentials \u2014 W3C Verifiable Credentials / DID", "rationale": "PingOne Credentials issues cryptographically verifiable credentials conformant with the W3C Verifiable Credentials data model, enabling DID-anchored attestations for agent identity in cross-domain interactions. These credentials are cryptographically signed by the issuer, tamper-evident, and can be selectively disclosed, providing a DID-compatible identity binding mechanism for AI agents operating across organizational boundaries.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "PingOne Credentials issues W3C VC/DID-conformant verifiable credentials for cross-domain agent identity - the DID-based mechanism the control governs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud WIF \u2014 External OIDC Verification", "rationale": "Google Cloud Workload Identity Federation validates external OIDC identity tokens against the issuer's JWKS endpoint, enabling verification of cryptographically signed identity claims that are compatible with DID-based identity patterns. WIF attribute conditions allow mapping external DID-bound identity attributes to Google Cloud IAM bindings.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "GCP WIF validates external OIDC tokens via JWKS, a related but distinct federation mechanism the rationale itself calls only DID-compatible.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://identity/controls/IF-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "DID-based identity must be applied only to cross-organizational federation scenarios with no shared central IdP, under a documented applicability decision. DID Documents for organizational agents must conform to W3C DID Core required fields, DID resolution must fail closed on resolution failure (no stale-cache fallback beyond TTL), and all consequential cross-org actions must carry a DID-linked proof verified against the current resolved DID Document.", "evidence_required": [ "did_applicability_decision_record per cross-org federation relationship documenting why DID was selected over workload identity or OIDC federation, with approver identity and date", "did_document_inventory listing each organizational agent DID Document with controller, verification_methods, service endpoints, key_rotation_schedule, and last_updated timestamp", "did_resolution_config showing cache_ttl not exceeding 24 hours and explicit fail-closed behavior (authentication denial) on resolution failure with no stale-cache fallback beyond TTL", "did_proof_verification_log showing DID-linked proof validation result per consequential cross-org action with DID resolved, verification method used, and pass/fail verdict" ], "machine_tests": [ "Cache DID:Web document; take DID:Web endpoint offline; advance clock past cache TTL and attempt authentication \u2192 assert authentication is denied with error=did_resolution_failed (not served from stale cache beyond TTL)", "Attempt authentication using a verification method key that has been removed from the current DID:Web document \u2192 assert verifying party rejects with error=verification_method_not_found", "Submit a consequential cross-org action with DID-linked proof field absent \u2192 assert receiving service rejects with error=did_proof_required before processing the action", "Attempt to register a DID:Key as a durable organizational agent identity where DID:Web is required \u2192 assert identity validation rejects with error=invalid_did_method_for_durable_identity" ], "human_review": [ "Review DID Document versioning records to confirm each key rotation event is logged with old key reference, new key reference, rotation timestamp, and approver identity \u2014 rotation events without audit records cannot be traced", "Assess the applicability decision for each DID deployment to confirm DID was selected only for no-shared-IdP cross-org scenarios and not applied as a general-purpose identity option for cloud-native workloads", "Verify DID:Web Document hosting domains are under verifiable organizational DNS control through evidence such as DNS registrar records or domain ownership certificates for each hosting domain" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Deploying DID for all enterprise AI agents including cloud-native workloads with an available shared enterprise IdP \u2014 adds resolution complexity and operational burden where workload identity already solves the authentication problem", "Using DID:Key for durable organizational agent identities \u2014 DID:Key encodes the public key directly in the DID string and cannot be revoked, making any organizational agent using it irrevocable once deployed", "Treating DID resolution failure as a signal to fall back to a weaker authentication mechanism \u2014 resolution failure must fail closed and deny access, not trigger a credential downgrade to a less-verified method", "Hosting DID:Web documents on a domain not under verifiable organizational DNS control \u2014 a domain takeover attack would allow an adversary to substitute a malicious DID Document with attacker-controlled verification keys", "Failing to define a key rotation transition window with explicit overlap period \u2014 old keys may expire before new keys are resolvable, creating authentication outages that create operational pressure to disable fail-closed behavior" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-05", "layer": "IF", "plane": "data", "name": "eIDAS 2.0 Qualified Attestation for EU Operations", "plain": "Governs the use of EU Digital Identity Wallets and Qualified Electronic Attestations of Attributes for AI agents operating in EU-regulated contexts requiring cross-border identity recognition.", "threat": { "tags": [ "federation-bypass", "identity-spoofing" ], "desc": "AI agents operating in EU-regulated contexts face an identity recognition problem that is distinct from general cross-org federation: EU public sector services, large private sector providers within eIDAS 2.0 mandatory acceptance scope, and EU financial services under DORA require identity assertions that are legally recognized across EU member states. Without Qualified Electronic Attestations of Attributes (QEAAs) from a qualified trust service provider, an AI agent's identity claims are not legally recognized for regulated access. The risk is not just technical authentication bypass \u2014 it is operating in regulated EU contexts without legally valid identity, creating regulatory exposure for the deploying organization and making the AI agent's actions legally unattributable." }, "standard": [ { "id": "eidas2", "section": "Arts. 45b\u201345h", "title": "Electronic attestations of attributes \u2014 QEAA requirements and recognition (Art. 45d, Annex V)" }, { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a72", "title": "Cross-jurisdiction FAL alignment for EU identity recognition" }, { "id": "w3c_did", "section": "\u00a74\u2013\u00a75", "title": "DID document compatibility with QEAA-based identity" } ], "sources": [ { "id": "eidas2_reg_2024_1183", "title": "Regulation (EU) 2024/1183 \u2014 eIDAS 2.0", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1183", "published_on": "2024-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401183", "license": "public-domain", "status": "current", "flagship": false, "source_id": "eidas2_2024_1183", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1183 \u2014 eIDAS 2.0 requirements informing the apeiris://identity/controls/IF-05 eIDAS 2.0 Qualified Attestation for EU Operations control.", "reviewed_on": "2026-07-01" }, { "id": "w3c_did_v1_0", "title": "W3C Decentralized Identifiers (DID) v1.0", "authority": "World Wide Web Consortium (W3C)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2022-07-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.w3.org/TR/did-core/", "license": "W3C Document License", "status": "current", "flagship": false, "source_id": "w3c_did", "relationship": "implementation_pattern", "rationale": "Establishes W3C Decentralized Identifiers (DID) v1.0 requirements informing the apeiris://identity/controls/IF-05 eIDAS 2.0 Qualified Attestation for EU Operations control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-05 eIDAS 2.0 Qualified Attestation for EU Operations control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IF-05 eIDAS 2.0 Qualified Attestation for EU Operations control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "For AI agents that must authenticate to EU-regulated services within the eIDAS 2.0 mandatory acceptance scope, implement QEAA-based identity using an EU Digital Identity Wallet architecture. QEAAs are issued by qualified trust service providers and carry machine-verifiable attributes without requiring a central lookup. Track implementing act finalization in regulatory-watch.json and update control implementations as EU Digital Identity Wallet technical specifications are published.", "steps": [ "Determine eIDAS 2.0 scope applicability: the QEAA requirement applies to AI agents authenticating to EU public sector services (mandatory under eIDAS 2.0), large private sector providers within the mandatory acceptance scope (specific sectors to be defined by implementing acts), and EU financial services under DORA. For agents outside this scope, eIDAS 2.0 QEAA is not required \u2014 apply IF-03 or IF-04.", "Identify the qualified trust service providers (QTSPs) that will issue QEAAs for the organization's AI agents. QTSPs must be listed on an EU member state's trusted list (national TSL). Verify QTSP status via the EU Trusted List Browser before relying on any QTSP for QEAA issuance. Non-qualified trust services cannot issue valid QEAAs.", "Design the QEAA attribute structure for AI agent identities: QEAAs must carry the attributes relevant to the regulated context (agent operator identity, agent capability authorization, agent's authorized action scope for the regulated service, delegation chain back to a natural or legal person). Work with the QTSP to define the attribute schema appropriate for the regulated service's requirements.", "Implement QEAA presentation flow: AI agents present QEAAs to regulated services using the EU Digital Identity Wallet interaction protocol. The receiving service verifies the QEAA signature against the issuing QTSP's key (resolvable from the EU Trusted List) without requiring a central lookup. The QEAA must be current \u2014 expired QEAAs are not valid even with a valid signature.", "Track implementing act status in regulatory-watch.json: the EU Digital Identity Wallet technical specification and implementing acts for specific sectors are being finalized through 2025-2027. Review and update IF-05 implementation guidance whenever a relevant implementing act is published. Mark this control as 'implementation-contingent-on-implementing-acts' in the deployment checklist for affected deployments.", "For cross-border recognition: QEAAs issued by a QTSP in one EU member state must be accepted by services in all other EU member states (mutual recognition under eIDAS 2.0). Verify that the receiving service's QEAA validation logic queries the unified EU Trusted List, not just the domestic member state TSL, to confirm recognition across borders." ], "anti_patterns": [ "Applying eIDAS 2.0 QEAA requirements to all AI agent deployments regardless of whether they interact with EU-regulated services within mandatory acceptance scope \u2014 this adds significant operational complexity without regulatory necessity.", "Relying on self-asserted qualified trust service status without verifying the QTSP against the official EU national Trusted List \u2014 non-listed QTSPs cannot issue legally recognized QEAAs regardless of their technical capabilities.", "Treating the implementing acts as finalized before they are published \u2014 the EU Digital Identity Wallet architecture includes elements still being specified; implementing controls based on draft implementing acts creates update burden as acts are finalized." ] }, "validation": { "design_check": [ "Confirm the scope applicability assessment is documented: which of the organization's AI agent deployments interact with EU services within eIDAS 2.0 mandatory acceptance scope [ref:eidas2_reg_2024_1183].", "Verify that each QTSP used for QEAA issuance is listed on an EU member state national Trusted List and that the listing is current (TSLs are updated periodically) [ref:eidas2_reg_2024_1183].", "Confirm regulatory-watch.json includes tracking entries for eIDAS 2.0 implementing acts relevant to the organization's deployment sectors [ref:eidas2_reg_2024_1183]." ], "runtime_test": [ "Present a QEAA issued by a qualified trust service provider and verify that the receiving service validates the QEAA signature against the EU Trusted List without requiring a central lookup [ref:eidas2_reg_2024_1183].", "Present an expired QEAA (valid signature, past validity period) and confirm the receiving service rejects the QEAA on expiry grounds [ref:eidas2_reg_2024_1183].", "Present a QEAA from a QTSP in a different EU member state and confirm cross-border recognition via the unified EU Trusted List [ref:eidas2_reg_2024_1183]." ], "evidence": [ "identity:eidas2-scope-assessment \u2014 documented assessment identifying which AI agent deployments fall within eIDAS 2.0 mandatory acceptance scope and require QEAA-based identity [unverified]", "identity:qtsp-verification-records \u2014 records confirming each QTSP's listing on the applicable EU national Trusted List with verification date [unverified]", "identity:regulatory-watch-eidas \u2014 regulatory-watch.json entries tracking eIDAS 2.0 implementing act publication status and scheduled control review dates [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "eIDAS 2.0 QEAA integration requires implementing the EU Digital Identity Wallet presentation protocol and QEAA validation against the EU Trusted List. This is distinct from standard OIDC or DID flows and requires specific library support that is actively being standardized. Engage with the QTSP early \u2014 QEAA issuance requires a formal engagement with a listed trust service provider.", "actions": [ "Identify and engage qualified trust service providers (from the EU national Trusted List) for QEAA issuance before building the integration", "Implement QEAA validation logic that queries the EU Trusted List for QTSP key material \u2014 do not hardcode QTSP keys", "Subscribe to the relevant EU member state national Trusted List update notifications to detect QTSP status changes" ], "failure_signals": [ "QEAA validation hardcodes QTSP public keys rather than resolving from the EU Trusted List \u2014 fails to detect QTSP revocation or key rotation", "QEAA issuance relies on a non-listed provider that self-describes as qualified" ] }, "security_architect": { "summary": "eIDAS 2.0 QEAA architecture is still being finalized through implementing acts. The architecture for EU-context AI agent identity must be designed to accommodate implementing act updates without requiring full re-architecture. Design for implementing act versioning from the start.", "actions": [ "Design the QEAA validation component as a pluggable module that can be updated as implementing acts finalize the technical specification", "Define the fallback authentication path for EU-context agents when QEAA validation fails \u2014 this must be fail-closed for regulated service access", "Establish a regulatory watch process with defined review triggers for eIDAS 2.0 implementing act publications" ], "failure_signals": [ "QEAA validation is tightly coupled to other authentication logic \u2014 implementing act changes require significant re-engineering", "No defined fallback behavior for QEAA validation failure \u2014 uncertainty about whether to deny or downgrade" ] }, "legal_counsel": { "summary": "eIDAS 2.0 creates binding legal obligations for organizations within the mandatory acceptance scope. Legal review must confirm which of the organization's services fall within scope and whether the planned QEAA implementation satisfies the legal recognition requirements for each regulated service type.", "actions": [ "Confirm with EU counsel whether the organization's services fall within the eIDAS 2.0 mandatory acceptance scope for any member state's national implementing law", "Verify that the QTSP engagement agreements clearly specify the attributes to be attested in QEAAs and the QTSP's liability for incorrect or revoked attestations", "Monitor implementing act publications to identify compliance deadlines that may affect AI agent deployments" ], "failure_signals": [ "EU-context AI agent deployments in regulated services without a formal eIDAS 2.0 scope assessment conducted with EU legal counsel", "QTSP agreements do not specify attribute accuracy liability" ] }, "grc_auditor": { "summary": "eIDAS 2.0 compliance requires demonstrating that QEAA-required deployments use properly qualified trust services and that QEAAs are current, valid, and issued by listed QTSPs. The scope assessment and QTSP verification records are the primary audit artifacts.", "actions": [ "Obtain and review the eIDAS 2.0 scope applicability assessment to confirm it covers all current AI agent deployments in EU contexts", "Verify QTSP listings: pull the current national Trusted List for each QTSP used and confirm their qualified status is current and unrevoked", "Confirm regulatory-watch.json is being actively maintained with eIDAS 2.0 implementing act tracking" ], "metrics": [ "Number of EU-context AI agent deployments without a completed eIDAS 2.0 scope assessment (target: zero)", "Number of QTSPs used whose Trusted List listing has not been reverified in the last 90 days (target: zero)" ], "failure_signals": [ "No scope assessment exists for EU-context AI agent deployments", "QTSPs used have not been reverified against the current national Trusted List" ] }, "it_operations": { "summary": "QEAA validity has a time dimension \u2014 QEAAs expire and must be renewed. Operations must monitor QEAA expiry for AI agents operating in EU-regulated contexts and ensure renewal processes are in place before expiry causes access failures.", "actions": [ "Implement QEAA expiry monitoring and alert when any agent's QEAA is within 30 days of expiry", "Test QEAA renewal workflow end-to-end before any agent's QEAA approaches expiry in production", "Maintain a contacts list for each QTSP covering renewal request procedures and emergency re-issuance contacts" ], "failure_signals": [ "No QEAA expiry monitoring \u2014 EU-context AI agents lose access when QEAAs expire without warning", "QEAA renewal process requires manual QTSP engagement with no defined SLA \u2014 renewal outages are likely" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "eIDAS 2.0 QEAA for AI agents is an emerging requirement. Most organizations have not yet assessed whether their EU-context AI agent deployments fall within mandatory acceptance scope. Achieving 'defined' requires a scope assessment, QTSP engagement for in-scope deployments, and regulatory watch tracking. Full 'managed' maturity is contingent on implementing act finalization." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "IAM Team", "Legal/Compliance", "Enterprise Architecture" ], "frameworks": [ { "framework": "eidas2", "requirement_id": "Arts. 45b\u201345h", "fit": "direct", "rationale": "eIDAS 2.0 Articles 45b\u201345h define the electronic attestation of attributes framework; qualified electronic attestations of attributes (QEAA) are governed by Article 45d and Annex V. IF-05 directly implements this framework for EU-context AI agent authentication.", "source_version": "2024/1183", "reviewed_on": "2026-07-02", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a72", "fit": "adjacent", "rationale": "SP 800-63C-4 \u00a72's FAL framework provides a complementary assurance level model for evaluating how eIDAS 2.0 QEAA-based assertions map to FAL levels for cross-jurisdiction deployments involving both US and EU regulatory contexts.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_did", "requirement_id": "\u00a74\u2013\u00a75", "fit": "adjacent", "rationale": "W3C DID Core's DID document model (\u00a74\u2013\u00a75) is architecturally compatible with eIDAS 2.0 QEAA presentation flows and may underlie EU Digital Identity Wallet implementations; the final alignment depends on implementing act text.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "ping_identity", "requirement_id": "PingOne Credentials \u2014 eIDAS 2.0-aligned verifiable credentials", "rationale": "PingOne Credentials supports issuance of cryptographically verifiable credentials conformant with eIDAS 2.0 requirements for qualified electronic attestations. The PingOne Advanced Identity Cloud platform has been designed for compliance with EU digital identity regulations, making it the prescribed Ping Identity path for enterprises requiring eIDAS 2.0 qualified attestation for AI agent identities operating in EU-regulated contexts.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "PingOne issues eIDAS 2.0-aligned verifiable credentials, but alignment is not the QTSP Trusted-List qualified-attestation status the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IF-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "AI agents authenticating to EU-regulated services within the eIDAS 2.0 mandatory acceptance scope must present Qualified Electronic Attestations of Attributes issued by a QTSP currently listed on an EU member state national Trusted List. Receiving services must validate QEAA signatures against the unified EU Trusted List, reject expired QEAAs regardless of signature validity, and accept cross-border QEAAs through unified Trusted List lookup rather than domestic-only TSL.", "evidence_required": [ "eidas2_scope_assessment documenting which AI agent deployments fall within eIDAS 2.0 mandatory acceptance scope, with justification per deployment and review date by EU legal counsel", "qtsp_verification_records confirming each QTSP's listing on the applicable EU national Trusted List with verification date, listing URL, and next-scheduled reverification date", "regulatory_watch_entries in regulatory-watch.json tracking eIDAS 2.0 implementing act publication status, relevant-to-deployment flags, and scheduled control review dates", "qeaa_validation_test_results showing expired QEAA rejection and cross-border recognition via unified EU Trusted List for each QTSP used" ], "machine_tests": [ "Present QEAA issued by QTSP listed on EU national Trusted List \u2192 assert receiving service validates signature via EU Trusted List resolution without requiring direct QTSP key lookup", "Present expired QEAA with valid signature and validity_period in the past \u2192 assert receiving service rejects with error=qeaa_validity_period_expired", "Present QEAA from QTSP listed on one member state's national Trusted List to a cross-border service \u2192 assert receiving service accepts via unified EU Trusted List cross-border recognition, not domestic-only TSL", "Present QEAA issued by a provider not listed on any EU member state national Trusted List \u2192 assert receiving service rejects with error=untrusted_qualified_trust_service" ], "human_review": [ "Review the eIDAS 2.0 scope applicability assessment with EU legal counsel to confirm in-scope determinations cover all current AI agent deployments interacting with EU-regulated services and reflect the latest implementing act status", "Verify QTSP engagement agreements specify attribute accuracy liability, mandatory notification on QTSP status changes on the Trusted List, and emergency re-issuance procedures", "Assess regulatory-watch.json entries for eIDAS 2.0 implementing acts to confirm entries are complete, have assigned owners, scheduled review dates, and reflect the current published status of each tracked act" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Applying eIDAS 2.0 QEAA requirements to all AI agent deployments regardless of mandatory acceptance scope \u2014 creates significant operational burden for agents not interacting with in-scope EU regulated services", "Relying on a provider's self-assertion of qualified trust service status without verifying the QTSP against the official EU national Trusted List \u2014 non-listed providers cannot issue legally recognized QEAAs regardless of technical capability", "Hardcoding QTSP public keys for QEAA validation rather than resolving from the EU Trusted List \u2014 fails to detect QTSP revocation or key rotation, causing silent validation failures or continued trust in a revoked QTSP", "Implementing QEAA validation against a single member state's national TSL rather than the unified EU Trusted List \u2014 breaks cross-border recognition when the issuing QTSP is listed only on a different member state's TSL", "Operating EU-regulated AI agents in mandatory acceptance scope services without a documented scope assessment reviewed by EU legal counsel \u2014 creates regulatory exposure for operating without legally valid identity in regulated contexts" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-06", "layer": "IF", "plane": "data", "name": "Token Validation and Binding", "plain": "Requires cryptographic validation of identity tokens at every service an AI agent accesses, with client-bound tokens to prevent replay and theft, and prohibition on token forwarding without re-validation.", "threat": { "tags": [ "credential-compromise", "federation-bypass", "lateral-movement" ], "desc": "Token theft and replay are the primary post-authentication attack vectors against AI agent federation. A stolen access token without client binding can be used from any client to access any resource the token's scope covers. Token forwarding without re-validation allows a compromised upstream service to pass a token it received to a downstream service, effectively laundering credentials across the service graph. Validating only at session initiation \u2014 not at each service boundary \u2014 means that a token that was valid at authentication time may be used after scope changes, revocation, or expiry to access services that were not the original target." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a73.15\u2013\u00a73.16", "title": "Bound authenticators \u2014 binding assertions to authenticators" }, { "id": "openid", "section": "RFC 9396 \u00a72", "title": "authorization_details \u2014 structured authorization validated per service" }, { "id": "ietf_rfc_9449_dpop", "section": "RFC 9449", "title": "OAuth 2.0 Demonstrating Proof of Possession (DPoP)" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 3", "title": "Per-request authorization verification at each service boundary" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-06 Token Validation and Binding control.", "reviewed_on": "2026-07-01" }, { "id": "rfc_9396", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "Internet Engineering Task Force (IETF)", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "RFC 9396", "published_on": "2023-05-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/IF-06 Token Validation and Binding control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IF-06 Token Validation and Binding control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IF-06 Token Validation and Binding control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IF-06 Token Validation and Binding control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement token validation at every service boundary, not just at session initiation. Bind tokens to the requesting client using DPoP (RFC 9449) so that a stolen token cannot be used from a different client. Prohibit token forwarding to downstream services without explicit token exchange (RFC 8693).", "steps": [ "Implement per-service token validation middleware in every service that receives AI agent requests. Validate in sequence: (1) cryptographic signature against current JWKS, (2) issuer (iss) against trust anchor registry, (3) audience (aud) must include this service's URI, (4) expiry (exp) must be in the future with no clock skew tolerance beyond 30 seconds, (5) scope or authorization_details must authorize the specific requested action, (6) cnf claim if DPoP binding is required.", "Implement DPoP binding (RFC 9449) for consequential action tokens: the authorization server includes a cnf claim in the access token containing the hash of the client's public key. The client must present a DPoP proof header on each request \u2014 a JWT signed with the client's private key covering the HTTP method, URL, and a one-time nonce. The resource server validates the DPoP proof against the cnf claim. A token without a matching DPoP proof is rejected even if the signature is valid.", "Prohibit token forwarding: no service may take an access token it received from an AI agent client and forward it as-is to a downstream service. Services that need to call downstream services on behalf of an agent request must either use their own service identity (for service-to-service calls) or initiate a token exchange (RFC 8693) to obtain a new token scoped to the downstream service. Implement detection for token forwarding at the authorization server by tracking the azp and cnf claims across the call graph.", "Implement scope validation at action granularity: the scope or authorization_details in the token must authorize the specific action being requested, not just resource-level access. A token with scope 'read:reports' must not authorize write operations even if the endpoint accepts both. Implement action-level authorization checks in resource server middleware, not just scope presence checks.", "Handle token revocation checking: for consequential action paths, implement an introspection endpoint query (RFC 7662) or a local revocation cache with a short TTL (max 60 seconds) to detect tokens that have been revoked since issuance. Accepting only the expiry time without checking revocation means a revoked token remains usable until it expires.", "Log every token validation event at consequential action endpoints: record the token's jti (JWT ID) or hash, the validation result for each check (signature, issuer, audience, expiry, scope, DPoP), and the resulting action verdict (permit/deny). These logs are the primary evidence for IF-08 audit reconciliation." ], "anti_patterns": [ "Validating tokens only at the API gateway or entry point and trusting all internal service calls without re-validation \u2014 this means a compromised internal service can make unauthorized requests to any downstream service without a valid token.", "Using bearer tokens without DPoP binding for consequential action paths \u2014 a stolen bearer token can be replayed from any client until it expires, and short lifetimes alone do not prevent replay within the token's validity window.", "Forwarding received tokens to downstream services rather than using token exchange \u2014 this spreads credential exposure across the service graph and makes revocation ineffective since the same token may be in use at multiple services." ] }, "validation": { "design_check": [ "Confirm that every internal service that receives AI agent requests has token validation middleware, not just the API gateway or edge proxy [ref:nist_sp_800_207].", "Verify that DPoP binding is implemented for consequential action tokens: the authorization server issues tokens with cnf claims, and resource servers validate DPoP proof headers [ref:nist_800_63_4].", "Confirm the token forwarding prohibition is implemented: inspect service-to-service call patterns to verify downstream calls use service identity or token exchange, not forwarded agent tokens [ref:nist_sp_800_207]." ], "runtime_test": [ "Obtain a valid access token for service A and attempt to use it against service B (different URI in aud claim); confirm service B rejects with audience mismatch [ref:nist_800_63_4].", "Obtain a DPoP-bound access token; strip the DPoP proof header and attempt to use the token as a bare bearer token; confirm the resource server rejects the request [ref:nist_800_63_4].", "Revoke an access token via the authorization server and within the revocation propagation window, attempt to use the token for a consequential action; confirm the resource server queries introspection and rejects the revoked token [ref:nist_sp_800_207]." ], "evidence": [ "identity:token-validation-middleware-config \u2014 configuration or code reference showing per-service token validation middleware with all required checks implemented [unverified]", "identity:dpop-binding-config \u2014 authorization server configuration showing cnf claim issuance and resource server DPoP proof validation configuration for consequential action paths [unverified]", "identity:token-validation-audit-log \u2014 sample of token validation audit log entries showing jti reference, each validation check result, and action verdict per request [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Token validation at every service boundary is a non-negotiable requirement for zero-trust AI agent federation. Per-service validation middleware must be treated as infrastructure, not optional middleware. DPoP binding implementation requires coordination between the authorization server team and each resource server team.", "actions": [ "Implement token validation as a shared middleware library that all services import \u2014 not service-specific implementations that can diverge", "Coordinate DPoP implementation between authorization server (cnf claim issuance) and resource servers (DPoP proof validation) before enabling for any consequential action path", "Implement RFC 7662 introspection or a short-TTL revocation cache in consequential action resource servers" ], "failure_signals": [ "Different services implement token validation differently \u2014 some validate audience, some do not; inconsistent enforcement creates bypass paths", "No introspection or revocation cache in consequential action paths \u2014 revoked tokens remain usable until expiry" ] }, "security_architect": { "summary": "Token validation architecture must treat every service boundary as a trust boundary. The SPOF is assuming that gateway-level validation covers all internal service calls. DPoP binding closes the bearer token replay attack surface. Token forwarding prohibition prevents credential laundering across the service graph.", "actions": [ "Map all service-to-service call paths for AI agent requests to identify where tokens flow internally and confirm each boundary has validation", "Define the DPoP binding requirement threshold: which action types require DPoP vs. which can use standard bearer tokens", "Design a token forwarding detection mechanism using jti tracking or call graph analysis" ], "failure_signals": [ "Service mesh or API gateway configuration shows internal service traffic bypassing authentication middleware", "Token jti values appear across multiple services in a pattern consistent with forwarding rather than legitimate token exchange" ] }, "legal_counsel": { "summary": "Token validation logging creates the evidence trail needed to prove or refute claims about what an AI agent was authorized to do at a specific moment. The jti-level audit log is critical for incident response and regulatory inquiry.", "actions": [ "Confirm that token validation audit logs are retained for a period consistent with regulatory requirements applicable to the most sensitive services (minimum 1 year for most, longer for financial services)", "Verify that the token validation log includes enough information to reconstruct the authorization state at any past point \u2014 not just whether access was granted, but what scope and authorization_details were presented", "Review incident response procedures to confirm token validation logs are included in the evidence collection protocol" ], "failure_signals": [ "Token validation logs are not retained beyond system defaults \u2014 critical evidence for incident investigation is not available", "Log entries record access granted/denied but not the scope or authorization_details that were evaluated" ] }, "grc_auditor": { "summary": "Token validation at every service boundary is the primary defense against post-authentication lateral movement. Auditors should verify that the validation implementation covers all services, not just entry-point services, and that DPoP binding is in use for consequential action paths.", "actions": [ "Request a service inventory with token validation middleware status and confirm each service requiring AI agent access has validation implemented", "Confirm DPoP binding is in use for the consequential action paths identified in the risk assessment \u2014 not just described as a future requirement", "Sample token validation audit logs from 3-5 consequential action events and verify each log entry contains jti, all validation check results, and action verdict" ], "metrics": [ "Percentage of services with AI agent access that have per-service token validation middleware (target: 100%)", "Percentage of consequential action paths with DPoP binding enabled (target: 100%)" ], "failure_signals": [ "Service inventory shows services receiving AI agent tokens without token validation middleware", "DPoP binding listed as planned but not implemented for consequential action paths" ] }, "it_operations": { "summary": "DPoP proof validation requires tight clock synchronization between clients and resource servers. Token validation at every service boundary adds latency; the shared middleware approach is critical to keeping this overhead manageable. Revocation cache TTL is an operational tuning parameter.", "actions": [ "Ensure NTP synchronization across all services that validate DPoP proofs \u2014 clock skew above 30 seconds will cause false rejections", "Monitor token validation middleware performance impact across services; set latency budgets before rollout", "Configure revocation cache TTL to balance security (short = faster revocation propagation) against load on the introspection endpoint (short = more queries)" ], "failure_signals": [ "DPoP proof validation failures spike during NTP sync events \u2014 clock skew tolerance is too tight or NTP is unreliable", "Revocation introspection endpoint is a bottleneck \u2014 no caching or rate limiting in place" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations validate tokens only at API gateway entry points. Per-service validation, DPoP binding, and token forwarding prohibition are advanced practices. Achieving 'defined' requires shared validation middleware deployed across all services, DPoP implementation for consequential action paths, and RFC 7662 introspection or revocation cache." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "cloud-native", "universal-enterprise", "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "IAM Team", "Platform Engineering", "API Security" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a73.15\u2013\u00a73.16", "fit": "direct", "rationale": "SP 800-63C-4 \u00a73.15\u2013\u00a73.16 define bound authenticators, which bind assertions to an authenticator the subscriber controls so a captured assertion cannot be replayed. IF-06 implements the same binding property for agent tokens through DPoP and per-service validation.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396 \u00a72", "fit": "direct", "rationale": "RFC 9396 authorization_details gives each service a structured authorization payload to validate against policy at its own boundary, supporting per-service validation of what the token actually authorizes.", "source_version": "RFC 9396", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9449 (DPoP)", "fit": "direct", "rationale": "RFC 9449 DPoP binds access tokens to the client's key pair so a stolen token cannot be replayed by a different client \u2014 the client-binding mechanism IF-06 requires for consequential action paths.", "source_version": "RFC 9449", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 3", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 3 requires per-session, per-request authorization at each service boundary. IF-06's per-service token validation directly implements this principle for AI agent access.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta OAuth \u2014 DPoP token binding (RFC 9449)", "rationale": "Okta supports DPoP (Demonstration of Proof of Possession, RFC 9449) which cryptographically ties access tokens to the client's key pair by requiring the client to sign each request with a private key whose public key is embedded in the DPoP proof JWT. This prevents stolen tokens from being replayed by a different client, providing hardware- or software-bound token validation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta DPoP (RFC 9449) cryptographically binds tokens to the client key pair with per-request signatures - the client-bound anti-replay binding required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Service authentication (token-based authentication)", "fit": "partial", "rationale": "Token-based authentication with expiration/refresh underlies token validation. Partial: doc does not prescribe token binding/validation semantics for federation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IF-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every service receiving AI agent requests must validate access tokens using a complete six-step blocking sequence (signature, issuer, audience, expiry within 30-second clock skew, scope/authorization_details, and DPoP cnf claim for consequential paths), with no service permitted to forward received agent tokens to downstream services without token exchange, and revocation status checked within a 60-second cache TTL for consequential action endpoints.", "evidence_required": [ "token_validation_middleware_inventory mapping each service that receives AI agent requests to its validation middleware deployment status, confirming per-service (not gateway-only) coverage", "dpop_binding_config showing authorization server cnf claim issuance configuration and resource server DPoP-Proof header validation for all consequential action paths", "token_validation_audit_log sample showing jti reference, validation result for each of the six checks, and permit/deny verdict per request at consequential action endpoints", "service_call_graph_review confirming no service-to-service call pattern passes a received agent token forward without explicit token exchange via RFC 8693" ], "machine_tests": [ "Submit valid access token with aud=service-A to service-B (different resource server URI) \u2192 assert service-B returns 401 with error=audience_mismatch", "Obtain DPoP-bound access token with cnf claim; strip DPoP-Proof header and submit as bare bearer token to resource server \u2192 assert resource server returns 401 with error=dpop_proof_required", "Revoke access token at authorization server; within 60-second revocation cache TTL submit revoked token to consequential action endpoint \u2192 assert resource server queries introspection and returns 401 with error=token_revoked", "Submit access token with scope=read:reports to a write endpoint on the same resource \u2192 assert resource server returns 403 with error=insufficient_scope (scope check at action granularity, not just scope presence)" ], "human_review": [ "Review service architecture map to confirm all internal service boundaries receiving AI agent tokens have per-service token validation middleware deployed, not just the API gateway entry points", "Assess consequential action paths against the DPoP binding requirement: confirm all paths identified in the risk assessment have DPoP binding implemented, not described as planned future work", "Verify token validation audit log retention period is consistent with the most stringent regulatory requirements applicable to any service in the portfolio \u2014 minimum 1 year for most regulated industries" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Validating tokens only at the API gateway or edge proxy and trusting all downstream internal service calls \u2014 a compromised internal service can make unauthorized requests to any reachable downstream service without presenting a valid token", "Deploying bearer tokens without DPoP binding for consequential action paths \u2014 a stolen bearer token is replayable from any client until it expires, with no cryptographic binding to detect or prevent credential theft and replay", "Forwarding received agent tokens to downstream services instead of using token exchange \u2014 spreads credential exposure across the service graph and makes revocation ineffective since the same token may be in simultaneous use at multiple services", "Performing scope presence checks ('does the token contain scope read:reports?') instead of action-level authorization \u2014 permits write operations on a read-only scoped token when the endpoint accepts multiple HTTP methods", "Setting revocation introspection cache TTL above 60 seconds for consequential action paths \u2014 a revoked token remains usable at all resource servers for the full cache TTL duration after revocation, creating a known unauthorized access window" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-07", "layer": "IF", "plane": "data", "name": "Identity Provider Resilience and Fallback", "plain": "Ensures that identity provider unavailability defaults to deny-by-default access refusal rather than open access, with emergency access handled exclusively through the break-glass procedure.", "threat": { "tags": [ "orphaned-credential", "federation-bypass" ], "desc": "Identity provider availability is a load-bearing dependency: when the IdP is unavailable, the fail-behavior determines whether the system is secure or open. The threat is not IdP unavailability itself \u2014 it is the fail-open configuration that responds to unavailability by granting access anyway, on the assumption that the IdP outage is transient. An adversary who can cause an IdP outage (through DDoS, BGP hijack, or supply chain interference) can trigger the fail-open condition and gain access to resources that would otherwise require authentication. Separately, AI agent workflows that cache tokens beyond expiry and use the expired token when the IdP is unreachable for refresh create an orphaned credential scenario where access persists past its authorized period." }, "standard": [ { "id": "nist_zt", "section": "\u00a73.4.1", "title": "Network requirements to support ZTA \u2014 PDP/PE availability and fail-safe" }, { "id": "nist_800_63", "section": "SP 800-63B-4", "title": "Authenticator lifecycle \u2014 availability and recovery" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Access Management", "title": "Identity resilience and continuity of deny-by-default" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IF-07 Identity Provider Resilience and Fallback control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IF-07 Identity Provider Resilience and Fallback control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IF-07 Identity Provider Resilience and Fallback control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IF-07 Identity Provider Resilience and Fallback control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IF-07 Identity Provider Resilience and Fallback control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Configure all identity-dependent access controls to fail closed: deny access when the IdP is unavailable rather than allowing pass-through. Implement primary/secondary IdP redundancy for operational resilience. Cache valid tokens within their original lifetime only \u2014 never extend beyond expiry. Route emergency access exclusively through the NI-08 break-glass procedure.", "steps": [ "Configure all token validation middleware to fail closed when the IdP's JWKS endpoint, discovery document, or introspection endpoint is unreachable. 'Fail closed' means: return HTTP 503 with a Retry-After header, do not grant access. Do not fall back to a cached JWKS that is past its TTL. Do not grant access because 'the IdP was probably fine when the token was issued.'", "Implement IdP redundancy: deploy a secondary IdP instance in a different availability zone or region with automatic failover. Failover trigger should be 60 seconds of primary IdP unavailability for consequential access paths, 5 minutes for non-consequential paths. The secondary IdP must be synchronized with the primary \u2014 same trust anchor registry, same scope definitions, same revocation state.", "Cache JWKS and discovery document responses with a TTL not exceeding 5 minutes (for validation cache) or the document's own Cache-Control header, whichever is shorter. Serve cached responses only within their TTL. After TTL expiry, if the IdP is unreachable, fail closed \u2014 do not serve stale cached JWKS beyond TTL.", "Cache access tokens within their original exp claim lifetime for graceful degradation: if an AI agent has a valid, non-expired token and the IdP becomes unreachable, the token remains valid at resource servers until it expires. This is acceptable because the token is within its authorized validity period. After the token's exp time passes, deny access \u2014 do not extend the token's validity because the IdP is unavailable.", "Define the IdP unavailability incident threshold and response: if the primary IdP has been unavailable for more than 60 seconds on a consequential access path (or the defined threshold), trigger an incident response page to the on-call IAM team. If unavailability extends beyond 5 minutes, escalate to a P1 incident and activate the secondary IdP if automated failover has not already occurred.", "Prohibit IdP bypass mechanisms: no configuration option, feature flag, environment variable, or maintenance mode may grant access without IdP validation. Emergency access during extended IdP outages must follow the NI-08 break-glass procedure exclusively. Document this prohibition in the authorization server configuration standards and verify in configuration audits." ], "anti_patterns": [ "Configuring a 'maintenance mode' or 'bypass flag' that disables IdP validation for operational convenience \u2014 this is a permanently open backdoor waiting for an incident or misuse.", "Extending cached JWKS beyond its TTL when the IdP is unreachable, on the assumption that the keys are probably still valid \u2014 keys may have been rotated or the IdP may have been compromised, and serving stale JWKS defeats key rotation as a security control.", "Treating IdP unavailability as a non-security operational event \u2014 a 60-second IdP outage on a consequential access path is a security incident with a defined response, not just an SRE ticket." ] }, "validation": { "design_check": [ "Confirm that token validation middleware has explicit fail-closed configuration: a documented, tested behavior of denying access when the IdP endpoint is unreachable [ref:nist_sp_800_207].", "Verify secondary IdP configuration: the secondary IdP exists, has synchronized trust state with the primary, and automatic failover is tested in the disaster recovery plan [ref:cisa_zt_maturity_v2].", "Confirm that JWKS caching TTL is correctly configured and that no code path serves JWKS responses beyond the TTL when the IdP is unreachable [ref:nist_800_63_4]." ], "runtime_test": [ "Take the primary IdP JWKS endpoint offline; attempt to authenticate a new AI agent session; confirm the resource server returns 503 with Retry-After rather than granting access [ref:nist_sp_800_207].", "Take the primary IdP offline while an AI agent holds a valid, non-expired token; confirm the agent can complete its current session using the valid cached token but cannot obtain new tokens or refresh after expiry [ref:nist_sp_800_207].", "Confirm that after the primary IdP has been offline for the configured failover threshold (e.g., 60 seconds), the secondary IdP is active and new authentication flows succeed [ref:cisa_zt_maturity_v2]." ], "evidence": [ "identity:fail-closed-config \u2014 token validation middleware configuration showing explicit fail-closed behavior with a test result confirming deny-on-IdP-unavailability behavior [unverified]", "identity:secondary-idp-config \u2014 secondary IdP deployment configuration and synchronization setup showing trust state parity with primary [unverified]", "identity:dr-test-results \u2014 disaster recovery test results showing successful failover to secondary IdP within the defined failover threshold [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Fail-closed is a configuration decision that must be made explicitly \u2014 most OIDC middleware libraries have a default behavior on IdP unavailability that may not be fail-closed. Review the default behavior of every OIDC/JWT validation library in use and confirm fail-closed is explicitly configured, not assumed.", "actions": [ "Review the default behavior of each JWT/OIDC library on JWKS endpoint unavailability and confirm fail-closed is the configured behavior", "Implement JWKS TTL enforcement at the cache layer \u2014 not just relying on the library's built-in caching", "Test failover to secondary IdP end-to-end in a staging environment before enabling in production" ], "failure_signals": [ "JWT library on JWKS unavailability defaults to serving stale keys beyond TTL or accepting tokens without signature verification", "Secondary IdP has never been tested for failover \u2014 failover is assumed to work based on configuration review only" ] }, "security_architect": { "summary": "IdP resilience architecture must treat the IdP as a security-critical dependency, not just an availability dependency. Fail-closed behavior and secondary IdP redundancy are security requirements, not just reliability requirements. The architecture must prevent any access path from bypassing IdP validation.", "actions": [ "Audit all access paths for AI agent traffic to confirm no path can succeed without IdP validation", "Design secondary IdP synchronization to include trust anchor registry, revocation state, and scope definitions \u2014 not just authentication capability", "Define the SLA for secondary IdP activation and confirm the automated failover mechanism meets the SLA through load testing" ], "failure_signals": [ "Secondary IdP does not have the same trust anchor registry as primary \u2014 a failed-over secondary will accept tokens from trust anchors not vetted by the primary's process", "An access path exists that uses a cached service account token and does not re-validate against the IdP on each request" ] }, "legal_counsel": { "summary": "An AI agent that gains access during an IdP outage through a fail-open configuration has performed unauthorized access, even if the action appears legitimate. The legal exposure from fail-open access during an outage is significant and must be addressed in the authorization server configuration standards.", "actions": [ "Confirm that the authorization server configuration standards explicitly prohibit fail-open configurations and that this prohibition is documented as a control", "Review incident response agreements to confirm that IdP outage events that result in access decisions (even denied access) are logged for regulatory and legal purposes", "Confirm that the NI-08 break-glass procedure has a documented legal basis for emergency access and that this procedure is the only authorized path during extended IdP outages" ], "failure_signals": [ "No documented prohibition on fail-open configurations in the authorization standards \u2014 the control exists informally but is not enforceable", "Break-glass procedure does not have a documented legal basis or approval authority" ] }, "grc_auditor": { "summary": "Fail-closed behavior must be verified through testing, not just configuration review. The secondary IdP existence and synchronization state must be confirmed. IdP outage incident response procedures must be documented and tested.", "actions": [ "Request the fail-closed behavior test results from the last DR test cycle \u2014 configuration review alone is insufficient", "Confirm secondary IdP trust state synchronization: pull the trust anchor registries from both primary and secondary IdP and verify they match", "Review the last 12 months of IdP outage incident logs to confirm that each outage triggered the defined incident response and that no access was granted outside the defined fail-closed behavior" ], "metrics": [ "Number of IdP outage events in the last 12 months where fail-closed behavior was confirmed in logs (versus any access granted during outage)", "Time to secondary IdP activation in last DR test (target: within defined failover threshold)" ], "failure_signals": [ "No DR test results for secondary IdP failover in the last 12 months", "IdP outage incident logs show access was granted during an outage period \u2014 fail-open behavior detected" ] }, "it_operations": { "summary": "IdP failover is an operational procedure with a defined threshold and defined steps. Operations must know the failover threshold, how to confirm failover status, and how to revert to primary IdP after recovery. JWKS cache TTL is a tuning parameter that must be monitored.", "actions": [ "Document the IdP failover runbook: how to detect the primary IdP is down, how to confirm the secondary has activated, how to test secondary authentication, and how to revert to primary", "Monitor JWKS cache hit rates and refresh failures \u2014 a spike in refresh failures is an early indicator of IdP availability issues before they reach the failover threshold", "Conduct quarterly failover tests in staging to confirm the secondary IdP is in sync and the failover threshold is correctly configured" ], "failure_signals": [ "No runbook for IdP failover \u2014 operations team does not know the failover threshold or how to confirm secondary activation", "No monitoring on JWKS cache refresh failures \u2014 IdP availability issues are discovered through authentication failures, not proactive monitoring" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have not explicitly tested fail-closed behavior on IdP unavailability. Secondary IdP redundancy is common in enterprise environments but is often configured for availability rather than security resilience. Achieving 'managed' requires tested fail-closed behavior, confirmed secondary IdP trust state synchronization, and a documented DR test cycle." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "cloud-native", "universal-enterprise", "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "IAM Team", "Platform Engineering", "Site Reliability Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a73.4.1", "fit": "direct", "rationale": "SP 800-207 \u00a73.4.1 sets the network requirements to support ZTA, including that the policy decision/enforcement infrastructure remain available and that access fails safe when it is not. IF-07's fail-closed IdP unavailability behavior and secondary IdP redundancy implement that availability-and-deny-by-default posture for the identity provider dependency.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Access Management", "fit": "partial", "rationale": "The CISA ZTMM Identity pillar's Access Management function expects access decisions to remain policy-governed under all conditions; IF-07 implements deny-by-default resilience and secondary IdP redundancy so that identity provider failure cannot bypass access management.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4", "fit": "partial", "rationale": "SP 800-63B-4's authenticator lifecycle requirements include maintaining access despite authenticator loss or unavailability. IF-07's secondary IdP and break-glass integration apply that recovery discipline to the identity-provider dependency; the break-glass procedure itself is NI-08.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta \u2014 Multi Region Resilience", "rationale": "Okta's multi-region active-active architecture provides a contractual 99.99% uptime SLA. Okta recommends implementing local credential caching with defined TTLs for critical workloads to ensure fallback capability during IdP unavailability periods. The Okta Health Dashboard provides real-time status for capacity planning and incident response.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Okta multi-region HA and cache guidance improve IdP availability but do not implement the relying-party deny-by-default fail-closed behavior required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Regional STS Endpoints", "rationale": "AWS IAM is a global service with automatic multi-region replication of policy data. AWS STS regional endpoints should be configured instead of the global endpoint to avoid single-region dependency; regional STS endpoints remain available during global STS disruptions. Cached STS tokens remain valid for their full session duration during regional service events.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "AWS regional STS endpoints improve IdP-side availability but do not implement the fail-closed 503 relying-party behavior on IdP unavailability.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IF-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All token validation middleware must be explicitly configured to deny access and return HTTP 503 with a Retry-After header when the IdP JWKS endpoint, discovery document, or introspection endpoint is unreachable, with no code path serving JWKS responses beyond the configured TTL (maximum 5 minutes or document Cache-Control, whichever is shorter). Secondary IdP failover must activate within the defined threshold (60 seconds for consequential access paths) with synchronized trust anchor registry and revocation state. No maintenance mode, bypass flag, or fallback mechanism may grant access without IdP validation \u2014 emergency access is exclusively through the NI-08 break-glass procedure.", "evidence_required": [ "fail_closed_config showing explicit deny-on-IdP-unavailability configuration in token validation middleware for each service, with a test result confirming 503 response behavior on IdP endpoint unavailability", "secondary_idp_config showing secondary deployment in a different availability zone or region with trust anchor registry, scope definitions, and revocation state synchronized with primary", "dr_test_results from the last disaster recovery test cycle confirming secondary IdP activated within the defined failover threshold with successful authentication traffic confirmed on secondary", "idp_outage_incident_log for the last 12 months confirming each outage triggered defined incident response, fail-closed behavior was maintained, and no access was granted outside the defined fail-closed behavior" ], "machine_tests": [ "Take primary IdP JWKS endpoint offline; immediately attempt new AI agent authentication request \u2192 assert resource server returns 503 with Retry-After header rather than granting access or attempting stale-cache fallback", "Take primary IdP offline; agent holds valid non-expired token and completes current request successfully; advance clock past token exp and attempt next request while IdP remains offline \u2192 assert 503 response (IdP unavailable, not 401 token_expired)", "Take primary IdP offline for the configured failover threshold (e.g., 60 seconds for consequential paths) \u2192 assert automated failover has activated secondary IdP and new authentication flows succeed via secondary", "Serve cached JWKS response from local cache after TTL expiry while IdP remains offline \u2192 assert middleware refuses to use stale JWKS and returns 503 rather than validating tokens against expired cached keys" ], "human_review": [ "Review JWT and OIDC library configurations for each service to confirm fail-closed behavior is explicitly configured rather than assumed, and that the library's default behavior on JWKS unavailability has been documented and overridden where the default is not fail-closed", "Assess secondary IdP trust state synchronization by comparing trust anchor registries and scope definitions between primary and secondary \u2014 a secondary IdP with a different trust anchor registry will accept tokens from unvetted external IdPs after failover", "Verify that no maintenance mode flag, bypass environment variable, or emergency access path exists that can grant access without IdP validation \u2014 confirm the NI-08 break-glass procedure is the sole authorized path for access during extended IdP outages" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Configuring a maintenance mode or bypass flag that disables IdP validation during outages for operational convenience \u2014 creates a permanently available backdoor that can be triggered deliberately by any actor capable of causing or simulating an IdP availability event", "Serving stale JWKS beyond its configured TTL when the IdP is unreachable on the assumption that keys are probably still valid \u2014 defeats key rotation as a security control and allows tokens signed by a rotated or compromised key to be accepted indefinitely", "Treating IdP unavailability as a routine operational event rather than a security incident \u2014 a 60-second IdP outage on a consequential access path triggers a defined security incident response, not just an SRE alerting ticket", "Deploying a secondary IdP without synchronizing the trust anchor registry from the primary \u2014 a failed-over secondary IdP will accept tokens from external organizations not vetted by the primary's trust anchor registration process", "Caching access tokens beyond their exp claim to allow operations to continue during an IdP outage \u2014 this extends authorized access periods without authorization and creates orphaned credential scenarios where access persists past its valid period" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-08", "layer": "IF", "plane": "data", "name": "Cross-Domain Identity Audit Reconciliation", "plain": "Reconciles identity audit logs across all federated systems to detect event chain gaps, cross-domain access discrepancies, and unauthorized activity that spans organizational identity boundaries.", "threat": { "tags": [ "federation-bypass", "lateral-movement", "identity-spoofing" ], "desc": "Federated identity attacks span multiple systems by design: authentication happens at an IdP, authorization at an authorization server, and access at resource servers \u2014 often across organizational boundaries. Each system logs its own events, but no single system has visibility into the full event chain. An attacker who knows this gap can arrange that the authentication event, the token issuance event, and the resource access event each appear legitimate in their respective logs while the overall pattern reveals unauthorized access. Without cross-domain audit reconciliation, this attack pattern is invisible. The consequence is prolonged unauthorized access \u2014 the attacker maintains access for as long as each individual system sees only apparently legitimate events." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 7", "title": "Collect security information across all assets for visibility" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Log and inspect all traffic including federated identity events" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Audit requirements and reconciliation of identity records" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IF-08 Cross-Domain Identity Audit Reconciliation control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IF-08 Cross-Domain Identity Audit Reconciliation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IF-08 Cross-Domain Identity Audit Reconciliation control.", "reviewed_on": "2026-07-02" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IF-08 Cross-Domain Identity Audit Reconciliation control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IF-08 Cross-Domain Identity Audit Reconciliation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Collect and correlate identity audit events from all federated systems \u2014 IdP authentication events, authorization server token issuance events, and resource server access events \u2014 into a unified reconciliation pipeline. Detect gaps and discrepancies in the event chain as security findings. Feed reconciliation results to IC-08 (Identity Attestation) as federation audit completeness evidence.", "steps": [ "Define the required event chain for every federated access: (1) authentication event at the IdP (agent authenticated, issuer, time), (2) token issuance event at the authorization server (token jti, scope, audience, agent sub, issuance time), (3) resource access event at the resource server (token jti, resource URI, action, verdict, time). Every consequential access should produce all three event types in the correct temporal order.", "Implement structured audit log formats with a correlation ID that flows through all three event types: the authorization server embeds a correlation ID (or uses token jti) in the token, the resource server includes the same jti or correlation ID in its access log. This enables log join across systems even when logs are collected asynchronously.", "Build the reconciliation pipeline: collect events from IdP, authorization server, and resource server logs into a centralized log aggregation system (SIEM or dedicated pipeline). Define the reconciliation queries: (a) token issuance events with no preceding authentication event (suspicious), (b) resource access events with no corresponding token issuance event (suspicious), (c) authentication events with no subsequent token issuance or resource access (may be normal, but high volume warrants investigation), (d) resource access events where token exp was in the past (expired token use).", "Detect and alert on cross-domain access discrepancies: for federated access involving external organizations, reconcile the external org's authentication log (if shared under the federation agreement) against the enterprise's token issuance log. Any external agent that issued tokens without a corresponding authentication event in the external org's log is a finding. Define the audit log sharing format for cross-org reconciliation in the federation agreement.", "Define the reconciliation cadence: real-time streaming for consequential access paths (alert within 5 minutes of gap detection), batch for non-consequential paths (daily reconciliation report). Define the gap detection thresholds: a gap in the event chain on a consequential access path is a P1 finding; a gap on a non-consequential path with no pattern of repetition is a P3 finding.", "Feed reconciliation results to IC-08 attestation: the cross-domain audit reconciliation completeness score (percentage of consequential access events with a complete event chain) is an input to the IdentityAttestation. An attestation period where reconciliation detected gaps that were not resolved within the defined SLA must be reflected in the attestation verdict." ], "anti_patterns": [ "Treating each federated system's audit log as a complete record of access activity \u2014 no single system sees the full event chain, and gaps between systems are exactly where sophisticated attacks hide.", "Implementing reconciliation only as a periodic batch process for all access types \u2014 consequential access path discrepancies require near-real-time detection; a daily batch means an attack in the morning is not detected until the evening review.", "Treating reconciliation gaps as data quality issues rather than security findings \u2014 a missing event in the chain is a hypothesis that unauthorized access may have occurred, and it must be investigated to resolution before being closed." ] }, "validation": { "design_check": [ "Confirm that a correlation ID or token jti field is implemented in token issuance and propagated in resource access logs \u2014 the key that enables log join across IdP, authorization server, and resource server [ref:nist_sp_800_207].", "Verify the reconciliation pipeline is implemented with the four gap detection queries defined (authentication without token issuance, resource access without token issuance, resource access with expired token, and cross-org auth without corresponding external org event) [ref:cisa_zt_maturity_v2].", "Confirm reconciliation results feed into IC-08 attestation: the attestation procedure references the reconciliation completeness score as an input to the attestation verdict [ref:iso_24760_2019]." ], "runtime_test": [ "Inject a synthetic resource access event with a jti that has no corresponding token issuance event in the authorization server log; confirm the reconciliation pipeline detects and alerts on the gap within the defined detection window [ref:nist_sp_800_207].", "Simulate a token issuance event with no preceding authentication event (at the IdP log) and confirm the reconciliation pipeline flags this as a suspicious finding [ref:cisa_zt_maturity_v2].", "Verify that a resource access event using an expired token (exp in the past) is detected by the reconciliation pipeline and classified as a P1 finding [ref:nist_sp_800_207]." ], "evidence": [ "identity:reconciliation-pipeline-config \u2014 configuration of the cross-domain audit reconciliation pipeline showing event sources, gap detection queries, and alert thresholds [unverified]", "identity:reconciliation-report-sample \u2014 sample reconciliation report from the last 30-day period showing event chain completeness rate, gaps detected, and resolution status for each gap [unverified]", "identity:ic08-attestation-input \u2014 documented reconciliation completeness score input to the IC-08 attestation process showing how reconciliation findings affect attestation verdict [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Cross-domain audit reconciliation requires a correlation ID that is defined at the authorization server layer and propagated through every resource server's access log. Without this correlation ID, logs cannot be joined across systems and reconciliation reduces to heuristic matching that misses targeted attacks.", "actions": [ "Implement correlation ID (or token jti propagation) as a standard header in all AI agent request flows that resource servers log alongside access events", "Define the structured audit log format for all three event types (authentication, token issuance, resource access) with correlation ID as a required field", "Build or configure the SIEM reconciliation queries for the four gap detection patterns" ], "failure_signals": [ "Resource server access logs do not include the token jti or a correlation ID \u2014 logs cannot be joined to token issuance events", "IdP authentication events and authorization server token issuance events use different subject identifiers that cannot be reliably joined" ] }, "security_architect": { "summary": "Cross-domain audit reconciliation is where federated identity meets security monitoring. The architecture must treat the event chain \u2014 authentication, token issuance, resource access \u2014 as a single logical security event that happens to span multiple physical systems. The correlation ID is the architectural keystone.", "actions": [ "Define the correlation ID scheme as an architecture standard before any federated access logging is implemented \u2014 retrofitting correlation IDs into existing logs is expensive", "Design the reconciliation pipeline to handle the latency between IdP events and resource server events \u2014 a 60-second window is typical; alert thresholds must account for legitimate latency", "Define the cross-org audit log sharing format in all federation agreements before operational federation begins" ], "failure_signals": [ "No correlation ID standard defined \u2014 each service uses a different request ID scheme that cannot be correlated across system boundaries", "Federation agreements do not include audit log sharing provisions \u2014 cross-org reconciliation is impossible without the external org's authentication logs" ] }, "legal_counsel": { "summary": "Cross-org audit log sharing for reconciliation purposes raises data protection questions in EU contexts. The audit log sharing format in federation agreements must include data minimization provisions and retention limits consistent with GDPR and applicable national law.", "actions": [ "Review the cross-org audit log sharing format in each federation agreement to confirm it includes only the minimum fields needed for reconciliation and no personal data beyond what is legally permissible", "Confirm that audit log retention periods for reconciliation logs comply with applicable data protection law in each jurisdiction involved in the federation", "Verify that the reconciliation pipeline itself is subject to access controls and audit logging \u2014 the reconciliation system has visibility into sensitive access patterns and must be protected accordingly" ], "failure_signals": [ "Cross-org audit log sharing format includes fields not needed for reconciliation \u2014 more data than necessary is shared, creating GDPR exposure", "No data protection review of the reconciliation pipeline's own log retention and access controls" ] }, "grc_auditor": { "summary": "Cross-domain audit reconciliation is a tier-1 audit artifact. The reconciliation report demonstrates that the organization can detect event chain gaps \u2014 the absence of this capability is itself a material control deficiency. The reconciliation completeness rate is the primary metric.", "actions": [ "Obtain the reconciliation report for the audit period and review the event chain completeness rate for consequential access paths", "Inspect each gap finding detected during the audit period: confirm that each gap was investigated and either resolved with a documented explanation or escalated as a security incident", "Verify that the reconciliation completeness rate is correctly reflected as an input to the IC-08 attestation verdict \u2014 a period with unresolved gaps must show a qualified or conditional attestation" ], "metrics": [ "Event chain completeness rate for consequential access paths (target: 99.5% or higher)", "Number of detected gaps not resolved within the defined SLA in the audit period (target: zero)" ], "failure_signals": [ "No reconciliation pipeline exists \u2014 federated access logs are collected per-system but never cross-joined", "Reconciliation gaps are classified as data quality issues and closed without security investigation" ] }, "it_operations": { "summary": "The reconciliation pipeline is a data pipeline with latency, volume, and availability requirements of its own. Event ingestion from multiple federated systems must handle different log formats, different latencies, and different retention policies. Operations must treat pipeline health as a security control health metric.", "actions": [ "Monitor reconciliation pipeline event ingestion lag: if events from any source are delayed by more than the defined reconciliation window (e.g., 5 minutes for consequential path events), alert", "Implement dead letter queues for events that fail to ingest \u2014 dropped events create false-negative gaps in reconciliation", "Test reconciliation pipeline recovery after an outage: confirm that events buffered during outage are correctly processed on recovery, not lost" ], "failure_signals": [ "Reconciliation pipeline has no ingestion lag monitoring \u2014 delays in event ingestion cause false-positive gap alerts without operational visibility into the cause", "No dead letter queue for failed event ingestion \u2014 dropped events reduce the completeness rate without a detectable signal" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Cross-domain audit reconciliation is rare even in mature identity programs. Most organizations collect logs from each federated system independently and perform manual correlation only during incident investigation. Achieving 'managed' requires a correlation ID standard, a structured reconciliation pipeline with automated gap detection, and integration into the IC-08 attestation process." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "cloud-native", "universal-enterprise", "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "Security Operations", "IAM Team", "SIEM/Platform Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 7", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 7 requires collecting information about the current state of assets and communications and using it to improve security posture. IF-08's cross-domain reconciliation pipeline implements this for federated identity event chains.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "fit": "direct", "rationale": "The CISA ZTMM Visibility and Analytics cross-cutting capability requires logging and inspection of activity, including identity events. IF-08 implements this for federated identity by reconciling authentication, token issuance, and resource access events.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015 specifies audit requirements for identity management systems, including keeping identity records reconcilable across systems; IF-08 implements reconciliation at the federated event-chain level.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail \u2014 Organization Trail", "rationale": "AWS CloudTrail with an organization trail consolidates identity audit logs from all member accounts into a central S3 bucket in the management account, enabling cross-domain reconciliation of agent authentication events across the entire organizational boundary. Cross-account query with Amazon Athena over the centralized trail enables federation reconciliation at scale.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail organization trails centralize identity logs enabling reconciliation, but not the jti-correlated gap-detection pipeline the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Audit Logs \u2014 Organization Log Sink", "rationale": "Google Cloud Audit Logs with organization-level log sinks to BigQuery or Cloud Storage enable cross-domain identity audit reconciliation across all projects and folders. Cloud Asset Inventory tracks IAM policy binding changes across the organization, providing a unified view for reconciliation of agent identity events across organizational boundaries.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP org log sinks aggregate audit logs across projects for reconciliation, but not the defined jti-correlated gap-detection queries the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://identity/controls/IF-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A cross-domain audit reconciliation pipeline must ingest authentication events (IdP), token issuance events (authorization server), and resource access events (resource server) correlated by token jti or correlation ID, execute the four defined gap detection queries, and alert on consequential access path gaps within 5 minutes of detection. The event chain completeness rate for consequential access paths must meet or exceed 99.5% as a required input to the IC-08 attestation verdict, with unresolved gaps reflected as qualified or conditional attestation status.", "evidence_required": [ "reconciliation_pipeline_config showing event sources (IdP, authorization server, resource server), all four gap detection queries implemented, alert thresholds per gap severity tier, and streaming detection enabled for consequential access paths", "reconciliation_report_sample from the last 30-day period showing event chain completeness rate for consequential access paths, all gaps detected, and resolution status with documented explanation or escalation record for each gap", "correlation_id_propagation_spec confirming token jti or correlation ID is a required field in all three event log types and that resource server access logs include the field as a mandatory non-nullable attribute", "ic08_attestation_input_record showing reconciliation completeness score used as an input to the IC-08 attestation verdict for the last attestation period, including any qualified status triggered by unresolved gaps" ], "machine_tests": [ "Inject synthetic resource access event with a jti that has no corresponding token issuance event in the authorization server log \u2192 assert reconciliation pipeline detects and raises an alert within 5 minutes", "Inject synthetic token issuance event with no preceding authentication event in the IdP log for the same agent sub within the defined correlation window \u2192 assert reconciliation pipeline flags as suspicious finding requiring investigation", "Inject resource access event with exp timestamp in the past at time of access \u2192 assert reconciliation pipeline classifies as P1 finding and alerts within the defined detection window", "Disable event ingestion from one source system for 10 minutes then restore \u2192 assert pipeline processes buffered events correctly on recovery and does not generate false-positive gaps for the buffered period" ], "human_review": [ "Review each reconciliation gap detected in the last audit period to confirm it was investigated to documented resolution or formally escalated as a security incident \u2014 gaps closed as data quality issues without security investigation are a control failure", "Assess federation agreements with each external organization to confirm cross-org audit log sharing format, minimization requirements, and data retention limits for reconciliation purposes are explicitly documented", "Verify that the reconciliation completeness rate is correctly reflected as a required input to the IC-08 attestation verdict and that attestation periods with unresolved gaps are recorded as qualified or conditional attestation status, not as clean passes" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating each federated system's audit log as a self-sufficient record of access activity \u2014 no single system sees the full authentication-to-access event chain, and gaps between systems are precisely where sophisticated federated identity attacks conceal themselves", "Implementing reconciliation only as a daily batch process for all access types \u2014 consequential access path discrepancies require near-real-time detection; a daily batch means an attack conducted in the morning is not detected until the evening reconciliation run", "Classifying reconciliation gaps as data quality issues and closing them without security investigation \u2014 a missing event in the event chain is a hypothesis of possible unauthorized access that requires investigation to rule out before closure", "Omitting cross-org audit log sharing provisions from federation agreements before operational federation begins \u2014 cross-domain reconciliation for external organization agent events is impossible without the external organization's authentication logs", "Implementing log collection without a defined correlation ID standard \u2014 resource access events cannot be reliably joined to token issuance events, making reconciliation dependent on heuristic matching that cannot detect targeted event suppression attacks" ], "update_status": "current", "layer_code": "IF" }, { "id": "IF-09", "layer": "IF", "plane": "lifecycle", "name": "Identity Federation Layer Evidence Package", "plain": "Compile a quarterly identity federation layer evidence package consolidating artifacts from IF-01 through IF-08 to demonstrate that federation trust anchors, vetting processes, and cross-domain audit reconciliation are current and complete. The package is a required input to IC-08 (IdentityAttestation) production.", "threat": { "tags": [ "governance-evidence-gap", "attestation-unverifiable", "audit-readiness-deficit" ], "desc": "Without periodic structured compilation of identity federation layer evidence, the IdentityAttestation (IC-08) rests on assertions from individual controls rather than compiled, reviewed, and signed evidence. Layer-level gaps are only visible through compilation." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review of AI management system at planned intervals" }, { "id": "nist_rmf", "section": "GOVERN 1.5", "title": "Ongoing monitoring and periodic review of the risk management process and its outcomes" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management system for high-risk AI providers" } ], "sources": [ { "id": "iso_27001_2022", "title": "ISO/IEC 27001:2022 \u2014 Information Security Management System", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "certification-standard", "version": "2022", "published_on": "2022-10-25", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/27001", "license": "proprietary", "status": "current", "flagship": true, "source_id": "iso_27001", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27001:2022 \u2014 Information Security Management System requirements informing the apeiris://identity/controls/IF-09 Identity Federation Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_100_1", "title": "NIST AI 100-1: Artificial Intelligence Risk Management Framework", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 100-1: Artificial Intelligence Risk Management Framework requirements informing the apeiris://identity/controls/IF-09 Identity Federation Layer Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a quarterly evidence compilation process for the Identity Federation layer. Collect required artifacts from IF-01 through IF-08. Review completeness and identify gaps. Produce a signed evidence package for IC-08 IdentityAttestation input.", "steps": [ "Define the IF-layer evidence package schema: required_artifacts[], acceptance_criteria[], gap_register, package_owner, and review_signatories.", "For each control in IF-01 through IF-08, define required evidence artifacts and freshness criteria.", "Compile artifacts quarterly: generate or collect required evidence and stage for structured review.", "Conduct a review session to evaluate completeness, identify gaps, and assign remediation owners.", "Produce a signed identity federation layer evidence package and submit it as input to IC-08 IdentityAttestation production.", "Retain the package as an immutable record for audit and regulatory review." ] }, "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001 \u00a79.3 requires management review at planned intervals. IF-09 provides the structured review artifact for the Identity Federation layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.5", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.5 requires ongoing monitoring and periodic review of the risk management process and its outcomes, with clear organizational responsibilities. IF-09 instantiates that periodic review at the Identity Federation layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Art. 17 requires a quality management system. IF-09 is the QMS artifact for the Identity Federation layer.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://identity/controls/IF-09", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A quarterly identity federation layer evidence package must be compiled from all required artifacts across IF-01 through IF-08, reviewed against defined acceptance criteria for completeness and freshness, with all gaps registered in a gap_register with assigned remediation owners and target dates, and signed by defined review signatories before being submitted as a required input to IC-08 IdentityAttestation production.", "evidence_required": [ "identity_federation_evidence_package quarterly compilation artifact including required_artifacts list covering IF-01 through IF-08, acceptance_criteria per artifact, gap_register with owner and target date, package_owner, and package_completion_date", "evidence_package_review_record showing review session date, attendees representing IAM, security, and compliance functions, completeness findings per control, gaps identified, and sign-off by defined review signatories", "ic08_attestation_input_record confirming the signed evidence package was submitted as a required input to IC-08 IdentityAttestation production for the current attestation period with package_id and submission_timestamp", "gap_register showing all gaps identified during compilation with remediation_owner, target_date, root_cause, and resolution_status for each gap" ], "machine_tests": [ "Parse evidence package artifact list and verify it contains at least one required artifact entry for each of IF-01 through IF-08 \u2192 assert no controls are absent from the artifact list", "Check evidence package metadata for package_owner, review_signatories (minimum two, from different functions), and package_completion_date fields \u2192 assert all fields are populated with non-null values", "Verify IC-08 attestation input record references the signed evidence package with package_id, submission_timestamp, and submitter_id \u2192 assert all three reference fields are present and non-null" ], "human_review": [ "Review the gap_register to confirm each gap has an assigned remediation_owner, a target_date, and a documented root_cause \u2014 gaps without owners or dates are uncontrolled and cannot be tracked to resolution", "Assess review signatories to confirm they represent the appropriate functions (IAM, security, compliance) and hold the authority to attest to evidence completeness for the identity federation layer", "Verify that the evidence package covers the full IF-01 through IF-08 control set and that no controls have been silently omitted from the compilation due to evidence unavailability \u2014 omissions must be recorded as gaps, not treated as out-of-scope" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Compiling the evidence package as a point-in-time document collection without defined acceptance criteria \u2014 artifacts are included regardless of freshness or completeness, making the package a filing exercise rather than a governance gate", "Treating the evidence package as a documentation artifact compiled after IC-08 attestation is already complete \u2014 the package must gate attestation production, not ratify a pre-determined attestation outcome", "Omitting control gaps from the gap_register because they are known issues under remediation \u2014 all gaps must be formally registered with owners and target dates, not quietly excluded to preserve attestation completeness appearances", "Signing the evidence package without a structured review session where signatories examine the artifacts and gap_register \u2014 signatures applied to a pre-populated document without examination provide no assurance value and may create legal exposure", "Retaining the evidence package for a shorter period than the applicable regulatory or audit retention requirement \u2014 the package is a tier-1 attestation input and must be retained as an immutable, auditable record for the full required retention period" ], "update_status": "current", "lenses": { "iam_engineer": { "summary": "This package consolidates the Identity Federation layer, so what you assemble is the federation-trust record: trust anchors, IdP vetting, and cross-domain audit reconciliation from IF-01 through IF-08. Each of the eight controls must appear as at least one artifact entry, the review must involve IAM, security, and compliance functions, and the IC-08 input record must reference the package by package_id, submission_timestamp, and submitter_id. The federation-specific risk is a stale or over-trusted trust anchor and audit trails that do not reconcile across federated domains.", "actions": [ "Assemble the package so it contains at least one artifact entry for every IF-01 through IF-08 control, with no control absent from the list.", "Include current trust-anchor and IdP-vetting evidence plus the cross-domain audit reconciliation from the federation layer.", "Populate package metadata with package_owner, a review_signatories set of at least two members from different functions, and a package_completion_date.", "Record the ic08_attestation_input_record with package_id, submission_timestamp, and submitter_id all present and non-null.", "Maintain the gap_register with remediation_owner, target_date, root_cause, and resolution_status for every federation gap identified during compilation." ] }, "security_architect": { "summary": "IF-09 makes the federation layer attestable and blocks deployment when incomplete. Federation extends trust to external identity providers, so the property this package must prove is that every trust anchor is vetted, current, and reconciled, and that token exchange across domains stays within established trust. An unreviewed trust anchor or an audit trail that does not reconcile across domains is the failure that undermines IC-08's claim about federated identities.", "actions": [ "Require evidence that federation trust anchors and IdP relationships were vetted and remain current as an acceptance criterion.", "Make cross-domain audit reconciliation a load-bearing artifact so gaps between federated domains are surfaced rather than assumed clean.", "Ensure the review draws from IAM, security, and compliance so federation trust decisions get multi-function scrutiny.", "Confirm the IF-09 package is a required, verified input to IC-08 and that unresolved federation gaps block the attestation." ] }, "legal_counsel": { "summary": "Federation means the enterprise is relying on identity assertions issued by external parties, often under cross-organization agreements. The signed IF package is the record showing those federated trust relationships were vetted and monitored, and that cross-domain audit trails reconcile. In a dispute over an action taken by a federated identity, this is the artifact establishing the trust was governed rather than assumed.", "actions": [ "Confirm the package documents the basis for trusting each federated IdP in terms consistent with the underlying federation or partner agreements.", "Verify cross-domain audit reconciliation evidence is retained so a federated identity's actions can be traced across organizational boundaries.", "Ensure the review record naming IAM, security, and compliance attendees is preserved as evidence of governed trust decisions.", "Check that gap_register root_cause and resolution fields are complete enough to defend how a federation weakness was handled." ] }, "grc_auditor": { "summary": "For IF-09 the evidence is the federation-layer package, its review record, the IC-08 input record, and the gap_register. The auditable disciplines specific to this layer are full IF-01 through IF-08 artifact coverage, a review drawing attendees from IAM, security, and compliance, and an IC-08 reference carrying package_id, submission_timestamp, and submitter_id. Confirm no federation control is missing an artifact and that the review was genuinely multi-function.", "actions": [ "Parse the artifact list and confirm at least one entry exists for each of IF-01 through IF-08, with no control absent.", "Check package metadata for package_owner, review_signatories of at least two members from different functions, and a package_completion_date, all non-null.", "Verify the evidence_package_review_record names attendees representing IAM, security, and compliance and records completeness findings per control.", "Confirm the IC-08 attestation input record references the signed package with package_id, submission_timestamp, and submitter_id." ] }, "it_operations": { "summary": "You run the quarterly federation-package compilation and organize the multi-function review that IAM, security, and compliance must attend. The operational task unique to this layer is keeping federation-metadata and trust-anchor evidence current, and running the cross-domain audit reconciliation so it is fresh at compile time. A missing artifact for any IF control, or a skipped compilation, blocks deployment at IC-08.", "actions": [ "Schedule the quarterly federation package compilation and the IAM, security, and compliance review session, and alert on any slip.", "Refresh trust-anchor and federation-metadata evidence on cadence so it is current when the package is compiled.", "Run the cross-domain audit reconciliation ahead of compilation and route unreconciled entries to an owner.", "Ensure the IC-08 submission is recorded with package_id, submission_timestamp, and submitter_id, and re-sign the package if a gap is remediated mid-cycle." ] } }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "maturity": { "current": "initial", "target": "defined", "notes": "Layer-level evidence compilation is rare; most organizations assemble identity audit evidence ad hoc at audit time. Target state is an automated quarterly Identity Federation package with signed integrity, a maintained gap register, and direct feed into IC-08 attestation production." }, "implementers": [ "IAM Team", "GRC / Internal Audit", "Platform Engineering" ], "validation": { "design_check": [ "Verify the Identity Federation evidence package schema defines required artifacts for every IF-01 through IF-08 control, with acceptance criteria and freshness windows per artifact.", "Confirm package assembly is automated from authoritative sources (registry exports, IdP and pipeline logs) rather than manually collated documents.", "Validate that the package is signed and hash-chained so downstream consumers (IC-08 attestation production) can verify integrity and completeness." ], "runtime_test": [ "Request the current Identity Federation evidence package via the integration API and confirm every IF-layer control contributes at least one artifact with a collection timestamp inside the freshness window.", "Tamper with one staged artifact and confirm the package integrity check fails and the package is rejected as IC-08 input.", "Simulate a missing artifact for one control and confirm the gap register records it with an assigned owner and remediation date." ], "evidence": [ "evidence-package:Signed quarterly Identity Federation layer evidence package with per-control artifact manifest [unverified]", "gap-register:Gap register entries for the prior four quarters with remediation owners and closure dates [unverified]", "review-signoff:Quarterly review sign-off records naming the reviewing owners and their dispositions [unverified]" ] }, "layer_code": "IF", "lens_enrichment": "ap42 2026-07-08" }, { "id": "IM-01", "layer": "IM", "plane": "both", "name": "Credential Use Baseline", "plain": "Establishes and maintains a behavioral baseline of normal credential use patterns for each AI agent identity, capturing typical tools, action frequency, data volumes, time patterns, and network context to enable anomaly detection.", "threat": { "tags": [ "credential-compromise", "lateral-movement" ], "desc": "Without a behavioral baseline, anomalous credential activity blends into normal operational noise and evades detection entirely. Attackers who compromise an AI agent credential can use it at will, accessing sensitive resources and pivoting laterally across systems, because there is no reference point against which to measure abnormality. The absence of baselines means that even coarse indicators \u2014 such as an agent accessing a database it has never touched \u2014 go unreported. Establishing per-identity baselines converts the detection problem from signature-matching to statistical deviation, dramatically reducing attacker dwell time." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 5", "title": "Monitor and measure the integrity and security posture of all assets" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Risk Assessments", "title": "Identity risk assessment informed by behavioral analytics" }, { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "General authenticator requirements \u2014 binding and management" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-01 Credential Use Baseline control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Instrument the agent runtime to emit telemetry events for every tool call, API request, and data access. Ingest events into a time-series store. Run statistical characterization (mean, standard deviation, percentile distributions) per agent credential over a rolling 30-day observation window. Persist baseline snapshots keyed to credential_id + deployment_version, and refresh baselines on credential re-issuance or deployment change events.", "steps": [ "Instrument agent runtime to emit structured telemetry events per action: tool_id, action_type, resource_target, bytes_read, bytes_written, source_ip, timestamp_utc, duration_ms, outcome.", "Ingest telemetry into a time-series datastore (e.g., OpenTelemetry Collector \u2192 ClickHouse or Prometheus TSDB) partitioned by credential_id and scoped to a 30-day sliding window.", "Compute baseline profile per agent credential: tools accessed (set of tool_ids), action frequency (mean and \u03c3 actions/minute), data volume (mean and \u03c3 bytes/operation), time-of-day distribution (histogram), and network context (IP CIDR or ASN set of expected call origins).", "Store baseline snapshots in the identity registry alongside the credential record; trigger baseline invalidation and restart of the 30-day observation window on any credential re-issuance or deployment manifest version change event, notifying IM-02 of the baseline reset." ], "anti_patterns": [ "Sharing a single baseline across multiple agent roles or deployment environments \u2014 baselines must be per-credential to avoid masking anomalies through role averaging.", "Computing baselines from a <7-day window during initial deployment when usage patterns are not yet representative, leading to high false-positive rates in IM-02.", "Failing to invalidate the baseline when the agent's capability manifest changes, causing legitimate new tool usage to be flagged as anomalous indefinitely." ] }, "validation": { "design_check": [ "Verify baseline records exist in the identity registry for every active agent credential, with a baseline_established_at timestamp no older than 30 days plus grace period.", "Confirm that baseline invalidation events are triggered in the event log on credential re-issuance and deployment version change.", "Confirm telemetry coverage: sample 10 agent credentials and verify that at least 90% of their documented tool calls appear in the baseline profile." ], "runtime_test": [ "Deploy a test agent with a stable credential for 30 days, then verify its baseline profile contains expected tool_ids, action frequency range, and network context.", "Re-issue the test agent credential and verify the baseline is invalidated within 60 seconds and a new 30-day observation window begins.", "Inject synthetic off-hours traffic (outside the established time-of-day histogram) and verify that IM-02 receives the anomaly event referencing the IM-01 baseline." ], "evidence": [ "telemetry-coverage-report: percentage of agent credentials with active baselines [unverified]", "baseline-snapshot-export: sample of 5 baseline records showing profile fields [unverified]", "invalidation-event-log: log entries showing baseline resets on credential re-issuance events [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The baseline is the technical foundation for all anomaly detection in this layer. Without it, detection controls IM-02 and IM-03 have no reference point and will generate unbounded false positives or miss real attacks entirely. Treat baseline establishment as a deployment gate: no agent should graduate to production without a baseline record in the registry.", "actions": [ "Integrate baseline establishment into the agent deployment pipeline as a mandatory post-deployment phase before the agent receives production load.", "Build a baseline health dashboard showing coverage rate (percentage of active credentials with valid baselines) and flag credentials with expired or missing baselines.", "Automate baseline invalidation triggers from the credential lifecycle API so re-issuance events propagate to the telemetry system within one minute." ], "failure_signals": [ "Baseline coverage drops below 95% of active credentials \u2014 indicates telemetry collection gaps or deployment pipeline failures.", "Baseline last-updated timestamps show staleness beyond 35 days for active credentials \u2014 indicates invalidation triggers are broken." ] }, "security_architect": { "summary": "Behavioral baselines implement the continuous monitoring tenet of Zero Trust (NIST SP 800-207 \u00a72.1 Tenet 5) for AI agent identities. The baseline system must be architected so that the agent under observation has no write or delete access to its own telemetry, preventing a compromised agent from manipulating its baseline to evade detection. The telemetry pipeline is a high-value target and must be protected with equivalent rigor to the identity system itself.", "actions": [ "Design the telemetry pipeline with write-only endpoints from agent runtimes to a SIEM, ensuring agents cannot read, modify, or delete their own telemetry records.", "Architect baseline storage as an append-only ledger with cryptographic chaining so that baseline manipulation attempts are detectable.", "Define minimum telemetry fidelity requirements (event fields, latency SLA, sampling rate) and enforce them as a deployment prerequisite in the CI/CD pipeline." ], "failure_signals": [ "Telemetry pipeline allows agent credentials to authenticate to the SIEM write endpoint \u2014 indicates a privilege boundary failure.", "Baseline computation uses aggregated multi-agent data rather than per-credential data \u2014 masks individual anomalies and undermines detection." ] }, "legal_counsel": { "summary": "Behavioral baselines that include data volume telemetry may capture metadata about regulated data access (e.g., how many records an agent read from a healthcare database). Ensure that the telemetry data itself does not contain PII, PHI, or regulated content \u2014 only structural metadata about actions. Retention policies for baseline telemetry must align with the organization's data governance obligations.", "actions": [ "Review telemetry event schema to confirm that bytes_read/written and resource_target fields do not log the content of data accessed, only the structural metadata.", "Confirm that baseline telemetry retention policy (minimum 3 years) is documented and approved in the data governance framework.", "Ensure that baseline data is classified as operational security data under the organization's data classification policy, with appropriate access restrictions." ], "failure_signals": [ "Telemetry logs contain actual prompt content, response content, or data payloads rather than metadata \u2014 creates a regulated data exposure risk.", "Baseline telemetry is retained indefinitely without a defined deletion schedule \u2014 creates unnecessary data minimization liability." ] }, "grc_auditor": { "summary": "Baseline coverage and freshness are the key audit metrics for this control. NIST SP 800-207 \u00a72.1 Tenet 5 requires continuous monitoring and measurement of asset security posture; auditors should verify that this is operationalized through measurable baseline coverage, not just policy statements. The baseline system provides foundational evidence for demonstrating ongoing identity monitoring to SOC 2, FedRAMP, and ISO 27001 auditors.", "actions": [ "Obtain baseline coverage report showing percentage of active agent credentials with valid baselines; target is 100%, acceptable floor is 95% with documented exceptions.", "Verify baseline invalidation log demonstrates that credential re-issuance events consistently trigger baseline resets within the defined SLA.", "Confirm that baseline telemetry feeds into the organization's SIEM and that SIEM ingestion is verified through gap alerting (IM-06)." ], "metrics": [ "Baseline coverage rate: percentage of active agent credentials with a valid (non-expired) baseline record.", "Baseline freshness: average age of baseline records across the active credential population; alert if any exceed 35 days." ], "failure_signals": [ "Audit sample finds credentials with no baseline records \u2014 indicates the deployment pipeline gate is not enforced.", "Baseline snapshots show identical profiles across credentials with different roles \u2014 indicates baselines were not computed per-credential." ] }, "it_operations": { "summary": "Baseline establishment requires a 30-day observation window after each agent deployment before the agent's profile is considered reliable. Operations teams must plan for this warm-up period in deployment schedules and avoid triggering re-deployments unnecessarily (which reset baselines). Storage and compute costs for telemetry are bounded but must be budgeted proportionally to the number of agent credentials in the environment.", "actions": [ "Track baseline warm-up status per agent in the deployment dashboard and communicate to SOC when a new agent enters the 30-day observation window.", "Establish a change freeze policy for agent capability manifests during the baseline observation window to avoid premature invalidation.", "Budget time-series storage at approximately 500 events/day per active agent credential and plan capacity accordingly." ], "failure_signals": [ "Telemetry collection gaps visible in the time-series store \u2014 indicates network connectivity issues between agent runtime and telemetry endpoint.", "Baseline recomputation jobs are falling behind real-time by more than 6 hours \u2014 indicates compute capacity constraints in the analytics pipeline." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations start with no per-agent behavioral baselines; even basic tool-access and action-frequency profiling represents a significant maturity uplift over the initial state." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "IAM Team", "SIEM Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 5", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 5 has the enterprise monitor and measure the integrity and security posture of all owned and associated assets; behavioral baseline establishment is the foundational mechanism for monitoring agent identity posture.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Risk Assessments", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar's Risk Assessments function calls for identity risk determinations informed by runtime behavior; per-identity baselines supply the analytics that make those determinations possible.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "partial", "rationale": "SP 800-63B-4 \u00a73 addresses authenticator requirements and management; behavioral baselines extend that management surface to include runtime use monitoring beyond issuance.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail Insights \u2014 Behavior Baseline", "rationale": "AWS CloudTrail Insights establishes a statistical baseline of normal API call volume per identity type and generates Insights events when API activity deviates from the baseline by a statistically significant margin. This provides automated credential-use baseline detection for IAM roles used by AI agents, with no custom ML model required.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail Insights baselines API call volume per identity, one dimension of the multi-factor tool/frequency/volume/time/ASN baseline required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta ThreatInsight \u2014 Machine Identity Baseline", "rationale": "Okta ThreatInsight continuously builds per-identity behavior baselines from System Log telemetry, tracking authentication patterns, access times, source IPs, and accessed resources for machine identities. Deviations from the established baseline are surfaced as risk indicators that can trigger automated policy responses.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta ThreatInsight builds auth-centric per-identity baselines (times, IPs, resources) but not the tool and data-volume dimensions the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google SAIF \u2014 Extend detection and response to AI (behavioral baselines)", "rationale": "Google SAIF's element 'Extend detection and response to bring AI into an organization's threat universe' directs organizations to baseline AI workload behavior as a prerequisite for anomaly detection. Cloud IAM audit logs feed Cloud Monitoring for per-service-account access baseline establishment before anomaly alerting is configured.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Google SAIF directs orgs to baseline AI workload behavior and feeds logs to monitoring, but does not itself produce the structured baseline record.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://identity/controls/IM-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every active AI agent credential must have a current behavioral baseline record in the identity registry, established after a minimum 30-day observation window, capturing tool_ids accessed, action frequency distribution, data volume range, time-of-day histogram, and expected source ASN set. The baseline must be automatically invalidated and restarted when the agent's credential is re-issued or its deployment manifest version changes.", "evidence_required": [ "baseline_coverage_report listing each active credential_id with baseline_established_at timestamp, observation_window_days, and profile_fields_populated count", "baseline_snapshot_export for a sample of 5 credentials showing tool_id set, action_frequency_mean, action_frequency_stddev, time_of_day_histogram, and source_asn_set", "baseline_invalidation_event_log showing credential re-issuance events paired with corresponding baseline_reset events within 60 seconds", "telemetry_pipeline_config confirming agent runtime emits structured events per action with required fields: tool_id, action_type, resource_target, bytes_read, bytes_written, source_ip, timestamp_utc" ], "machine_tests": [ "Query identity registry for all active agent credentials and verify 100% have a baseline record with baseline_established_at within the last 35 days \u2192 assert zero credentials with missing or expired baseline", "Re-issue a test agent credential via the credential lifecycle API and poll the identity registry every 5 seconds \u2192 assert baseline_valid=false and observation_window_reset=true within 60 seconds of re-issuance", "Inject synthetic telemetry events for a test agent using a tool_id not in its baseline profile \u2192 assert IM-02 anomaly event is generated within 60 seconds referencing the IM-01 baseline_id" ], "human_review": [ "Review 5 sampled baseline records to confirm that tool_id sets reflect the agent's actual documented capability manifest and that no baseline silently omits tools the agent uses regularly", "Assess whether the 30-day observation window configuration is appropriate for each agent's operational cadence, including seasonal or cyclical batch agents that may need longer windows", "Verify that the telemetry pipeline architecture prevents agent credentials from writing to or deleting their own telemetry records" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Sharing a single behavioral baseline across multiple agent identities with different roles, causing individual anomalies to be masked by population averaging", "Starting the observation window immediately at deployment without a warm-up period, producing baselines from atypical initial-usage patterns that generate chronic false positives", "Retaining stale baselines indefinitely after credential re-issuance or deployment manifest changes, causing legitimate new tool usage to be flagged as anomalous", "Storing baseline data in a datastore the agent runtime has read-write access to, enabling a compromised agent to manipulate its own profile to evade detection", "Computing baselines from fewer than 7 days of data during pilot periods and treating the resulting profiles as production-grade" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-02", "layer": "IM", "plane": "both", "name": "Anomalous Credential Use Detection", "plain": "Detects deviations from established credential use baselines including unusual tool access, off-hours activity, high-frequency action bursts, and the required scope accumulation sub-check that identifies agents whose effective scope exceeds their currently authorized floor. References apeiris://authority/controls/PA-01 \u2014 org hierarchy changes (group removals, reporting structure changes, team transfers) trigger scope floor recalculation for all agents under affected principals. IM-02 must reconcile detected scope against the current PA-01 authorization floor to distinguish legitimate re-scoped access from unauthorized accumulation.", "threat": { "tags": [ "credential-compromise", "privilege-escalation", "lateral-movement" ], "desc": "Compromised AI agent credentials are frequently used in ways that deviate from the agent's established behavioral pattern \u2014 accessing unfamiliar tools, operating at unusual hours, or issuing actions at abnormal rates. Without deviation detection, these indicators are invisible. A specific and dangerous class of accumulation attack occurs when an agent retains access rights from previous role assignments or group memberships that were revoked; the agent's effective scope silently exceeds what current policy would authorize, creating a privilege escalation path that standard access reviews miss because each individual grant looks authorized. Reconciling effective scope against the recomputed authorization floor (PA-01) is the only reliable way to detect accumulated privilege." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 5", "title": "Monitor and measure the integrity and security posture of all assets" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Risk Assessments", "title": "Identity risk assessment informed by behavioral analytics" }, { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "General authenticator requirements \u2014 binding and management" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-02 Anomalous Credential Use Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Subscribe to IM-01 telemetry stream and continuously compare incoming events against the credential's stored baseline profile using statistical deviation scoring. In parallel, run the scope accumulation sub-check: retrieve the agent's current effective scope (all grants, group memberships, and delegated rights), recompute the authorization floor by replaying current PA-01 org hierarchy and policy assignments from scratch, and flag any delta as an accumulation finding. Alert thresholds: >3\u03c3 deviation triggers review; >5\u03c3 triggers automated scope enforcement. Cross-reference PA-01 (apeiris://authority/controls/PA-01) for org hierarchy change events that trigger scope floor recalculation.", "steps": [ "Subscribe to IM-01 telemetry events and compute a real-time z-score for each incoming event against the credential's baseline mean and \u03c3 for that metric; emit an anomaly event to the alert queue when z-score exceeds 3 on any dimension (tool access, action frequency, data volume, time-of-day, network context).", "Implement the scope accumulation sub-check as a scheduled job (minimum daily, triggered additionally by PA-01 org change events): enumerate all direct grants, group membership grants, and delegated rights for each agent credential; recompute the authorization floor by evaluating current PA-01 policy against current group memberships only; compare effective scope to floor and emit an accumulation finding for any rights present in effective scope but absent from the recomputed floor.", "For behavioral anomalies at >5\u03c3 or scope accumulation findings, trigger automated enforcement: suspend the over-scope right or rate-limit the credential pending human review; for behavioral anomalies at >3\u03c3, emit an alert-only event to the SOC queue with the specific deviation detail and the baseline value for context.", "Track false positive rates per agent and review monthly; persistent false positives on a specific tool or action type indicate that the IM-01 baseline requires refinement or that the agent's capability manifest (NI-02) is outdated and requires update." ], "anti_patterns": [ "Applying a single global deviation threshold across all agent types \u2014 high-frequency batch agents have fundamentally different baseline profiles than interactive query agents and require separate thresholds.", "Running the scope accumulation sub-check only on a monthly cadence \u2014 org hierarchy changes (group removals, role transfers) can introduce accumulation windows of weeks before detection.", "Suppressing anomaly alerts during maintenance windows without logging the suppression \u2014 creates an evasion window that sophisticated attackers can exploit by timing attacks to coincide with known maintenance periods." ] }, "validation": { "design_check": [ "Verify that the anomaly detection pipeline subscribes to IM-01 telemetry and computes per-credential z-scores in near-real-time (latency <60 seconds from event emission to alert generation).", "Confirm that the scope accumulation sub-check configuration references the PA-01 org hierarchy endpoint and that PA-01 change events are wired to trigger sub-check execution.", "Review the alert routing configuration to confirm >3\u03c3 alerts go to SOC queue and >5\u03c3 alerts trigger automated enforcement actions." ], "runtime_test": [ "Inject a synthetic action burst at 10\u00d7 the baseline action frequency for a test credential and verify an anomaly alert is generated within 60 seconds with z-score >5.", "Modify a test agent's group membership to remove a group and verify that the scope accumulation sub-check detects the residual right within one execution cycle.", "Simulate a PA-01 org change event (team transfer) and verify it triggers an immediate scope floor recalculation for all agents under the affected principal." ], "evidence": [ "anomaly-alert-log: sample of 10 anomaly events showing credential_id, z-score, dimension flagged, and baseline value [unverified]", "scope-accumulation-report: most recent sub-check output listing any accumulation findings and their remediation status [unverified]", "pa01-trigger-log: log entries showing PA-01 change events triggering scope floor recalculation [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The scope accumulation sub-check is the highest-value detection in this control and the most commonly missing capability. Most IAM systems grant rights accurately at provisioning time but have no mechanism to detect drift between effective scope and the current authorization floor after org changes. Building this sub-check requires a recomputable authorization model \u2014 not just a list of current grants \u2014 which is a significant engineering investment but essential for detecting privilege creep in long-running agent deployments.", "actions": [ "Implement the authorization floor recomputation as a pure function that takes current PA-01 org hierarchy and current group memberships as inputs and produces the minimal authorized scope set as output, making it testable and auditable.", "Wire PA-01 change event webhooks to trigger scope floor recalculation for all agents under the affected principal within 15 minutes of the change event.", "Build a remediation workflow that presents accumulation findings to IAM reviewers with one-click right removal and documents the resolution for audit purposes." ], "failure_signals": [ "Accumulation sub-check output shows zero findings despite recent org hierarchy changes \u2014 indicates the PA-01 event trigger is not wired correctly.", "Alert queue shows anomaly events without baseline values in the event payload \u2014 indicates the detection pipeline is not fetching baseline context at alert time." ] }, "security_architect": { "summary": "IM-02 is the runtime enforcement boundary for behavioral anomalies and scope drift; it converts the passive observation in IM-01 into active threat signals. The cross-domain dependency on PA-01 for scope floor recalculation means that authority domain integrity directly affects the correctness of identity monitoring. Architect the integration so that PA-01 change events are signed and authenticated before triggering scope recalculations, to prevent a compromised authority domain from masking accumulation findings.", "actions": [ "Design the PA-01 integration with signed event envelopes so that IM-02 verifies the PA-01 event signature before executing scope floor recalculation triggered by that event.", "Implement automated enforcement actions (credential rate-limiting, right suspension) as reversible operations that log the enforcement event and the triggering anomaly, enabling post-incident review.", "Establish a formal false positive review process and track false positive rates as a quality metric for the IM-01 baseline system." ], "failure_signals": [ "Automated enforcement actions are irreversible (credential hard-revocation on >5\u03c3) rather than temporary suspension \u2014 creates operational disruption for high-volatility legitimate agents.", "PA-01 event integration lacks authentication \u2014 a compromised authority domain event could trigger incorrect scope floor recalculations." ] }, "legal_counsel": { "summary": "Scope accumulation findings have direct legal relevance: they indicate that an AI agent may have been operating with more access than it was authorized to have, which could constitute a data governance violation under GDPR (data minimization), HIPAA (minimum necessary), or financial regulations (least privilege). Each accumulation finding should be treated as a potential compliance incident until reviewed and closed.", "actions": [ "Establish a policy that accumulation findings are documented in the compliance incident log with a 30-day remediation SLA.", "Review historical accumulation findings before audits to ensure all findings have been closed and root causes documented.", "Consult legal counsel on disclosure obligations if accumulation findings reveal that an agent accessed regulated data beyond its authorized scope." ], "failure_signals": [ "Accumulation findings are closed without documenting whether the agent exercised the excess rights \u2014 creates a gap in the evidence trail for regulators.", "Scope accumulation findings are not treated as compliance incidents \u2014 creates liability exposure if regulators discover the organization was aware of over-privileged agents." ] }, "grc_auditor": { "summary": "The scope accumulation sub-check is a direct audit control for least-privilege compliance. Auditors should request the most recent sub-check output and verify that all findings have remediation records with completion timestamps. The cross-domain dependency on PA-01 means that authority domain audit findings can have cascading effects on identity monitoring effectiveness \u2014 note this dependency when scoping joint audits.", "actions": [ "Request the scope accumulation sub-check execution log showing run frequency, number of credentials evaluated, and number of findings per run.", "Sample 5 closed accumulation findings and verify that the remediation action (right removal) was executed and that the agent's effective scope post-remediation matches the recomputed floor.", "Verify that PA-01 org change events are logged with timestamps and that IM-02 sub-check executions triggered by those events are traceable in the audit log." ], "metrics": [ "Scope accumulation finding rate: number of active accumulation findings per 100 agent credentials.", "Mean time to remediate accumulation findings: target <5 business days from detection to right removal." ], "failure_signals": [ "Sub-check output shows the same findings across multiple consecutive runs without remediation \u2014 indicates findings are not being actioned.", "Sub-check execution frequency is less than daily \u2014 creates accumulation windows that exceed acceptable exposure." ] }, "it_operations": { "summary": "The anomaly detection pipeline must process high-volume telemetry streams in near-real-time; at scale, this requires dedicated compute capacity separate from the agent runtime to avoid monitoring overhead affecting agent performance. Operations teams should monitor the detection pipeline latency (target <60 seconds from event to alert) as an SLA metric and capacity-plan for peak telemetry volumes during business hours.", "actions": [ "Deploy the anomaly detection pipeline on dedicated infrastructure isolated from the agent runtime to prevent monitoring overhead from affecting agent performance.", "Set up pipeline health monitoring with alerting on processing latency >120 seconds (2\u00d7 the 60-second SLA) and on queue depth growth indicating processing backlog.", "Coordinate with IAM team on the scope accumulation sub-check run schedule to avoid triggering heavy recalculation jobs during peak agent traffic hours." ], "failure_signals": [ "Telemetry processing latency exceeds 60 seconds during peak hours \u2014 indicates the detection pipeline needs horizontal scaling.", "Scope accumulation sub-check jobs are timing out for large credentials populations \u2014 indicates the authorization floor recomputation is not efficiently indexed." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Behavioral anomaly detection requires IM-01 baselines as a prerequisite; scope accumulation detection requires a recomputable authorization model that most organizations do not yet have in place." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "IAM Team", "SIEM Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 5", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 5 requires continuous monitoring and measurement of asset security posture; behavioral deviation detection and scope accumulation checking implement real-time monitoring of agent identity posture.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Risk Assessments", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar's Risk Assessments function expects identity risk to be continuously assessed from behavioral signals; IM-02 implements the detection layer that produces those signals.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "partial", "rationale": "SP 800-63B-4 \u00a73's authenticator management discipline is extended by runtime use monitoring; scope accumulation detection directly supports continuous assurance of the authenticator binding.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS GuardDuty \u2014 IAM Finding Types", "rationale": "AWS GuardDuty IAM finding types use ML-based behavioral modeling to detect credential compromise (UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration), unusual API calls from new geolocations (Discovery:IAMUser/AnomalousBehavior), and anomalous permission usage patterns. GuardDuty establishes per-identity normal profiles and generates findings when behavior deviates significantly.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS GuardDuty ML detects credential-compromise and geo anomalies but not the per-credential z-scores or scope-accumulation sub-check the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta ThreatInsight \u2014 Anomalous Auth Detection", "rationale": "Okta ThreatInsight applies ML-based risk scoring to detect anomalous authentication patterns for machine identities including new source IP authentication, authentication from new ASNs, impossible travel, and unusual access time patterns. High-risk authentication events can trigger automated policy responses including step-up verification or session termination.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta ThreatInsight risk-scores anomalous auth (new IP/ASN, impossible travel) but not the multi-dimensional z-scores and scope-accumulation sub-check.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Security Command Center \u2014 Threat Detection", "rationale": "Google Security Command Center Threat Detection identifies anomalous service account activity including unusual API call patterns, privilege escalation attempts, anomalous credential usage from unexpected source IPs, and cross-project access anomalies. Security Command Center generates findings that can trigger automated remediation via Cloud Functions.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP Security Command Center flags anomalous service-account activity, covering part of the required z-score thresholds and scope-accumulation sub-check.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Anomaly detection", "fit": "direct", "rationale": "Anomaly detection (threshold/statistical/ML) on credential and access behavior \u2014 anomalous credential use detection.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The anomaly detection pipeline must compute per-credential z-scores in near-real-time (within 60 seconds of event emission) across all baseline dimensions, generate alerts at the correct severity thresholds (>3sigma advisory, >5sigma enforcement), and the scope accumulation sub-check must execute at least daily and on every PA-01 org hierarchy change event, producing findings for any agent whose effective scope exceeds the recomputed PA-01 authorization floor.", "evidence_required": [ "anomaly_alert_log sample of 10 events each containing credential_id, timestamp, z_score, dimension_flagged, baseline_value, and alert_severity", "scope_accumulation_report from the most recent sub-check execution listing credentials evaluated, accumulation_findings_count, and remediation_status for each finding", "pa01_trigger_log showing PA-01 org change events paired with corresponding IM-02 scope floor recalculation executions and their completion timestamps", "detection_latency_measurement report confirming mean latency from telemetry event emission to alert generation is under 60 seconds over a 7-day sample period" ], "machine_tests": [ "Inject a synthetic burst of 100 tool invocations in 30 seconds for a test credential with a baseline frequency of 10/minute \u2192 assert an anomaly alert with z_score>5 and severity=CRITICAL is generated within 60 seconds", "Remove a group membership from a test agent in the identity registry and trigger a PA-01 change event \u2192 assert the scope accumulation sub-check runs within 15 minutes and produces a finding for the residual right", "Simulate off-hours tool access (outside the baseline time-of-day histogram) for a test credential \u2192 assert a z_score>3 advisory anomaly event is emitted and routes to the SOC queue" ], "human_review": [ "Review the scope accumulation sub-check output from the last 30 days and verify all findings have documented remediation actions with completion timestamps", "Assess whether per-agent deviation thresholds are calibrated appropriately for high-frequency batch agents versus low-frequency interactive agents, as a single global threshold will produce incorrect severities for both types", "Verify that PA-01 integration events are authenticated before triggering scope floor recalculations to prevent a compromised event source from masking accumulation findings" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Applying a single global z-score threshold across all agent types, causing batch agents with inherently high action frequency to generate constant false positives while interactive agents go undetected", "Running the scope accumulation sub-check only monthly rather than daily, creating multi-week windows during which accumulated excess rights are undetected after org hierarchy changes", "Suppressing anomaly alerts during maintenance windows without logging the suppression period, creating exploitable detection blind spots that sophisticated attackers can time attacks around", "Closing accumulation findings by adjusting the authorization floor upward rather than removing the excess right, converting a security finding into a policy ratification", "Running the scope accumulation sub-check only against the current grant list without recomputing the authorization floor from PA-01, making it impossible to detect accumulated drift from org changes" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-03", "layer": "IM", "plane": "both", "name": "Impossible Travel and Context Anomaly Detection", "plain": "Detects logically impossible credential use patterns including simultaneous use from multiple locations, access from unexpected network contexts, and use after confirmed revocation.", "threat": { "tags": [ "credential-compromise", "identity-spoofing", "lateral-movement" ], "desc": "Credential theft results in simultaneous use of the same identity from geographically disparate locations \u2014 the original agent continues operating in its deployment environment while the attacker uses the stolen credential from a different network. Impossible travel detection (verifying that a credential cannot physically have moved between two observed locations in the elapsed time) is a high-confidence, low-false-positive signal for credential compromise. Post-revocation access attempts indicate either a broken revocation propagation (IF-06 failure) or an attacker who captured a credential token before revocation and is replaying it; either case requires immediate blocking. Network context anomalies (agent calling from an unexpected IP range or ASN) identify agent process escapes, compromised container environments, or SSRF-mediated credential exfiltration." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 5", "title": "Monitor and measure the integrity and security posture of all assets" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Risk Assessments", "title": "Identity risk assessment informed by behavioral analytics" }, { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a74", "title": "Authenticator event management \u2014 revocation" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-03 Impossible Travel and Context Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-03 Impossible Travel and Context Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-03 Impossible Travel and Context Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-03 Impossible Travel and Context Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-03 Impossible Travel and Context Anomaly Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "For each authentication event, record source IP and resolve to geolocation (lat/lon) and ASN. For subsequent events on the same credential, compute the minimum required travel speed between the two observed locations given the elapsed time; flag if required speed exceeds 900 km/h (commercial aviation maximum). Maintain a credential revocation cache (populated from IF-06 revocation events); check every authentication attempt against the cache before granting access. Compare source ASN against the expected ASN set from the IM-01 baseline and alert on divergence.", "steps": [ "At every authentication and API access event, record source_ip, resolve to geolocation (lat/lon, accuracy radius) and ASN using a GeoIP database updated weekly; store both the previous and current observations per credential in a sliding window.", "Compute the impossible travel check: given the geodesic distance between consecutive source locations and the elapsed time, calculate required travel speed; if required speed >900 km/h, emit an impossible-travel anomaly event with severity HIGH; if simultaneous use is detected (two concurrent sessions with same credential_id from different IPs), emit with severity CRITICAL and initiate automated credential suspension.", "Maintain a local revocation cache populated by IF-06 revocation event stream with TTL equal to credential max token lifetime plus 5 minutes; check every incoming access request against the revocation cache before forwarding to the access decision point \u2014 if the credential appears in the revocation cache, block the request immediately and emit a post-revocation-use event with severity CRITICAL.", "Compare the source ASN of each access event against the expected ASN set from the IM-01 baseline; emit a context-anomaly event for any ASN not in the expected set and initiate human review within 1 hour per the IM-08 playbook; do not automatically block on ASN anomaly alone to avoid service disruption from legitimate IP address changes, but escalate to critical if ASN anomaly co-occurs with behavioral anomaly." ], "anti_patterns": [ "Relying on client-reported geolocation rather than authoritative GeoIP resolution \u2014 clients can spoof location headers; always resolve server-side from the observed source IP.", "Using a stale revocation cache with TTL shorter than token max lifetime \u2014 creates a window where revoked tokens remain valid between cache refresh cycles.", "Auto-blocking on ASN anomaly without considering that cloud provider IP ranges change frequently \u2014 leads to high false positive rates for agents deployed on elastic cloud infrastructure." ] }, "validation": { "design_check": [ "Verify that geolocation resolution is performed server-side from observed source IPs, not from client-reported headers.", "Confirm revocation cache TTL is set to at least the maximum token lifetime plus a 5-minute safety margin.", "Review the impossible travel speed threshold configuration and confirm it is set to a value appropriate for the deployment context (900 km/h for global deployments; tighter thresholds appropriate for on-premises or regional deployments)." ], "runtime_test": [ "Use a test credential to make two concurrent API requests from IP addresses geolocated >1000 km apart within a 60-second window; verify a CRITICAL anomaly event is generated and the credential is suspended.", "Revoke a test credential via IF-06 and immediately attempt an API call with the revoked token; verify the request is blocked at the revocation cache layer and a post-revocation-use event is emitted within 60 seconds.", "Make an API call from a test credential using an IP address in an ASN not in the credential's baseline; verify a context-anomaly alert is generated and routed to human review." ], "evidence": [ "impossible-travel-detection-log: sample of impossible travel events with source IPs, geolocations, computed travel speed, and response actions [unverified]", "revocation-cache-config: documentation showing revocation cache TTL settings relative to token lifetime [unverified]", "post-revocation-block-log: log entries showing revoked credential access attempts being blocked [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The revocation cache is the most operationally critical component of this control; a stale or missing cache means that revoked credentials remain valid until token expiry, which may be hours or days depending on token lifetime configuration. The revocation cache must be populated in real-time from IF-06 revocation events, not from periodic polling, to minimize the revocation-to-enforcement gap.", "actions": [ "Implement the revocation cache as a subscribe-push model from IF-06 revocation events, not a periodic poll, to minimize revocation propagation latency.", "Set maximum token lifetime to 1 hour for AI agent credentials to bound the worst-case revocation window if the revocation cache becomes unavailable.", "Instrument the revocation cache miss rate (requests that bypassed the cache check) as a monitoring metric to detect cache availability issues." ], "failure_signals": [ "Revocation cache is populated via periodic polling rather than real-time event subscription \u2014 creates revocation windows proportional to polling interval.", "Token lifetime is set >24 hours for agent credentials \u2014 creates unacceptably long revocation windows." ] }, "security_architect": { "summary": "Impossible travel detection for machine identities differs from human identity detection: AI agents typically operate from known static environments (cloud provider ASNs, specific container network ranges) so the expected variance in source location is much lower than for human users. This means impossible travel thresholds can be set much tighter, and any unexplained location change should be treated as high-confidence compromise rather than a possible legitimate mobility event.", "actions": [ "Set impossible travel thresholds appropriate for the agent deployment model: for single-region cloud deployments, any use from outside the expected cloud provider ASN and region should trigger immediate suspension.", "Architect the revocation check as an inline synchronous check in the API gateway authentication path, not an asynchronous notification \u2014 revoked credentials must be blocked before the request is processed.", "Design impossible travel detection to handle IPv4/IPv6 dual-stack environments where the same agent may present different IP versions \u2014 ensure both stacks are resolved to the same geolocation and ASN for consistency." ], "failure_signals": [ "Revocation check is implemented as an asynchronous webhook notification rather than a synchronous inline check \u2014 revoked credentials process requests before revocation is enforced.", "Impossible travel detection is disabled for service-to-service API calls \u2014 creates a detection blind spot for inter-service credential compromise." ] }, "legal_counsel": { "summary": "Post-revocation access attempts may indicate that an attacker accessed systems and data after the organization believed the credential was disabled, which has significant implications for breach notification timelines and the accuracy of breach scope assessments. All post-revocation-use events must be preserved as potential breach evidence and reviewed by counsel if they involve access to regulated data.", "actions": [ "Treat every post-revocation-use event as a potential breach indicator and route to legal review if the credential had access to regulated data.", "Ensure post-revocation-use event logs are preserved with litigation hold status if any event preceded or overlapped with a known security incident.", "Consult on breach notification obligations if post-revocation-use events indicate that an attacker accessed regulated data after revocation was intended but before enforcement." ], "failure_signals": [ "Post-revocation-use events are treated as operational anomalies rather than potential breach indicators \u2014 creates liability if the events are not reviewed before breach notification deadlines.", "Revocation event logs do not include the timestamp at which revocation was requested versus enforced \u2014 creates gaps in the breach timeline evidence." ] }, "grc_auditor": { "summary": "This control provides direct evidence for continuous re-authentication requirements under Zero Trust frameworks. Auditors should verify that the impossible travel and post-revocation checks are implemented as blocking controls (not just alerts) to confirm that detection translates to prevention.", "actions": [ "Request logs from the last 90 days showing any impossible travel events, their severity classification, and the response actions taken.", "Verify that revocation enforcement latency (time from IF-06 revocation event to revocation cache update) is <5 minutes through review of the cache update logs.", "Confirm that post-revocation-use events are tracked as security incidents with root cause analysis documentation." ], "metrics": [ "Revocation enforcement latency: mean time from revocation event to blocking enforcement; target <5 minutes.", "Post-revocation-use incidents: count per quarter; any non-zero count requires root cause analysis." ], "failure_signals": [ "Revocation enforcement latency exceeds 15 minutes \u2014 indicates the revocation cache is not receiving real-time updates.", "Impossible travel events result only in alerts, not in automated credential suspension \u2014 detection is not backed by enforcement." ] }, "it_operations": { "summary": "GeoIP database freshness is an operational dependency for this control; stale GeoIP data leads to incorrect geolocation resolution, false positives on impossible travel, and missed detection when cloud providers reallocate IP ranges. Establish a weekly GeoIP database refresh schedule and monitor for database age as part of the operations runbook.", "actions": [ "Schedule weekly GeoIP database updates from a commercial or authoritative provider and alert if the database age exceeds 10 days.", "Monitor revocation cache size and eviction rates to ensure the cache has sufficient capacity for the active credential population plus a buffer for recently revoked credentials.", "Maintain a list of known legitimate IP range changes (cloud provider ASN expansions, migration events) to prevent false impossible travel alerts during planned infrastructure changes." ], "failure_signals": [ "GeoIP database age exceeds 14 days \u2014 indicates the update schedule has failed and geolocation accuracy is degraded.", "Revocation cache eviction rate is non-zero \u2014 indicates the cache is undersized and recently revoked credentials may be evicted before their token expiry." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Impossible travel detection is well-understood for human identities but requires recalibration for machine identities operating from known static environments; the tighter thresholds for agents represent a maturity uplift from human-identity detection approaches." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "SIEM Engineering", "IAM Team" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 5", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 5's continuous monitoring of asset posture underpins impossible-travel and context anomaly detection \u2014 high-confidence monitoring for agent credential compromise.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Risk Assessments", "fit": "direct", "rationale": "Impossible travel and post-revocation access are identity-risk signals the CISA ZTMM Identity pillar's Risk Assessments function consumes; IM-03 produces these high-confidence compromise indicators.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a74", "fit": "direct", "rationale": "SP 800-63B-4 \u00a74 requires authenticator revocation to be enforced; post-revocation access detection verifies the effectiveness of revocation enforcement.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta Adaptive MFA \u2014 Impossible Travel Detection", "rationale": "Okta's adaptive MFA risk engine detects impossible travel and context anomalies for machine identity authentication events: new IP address authentication, authentication from a new autonomous system number (ASN), geographic velocity violations (travel time between sequential authentications shorter than possible by any means), and new device fingerprint registration. Detected anomalies trigger configurable policy responses.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta adaptive MFA detects impossible travel and context anomalies (new IP/ASN, geo-velocity) for machine identities - the named detection the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS GuardDuty \u2014 Instance Credential Exfiltration", "rationale": "AWS GuardDuty IAM finding type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration detects when EC2 instance-bound credentials (obtained via the instance metadata service) are used from an external IP address outside the instance \u2014 representing impossible travel for hardware-bound credentials. This is a high-confidence indicator of credential exfiltration in AI agent deployments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS GuardDuty instance-credential-exfiltration detects credential use from an unexpected context, a partial signal but not impossible-travel detection.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Anomaly detection; Part IV Phase 6 \u2014 Attribute-based Access Control (ABAC: source location, time of day)", "fit": "partial", "rationale": "ABAC evaluates source location/time and anomaly detection flags unusual context. Partial: doc does not name impossible-travel detection specifically.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every access event for an AI agent credential must be checked server-side against a revocation cache populated in real-time from IF-06 events, and consecutive access events from the same credential must be evaluated for impossible travel; any credential appearing in the revocation cache must be blocked before the request is forwarded, and any credential presenting concurrent use from geolocations requiring travel faster than 900 km/h must trigger a CRITICAL event and automated suspension.", "evidence_required": [ "impossible_travel_detection_log sample of events showing credential_id, source_ip_1, geolocation_1, source_ip_2, geolocation_2, elapsed_seconds, computed_speed_kmh, and response_action taken", "revocation_cache_config documentation showing TTL setting relative to maximum token lifetime with calculation demonstrating TTL >= max_token_lifetime + 300 seconds", "post_revocation_block_log entries showing revoked-credential access attempts blocked at the cache layer with IF-06 revocation_event_id cross-reference", "geoip_database_metadata confirming database version and last_updated_at within 10 days of the validation date" ], "machine_tests": [ "Make two concurrent API requests with the same test credential from IP addresses geolocated >1000 km apart within a 60-second window \u2192 assert a CRITICAL impossible-travel event is generated and the credential suspension is initiated within 60 seconds", "Revoke a test credential via the IF-06 API endpoint and immediately submit an API request using that credential's token \u2192 assert the request returns HTTP 401 and a post-revocation-use event with severity=CRITICAL is emitted within 30 seconds", "Submit an API request from a test credential using an IP address in an ASN not present in the credential's IM-01 baseline \u2192 assert a context-anomaly advisory alert is generated and routed to human review queue" ], "human_review": [ "Review revocation enforcement latency samples over the last 90 days and verify that mean time from IF-06 revocation event to cache update does not exceed 5 minutes", "Assess whether the 900 km/h impossible travel threshold is calibrated appropriately for the deployment model: single-region cloud deployments should use tighter thresholds tied to the specific cloud provider region", "Verify that post-revocation-use events are treated as potential breach indicators and routed to legal review when the revoked credential had access to regulated data" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Resolving geolocation from client-supplied headers (X-Forwarded-For, X-Real-IP) rather than authoritative server-side GeoIP resolution, enabling attackers to spoof their location to avoid detection", "Populating the revocation cache via periodic polling rather than real-time IF-06 event subscription, creating revocation windows proportional to the polling interval during which revoked tokens remain valid", "Auto-blocking on ASN anomaly without accounting for cloud provider elastic IP reassignments, causing false service disruptions for agents on dynamic infrastructure", "Setting revocation cache TTL shorter than the maximum token lifetime, allowing evicted entries to create windows where revoked tokens pass cache checks" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-04", "layer": "IM", "plane": "both", "name": "Privilege Escalation Attempt Detection", "plain": "Detects AI agent attempts to access resources or perform actions beyond their authorized scope, triggering immediate blocking of the over-scope request and an alert to the IAM team within 30 seconds.", "threat": { "tags": [ "privilege-escalation", "lateral-movement" ], "desc": "AI agents operate with narrowly defined capability manifests; attempts to access resources or invoke actions outside those manifests are a primary signal for either compromised credentials or a misbehaving agent that has been manipulated (e.g., through prompt injection) to attempt unauthorized actions. Privilege escalation via token manipulation (scope injection, token forgery, or JWT claim manipulation) is a technical attack vector where the agent modifies its own authorization token to claim broader permissions. Persistent false positives on specific tools or action types indicate that the agent's declared scope in NI-02 is incomplete and should be remediated through scope definition rather than alert suppression." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Strict, dynamic access control enforcement" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Risk Assessments", "title": "Identity risk assessment informed by behavioral analytics" }, { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "General authenticator requirements \u2014 binding and management" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-04 Privilege Escalation Attempt Detection control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-04 Privilege Escalation Attempt Detection control.", "reviewed_on": "2026-07-01" }, { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-04 Privilege Escalation Attempt Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-04 Privilege Escalation Attempt Detection control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IM-04 Privilege Escalation Attempt Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "At every access decision point (API gateway, resource authorization service), evaluate the incoming request against the agent's authorized scope: allowed resource set (from NI-01 capability manifest), allowed action types, and declared token scope claims. Reject any request that falls outside the authorized scope before the action is executed. Log all rejections as privilege escalation attempts with the specific over-scope dimension. Route alerts to the IAM SOC queue within 30 seconds. Track false positive rates per agent credential to identify scope definition gaps.", "steps": [ "Deploy an authorization enforcement layer at every API gateway and resource access point that evaluates each incoming agent request against the agent's current authorized scope (fetched from the identity registry using the credential_id from the request's authentication token), blocking requests that reference resources, action types, or scopes not in the manifest before any action is executed.", "Detect token manipulation attempts: validate that the scope claims in the incoming authentication token do not exceed the scope authorized at token issuance time (cross-reference with the issuance record in the identity registry); flag any token presenting broader scope than was issued as a privilege escalation attempt with severity CRITICAL.", "Emit a structured escalation-attempt event within <1 second of blocking: include credential_id, agent_id, requested resource, requested action_type, authorized scope (what was allowed), and the specific over-scope dimension; route the event to the SOC alert queue with a 30-second acknowledgment SLA.", "Track false positive rates monthly per agent credential: persistent escalation attempts on the same tool or action type across multiple sessions are a scope definition gap signal, not a security signal; route these to the IAM team for NI-02 scope review rather than treating them as ongoing threats." ], "anti_patterns": [ "Logging privilege escalation attempts without blocking the request \u2014 detection without enforcement provides no protection and creates audit records that appear more secure than the system is.", "Suppressing alerts for 'known-noisy' agents rather than fixing their scope definitions \u2014 the noise indicates a real gap between declared and actual required scope.", "Evaluating token scope claims without cross-referencing the issuance record \u2014 allows scope inflation attacks where an agent generates a new token with broader claims than were authorized." ] }, "validation": { "design_check": [ "Verify that authorization enforcement is implemented as a synchronous blocking check before request forwarding, not as an asynchronous post-hoc audit.", "Confirm that token scope claim validation cross-references the issuance record in the identity registry, not just the token's self-asserted claims.", "Review false positive tracking configuration: confirm monthly reports are generated and routed to IAM for scope review." ], "runtime_test": [ "Attempt an API call from a test agent credential to a resource not in its declared capability manifest; verify the request is blocked at the authorization layer and an escalation-attempt event is emitted within 1 second.", "Craft a test JWT with scope claims broader than were issued for a test credential and submit it; verify the token manipulation detection blocks the request and emits a CRITICAL alert.", "Simulate 10 consecutive escalation attempts on the same tool from a test credential and verify that a false-positive review ticket is generated and routed to the IAM team." ], "evidence": [ "escalation-attempt-log: sample of 10 blocked privilege escalation attempts with credential_id, requested resource, authorized scope, and over-scope dimension [unverified]", "token-manipulation-detection-log: log entries showing token scope claim validation rejections [unverified]", "false-positive-review-tickets: evidence that recurring escalation patterns trigger NI-02 scope review workflows [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The authorization enforcement layer must be positioned as a choke point that all agent API calls traverse; if any API surface bypasses the enforcement layer (e.g., internal service-to-service calls, sidecar proxies), the control has gaps. Enumerate all API entry points in the deployment and confirm enforcement coverage before declaring this control implemented.", "actions": [ "Enumerate all API entry points and internal service interfaces accessible to agent credentials and confirm that each is covered by the authorization enforcement layer.", "Build a scope coverage map showing which resources and action types are covered by authorization enforcement and identify any uncovered surfaces.", "Implement token issuance records that are queryable by the enforcement layer in <10ms to support the synchronous scope claim validation at request time." ], "failure_signals": [ "Internal service-to-service APIs do not require agent credentials or bypass the authorization enforcement layer \u2014 creates an unmonitored escalation surface.", "Authorization enforcement layer response time >100ms \u2014 indicates the issuance record lookup is adding unacceptable latency to the request path." ] }, "security_architect": { "summary": "Token manipulation detection requires comparing token claims to the canonical issuance record, which requires that token issuance is recorded in a tamper-evident registry queryable at validation time. If the identity system relies on self-contained tokens (e.g., JWTs) without an issuance registry, token manipulation detection is not possible; the architecture must include an issuance registry or short-lived tokens with server-side session records.", "actions": [ "Require that all agent credential tokens are backed by an issuance record in the identity registry, enabling scope claim validation at request time.", "Set maximum token lifetime to 1 hour for agent credentials to limit the window during which a manipulated token remains useful.", "Design the authorization enforcement layer to be stateless and horizontally scalable to handle peak agent traffic without becoming a latency bottleneck." ], "failure_signals": [ "Token issuance records are not persisted \u2014 token scope claim validation against issuance records is impossible, leaving token manipulation undetected.", "Authorization enforcement is implemented only at the external API gateway, not at internal service boundaries \u2014 allows escalation via internal paths." ] }, "legal_counsel": { "summary": "Privilege escalation attempts, especially those involving token manipulation, may constitute unauthorized access under computer fraud statutes (CFAA, Computer Misuse Act) if perpetrated by an external attacker, or may indicate an insider threat if the escalation is from a legitimate principal manipulating their own agent. Preserve escalation attempt logs with chain-of-custody documentation for potential law enforcement referral.", "actions": [ "Establish a policy for escalating CRITICAL privilege escalation events (token manipulation detected) to the legal team within 24 hours for assessment of reporting obligations.", "Ensure escalation attempt logs are preserved with integrity protection (hash chaining per IM-06) to support potential legal proceedings.", "Review escalation attempt patterns periodically to identify whether attempts appear to originate from insider activity versus external attacks \u2014 the response and disclosure obligations differ." ], "failure_signals": [ "CRITICAL token manipulation events are not escalated to legal review \u2014 creates a gap in the breach notification assessment process.", "Escalation attempt logs are not integrity-protected \u2014 reduces their evidentiary value in legal proceedings." ] }, "grc_auditor": { "summary": "Privilege escalation attempt detection operationalizes the least-privilege principle at runtime. Auditors should verify not only that the blocking control is in place but that persistent patterns are feeding back into scope definition improvements, demonstrating a continuous improvement cycle rather than a static control.", "actions": [ "Review the escalation attempt log for the audit period and verify that CRITICAL events (token manipulation) were investigated and closed with root cause documentation.", "Confirm that false positive review tickets are being generated and actioned \u2014 evidence of scope refinement based on monitoring feedback demonstrates control maturity.", "Verify that the authorization enforcement layer coverage includes all API surfaces accessible to agent credentials, not just external-facing endpoints." ], "metrics": [ "Privilege escalation attempt rate: count of blocked escalation attempts per 1000 agent API calls; declining trend indicates scope definitions are improving.", "CRITICAL escalation closure rate: percentage of CRITICAL (token manipulation) events closed with documented root cause within 5 business days." ], "failure_signals": [ "Escalation attempt rate is increasing over time without corresponding scope review actions \u2014 indicates monitoring is occurring but not driving remediation.", "Zero escalation attempts recorded across a large agent population \u2014 may indicate the enforcement layer is misconfigured and not logging blocks." ] }, "it_operations": { "summary": "The authorization enforcement layer sits in the hot path of every agent API call; its performance directly affects agent response latency. Benchmark the enforcement layer overhead and establish a maximum acceptable latency budget (recommended <10ms p99 for the authorization check alone) to ensure that security enforcement does not degrade agent performance to an unacceptable level.", "actions": [ "Benchmark the authorization enforcement layer latency in a load test environment at 2\u00d7 peak expected agent traffic and confirm p99 latency is within the 10ms budget.", "Monitor authorization enforcement layer error rates separately from agent errors to distinguish enforcement failures from agent failures in incident response.", "Cache agent scope records at the enforcement layer with a TTL of 5 minutes to reduce identity registry lookup latency without creating an unacceptable stale-scope window." ], "failure_signals": [ "Authorization enforcement layer p99 latency >50ms \u2014 indicates caching is not effective or the identity registry is a bottleneck.", "Authorization enforcement layer error rate >0.1% \u2014 indicates reliability issues that may be causing escalation events to be blocked from being logged." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many deployments have access control but lack the detailed scope claim validation against issuance records required for token manipulation detection; this represents the key maturity gap for most organizations." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "IAM Team", "Platform Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 6 requires strictly enforced, dynamic authorization; privilege escalation attempt detection implements real-time enforcement of access boundaries with logging of violations.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Risk Assessments", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar's Risk Assessments function expects identity threats to be assessed continuously; privilege escalation attempts are a primary identity risk for AI agent systems.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "partial", "rationale": "SP 800-63B-4 \u00a73 authenticator binding requirements are extended by runtime validation of scope claims against issuance records to prevent token manipulation.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS GuardDuty \u2014 Privilege Escalation Findings", "rationale": "AWS GuardDuty IAM finding types (PrivilegeEscalation:IAMUser/AdministrativePermissions, Policy:IAMUser/RootCredentialUsage) detect privilege escalation patterns including attempts to attach administrator policies, create new privileged users, and use root credentials. CloudTrail monitoring for iam:PutUserPolicy, iam:AttachRolePolicy, and iam:CreatePolicyVersion API calls provides fine-grained privilege escalation detection.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS GuardDuty detects privilege-escalation patterns but is detective; the control requires synchronous pre-execution scope evaluation and blocking.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Security Command Center \u2014 privilege escalation detection", "rationale": "Google Security Command Center detects IAM privilege escalation attempts including anomalous IAM role binding additions, unexpected service account key creation by non-administrator principals, and anomalous use of the iam.serviceAccounts.actAs permission. Findings are generated in near-real-time and can be routed to SIEM or incident response platforms.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP Security Command Center detects escalation attempts (role-binding, actAs abuse) but detectively, not the synchronous blocking the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II \u2014 Memory-based privilege retention (escalating privileges across session boundaries); Part III \u2014 Anomaly detection", "fit": "partial", "rationale": "Doc describes privilege escalation via cached credentials across sessions; anomaly detection surfaces it. Partial: doc does not prescribe a dedicated escalation-attempt detector.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent API request must be evaluated synchronously against the agent's authorized scope (drawn from its NI-01 capability manifest and token issuance record) before any action is executed; over-scope requests must be blocked and a structured escalation-attempt event emitted within 1 second, and JWT scope claims must be validated against the issuance record to detect token manipulation attempts.", "evidence_required": [ "escalation_attempt_log sample of 10 blocked events each containing credential_id, agent_id, requested_resource, requested_action_type, authorized_scope_set, over_scope_dimension, and timestamp", "token_manipulation_detection_log entries showing JWT scope claim validation rejections with the claimed_scope and issued_scope values compared", "authorization_enforcement_coverage_map listing all API entry points and confirming each is covered by the enforcement layer", "false_positive_review_tickets showing recurring escalation patterns routed to the IAM team for NI-02 scope review within the last 90 days" ], "machine_tests": [ "Submit an API request from a test agent credential targeting a resource not in the agent's NI-01 capability manifest \u2192 assert the request is blocked with HTTP 403 and an escalation-attempt event is emitted within 1 second with the over_scope_dimension field populated", "Generate a JWT for a test credential with scope claims broader than the issuance record and submit it to the API gateway \u2192 assert the token validation layer rejects the request with error=scope_inflation_detected and a CRITICAL alert is emitted", "Simulate 10 consecutive escalation attempts on the same tool_id from a test credential within a 5-minute window \u2192 assert a false-positive review ticket is auto-generated and routed to the IAM team" ], "human_review": [ "Review the authorization enforcement coverage map to confirm all internal service-to-service API surfaces accessible to agent credentials are covered, not just external-facing endpoints", "Assess CRITICAL token manipulation events from the last 90 days and verify each was investigated with a documented root cause and whether law enforcement referral was considered", "Verify that persistent false positive patterns have resulted in NI-02 scope definition updates, demonstrating that monitoring is feeding back into control improvement" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Implementing privilege escalation detection as an asynchronous post-hoc audit rather than a synchronous blocking check, allowing over-scope actions to execute before detection fires", "Validating JWT scope claims against the token's self-asserted values rather than the canonical issuance record, making scope inflation attacks undetectable", "Suppressing escalation alerts for agents labeled as known-noisy rather than fixing their NI-02 scope definitions, accumulating unreviewed escalation events that mask real attacks", "Deploying the authorization enforcement layer only at the external API gateway while leaving internal service-to-service paths uncovered, creating an unmonitored escalation surface" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-05", "layer": "IM", "plane": "both", "name": "Credential Sharing Detection", "plain": "Detects patterns indicating that an AI agent credential is being used by multiple agent instances simultaneously or by a human actor, which indicates credential compromise or deliberate credential sharing in violation of II-05.", "threat": { "tags": [ "credential-compromise", "lateral-movement", "identity-spoofing" ], "desc": "AI agent credentials are scoped to a specific agent identity and should never be used by more than one agent instance or by a human. Credential sharing \u2014 whether due to misconfiguration, deliberate policy bypass, or credential theft \u2014 collapses the attribution model and makes it impossible to determine which actions were taken by which actor. Human use of an agent credential is particularly dangerous because humans are not bound by the same behavioral constraints as agent runtimes and can use the credential to perform arbitrary actions at human cognitive speed and creativity. Detection is based on behavioral fingerprinting: the timing regularity, request structure, and interaction patterns of an automated agent process differ fundamentally from human interaction patterns, enabling statistical discrimination between machine and human usage of the same credential." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "Authenticator uniqueness and binding" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 6", "title": "Strict, dynamic access control enforcement" }, { "id": "iso_24760", "section": "\u00a78", "title": "Identification \u2014 reliable binding of identity information to an entity" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-05 Credential Sharing Detection control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-05 Credential Sharing Detection control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IM-05 Credential Sharing Detection control.", "reviewed_on": "2026-07-02" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-05 Credential Sharing Detection control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-05 Credential Sharing Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Track concurrent session counts per credential_id and flag any credential with >1 concurrent session as a potential sharing event. Apply ASN-based heuristics to detect human-origin access: cloud provider ASNs are expected for agent-origin calls; residential ISP and corporate enterprise ASNs indicate human-origin calls. Apply behavioral fingerprinting: machine requests exhibit timing regularity (low inter-request variance), consistent request structure (same headers, same user-agent pattern), and no typo-correction patterns; human requests exhibit irregular timing, varied request structure, and interactive query patterns. Classify all access events as machine-origin or human-origin using the fingerprint model; human-origin classification on an agent credential triggers immediate CRITICAL alert and credential revocation.", "steps": [ "Instrument the authentication layer to track active concurrent session count per credential_id in a distributed session counter (e.g., Redis INCR/DECR with TTL equal to session timeout); emit a credential-sharing-suspected event if concurrent session count exceeds 1, with severity proportional to the count (2 concurrent = HIGH, 3+ = CRITICAL).", "Apply ASN origin classification to every access event: resolve source IP ASN and classify as 'cloud-origin' (matches known cloud provider ASN lists: AWS, GCP, Azure, major hyperscalers) or 'human-origin' (residential ISP ASNs, corporate enterprise ASNs, mobile carrier ASNs); any human-origin classification on an agent credential immediately emits a human-use-of-agent-credential CRITICAL event.", "Apply behavioral fingerprint scoring to each session: compute inter-request timing variance (machine sessions have variance <10% of mean; human sessions >30%), request structure regularity (machine sessions repeat identical header sets; human sessions show User-Agent variation, Accept-Language changes), and query pattern regularity (machine sessions use structured API patterns; human sessions show exploratory query patterns); sessions scoring in the human range trigger escalation to IM-08 credential compromise playbook.", "Human-use-of-agent-credential is a severity-1 incident: initiate immediate credential revocation via IF-06, alert IAM and security teams within 5 minutes, initiate forensic review of all access events since the credential was last confirmed as machine-only, and require post-incident review of how the credential was obtained by the human actor." ], "anti_patterns": [ "Treating concurrent sessions as a definitive sharing indicator without considering legitimate multi-region agent deployments where the same credential is used by agent replicas \u2014 architect multi-replica deployments to use per-instance credentials derived from a root credential, not a shared credential.", "Relying solely on ASN classification for human detection \u2014 VPNs and cloud-hosted browsers can mask human origin ASNs; always apply behavioral fingerprinting as a second layer.", "Suppressing human-origin alerts for credentials used by on-call engineers 'for troubleshooting' \u2014 this is exactly the credential sharing pattern the control is designed to detect; engineers must use human credentials for human access." ] }, "validation": { "design_check": [ "Confirm that multi-replica agent deployments use per-instance credentials, not a single shared credential across replicas.", "Review the ASN classification lists for cloud provider ASNs and confirm they are updated at least monthly as cloud provider IP ranges evolve.", "Verify that human-use-of-agent-credential events are routed to the IM-08 credential compromise playbook, not just to a monitoring dashboard." ], "runtime_test": [ "Use a browser to make an API call with a test agent credential and verify a human-use-of-agent-credential CRITICAL event is generated within 60 seconds and the credential suspension is initiated.", "Simulate concurrent access from two distinct agent instances using the same test credential from the same cloud provider ASN and verify a credential-sharing-suspected HIGH event is generated.", "Verify that behavioral fingerprint scoring correctly classifies a scripted human-paced session (irregular timing, varied headers) as human-origin versus a regular machine-paced session." ], "evidence": [ "human-use-detection-log: log entries showing human-origin classification events on agent credentials [unverified]", "concurrent-session-events: sample of credential-sharing-suspected events with session counts and source ASNs [unverified]", "behavioral-fingerprint-scores: distribution of machine vs human fingerprint scores across active agent sessions [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The most common failure mode for this control is agent deployments that use a single shared credential across multiple agent replicas for operational convenience \u2014 this immediately creates false concurrent session sharing alerts. The IAM architecture must mandate per-instance credentials, which requires the credential issuance pipeline to support high-volume credential generation and rotation at scale proportional to the number of agent replicas.", "actions": [ "Audit all multi-replica agent deployments and confirm that each replica uses a unique per-instance credential derived from a root identity, not a shared static credential.", "Build the credential issuance pipeline to support bulk issuance of per-instance credentials at container or pod startup time, with automatic revocation on instance termination.", "Implement a credential lineage registry that tracks parent-child relationships between root identities and instance credentials, enabling aggregate monitoring of a logical agent across its replicas." ], "failure_signals": [ "Multi-replica deployments using a single shared credential \u2014 triggers high-volume false concurrent session alerts and makes the control unusable in practice.", "Credential issuance pipeline cannot support per-instance credential generation at the scale of the container orchestration environment \u2014 forces engineers to reuse credentials." ] }, "security_architect": { "summary": "Behavioral fingerprinting for human vs machine detection is an area where adversarial evasion is possible: a sophisticated attacker with automation tooling could mimic machine timing patterns to avoid detection. The control should not be relied upon as the sole detection mechanism; the combination of ASN classification, concurrent session detection, and behavioral fingerprinting provides defense-in-depth that raises the bar for evasion significantly above what a casual attacker would implement.", "actions": [ "Implement the three-layer detection model (ASN classification, concurrent session tracking, behavioral fingerprinting) as independent detection mechanisms that each generate alerts, not as a single composite score that an attacker could optimize against.", "Periodically red-team the behavioral fingerprinting model to assess evasion difficulty and update fingerprint features accordingly.", "Consider adding client TLS certificate binding to agent credentials so that credential use from a non-enrolled client environment is detectable regardless of behavioral patterns." ], "failure_signals": [ "Behavioral fingerprinting is the only detection mechanism without ASN classification or concurrent session tracking \u2014 single-layer detection is easily evaded.", "Fingerprint model has not been reviewed or updated in >6 months \u2014 adversarial drift may have reduced detection effectiveness." ] }, "legal_counsel": { "summary": "Human use of an AI agent credential creates a complex attribution problem: actions taken by a human using an agent credential will appear in audit logs as agent actions, potentially misattributing human decisions to an AI system. This has significant implications for accountability frameworks, AI governance policies, and potentially for litigation if the human-operated-as-agent committed a harmful action. Preserve human-use-of-agent-credential event logs with chain-of-custody protection.", "actions": [ "Ensure that human-use-of-agent-credential incidents are documented with the specific actions taken during the human session for retroactive attribution in audit logs.", "Review AI governance policy to confirm that human use of agent credentials is explicitly prohibited and that the prohibition is enforced rather than just stated.", "Consult on any regulatory implications of AI actions that were actually taken by a human using an agent credential \u2014 AI liability frameworks may not apply to human actors." ], "failure_signals": [ "Audit logs do not retroactively flag actions taken during a confirmed human-use-of-agent-credential session \u2014 creates false attribution of human decisions to AI systems.", "AI governance policy does not explicitly prohibit human use of agent credentials \u2014 creates a policy gap that may be exploited to avoid accountability." ] }, "grc_auditor": { "summary": "This control directly addresses the identity uniqueness requirement that underlies AI attribution \u2014 each action must be attributable to a specific, singular identity. Auditors should verify not only that the detection is in place but that the architectural controls (per-instance credentials, no shared credentials) are implemented to eliminate the credential sharing vectors rather than merely detecting them after the fact.", "actions": [ "Sample 10 multi-replica agent deployments and confirm each replica uses a unique per-instance credential in the identity registry.", "Review the human-use-of-agent-credential incident log for the audit period and confirm all incidents have closed root cause analyses.", "Verify that the concurrent session counter is implemented with distributed consistency guarantees rather than a single-node counter that could miss concurrent sessions in distributed deployments." ], "metrics": [ "Human-use-of-agent-credential incidents per quarter: target zero; any occurrence requires root cause analysis and credential architecture review.", "Shared credential rate: percentage of multi-replica deployments using shared versus per-instance credentials; target 0% shared." ], "failure_signals": [ "Human-use-of-agent-credential incidents are classified as LOW severity \u2014 indicates the organization does not recognize the severity of the attribution and attribution failure.", "Per-instance credential adoption rate is below 90% \u2014 indicates the credential issuance pipeline does not support the required deployment patterns." ] }, "it_operations": { "summary": "Per-instance credential requirements significantly increase credential volume: a deployment of 500 agent replicas requires 500 unique credentials rather than 1 shared credential, increasing issuance, storage, and rotation overhead by two orders of magnitude. Credential management automation is essential at this scale; manual credential management is not operationally viable.", "actions": [ "Implement automated credential issuance and revocation integrated with the container orchestration platform (Kubernetes ServiceAccount tokens, or equivalent) to eliminate manual credential management.", "Establish capacity planning for the credential management infrastructure at the maximum expected agent replica count plus a 3\u00d7 growth buffer.", "Monitor credential issuance failure rates at pod startup as an operational reliability metric \u2014 failed issuance means the agent starts without a valid identity." ], "failure_signals": [ "Credential issuance latency at pod startup exceeds 5 seconds \u2014 creates deployment slowdowns that incentivize engineers to reuse pre-issued credentials.", "Credential management infrastructure has availability SLA below 99.9% \u2014 agent pods cannot start during outages, creating pressure to cache or reuse credentials." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Per-instance credential architecture is the foundational prerequisite for this control; most organizations start with shared credentials for operational convenience and must migrate to per-instance issuance as a prerequisite to effective sharing detection." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "IAM Team", "SIEM Engineering" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "direct", "rationale": "SP 800-63B-4 \u00a73 requires each authenticator to be bound to a single subscriber account; credential sharing detection enforces this uniqueness-of-binding requirement at runtime.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 6", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 6's strictly enforced authentication includes identity-bound access; credential sharing detection identifies violations of the one-credential-per-identity principle.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "\u00a78", "fit": "partial", "rationale": "ISO/IEC 24760-1 \u00a78 covers identification \u2014 establishing that identity information reliably refers to a specific entity; credential sharing breaks the one-to-one binding between credential and entity that identification depends on.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta \u2014 Concurrent Session Detection", "rationale": "Okta concurrent session detection flags multiple simultaneous authentication sessions from different geographic contexts or device fingerprints for the same machine identity credential. For non-human identities that should operate from a fixed deployment context, any concurrent session from a different context is a high-confidence indicator of credential sharing or theft.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta concurrent-session detection flags multi-context simultaneous use, a core sharing signal, but not the human behavioral-fingerprint detection.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail \u2014 Credential Sharing Detection", "rationale": "AWS CloudTrail analysis of STS session credentials used simultaneously from multiple source IP addresses indicates credential sharing or exfiltration. GuardDuty credential exfiltration findings (UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration) cover the pattern of EC2 instance credentials used from external IPs. Custom CloudTrail Insights rules can detect concurrent use of the same session token from multiple IPs.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS CloudTrail flags STS credentials used from multiple source IPs simultaneously, a sharing signal, but not human-fingerprint or single-instance binding.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 \u2014 Credential isolation (each agent instance has unique credentials)", "fit": "partial", "rationale": "Per-agent unique credentials make shared-credential use avoidable and detectable. Partial: doc prescribes preventing credential sharing rather than detecting it.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every AI agent credential must be bound to a single agent instance identity and must not present behavioral fingerprint patterns consistent with human interaction; any concurrent session from multiple distinct source IPs for the same credential or any request with human-origin behavioral fingerprint must trigger a CRITICAL event and initiate the IM-08 credential compromise playbook.", "evidence_required": [ "concurrent_session_detection_log sample of events showing credential_id, session_count, distinct_source_ips, source_asns, elapsed_window_seconds, and response_action", "human_use_detection_log entries showing human-origin fingerprint classification events on agent credentials with fingerprint_score, classification_confidence, and credential_suspension_initiated flag", "behavioral_fingerprint_scoring_distribution report showing the distribution of machine versus human fingerprint scores across all active agent sessions over a 30-day period", "per_instance_credential_architecture_review documenting that multi-replica agent deployments use per-instance credentials, not a shared credential across replicas" ], "machine_tests": [ "Open two concurrent sessions with the same test agent credential from two distinct source IPs in different cloud provider regions \u2192 assert a credential-sharing-suspected HIGH event is generated within 60 seconds with both source IPs recorded", "Use a browser with human-paced interaction patterns (irregular timing, standard browser User-Agent header, varied request structure) to make API calls using a test agent credential \u2192 assert a human-use-of-agent-credential CRITICAL event is generated within 60 seconds and credential suspension is initiated", "Verify that a standard machine-paced scripted session (regular timing, consistent headers, no human-origin fingerprint signals) is classified as machine-origin with confidence > 0.95" ], "human_review": [ "Review the per-instance credential architecture for multi-replica agent deployments and verify that each replica receives a unique credential at deployment time rather than sharing a deployment-level credential", "Assess the behavioral fingerprint scoring model's false positive rate for legitimate high-concurrency agent deployments that may appear to have multiple concurrent sessions", "Verify that human-use-of-agent-credential events are escalated through the IM-08 credential compromise playbook and not merely logged to a monitoring dashboard without mandatory response actions" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Deploying multiple replicas of the same agent with a shared credential, making it impossible to distinguish legitimate multi-instance use from credential sharing or theft", "Exempting service-to-service calls or internal API calls from credential sharing detection, leaving an entire class of sharing patterns unmonitored", "Classifying concurrent sessions from the same cloud provider ASN as safe without checking whether the sessions originate from the same instance, missing intra-cloud credential sharing", "Treating human-use-of-agent-credential events as low-severity monitoring alerts rather than CRITICAL credential compromise indicators requiring immediate suspension" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-06", "layer": "IM", "plane": "both", "name": "Identity Event Log Integrity", "plain": "Ensures that identity event logs are tamper-evident, forwarded to a SIEM outside the AI agent's control plane, and structured with sufficient detail to reconstruct delegation chains and attribute all actions to specific credential holders.", "threat": { "tags": [ "credential-compromise", "identity-spoofing" ], "desc": "An AI agent that can write or delete its own audit logs can cover the tracks of any action it takes, eliminating the forensic evidence needed to detect or reconstruct an attack. Log integrity is therefore a prerequisite for all other monitoring controls in this layer: if logs can be manipulated, detection signals are unreliable. Log completeness \u2014 ensuring that every delegation chain reference is recorded with sufficient detail to reconstruct the authorization path \u2014 is essential for post-incident investigation of complex multi-agent delegation attacks. A SIEM gap alert (log stream silence >5 minutes) is a critical signal because it may indicate that an agent is actively suppressing log forwarding rather than that the agent is simply idle." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 7", "title": "Collect and analyze information to improve security posture" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Visibility and analytics capability" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Audit \u2014 tamper-evident records of identity events" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-06 Identity Event Log Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-06 Identity Event Log Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IM-06 Identity Event Log Integrity control.", "reviewed_on": "2026-07-02" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-06 Identity Event Log Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://identity/controls/IM-06 Identity Event Log Integrity control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Route all identity event logs through a write-only log forwarding agent to the SIEM; the identity log forwarding path must not traverse any network or service controlled by the AI agent. Implement hash chaining on log entries (each entry includes a SHA-256 hash of the previous entry) to make log tampering detectable via chain discontinuity. Monitor for log stream gaps >5 minutes and alert as a potential tampering event. Enforce the required log entry schema on every event before SIEM ingestion.", "steps": [ "Configure the agent runtime to emit identity event logs to a sidecar log forwarder (e.g., Fluent Bit, OpenTelemetry Collector) that runs in a separate container with no shared network namespace with the agent; the sidecar forwards directly to the SIEM over a TLS-authenticated channel; the agent has no access to the sidecar's network interface or the SIEM endpoint.", "Implement hash chaining on the SIEM ingestion side: the SIEM computes SHA-256(previous_entry_hash || current_entry_content) for each ingested entry and stores the chain; run a chain integrity check every 6 hours and alert immediately on any discontinuity (which indicates log tampering or entry deletion).", "Configure SIEM gap alerting: if no identity event log entries are received from a specific agent source within a 5-minute window during which the agent is known to be active (per deployment health check), emit a log-gap CRITICAL alert; distinguish between true agent inactivity (expected) and log suppression (suspect) by cross-referencing with agent liveness signals.", "Enforce required log entry schema: every identity event log entry must contain credential_id, agent_id, action_type, resource_target, outcome (allow/deny), timestamp_utc (ISO 8601 with milliseconds), session_id, client_ip, delegation_chain_reference (pointer to the delegation record in DE-layer), and scope_used (the specific scope claim exercised); reject log entries missing required fields at SIEM ingestion time and alert on schema violations." ], "anti_patterns": [ "Logging identity events to a local file or local database accessible to the agent runtime \u2014 the agent can modify or delete local logs, making them forensically unreliable.", "Using the agent's service account credentials to authenticate the log forwarder to the SIEM \u2014 if the agent credential is compromised, the attacker can impersonate the log forwarder.", "Omitting the delegation_chain_reference from log entries \u2014 prevents reconstruction of multi-agent authorization paths during incident investigation, a critical forensic gap." ] }, "validation": { "design_check": [ "Verify that the agent's IAM role or service account does not have write, delete, or update permissions on the SIEM destination (log group, index, or bucket).", "Confirm that the log forwarding sidecar authenticates to the SIEM with its own dedicated credential that is not accessible to the agent runtime.", "Review the log entry schema enforcement configuration at the SIEM ingestion point and confirm required fields are validated before ingestion." ], "runtime_test": [ "Attempt to write directly to the SIEM log destination using a test agent credential and verify the request is denied with a permission error.", "Delete 5 log entries from the SIEM test log group and verify that the hash chain integrity check detects the discontinuity and emits a tamper-detection alert within 6 hours.", "Stop the log forwarder sidecar for a test agent that is actively processing requests and verify a log-gap CRITICAL alert is generated within 5 minutes." ], "evidence": [ "iam-policy-review: documentation confirming agent credentials lack write/delete access to SIEM log destinations [unverified]", "chain-integrity-check-log: most recent chain integrity check output showing all chains intact [unverified]", "log-gap-alert-test-record: evidence from runtime test showing gap alert generated within 5 minutes of log suppression [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The IAM configuration for this control is the most critical implementation detail: the agent credential must be scoped to write actions only (not read, update, or delete), and the SIEM destination must be in a separate IAM boundary from the agent's operational scope. Review IAM policies for both the agent role and the log forwarder role to confirm this separation before declaring the control implemented.", "actions": [ "Review all agent IAM roles and confirm none include s3:DeleteObject, cloudwatch:DeleteLogGroup, cloudwatch:DeleteLogStream, or equivalent SIEM destination write/delete permissions.", "Create a dedicated IAM role for the log forwarder sidecar with write-only access to the SIEM destination and confirm the agent runtime cannot assume this role.", "Implement SCPs (Service Control Policies) or equivalent organizational guardrails that prevent any agent role from being granted SIEM destination delete permissions." ], "failure_signals": [ "Agent IAM role includes any delete or update permission on the SIEM log destination \u2014 the log integrity guarantee is broken.", "Log forwarder and agent runtime share a service account \u2014 compromising the agent enables log manipulation." ] }, "security_architect": { "summary": "Log integrity is the forensic foundation for every other monitoring control in this layer. If log integrity is compromised, detection signals from IM-01 through IM-05 cannot be trusted. Architect the log integrity system as a security control with its own threat model: consider the scenario where an adversary has full control of the agent runtime and is actively attempting to suppress or manipulate logs, and verify that the sidecar architecture resists this threat.", "actions": [ "Threat-model the log forwarding architecture against an adversary with full control of the agent container: verify that network namespace isolation prevents the agent from intercepting or dropping log forwarder traffic.", "Implement append-only cloud storage for log archives (S3 Object Lock, Azure Immutable Blob Storage) to prevent retroactive log modification even by privileged cloud administrators.", "Consider Write-Once-Read-Many (WORM) storage for regulated sectors where log retention requirements carry legal weight." ], "failure_signals": [ "Log forwarder and agent runtime share a network namespace \u2014 the agent can intercept or drop log traffic.", "Log archive storage is not configured with WORM or object lock \u2014 privileged administrators can modify historical logs." ] }, "legal_counsel": { "summary": "Tamper-evident log integrity is a prerequisite for logs to be admissible as evidence in legal proceedings. Hash chain integrity provides a cryptographic basis for demonstrating that logs have not been altered, which is essential for breach litigation, regulatory investigations, and law enforcement cooperation. Establish the log integrity chain documentation process before it is needed in a legal context.", "actions": [ "Document the hash chaining methodology and integrity verification process in a discoverable format that can be presented to regulators or courts to establish log authenticity.", "Establish retention policies aligned with statute of limitations and regulatory retention requirements: 7 years for HIPAA/financial sectors, 3 years minimum for all sectors.", "Ensure that log integrity records (hash chain checkpoints) are preserved alongside the logs themselves as part of the evidentiary package." ], "failure_signals": [ "Hash chain documentation is not maintained in a format that could be used to authenticate logs in legal proceedings \u2014 reduces evidentiary value.", "Log retention policy is shorter than the applicable regulatory retention requirement \u2014 creates compliance exposure." ] }, "grc_auditor": { "summary": "Log integrity is the foundation of the entire audit evidence chain for AI agent identity monitoring. Auditors should verify the technical controls (IAM permissions, hash chaining, SIEM gap alerting) rather than accepting policy attestations alone, since the integrity of all other monitoring evidence depends on the integrity of the log system.", "actions": [ "Request and review the agent IAM role policy documents to verify absence of SIEM destination delete/update permissions.", "Request the most recent hash chain integrity check report and verify it shows all chains intact with no discontinuities.", "Request the log gap alert configuration and verify the 5-minute threshold is correctly set and the alert is routed to the SOC." ], "metrics": [ "Hash chain integrity check pass rate: target 100%; any discontinuity triggers immediate investigation.", "Log entry schema compliance rate: percentage of ingested log entries meeting the required schema; target >99.9%." ], "failure_signals": [ "Hash chain integrity check has not been run in >7 days \u2014 the tamper-detection guarantee lapses between checks.", "Log entry schema compliance rate <99% \u2014 indicates agent runtimes are emitting incomplete log entries that cannot be used for attribution." ] }, "it_operations": { "summary": "The log forwarder sidecar is a critical operational dependency for every agent deployment; a sidecar failure means log integrity is lost from that point forward. Operations teams must monitor sidecar health as a deployment health signal equivalent in importance to the agent process itself, and must have a defined runbook for sidecar restart without log loss.", "actions": [ "Add log forwarder sidecar health to the deployment health check definition so that a sidecar failure fails the deployment health check and triggers an alert.", "Implement local log buffering in the sidecar so that logs accumulated during a SIEM connectivity outage are preserved and forwarded in order when connectivity is restored, preserving hash chain continuity.", "Establish a runbook for investigating log-gap CRITICAL alerts that includes distinguishing between true inactivity, sidecar failure, SIEM connectivity issues, and potential log suppression attacks." ], "failure_signals": [ "Log forwarder sidecar restart causes a log sequence gap that triggers false tamper-detection alerts \u2014 indicates the sidecar is not buffering logs across restarts.", "Log-gap alerts are being dismissed as false positives without investigation \u2014 creates a habituation risk where real log suppression attacks are missed." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Log integrity controls are commonly implemented for human identity systems but rarely extended to AI agent identities with the required scope: separate IAM boundary, hash chaining, gap alerting, and delegation chain references all require deliberate design for the AI agent context." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "SIEM Engineering", "Platform Engineering" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 7", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 7 requires collection and use of security information; tamper-evident log integrity ensures the collected information is reliable and actionable.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "fit": "direct", "rationale": "The CISA ZTMM Visibility and Analytics cross-cutting capability requires comprehensive, reliable logging of identity events; log integrity controls fulfill this requirement.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015's audit requirements call for reliable, tamper-evident records of identity events; hash chaining and SIEM isolation implement this requirement.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS CloudTrail \u2014 Log File Integrity Validation", "rationale": "AWS CloudTrail log file integrity validation uses SHA-256 hashing of each log file and RSA-2048 digital signing of digest files that reference those hashes. The digest chain allows detection of any modification, deletion, or insertion of identity event log records after delivery to S3, providing cryptographic tamper evidence for the full audit trail.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail log-file integrity gives hash-chained tamper evidence, but the control also requires SIEM-external storage and 5-minute log-gap alerting.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Google Cloud Audit Logs \u2014 Immutable Logs", "rationale": "Google Cloud Audit Logs for Admin Activity and Data Access events are stored in a Google-managed log bucket with controls separate from customer-managed storage; customers cannot modify or delete these logs regardless of IAM permissions. This immutability guarantee provides tamper-evident identity event log integrity without requiring additional customer-side integrity controls.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "GCP immutable audit logs provide tamper-evident storage, but not the agent-external SIEM forwarding and log-gap alerting the control also requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Action logging (Immutable audit trails with integrity verification)", "fit": "direct", "rationale": "Append-only, cryptographically integrity-verified logs \u2014 identity event log integrity.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Identity event logs must be written to a SIEM destination where agent credentials have no write, delete, or update permissions; log entries must be hash-chained so that any deletion or modification is detectable within 6 hours; and a log-gap alert must fire within 5 minutes when an active agent stops forwarding events, with delegation chain references present in every event involving a delegated credential.", "evidence_required": [ "iam_policy_review confirming that no active agent IAM role or service account has s3:PutObject, s3:DeleteObject, cloudwatch:PutLogEvents, or equivalent write/delete permissions on the SIEM log destination", "chain_integrity_check_log from the most recent 24-hour verification run showing all hash chains intact and zero tamper events detected", "log_gap_alert_test_record from the most recent operational test showing a gap alert generated within 5 minutes of log forwarder suspension for an active agent", "log_entry_schema_sample of 10 identity events confirming each contains delegation_chain_id, actor_credential_id, action_type, resource_target, outcome, and event_hash fields" ], "machine_tests": [ "Attempt to delete a log entry from the SIEM test log group using a test agent credential \u2192 assert the deletion request is denied with an authorization error", "Delete 3 log entries from a test hash-chained log stream and run the integrity verification job \u2192 assert the job detects a chain discontinuity and emits a tamper-detection alert within 6 hours", "Stop the log forwarder sidecar for an active test agent and continue generating agent activity for 5 minutes \u2192 assert a log-gap CRITICAL alert is generated referencing the agent credential_id and the gap start timestamp" ], "human_review": [ "Review the IAM boundary between agent runtime credentials and the SIEM log destination to confirm the separation is enforced at the cloud provider IAM level, not only by application-layer controls that a compromised agent could bypass", "Assess whether delegation chain references are present and complete in sampled log entries involving sub-agent or delegated actor actions, confirming the full authorization path is reconstructable from logs alone", "Verify that hash chain integrity checks are scheduled at a frequency that meets the 6-hour tamper detection SLA and that check results are themselves stored in a tamper-evident location" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Granting agent runtime IAM roles any write or delete permissions on the log storage destination under the assumption that agents will not misuse them", "Implementing log integrity as application-layer record checksums while allowing the agent to write directly to the underlying storage, enabling a compromised agent to rewrite both the record and its checksum", "Treating a SIEM log stream silence of over 5 minutes for an active agent as a routine infrastructure event rather than a CRITICAL security alert requiring immediate investigation", "Omitting delegation chain identifiers from log entries for sub-agent calls, making it impossible to reconstruct the authorization path during post-incident forensics" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-07", "layer": "IM", "plane": "both", "name": "Credential Exposure Scanning", "plain": "Continuously scans code repositories, deployment artifacts, prompt templates, and logging outputs for exposed AI agent credentials, triggering automatic rotation requests and incident notification within one hour of detection.", "threat": { "tags": [ "credential-compromise", "lateral-movement" ], "desc": "AI agent credentials embedded in code, configuration files, or prompt templates are one of the most common and highest-impact credential exposure patterns in modern software development. Unlike human credentials, AI agent credentials are often long-lived service account tokens with broad scoped permissions, making their exposure particularly damaging. Prompt templates represent a novel and underappreciated exposure surface: operators who include API keys or bearer tokens in system prompts to configure agent behavior inadvertently expose those credentials to every user who can observe agent responses, and those credentials may appear in training data or log outputs. Post-exposure auditing is required because exposure may predate detection, creating a window during which the credential was available to unauthorized parties." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63B-4 \u00a73", "title": "Authenticator requirements \u2014 protection of secrets" }, { "id": "nist_zt", "section": "\u00a72.1 Tenet 5", "title": "Monitor and measure the integrity and security posture of all assets" }, { "id": "cisa_zt", "section": "Identity Pillar \u2014 Authentication", "title": "Credential management and protection" } ], "sources": [ { "id": "nist_800_63_4", "title": "NIST SP 800-63-4 \u2014 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 \u2014 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IM-07 Credential Exposure Scanning control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-07 Credential Exposure Scanning control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-07 Credential Exposure Scanning control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-07 Credential Exposure Scanning control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-07 Credential Exposure Scanning control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy multi-surface credential scanning covering: git repositories (pre-commit hooks via gitleaks or detect-secrets, plus continuous repo scanning via CI pipeline integration), container image scanning (scan image layers for credential patterns before registry push), Terraform state and Helm chart scanning (CI pipeline gate), and SIEM output scanning (regex-based scan of log aggregation pipeline outputs for credential token patterns). All scan surfaces feed into a unified finding queue with deduplication; any finding triggers automatic rotation request via the credential management API and incident notification within 1 hour.", "steps": [ "Install pre-commit hooks (gitleaks, detect-secrets, or truffleHog) in all repositories containing agent configuration, infrastructure code, or prompt templates; configure hooks to block commits containing credential patterns matching the AI agent credential format (e.g., bearer token regex, API key format); integrate the same scanners into the CI/CD pipeline as a mandatory gate that fails the build on detection.", "Integrate container image scanning into the CI/CD pipeline: scan all container image layers for credential patterns before push to the image registry; maintain a credential pattern library that includes all credential formats used in the organization's agent deployments and update it within 24 hours of any new credential format introduction.", "Implement log output scanning as a continuous process: deploy a streaming scan agent against log aggregation outputs (CloudWatch Logs Insights, Splunk, Datadog) using regex patterns for all credential formats; scan both current log streams and a rolling 30-day archive scan to detect historical exposures; rate-limit the archive scan to avoid impacting log system performance.", "On any credential exposure detection: automatically initiate a rotation request via the credential management API within 15 minutes; notify the IAM team and security operations within 1 hour via incident ticket (P1 severity); initiate a forensic review of all access events from the exposed credential since its issuance date to determine if unauthorized use occurred before detection." ], "anti_patterns": [ "Running credential exposure scans only on push events, not on pull requests \u2014 credential patterns committed in feature branches can persist in git history even if removed before merge.", "Using a credential pattern library that is not updated when new credential formats are introduced \u2014 new credentials are invisible to the scanner until the pattern library is updated.", "Treating credential exposure as a low-severity finding that requires only rotation without forensic review \u2014 the rotation does not retroactively invalidate the exposure window, during which unauthorized use may have occurred." ] }, "validation": { "design_check": [ "Confirm that pre-commit hooks are enforced across all repositories containing agent configuration and cannot be bypassed without an explicit override with audit trail.", "Verify that the credential pattern library includes all currently active credential formats and has a documented update process with a 24-hour SLA for new format additions.", "Review the incident response configuration to confirm that exposure findings trigger P1 incidents with IAM team notification within 1 hour." ], "runtime_test": [ "Attempt to commit a test credential pattern (inert, non-functional) to a test repository and verify the pre-commit hook blocks the commit and logs the attempt.", "Push a test container image with an embedded test credential pattern and verify the image scanning pipeline blocks the push and emits a detection finding.", "Inject a test credential pattern into a log stream and verify the log scanning agent detects it within 5 minutes and generates a finding in the unified queue." ], "evidence": [ "pre-commit-hook-coverage-report: list of repositories with pre-commit hooks installed and last verification date [unverified]", "scanner-finding-log: sample of credential exposure findings from the last 90 days showing scan surface, finding type, and response action [unverified]", "rotation-request-log: log showing automated rotation requests triggered by scanner findings with timestamps [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The most common gap in credential exposure scanning programs is coverage of non-obvious surfaces: Terraform state files, Helm values files, CI/CD environment variable exports, and prompt template databases are frequently missed by scanner deployments focused on application code repositories. Enumerate all surfaces where agent credentials could be present and verify scanner coverage explicitly against that list.", "actions": [ "Create a credential surface inventory listing all locations where agent credentials could be embedded: code repos, CI/CD variable stores, container registries, Terraform state backends, prompt template databases, and log aggregation systems.", "Verify scanner coverage against the surface inventory and document any uncovered surfaces with a remediation plan and timeline.", "Establish a credential format catalog maintained alongside the credential issuance system so that new credential formats are automatically added to scanner pattern libraries." ], "failure_signals": [ "Scanner coverage inventory does not include Terraform state, Helm charts, or prompt template storage \u2014 these surfaces are commonly missed and represent high-value exposure targets.", "Credential pattern library has not been updated in >30 days and new credential formats have been introduced in that period." ] }, "security_architect": { "summary": "Prompt templates are a qualitatively different exposure surface from code: they are often managed by non-engineers in content management systems, shared across teams without security review, and may be exported to model training pipelines. The credential exposure scanner must cover prompt template storage specifically and must be integrated into the content management workflow used by prompt engineers, not just the software development workflow.", "actions": [ "Integrate credential exposure scanning into the prompt template management workflow, including any content management systems, prompt registries, or LLM platform prompt libraries used by the organization.", "Establish a policy prohibiting embedding credentials in prompt templates and provide a secure alternative (environment variables, secrets manager references) for configuring agent behavior.", "Consider integrating LLM-based detection (as a complement to regex) for credential patterns in prompt templates, as regex patterns may miss obfuscated or paraphrased credentials embedded in natural language contexts." ], "failure_signals": [ "Prompt template storage is not included in the scanner surface inventory \u2014 a novel and high-risk exposure surface is uncovered.", "No secure alternative to embedding credentials in prompt templates is provided to prompt engineers \u2014 organizational pressure will lead to credential embedding despite the prohibition." ] }, "legal_counsel": { "summary": "Credential exposure in public repositories (GitHub, GitLab public repos) may constitute a breach notification trigger if the credential provided access to regulated data. Organizations must maintain a documented process for assessing breach notification obligations when credential exposures are detected, including a timeline analysis of how long the credential was exposed before detection.", "actions": [ "Establish a P1 incident response process for credential exposures that includes a legal review checkpoint at hour 4 to assess breach notification obligations.", "Document the temporal analysis methodology: for each detected exposure, determine the earliest possible exposure date (git commit timestamp, container image push timestamp) and whether any regulated data was accessible via the exposed credential.", "Ensure that scanner findings are preserved as evidence with metadata (detection timestamp, scan surface, credential type, estimated exposure window)." ], "failure_signals": [ "Credential exposure incidents are closed without documenting the estimated exposure window \u2014 creates a gap in breach notification analysis.", "Legal review is not part of the P1 incident response playbook for credential exposures \u2014 regulatory notification deadlines may be missed." ] }, "grc_auditor": { "summary": "Credential exposure scanning is a preventive and detective control that demonstrates due diligence in credential protection. Auditors should verify scanner coverage breadth (all surfaces, not just code repos) and the completeness of the response process (rotation + forensic review, not just rotation alone).", "actions": [ "Request the credential surface inventory and scanner coverage map and verify alignment between the two.", "Review the most recent 5 P1 credential exposure incidents and confirm each has a documented forensic review with a conclusion on whether unauthorized use occurred.", "Verify that the credential pattern library update process is documented with a defined SLA and that it has been followed for all credential format introductions in the last 12 months." ], "metrics": [ "Scanner surface coverage rate: percentage of identified credential exposure surfaces with active scanner coverage; target 100%.", "Mean time to rotation after detection: target <15 minutes from detection event to rotation request initiation." ], "failure_signals": [ "Scanner surface coverage rate below 90% \u2014 significant exposure surfaces are unmonitored.", "Credential exposure incidents closed without forensic review \u2014 the organization cannot determine whether credentials were used before detection." ] }, "it_operations": { "summary": "Pre-commit hooks can be bypassed by developers using --no-verify; the CI/CD pipeline gate is the authoritative enforcement point and must not be bypassable without explicit exception with audit trail. Operations teams should monitor scanner false positive rates to maintain developer trust in the pre-commit hooks: high false positive rates lead to hook disabling, which eliminates the first line of defense.", "actions": [ "Configure the CI/CD pipeline credential scan as a mandatory gate that cannot be bypassed except through a documented exception approval process with IAM team sign-off.", "Monitor pre-commit hook bypass rates (git commits with --no-verify) and treat increases as a signal that false positive rates are too high or that developer education is needed.", "Establish a false positive review process where developers can report scanner false positives and get them resolved within 2 business days to maintain scanner accuracy and developer adoption." ], "failure_signals": [ "CI/CD pipeline credential scan can be bypassed by setting an environment variable or commit flag without approval \u2014 the scanner is not an authoritative gate.", "Pre-commit hook bypass rate is increasing over time \u2014 indicates developer friction with the scanner that will eventually lead to informal policy workarounds." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have some form of code repository scanning but lack coverage of prompt templates, deployment artifacts, and log outputs; comprehensive multi-surface scanning with automated rotation and forensic review represents a significant maturity jump." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "DevSecOps", "Platform Engineering" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63B-4 \u00a73", "fit": "direct", "rationale": "SP 800-63B-4 \u00a73 requires authenticator secrets to be protected; credential exposure scanning detects violations of those protection requirements and enables rapid remediation.", "source_version": "4", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 5", "fit": "partial", "rationale": "SP 800-207 \u00a72.1 Tenet 5's asset posture monitoring extends to credential material embedded in infrastructure artifacts; scanning ensures credentials are not present in monitored asset surfaces.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Authentication", "fit": "direct", "rationale": "The CISA ZTMM Identity pillar expects credentials to be protected from unauthorized disclosure across their lifecycle; exposure scanning is the detection mechanism for disclosure violations.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Trusted Advisor \u2014 Exposed Access Keys / Amazon GuardDuty", "rationale": "AWS Trusted Advisor's Exposed Access Keys check reports access keys found in public code repositories, and AWS automatically applies a quarantine policy when keys are detected in public commits; Amazon GuardDuty credential-exfiltration findings detect exposed credentials in active use. Together these provide the exposure-scanning and rapid-remediation loop IM-07 requires.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Trusted Advisor/GuardDuty detect and quarantine keys exposed in public repos, but not prompt/artifact/log scanning with 1h rotation workflow.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta ISPM \u2014 Credential Exposure Scanning", "rationale": "Okta Identity Security Posture Management (ISPM) continuously scans for exposed service account credentials, overprivileged non-human identities, and stale API keys across the Okta identity estate. ISPM risk scoring prioritizes exposed credentials for immediate remediation and can trigger automated revocation workflows when exposure is detected.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta ISPM scans for exposed service-account credentials and stale keys, covering part of the repo/artifact/prompt/log scanning the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All code repositories, container images, deployment artifacts, prompt templates, and log outputs containing AI agent configuration must be continuously scanned for credential material; any exposure finding must trigger a P1 incident within 1 hour, automated rotation of the exposed credential, and a post-exposure audit covering the window from credential issuance to confirmed rotation.", "evidence_required": [ "pre_commit_hook_coverage_report listing all repositories with agent configuration and confirming pre-commit hooks installed, last_verified_at timestamps, and whether bypass requires an audited override", "scanner_finding_log from the last 90 days showing scan_surface, finding_type, exposed_credential_pattern, detected_at, p1_incident_created_at, and rotation_completed_at for each finding", "rotation_request_log confirming automated rotation was triggered by scanner findings with time-to-rotation measured from detection to completion", "post_exposure_audit_records for any finding in the last 90 days documenting the exposure window, resources accessible during the window, and evidence of unauthorized use" ], "machine_tests": [ "Attempt to commit a file containing an inert test credential pattern (non-functional key format) to a repository with pre-commit hooks installed \u2192 assert the commit is blocked and an attempt_log entry is created", "Push a container image with an embedded inert test credential pattern to the container registry \u2192 assert the image scanning pipeline blocks the push and creates a finding in the unified exposure queue within 10 minutes", "Inject an inert test credential pattern into a monitored log stream \u2192 assert the log scanning agent detects it within 5 minutes and generates a finding with the source_stream and credential_pattern_type fields populated" ], "human_review": [ "Review the credential pattern library to confirm it includes all current credential formats in use, including any proprietary internal service token formats, and assess whether the 24-hour SLA for adding new formats is being met", "Assess post-exposure audit records for any findings in the last 90 days and verify that the exposure window was fully characterized and that unauthorized use was either ruled out with evidence or escalated as a breach", "Verify that prompt template scanning is in scope and that system prompts and few-shot examples containing API keys or bearer tokens are detected, not only source code and infrastructure artifacts" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Scanning only application source code repositories while omitting prompt templates, deployment manifests, container image layers, and log outputs, leaving the majority of the agent credential exposure surface unmonitored", "Treating credential exposure findings as low-severity defects to be remediated in the next sprint rather than P1 incidents requiring immediate credential rotation", "Rotating an exposed credential without performing a post-exposure audit, leaving unresolved the question of whether the credential was used during the exposure window", "Maintaining a static credential pattern library without a process to add new formats within 24 hours of new credential types being issued, creating detection gaps for recently introduced credential formats", "Allowing pre-commit hook bypass without an auditable override mechanism, creating an untracked path for credential material to enter repositories" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-08", "layer": "IM", "plane": "both", "name": "Identity Incident Response", "plain": "Defines and enforces response playbooks for identity-related security incidents including credential compromise, unauthorized delegation, ghost identity exploitation, and federation abuse, with defined detection criteria, containment steps, and post-incident review requirements.", "threat": { "tags": [ "credential-compromise", "delegation-abuse", "identity-spoofing", "orphaned-credential" ], "desc": "Identity incidents in AI agent environments are higher-stakes than equivalent human identity incidents because AI agents can act autonomously at machine speed: a compromised agent credential can be used to issue thousands of API calls before a human reviewer can respond. Ghost identity exploitation \u2014 using credentials that belong to deprovisioned agents still present in downstream systems \u2014 bypasses all monitoring controls that rely on active credential records. Federation abuse, where an attacker manipulates a federated trust relationship to gain cross-organizational credential acceptance, can propagate a single compromise across multiple organizational boundaries simultaneously. Each of these incident types requires a distinct response playbook because the detection signals, containment steps, and recovery procedures differ fundamentally between them." }, "standard": [ { "id": "nist_zt", "section": "\u00a72.1 Tenet 7", "title": "Collect and analyze information to improve security posture" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Identity telemetry feeding incident response" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Audit and control \u2014 identity incident investigation records" } ], "sources": [ { "id": "nist_sp_800_207", "title": "NIST SP 800-207 \u2014 Zero Trust Architecture", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 \u2014 Zero Trust Architecture requirements informing the apeiris://identity/controls/IM-08 Identity Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_zt_maturity_v2", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2023-04-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "implementation_pattern", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IM-08 Identity Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 IT Security and Privacy \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IM-08 Identity Incident Response control.", "reviewed_on": "2026-07-02" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IM-08 Identity Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IM-08 Identity Incident Response control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain four documented and tested incident response playbooks covering credential compromise, unauthorized delegation, ghost identity exploitation, and federation abuse. Each playbook defines: detection criteria (specific signals from IM-01 through IM-07 that trigger the playbook), immediate containment actions (<30 minutes), investigation steps (forensic review scope and methodology), recovery steps (re-issuance, re-scoping, trust restoration), and post-incident review requirements. Playbooks must be tested via tabletop exercises at least annually and updated within 30 days of any exercise finding. Each playbook type maps to specific controls in this domain for detection signals.", "steps": [ "Implement and maintain Playbook 1 (Credential Compromise): detection criteria include IM-02 >5\u03c3 anomaly, IM-03 impossible travel CRITICAL, or IM-07 exposure finding; immediate containment: revoke credential via IF-06 within <10 minutes, terminate all active sessions, notify IAM and security teams; investigation: forensic review of all access events from the credential's issuance date using IM-06 logs, determine scope of unauthorized actions, identify compromise vector; recovery: re-issue credential with rotated key material (do not simply reset the same credential), conduct NI-02 scope review before re-issuance, require re-enrollment if certificate-based authentication is used; post-incident: root cause analysis within 5 business days, update IM-01 baseline after re-issuance.", "Implement and maintain Playbook 2 (Unauthorized Delegation): detection criteria include DE-08 unauthorized delegation alert or IM-04 privilege escalation via delegated credential; immediate containment: revoke the delegation record and all downstream delegated credentials per the DE-08 revocation propagation model within <30 minutes; investigation: trace the delegation chain from the point of unauthorized grant, identify how authorization was obtained (social engineering, policy gap, compromised delegating identity); recovery: reconstruct the delegation chain from scratch through legitimate authorization channels, conduct DE-layer controls review; post-incident: identify the policy or technical gap that permitted the unauthorized delegation and close it within 10 business days.", "Implement and maintain Playbook 3 (Ghost Identity Exploitation): detection criteria include IM-06 log entries showing credential_id corresponding to a deprovisioned agent (cross-referenced against the identity registry), or IM-03 context anomaly from an agent identity not in the active deployment manifest; immediate containment: emergency deprovisioning of the ghost identity from all downstream systems (not just the identity registry), block at all API gateways; investigation: forensic review of all access events during the ghost period from the date of deprovisioning to the date of detection, determine if data was exfiltrated, actions were taken, or downstream systems were modified; recovery: audit all systems that the ghost identity had access to, assess for unauthorized changes; post-incident: root cause analysis of the II-07 (ghost identity detection) failure and NI-04 (deprovisioning completeness) gap that permitted the ghost period.", "Implement and maintain Playbook 4 (Federation Abuse): detection criteria include IM-02 scope accumulation finding referencing a federated identity, IM-03 context anomaly from an unexpected federation partner ASN, or federation trust anchor verification failure; immediate containment: suspend the federation trust anchor and revoke all credentials issued under the compromised federation relationship within <30 minutes, notify the affected federation partner within 24 hours; investigation: determine the scope of credentials issued under the compromised trust anchor, audit all access events attributed to federation-issued credentials; recovery: full re-vetting of the federation partner organization and federation configuration before trust restoration, require re-enrollment of all agent identities issued under the federation; post-incident: review II-03 (federation trust anchor management) configuration and implement additional verification controls." ], "anti_patterns": [ "Maintaining playbooks as static documents that are not updated after incident learnings \u2014 playbooks that do not reflect the current threat landscape and infrastructure configuration are operationally misleading.", "Using the same playbook for credential compromise and ghost identity exploitation \u2014 the containment steps differ fundamentally: credential compromise requires revocation of an active credential, while ghost identity exploitation requires audit and deprovisioning of a credential that should already have been deprovisioned.", "Delaying cross-org notification in federation abuse incidents to assess internal impact first \u2014 federation partners need to be notified within 24 hours to initiate their own containment, regardless of whether internal impact assessment is complete." ] }, "validation": { "design_check": [ "Verify that all four playbooks are documented with the required sections (detection criteria, containment SLA, investigation steps, recovery steps, post-incident review requirements) and have been reviewed within the last 12 months.", "Confirm that playbook detection criteria reference specific control IDs (IM-01 through IM-07, IF-06, DE-08) rather than generic descriptions, so that automated alerts can be mapped to playbooks.", "Review playbook owner assignments and confirm that named responders have been trained on the playbooks and that backup owners are designated." ], "runtime_test": [ "Conduct a tabletop exercise for Playbook 1 (Credential Compromise) using a realistic scenario and verify that all teams complete containment actions within the 30-minute SLA.", "Inject a ghost identity scenario (create a test agent, deprovision it, then simulate access using its credential) and walk through Playbook 3 to verify that the forensic review scope covers the full ghost period.", "Simulate a federation trust anchor failure for a test federation partner and verify that Playbook 4 triggers partner notification within the 24-hour SLA." ], "evidence": [ "playbook-documentation: current versions of all four playbooks with section completeness verification and last-review dates [unverified]", "tabletop-exercise-records: records of annual tabletop exercises for each playbook including findings and update actions [unverified]", "incident-closure-reports: sample of closed identity incidents showing playbook applied, timeline compliance, and post-incident review completion [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "The technical dependencies between playbooks and upstream controls must be explicitly documented: Playbook 1 requires IF-06 revocation to be functional; Playbook 2 requires DE-08 revocation propagation to be functional; Playbook 3 requires the identity registry to be queryable for deprovisioned credential status. Before an incident, verify these dependencies are working; during an incident, if a dependency is unavailable, the playbook must specify a manual fallback procedure.", "actions": [ "Document the technical dependencies for each playbook (which controls must be functional for the playbook to execute successfully) and verify those dependencies in quarterly playbook readiness reviews.", "Define manual fallback procedures for each playbook step that has a technical dependency, so that responders can execute the playbook even when automated systems are unavailable.", "Automate the first 15 minutes of each playbook (the containment steps with clear decision criteria) as runbook automation so that containment begins immediately without waiting for human responders to engage." ], "failure_signals": [ "Playbook containment steps require manual credential revocation through a UI rather than automated API calls \u2014 human execution of manual UI steps under incident pressure introduces errors and delays.", "Playbook dependencies on IF-06 or DE-08 have not been verified in >90 days \u2014 the playbook may fail at a critical step during a real incident." ] }, "security_architect": { "summary": "The four playbook types cover distinct incident patterns that require different architectural containment mechanisms; conflating them leads to over-broad or under-effective response. The most architecturally complex is federation abuse, which requires cross-organizational coordination and trust anchor management that spans multiple control planes. Architect the federation trust management system to support emergency trust anchor suspension as a first-class operation, not as an edge case.", "actions": [ "Design the federation trust anchor management system to support emergency suspension as a single API call with sub-minute execution time, not as a multi-step configuration change.", "Establish a pre-negotiated incident response communication channel with each federation partner that can be activated without waiting for executive approval in a time-critical federation abuse scenario.", "Architect the ghost identity detection capability (Playbook 3 trigger) as a continuous cross-reference between the identity registry's deprovisioned records and active session logs, not as a periodic reconciliation job." ], "failure_signals": [ "Federation trust anchor suspension requires manual configuration changes across multiple systems \u2014 the 30-minute containment SLA cannot be met through manual processes.", "Ghost identity detection is implemented only as a periodic reconciliation job (daily or weekly) \u2014 creates large detection windows during which ghost identity exploitation is occurring without triggering Playbook 3." ] }, "legal_counsel": { "summary": "Identity incidents involving AI agents have novel legal dimensions: unauthorized agent actions may create organizational liability for the consequences of those actions, and federation abuse incidents require cross-organizational disclosure that intersects with contractual obligations, breach notification statutes, and potentially law enforcement reporting. Legal counsel must be part of the incident response process for all P1 identity incidents.", "actions": [ "Embed a legal review checkpoint at hour 4 of every P1 identity incident response, regardless of incident type, to assess breach notification obligations, contractual disclosure requirements, and potential law enforcement reporting.", "Review the federation partnership agreements to confirm they include mutual incident notification obligations and that the 24-hour notification SLA in Playbook 4 is consistent with contractual terms.", "Ensure that post-incident review documentation is marked as attorney-client privileged communication where appropriate to protect sensitive root cause analysis from discovery." ], "failure_signals": [ "Legal counsel is not involved in P1 identity incident response until after containment is complete \u2014 breach notification deadlines may have already passed.", "Federation partnership agreements do not specify mutual incident notification obligations \u2014 the 24-hour notification SLA in Playbook 4 may not be contractually backed." ] }, "grc_auditor": { "summary": "Incident response playbook completeness and test cadence are key audit evidence points for demonstrating operational identity security maturity. Auditors should verify not only that playbooks exist but that they are tested, updated based on test findings, and actually used when incidents occur \u2014 the incident closure reports should reference the playbook version used and note any deviations.", "actions": [ "Request tabletop exercise records for each playbook and confirm exercises occurred within the last 12 months with documented findings and update actions.", "Sample 5 closed identity incidents from the last 12 months and verify that a playbook was applied, the playbook version is documented, any deviations are noted, and post-incident review is complete.", "Verify that the playbook update process is documented and that playbooks were updated within 30 days of the most recent tabletop exercise findings." ], "metrics": [ "Playbook test cadence: all four playbooks tested annually via tabletop exercise; target 100% coverage per year.", "Containment SLA compliance: percentage of P1 identity incidents where initial containment actions were completed within 30 minutes; target >90%." ], "failure_signals": [ "Tabletop exercises have not been conducted in >12 months \u2014 playbooks are untested and may not reflect current infrastructure or threat landscape.", "Incident closure reports do not reference playbook versions or note deviations \u2014 indicates playbooks are not being followed consistently during incidents." ] }, "it_operations": { "summary": "Operations teams are typically the first responders for identity incidents before the IAM and security teams engage; they need to understand the initial containment steps for each playbook and have the access and tooling to execute them under time pressure. Operational readiness for identity incident response must be part of the on-call runbook for all engineers who have access to identity infrastructure.", "actions": [ "Include identity incident response playbook summaries (detection signals, first 3 containment steps, escalation contacts) in the on-call engineer runbook alongside the standard operational procedures.", "Ensure that on-call engineers have pre-provisioned access to the credential revocation API and identity registry so that containment actions can be executed immediately without access request delays during an incident.", "Conduct quarterly incident response drills for the on-call team covering the first 30 minutes of a credential compromise scenario to maintain muscle memory for the most common incident type." ], "failure_signals": [ "On-call engineers do not have pre-provisioned access to the credential revocation API \u2014 containment is delayed while access is being granted, extending the attack window.", "Identity incident response procedures are not in the on-call runbook \u2014 first responders do not know the initial containment steps and escalate without taking immediate action." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have generic security incident response capabilities but lack AI agent identity-specific playbooks that account for machine-speed credential abuse, delegation chain revocation, ghost identity forensics, and federation trust suspension; developing and testing all four playbooks represents a significant maturity investment." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "IAM Team", "Incident Response Team" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a72.1 Tenet 7", "fit": "direct", "rationale": "SP 800-207 \u00a72.1 Tenet 7 requires collecting security information and using it to improve posture; incident response playbooks formalize the use of collected identity monitoring information to contain and recover from incidents.", "source_version": "1.0", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "fit": "partial", "rationale": "CISA ZTMM v2.0 defines five pillars and three cross-cutting capabilities; incident response is outside its scope. The Visibility and Analytics cross-cutting capability supplies the identity telemetry that IM-08's response playbooks consume; the playbook requirement itself is anchored in incident-response practice beyond the ZTMM.", "source_version": "2.0", "reviewed_on": "2026-07-02", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "informs" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "fit": "direct", "rationale": "ISO/IEC 24760-2:2015's audit and control requirements for identity management systems support IM-08's requirement that identity incidents be investigated and documented through defined playbooks.", "source_version": "2019", "reviewed_on": "2026-07-02", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_iam", "requirement_id": "AWS GuardDuty \u2014 Automated Incident Response", "rationale": "AWS GuardDuty automated response through EventBridge rules enables immediate IAM actions upon detection of identity incident findings: IAM user deactivation, role policy revision to deny all permissions, STS session revocation, and notification to security teams. The response latency from GuardDuty finding to automated IAM action is typically under 5 minutes.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS GuardDuty+EventBridge automate containment actions, but not the four documented, tested playbooks with control-ID detection criteria required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Workflows \u2014 Identity Incident Response", "rationale": "Okta Workflows enables automated identity incident response including immediate kill-switch activation for compromised agent identities, session revocation, credential rotation, and owner notification. Okta for AI Agents includes a built-in deactivation capability triggered by behavioral anomaly detection, enabling sub-minute response to detected identity incidents.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Workflows automate kill-switch, revocation and notification, but not the four documented, tested identity incident playbooks the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Automated response; Part V \u2014 Establish emergency change procedures in advance", "fit": "partial", "rationale": "Automated response revokes credentials/terminates sessions and Part V pre-establishes emergency containment authorization. Partial: doc's incident response is general, not identity-specific.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IM-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "The system maintains four documented, tested, and current identity incident response playbooks covering credential compromise, unauthorized delegation, ghost identity exploitation, and federation abuse, each with detection criteria referencing specific upstream control IDs, containment SLAs, investigation steps, recovery steps, and post-incident review requirements. Each playbook must have been executed in a tabletop exercise within the trailing 12 months and updated within 30 days of any exercise finding.", "evidence_required": [ "identity_incident_playbook_set: four versioned documents (Credential Compromise, Unauthorized Delegation, Ghost Identity Exploitation, Federation Abuse) each containing detection_criteria[] mapped to specific IM-layer control IDs, containment_sla_minutes, investigation_steps[], recovery_steps[], and post_incident_review_requirements[]", "tabletop_exercise_records: dated exercise reports for each playbook within the trailing 12 months including scenario description, participant list, findings, and update action items with completion dates", "incident_closure_reports: sample of closed identity incidents showing playbook_version applied, containment_timeline, timeline_compliance verdict, and post_incident_review completion status", "playbook_dependency_verification_log: quarterly records confirming IF-06 revocation API, DE-08 revocation propagation, and identity registry deprovisioned-credential query are operational and within defined latency thresholds" ], "machine_tests": [ "Query identity registry for a test agent credential marked as deprovisioned then simulate an API call using that credential \u2192 assert the system logs a ghost identity alert and blocks the access attempt", "Inject a synthetic CRITICAL impossible-travel event (Playbook 1 trigger) into the IM monitoring system \u2192 assert the event is mapped to Playbook 1 and a containment workflow task is initiated within 5 minutes", "Invoke the IF-06 credential revocation API for a test credential \u2192 assert all active sessions for that credential are terminated and the credential is rejected on next use within 10 minutes", "Simulate a federation trust anchor verification failure for a test partner \u2192 assert Playbook 4 is triggered and a partner-notification task is logged within the 24-hour SLA window" ], "human_review": [ "Review all four playbooks for section completeness: confirm each contains explicit detection criteria referencing specific IM-layer control IDs, a stated containment SLA in minutes, investigation scope definition, recovery procedure, and post-incident review requirement", "Assess tabletop exercise records for realism: verify each scenario includes machine-speed propagation timelines and that playbook updates were completed within 30 days of exercise closure", "Verify playbook owner assignments are current: confirm named primary and backup responders reflect current organizational roles and are listed in active on-call runbooks" ], "blocking_effect": "requires-review", "normative_status": "supervisory-guidance", "anti_patterns": [ "Maintaining a single generic incident response playbook that treats credential compromise and ghost identity exploitation as equivalent, when containment steps and forensic scope differ fundamentally between the two incident types", "Documenting detection criteria as generic descriptions rather than referencing specific upstream control IDs (IM-01 through IM-07, IF-06, DE-08), making automated alert-to-playbook routing impossible", "Testing playbooks with tabletop scenarios that omit realistic machine-speed propagation timelines, systematically understating the urgency of the 10-minute and 30-minute containment SLAs", "Delaying cross-organizational notification in federation abuse incidents until internal impact assessment is complete, causing the 24-hour partner notification window to lapse", "Implementing ghost identity detection only as a weekly reconciliation batch job rather than a continuous cross-reference, creating multi-day detection windows during which ghost credentials are exploited without triggering Playbook 3" ], "update_status": "current", "layer_code": "IM" }, { "id": "IM-09", "layer": "IM", "plane": "lifecycle", "name": "Identity Monitoring Layer Evidence Package", "plain": "Compile a quarterly identity monitoring layer evidence package consolidating artifacts from IM-01 through IM-08 to demonstrate that behavioral baselines, anomaly detection coverage, and identity incident response procedures are current and tested. The package is a required input to IC-08 (IdentityAttestation) production.", "threat": { "tags": [ "governance-evidence-gap", "attestation-unverifiable", "audit-readiness-deficit" ], "desc": "Without periodic structured compilation of identity monitoring layer evidence, the IdentityAttestation (IC-08) rests on assertions from individual controls rather than compiled, reviewed, and signed evidence. Layer-level gaps are only visible through compilation." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review of AI management system at planned intervals" }, { "id": "nist_rmf", "section": "GOVERN 1.5", "title": "Ongoing monitoring and periodic review of the risk management process and its outcomes" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management system for high-risk AI providers" } ], "sources": [ { "id": "iso_27001_2022", "title": "ISO/IEC 27001:2022 \u2014 Information Security Management System", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "certification-standard", "version": "2022", "published_on": "2022-10-25", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/27001", "license": "proprietary", "status": "current", "flagship": true, "source_id": "iso_27001", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27001:2022 \u2014 Information Security Management System requirements informing the apeiris://identity/controls/IM-09 Identity Monitoring Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_100_1", "title": "NIST AI 100-1: Artificial Intelligence Risk Management Framework", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 100-1: Artificial Intelligence Risk Management Framework requirements informing the apeiris://identity/controls/IM-09 Identity Monitoring Layer Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a quarterly evidence compilation process for the Identity Monitoring layer. Collect required artifacts from IM-01 through IM-08. Review completeness and identify gaps. Produce a signed evidence package for IC-08 IdentityAttestation input.", "steps": [ "Define the IM-layer evidence package schema: required_artifacts[], acceptance_criteria[], gap_register, package_owner, and review_signatories.", "For each control in IM-01 through IM-08, define required evidence artifacts and freshness criteria.", "Compile artifacts quarterly: generate or collect required evidence and stage for structured review.", "Conduct a review session to evaluate completeness, identify gaps, and assign remediation owners.", "Produce a signed identity monitoring layer evidence package and submit it as input to IC-08 IdentityAttestation production.", "Retain the package as an immutable record for audit and regulatory review." ] }, "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001 \u00a79.3 requires management review at planned intervals. IM-09 provides the structured review artifact for the Identity Monitoring layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.5", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.5 requires ongoing monitoring and periodic review of the risk management process and its outcomes, with clear organizational responsibilities. IM-09 instantiates that periodic review at the Identity Monitoring layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Art. 17 requires a quality management system. IM-09 is the QMS artifact for the Identity Monitoring layer.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://identity/controls/IM-09", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A quarterly identity monitoring layer evidence package exists, is complete per the defined package schema (required_artifacts[], acceptance_criteria[], gap_register, package_owner, review_signatories), covers all controls IM-01 through IM-08, has been reviewed and signed by named signatories, and has been formally submitted as input to IC-08 IdentityAttestation production within the current attestation cycle.", "evidence_required": [ "im_layer_evidence_package: signed quarterly package document with required_artifacts[] enumeration, acceptance_criteria[] per artifact, gap_register with remediation owners, and package_owner and review_signatories fields populated and dated", "per_control_evidence_artifacts: collected evidence artifacts from IM-01 through IM-08 staged for review, each meeting the freshness criteria defined in the package schema with retrieved_at timestamps", "evidence_package_review_record: dated review session record confirming completeness assessment, gap identification, remediation owner assignments, and signatory signatures with review date", "ic08_submission_record: record confirming the signed evidence package was submitted as input to IC-08 IdentityAttestation production with submission timestamp and recipient acknowledgment" ], "machine_tests": [ "Load the evidence package schema definition and validate the current quarterly package against it \u2192 assert zero missing required_artifacts[] entries and all acceptance_criteria[] fields are non-null", "Check the package production timestamp against the defined quarterly submission window \u2192 assert the package was produced and signed within 7 days of the quarter close date", "Verify the IC-08 submission record references the current evidence package version and bears a timestamp within the same reporting cycle \u2192 assert submission record exists and is linked to the correct package version" ], "human_review": [ "Review each artifact in the evidence package for freshness: confirm each artifact's collected_at timestamp meets the per-control freshness criteria defined in the package schema and that no artifact is older than the defined maximum age", "Assess the gap_register entries: confirm each gap has a named remediation owner, a target close date, and has been reviewed and acknowledged by the package_owner", "Verify that review_signatories are appropriate governance stakeholders (not self-signed by the package owner alone) and that their signatures are dated within the package production window" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Producing the evidence package as a document citing artifact locations rather than collecting and staging the actual artifacts, making independent verification impossible without re-running the collection process", "Treating the evidence package as an annual deliverable aligned with audit cycles rather than a quarterly operational process, leaving IC-08 IdentityAttestation unsupported for three out of four quarters", "Signing the package before the gap_register review is complete, creating a signed record that does not reflect the actual evidence state at the time of signing", "Submitting the evidence package to IC-08 without review signatory approval, breaking the accountability chain required for attestation validity and reducing IdentityAttestation to a self-assertion" ], "update_status": "current", "lenses": { "iam_engineer": { "summary": "This package consolidates the Identity Monitoring layer, so what you assemble is the detection posture: behavioral baselines, anomaly-detection coverage, detection log sources, alert routing, and identity incident-response test results from IM-01 through IM-08. Unlike the other layer packages this control requires review rather than blocking deployment, but it still must be schema-complete and produced within a tight window. The timing discipline is specific here: the package must be produced and signed within 7 days of quarter close.", "actions": [ "Assemble the im_layer_evidence_package with required_artifacts[], acceptance_criteria[], gap_register, package_owner, and review_signatories, covering all IM-01 through IM-08 controls.", "Include evidence of anomaly-detection coverage across identity log sources and of tested identity incident-response procedures, not just baseline definitions.", "Stage per-control evidence artifacts with retrieved_at timestamps that meet the freshness criteria defined in the package schema.", "Produce and sign the package within 7 days of the quarter close date and validate it against the package schema with zero missing required artifacts.", "Record the ic08_submission_record with a submission timestamp and recipient acknowledgment linking the exact package version to the current reporting cycle." ] }, "security_architect": { "summary": "IM-09 makes the identity monitoring layer attestable. It requires review rather than blocking deployment, which fits a detection-posture control: its role is to prove that anomaly detection has coverage and that incident response was tested, so that IC-08 can claim identity threats would actually be seen and handled. Thin detection coverage or untested incident response is the gap this package is meant to expose before the attestation relies on it.", "actions": [ "Require the package to evidence anomaly-detection coverage across the identity log sources that matter, not a subset that happens to be instrumented.", "Make tested identity incident response an acceptance criterion so an untested runbook is recorded as a gap.", "Treat the 7-day-post-quarter-close production window as a freshness guarantee that the monitoring picture reflects the current cycle.", "Confirm the IM-09 package is submitted as input to IC-08 within the same attestation cycle and that its gaps are visible to the attestation review." ] }, "legal_counsel": { "summary": "The IM-layer package is the record that the enterprise maintained the ability to detect and respond to misuse of identities, including tested incident-response procedures. If an identity-driven incident is later examined, this is the artifact showing detection coverage and response readiness were assessed each quarter rather than assumed. Its evidentiary strength depends on the review record and the tested-response evidence being retained.", "actions": [ "Confirm the signed package and its review record are retained for a period consistent with audit and regulatory retention obligations.", "Verify the tested incident-response evidence is sufficient to demonstrate response readiness at the time of the reporting cycle.", "Ensure gap_register entries record remediation owners so an identified detection gap has documented accountability.", "Check that the ic08_submission_record ties the reviewed package version to the attestation cycle so the record is unambiguous after the fact." ] }, "grc_auditor": { "summary": "For IM-09 the evidence is the signed monitoring-layer package, the per-control artifacts, the review record, and the IC-08 submission record. The auditable disciplines specific to this layer are the 7-day-post-quarter-close production window and the linkage between the exact reviewed package version and the current attestation cycle. Confirm the package validates against its schema with no missing required artifacts and that the submission record references the correct version.", "actions": [ "Validate the current quarterly package against its schema and confirm zero missing required_artifacts[] entries with all acceptance_criteria[] fields non-null.", "Check the package production and sign-off timestamp against the quarter close date and confirm it falls within the 7-day window.", "Verify the ic08_submission_record references the current package version and bears a timestamp within the same reporting cycle.", "Confirm the per-control artifacts from IM-01 through IM-08 carry retrieved_at timestamps meeting the defined freshness criteria." ] }, "it_operations": { "summary": "You run the quarterly monitoring-package compilation against a hard clock: it has to be produced and signed within 7 days of quarter close. Behind it you keep the detection log sources, anomaly-detection feeds, and alert routing healthy so the coverage evidence is real. The operational tell for this layer is a log source that went dark or an alert route that no longer fires, which shows up as a coverage gap in the package.", "actions": [ "Schedule compilation and sign-off to complete within 7 days of quarter close and alert if the window is at risk.", "Monitor detection log sources and alert-routing health so a silent gap in coverage is caught before it becomes an evidence gap.", "Ensure incident-response test results and anomaly-detection coverage data are captured with retrieved_at timestamps that meet freshness criteria.", "Record the IC-08 submission with timestamp and recipient acknowledgment, and re-run compilation if a detection gap is closed mid-cycle." ] } }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "maturity": { "current": "initial", "target": "defined", "notes": "Layer-level evidence compilation is rare; most organizations assemble identity audit evidence ad hoc at audit time. Target state is an automated quarterly Identity Monitoring package with signed integrity, a maintained gap register, and direct feed into IC-08 attestation production." }, "implementers": [ "IAM Team", "GRC / Internal Audit", "Platform Engineering" ], "validation": { "design_check": [ "Verify the Identity Monitoring evidence package schema defines required artifacts for every IM-01 through IM-08 control, with acceptance criteria and freshness windows per artifact.", "Confirm package assembly is automated from authoritative sources (registry exports, IdP and pipeline logs) rather than manually collated documents.", "Validate that the package is signed and hash-chained so downstream consumers (IC-08 attestation production) can verify integrity and completeness." ], "runtime_test": [ "Request the current Identity Monitoring evidence package via the integration API and confirm every IM-layer control contributes at least one artifact with a collection timestamp inside the freshness window.", "Tamper with one staged artifact and confirm the package integrity check fails and the package is rejected as IC-08 input.", "Simulate a missing artifact for one control and confirm the gap register records it with an assigned owner and remediation date." ], "evidence": [ "evidence-package:Signed quarterly Identity Monitoring layer evidence package with per-control artifact manifest [unverified]", "gap-register:Gap register entries for the prior four quarters with remediation owners and closure dates [unverified]", "review-signoff:Quarterly review sign-off records naming the reviewing owners and their dispositions [unverified]" ] }, "layer_code": "IM", "lens_enrichment": "ap42 2026-07-08" }, { "id": "IC-01", "layer": "IC", "plane": "lifecycle", "name": "Identity Governance Structure", "plain": "Establish and maintain a formal governance structure with defined roles, responsibilities, and oversight bodies accountable for enterprise identity management decisions.", "threat": { "tags": [ "orphaned-credential", "privilege-escalation", "org-change-lag" ], "desc": "Without a defined governance structure, accountability for identity lifecycle decisions becomes diffuse and reactive, allowing unowned credentials to persist indefinitely. Unmanaged identity programs accumulate orphaned accounts and unchecked privilege growth across organizational changes. Audit exposure compounds when no named party can demonstrate authority over access decisions during regulatory review." }, "standard": [ { "id": "nist_800_63", "section": "\u00a73", "title": "Digital Identity Risk Management" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Identity management governance \u2014 roles and responsibilities" } ], "sources": [ { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-01 Identity Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-01 Identity Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "cisa_ztmm_v2_2023", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "guidance", "normative_force": "best-practice", "version": "2.0", "published_on": "2023-04-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.cisa.gov/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "informative_reference", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IC-01 Identity Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IC-01 Identity Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-01 Identity Governance Structure control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish an Identity Governance Committee with cross-functional membership, define a RACI for all identity lifecycle decisions, and publish a charter with escalation paths and a defined review cadence.", "steps": [ "Form an Identity Governance Committee (IGC) with representation from IAM, Security, Legal, HR, and business unit owners", "Author a governance charter specifying committee scope, decision authority, escalation thresholds, and meeting cadence", "Publish a RACI matrix covering identity provisioning, access review, exception handling, and termination workflows", "Establish a governance metrics dashboard tracking SLA compliance, exception aging, and review completion rates" ], "anti_patterns": [ "Informal governance managed through email threads with no documented accountability or escalation chain", "Single-team ownership of identity governance with no cross-functional oversight or business stakeholder participation", "Governance charter exists on paper but the committee has not convened in over 90 days and tracks no active metrics" ] }, "validation": { "design_check": [ "IGC charter is signed, includes committee membership, defined scope, and documented decision authority levels", "RACI matrix covers all major identity lifecycle events: provisioning, modification, periodic review, and revocation", "Governance escalation path is defined, published in runbooks, and tested at least annually" ], "runtime_test": [ "Verify IGC meeting minutes exist for the trailing 12 months with attendance records and closed action items", "Confirm exception requests are logged, assigned to a named owner, and resolved within charter-defined SLAs", "Sample 10 recent identity lifecycle decisions and confirm each traces to a RACI-authorized approver" ], "evidence": [ "document:Signed identity governance charter with effective date and version history [unverified]", "record:IGC meeting minutes for trailing 12 months with action item disposition records [unverified]", "artifact:Approved RACI matrix version-controlled and acknowledged by CISO or designated delegate [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Governance structure defines who approves your provisioning workflows, exception requests, and tooling change requests.", "actions": [ "Map all automated provisioning decision points to a named governance owner in the RACI", "Ensure IGC charter grants explicit authority to approve IGA tool configuration changes and role model updates", "Publish IGC escalation contacts in internal IAM runbooks and on-call rotation documentation" ], "failure_signals": [ "Provisioning SLA breaches have no identified escalation owner in any documented runbook", "IGA tool configuration changes are deployed without any governance approval record" ] }, "security_architect": { "summary": "Governance structure determines how identity risk decisions are made and who holds authority to override controls.", "actions": [ "Ensure the governance charter includes a formal risk acceptance process with defined authority thresholds", "Integrate the IGC with the enterprise risk committee for cross-domain identity risk decisions", "Define governance thresholds that mandate security architecture review before exceptions are granted" ], "failure_signals": [ "Identity exceptions are approved by line managers with no security architecture review", "No formal process exists to escalate high-risk identity decisions to architecture-level authority" ] }, "legal_counsel": { "summary": "Governance structure establishes the accountability chain required for regulatory inquiry response and litigation holds.", "actions": [ "Confirm the governance charter assigns data controller accountability for identity data per applicable privacy law", "Ensure IGC includes legal representation or a defined escalation path for regulatory inquiries", "Verify governance decisions affecting identity data retention and deletion are documented with legal review" ], "failure_signals": [ "No named accountable party for identity data under GDPR, CCPA, or applicable privacy regulation", "Regulatory inquiries about access decisions cannot be traced to a documented governance record" ] }, "grc_auditor": { "summary": "Governance structure provides the primary audit evidence that identity decisions are made with documented authority and oversight.", "actions": [ "Collect IGC charter, current membership roster, and 12-month meeting minutes as core audit artifacts", "Verify the RACI matrix is reviewed and updated at least annually with version-controlled evidence", "Confirm all exceptions logged in the governance system are resolved within policy-defined timelines" ], "metrics": [ "IGC meeting frequency versus charter-defined cadence (target: 100% adherence over trailing 12 months)", "Open governance exceptions older than 30 days as a percentage of total open items (target: fewer than 5%)" ], "failure_signals": [ "IGC charter is unsigned, has no effective date, or has not been reviewed in over 24 months", "Audit cannot produce meeting minutes or closed action items for the past two governance cycles" ] }, "it_operations": { "summary": "Governance structure defines who can authorize operational changes to identity infrastructure and directory services.", "actions": [ "Require all identity system change requests to reference a governance approval record in the change management system", "Publish IGC escalation contacts in the operations ticketing system and incident response runbooks", "Include governance notification procedures for P1 identity incidents in on-call documentation" ], "failure_signals": [ "Identity system changes are deployed without any governance sign-off in change management records", "Operations team cannot identify the IGC escalation contact during an active identity incident" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations begin with ad-hoc governance; the target state requires a documented charter, an active IGC with measurable meeting cadence, and SLA-based exception tracking." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 \u00a73", "title": "Identity Assurance Level Selection and Governance", "rationale": "SP 800-63-4 \u00a73 (Digital Identity Risk Management) requires organizations to run a governed process for selecting and maintaining assurance levels; IC-01's governance structure is the organizational owner of that process for AI agent identities.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "SP 800-63-4 section 3 requires a governed digital-identity risk process; IC-01 establishes the organizational owner of that process for agent identity.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "title": "Identity Management Governance", "rationale": "ISO/IEC 24760-2:2015 specifies requirements for the management and governance of identity information, including defined roles and responsibilities; IC-01 establishes that governance structure for AI agent identity.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "ISO/IEC 24760-2 specifies governance of identity information with defined roles; IC-01 establishes that governance structure for AI agent identity.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Governance (cross-cutting capability)", "title": "Identity Governance \u2014 CISA ZTMM Identity Pillar", "rationale": "The CISA ZTMM v2.0 Governance cross-cutting capability requires formal ownership and policy enforcement across pillars as maturity advances; IC-01 establishes that ownership for the identity pillar.", "mapping_fit": "direct", "normative_force": "supervisory-guidance", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "CISA ZTMM Governance capability requires formal ownership and policy enforcement; IC-01 establishes that ownership for the identity pillar.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Identity Governance \u2014 Governance Structure", "rationale": "Okta Identity Governance (OIG) provides the organizational framework for governing both human and non-human identities through a unified platform: access certification campaigns for periodic review, access request workflows with approval routing, entitlement management for fine-grained access governance, and policy automation for continuous compliance enforcement.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Identity Governance supplies certification and access-request tooling that supports the governance structure but is not the chartered committee itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity for AI \u2014 Governance Capabilities", "rationale": "Ping Identity's Agent IAM Core includes governance capabilities for managing agent identity lifecycle with explicit owner linkage, organizational delegation policy enforcement, and audit trail generation. The governance framework extends traditional IAM governance patterns to non-human identities, ensuring AI agents are subject to the same accountability structures as human users.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Ping Agent IAM Core provides agent-lifecycle governance tooling with owner linkage and audit, supporting but not constituting the governance committee.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 AI governance policies (formal governance framework)", "fit": "direct", "rationale": "A formal cross-functional governance framework \u2014 identity governance structure.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-01", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A formal Identity Governance Committee exists with a signed charter, current cross-functional membership roster, documented decision authority levels, and a defined meeting cadence; the IGC has convened at the required cadence over the trailing 12 months with documented meeting minutes and closed action items; and all identity lifecycle decision authority is covered by a current RACI matrix acknowledged by the CISO or delegate.", "evidence_required": [ "identity_governance_charter: signed document with effective_date, version_history, committee_scope, decision_authority_thresholds, escalation_paths, and meeting_cadence; reviewed within the preceding 24 months", "igc_meeting_minutes: minutes for all IGC meetings over the trailing 12 months with attendance records, agenda items, decisions made, and action items with disposition status and close dates", "raci_matrix: version-controlled RACI covering identity provisioning, modification, periodic review, exception handling, and termination workflows; acknowledged by CISO or designated delegate with acknowledgment date", "governance_metrics_dashboard_snapshot: current snapshot showing SLA compliance rates, open exception aging distribution, and review completion rates as defined in the governance charter" ], "machine_tests": [ "Query the identity governance system for exception requests where age > charter_defined_sla_days and status != escalated \u2192 assert zero unescalated exceptions exceed the defined resolution window", "Cross-reference IGC meeting calendar entries against the charter-defined cadence for the trailing 12 months \u2192 assert meeting frequency meets charter requirements with no gap exceeding one full cadence interval" ], "human_review": [ "Review the IGC charter for completeness: confirm it contains committee scope, named decision authority levels, escalation thresholds, and a defined meeting cadence signed by the CISO or designated delegate", "Assess IGC meeting minutes for substantive governance activity: verify action items are tracked, assigned to named owners, and closed within charter-defined SLAs rather than deferred across consecutive meetings", "Verify the RACI matrix covers all identity lifecycle decision points and that named approvers reflect current organizational roles \u2014 not departed or transferred personnel" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Forming an Identity Governance Committee as a paper structure that has not convened in over 90 days and tracks no active metrics or open action items, creating nominal governance with no operational substance", "Assigning identity governance ownership to a single team (IAM or Security alone) with no cross-functional representation from Legal, HR, or business unit owners, creating blind spots in risk assessment and accountability", "Maintaining a RACI matrix that has not been updated following organizational changes, with named approvers who have since transferred or departed and whose successors are not reflected", "Approving identity exceptions through informal channels (email threads, Slack messages) without logging in a governed system, making audit reconstruction of the exception basis impossible", "Operating without documented escalation thresholds that specify when identity decisions must be elevated above the IGC to executive, board, or regulatory-response levels" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-02", "layer": "IC", "plane": "lifecycle", "name": "Identity Policy and Standards", "plain": "Author, approve, publish, and maintain a hierarchy of identity policies and technical standards that govern how digital identities are created, managed, and retired across the enterprise.", "threat": { "tags": [ "credential-compromise", "identity-spoofing", "delegation-abuse" ], "desc": "Without documented policies and technical standards, identity controls are implemented inconsistently, creating exploitable gaps between teams and systems. Undocumented delegation rules allow credential sharing and informal proxy arrangements that obscure audit trails. Identity spoofing becomes viable when authentication strength requirements are not codified and enforced uniformly." }, "standard": [ { "id": "nist_800_63", "section": "\u00a73.3.2", "title": "Assurance level (xAL) selection recorded in policy" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Identity management policy requirements across the lifecycle" } ], "sources": [ { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-02 Identity Policy and Standards control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-02 Identity Policy and Standards control.", "reviewed_on": "2026-07-02" }, { "id": "nist_sp_800_207_2020", "title": "NIST SP 800-207 Zero Trust Architecture", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-01", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 Zero Trust Architecture requirements informing the apeiris://identity/controls/IC-02 Identity Policy and Standards control.", "reviewed_on": "2026-07-01" }, { "id": "openai_preparedness_fw_v2", "title": "OpenAI Preparedness Framework v2", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2025-04-15", "retrieved_on": "2026-06-28", "canonical_url": "https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_preparedness", "relationship": "informative_reference", "rationale": "Establishes OpenAI Preparedness Framework v2 requirements informing the apeiris://identity/controls/IC-02 Identity Policy and Standards control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy (RSP) v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy (RSP) requirements informing the apeiris://identity/controls/IC-02 Identity Policy and Standards control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a three-tier policy hierarchy (enterprise policy \u2192 domain standards \u2192 implementation guidelines) with formal approval workflows, version control, and mandatory exception processes.", "steps": [ "Define the policy hierarchy: enterprise identity policy at tier 1, domain-specific identity standards at tier 2, and implementation guidelines at tier 3", "Author policies for all major identity lifecycle stages: identity proofing, enrollment, authentication, authorization, delegation, and termination", "Implement a policy exception process requiring named approver, documented risk acceptance, and defined expiry date", "Publish all policies in a version-controlled, searchable repository with automated expiry notifications for owners" ], "anti_patterns": [ "Single monolithic identity policy document that has not been reviewed in over 24 months", "Technical standards that exist only in engineering wikis with no formal approval or version history", "Exceptions granted verbally or via email with no formal risk acceptance documentation or expiry tracking" ] }, "validation": { "design_check": [ "Policy hierarchy is documented with clear parent-child relationships and defined applicability scope for each tier", "Each policy has a named owner, approval date, review cycle, and version history", "A formal exception process exists with documented approval authority and mandatory expiry dates" ], "runtime_test": [ "Confirm all active identity policies have been reviewed within their defined review cycle", "Sample 5 recently granted exceptions and verify each has a risk acceptance record, named approver, and expiry date", "Audit three identity systems to confirm their configurations match the applicable tier-2 standards" ], "evidence": [ "document:Approved enterprise identity policy with version history and CISO or delegate signature [unverified]", "record:Policy exception register showing open exceptions with approver, risk acceptance, and expiry date [unverified]", "artifact:Policy review completion records for trailing 24-month cycle covering all tier-1 and tier-2 documents [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Identity policies define the technical requirements your IGA configurations and authentication protocols must implement.", "actions": [ "Map each tier-2 identity standard to concrete IGA configuration parameters and authentication protocol settings", "Subscribe to policy expiry notifications so engineering changes are planned before policy gaps emerge", "Ensure implementation guidelines include machine-readable policy references for automated compliance checking" ], "failure_signals": [ "IGA configurations cannot be traced to a specific policy requirement or standard version", "Authentication strength settings differ across environments with no policy justification for the variance" ] }, "security_architect": { "summary": "Identity policy hierarchy determines how authentication strength requirements are inherited across system boundaries.", "actions": [ "Ensure tier-1 policy defines minimum authentication assurance levels by data classification and system risk tier", "Architect policy inheritance so higher-risk systems automatically adopt stricter standards without manual configuration", "Include policy binding requirements in architecture review checklists for new systems and integrations" ], "failure_signals": [ "High-risk systems have authentication requirements defined locally rather than inheriting from tier-1 policy", "No mechanism exists to detect when system-level configuration drifts from the applicable tier-2 standard" ] }, "legal_counsel": { "summary": "Identity policies create the contractual and regulatory basis for demonstrating due diligence in identity management.", "actions": [ "Verify identity policies address regulatory obligations including GDPR data minimization for identity data", "Ensure delegation and credential sharing policies explicitly prohibit practices that would create regulatory liability", "Confirm policy language is reviewed for legal enforceability, particularly for third-party identity obligations" ], "failure_signals": [ "Identity policies do not address applicable data protection law obligations for the jurisdictions of operation", "Delegation policies permit credential sharing in ways that would undermine non-repudiation in legal proceedings" ] }, "grc_auditor": { "summary": "Identity policies are the primary control baseline against which all identity-related audit findings are measured.", "actions": [ "Maintain a policy inventory with review dates, owners, and applicability scope as a standing audit artifact", "Map each policy requirement to the identity controls tested during audit to demonstrate coverage", "Verify exception register is complete and that no exceptions have exceeded their approved expiry date" ], "metrics": [ "Percentage of identity policies reviewed within their defined review cycle (target: 100%)", "Number of expired exceptions remaining active in the register (target: zero)" ], "failure_signals": [ "Identity policy inventory is incomplete or contains documents with no review date or named owner", "Exceptions are routinely renewed without fresh risk assessment or escalation to governance" ] }, "it_operations": { "summary": "Identity policy standards define the configuration baselines that operations must maintain across all identity systems.", "actions": [ "Reference applicable tier-2 identity standards in change management records for all identity system modifications", "Use automated compliance scanning to detect configuration drift from published identity standards", "Escalate standard conflicts discovered during operations to the IAM team before implementing workarounds" ], "failure_signals": [ "Configuration changes are made to identity systems without referencing the applicable standard or policy", "Compliance scan findings persist unresolved beyond the policy-defined remediation window" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Target state requires a formally approved three-tier policy hierarchy with version control, active review cycles, and a closed-loop exception process." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 \u00a73.3.2", "title": "Identity Assurance Requirements and Policy Binding", "rationale": "SP 800-63-4 \u00a73.3.2 defines the IAL/AAL/FAL selection outcome that identity policy must record; IC-02 requires xAL requirements to be documented and bound in formal policy per application, applied to AI agent identity by analogy.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "SP 800-63-4 section 3.3.2 defines the xAL selection outcome that identity policy must record; IC-02 binds those xAL requirements in formal policy.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "title": "Identity Management Policy Framework", "rationale": "ISO/IEC 24760-2:2015 requires documented policies for identity information management across the full lifecycle from creation through termination; IC-02's identity policy set implements this for AI agent identities.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "ISO/IEC 24760-2 requires documented identity-lifecycle policies; IC-02 authors and maintains that policy set for AI agent identities.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_zt", "requirement_id": "\u00a73.3", "title": "Identity Policy in Zero Trust Architecture", "rationale": "NIST SP 800-207 \u00a73.3 defines the trust algorithm \u2014 the policy engine's decision process over subject identity, credentials, and behavior. IC-02's identity policy supplies the enumerated subjects, credential requirements, and permitted access paths that the trust algorithm consumes.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "NIST SP 800-207 section 3.3 defines the trust algorithm over subjects and credentials; IC-02 policy supplies the enumerated subjects and credential rules.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Anthropic RSP v3.3 \u2014 ASL Deployment and Security Standards", "rationale": "Anthropic's Responsible Scaling Policy v3.3 conditions model deployment on AI Safety Level (ASL) Deployment and Security Standards \u2014 safeguards and access controls that scale with capability. For enterprise identity policy, the RSP's commitments (together with Anthropic's commercial terms and usage policies that operators accept) supply capability-conditioned deployment guardrails to reference; the RSP itself binds Anthropic, not enterprise operators.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic RSP conditions deployment on ASL standards, an analogous developer policy but not the enterprise identity policy standards the control requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_sf", "requirement_id": "Preparedness Framework v2 \u2014 safeguards for High-capability deployment", "rationale": "OpenAI's Preparedness Framework v2 requires that models reaching High capability thresholds have safeguards that sufficiently minimize risk before deployment; its safeguards appendix lists identity-relevant example measures such as KYC verification and access-control gating for higher-capability access. These are framework examples rather than blanket requirements, but they supply the baseline shape of an AI identity policy for enterprise deployments of OpenAI models.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI Preparedness Framework requires deployment safeguards with identity-relevant examples, analogous to but not the enterprise identity policy set.", "fit_assessed_on": "2026-07-03", "basis": "asserted", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 AI governance policies (Documented acceptable use and incident response policies)", "fit": "direct", "rationale": "Documented acceptable-use/prohibited-activity and governance policies \u2014 identity policy and standards.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-02", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A three-tier identity policy hierarchy exists with each document bearing a named owner, an approved version, and a completed review within its defined cycle; a formal exception process is actively maintained with all open exceptions carrying a risk acceptance record, named approver, and future expiry date; and zero expired exceptions remain active in the exception register.", "evidence_required": [ "policy_hierarchy_inventory: registry of all tier-1, tier-2, and tier-3 identity policy documents with document_id, named_owner, approval_date, review_cycle_days, current_version, and last_reviewed_date for each entry", "policy_approval_records: signed approval records for each tier-1 and tier-2 document including approver_name, approval_date, and version_approved", "exception_register: current list of all active policy exceptions with exception_id, policy_violated, risk_acceptance_rationale, approver, grant_date, and expiry_date; zero entries with expiry_date prior to today", "policy_review_completion_records: evidence that each policy document was formally reviewed within its defined review cycle covering the trailing 24 months, with reviewer name and review date" ], "machine_tests": [ "Query the exception register for entries where expiry_date < today and status = active \u2192 assert zero active exceptions have an expired approval date", "Cross-reference identity system configurations for three sampled systems against the applicable tier-2 standard \u2192 assert each configuration matches the standard or has a documented approved exception on file", "Query the policy inventory for documents where last_reviewed_date > (today minus review_cycle_days) \u2192 assert all documents are within their defined review cycle" ], "human_review": [ "Assess the three-tier policy hierarchy for lifecycle completeness: verify tier-1 covers all major identity stages (proofing, enrollment, authentication, authorization, delegation, termination) and that tier-2 standards exist for each covered system class", "Review a sample of five exception records for quality: confirm each has a substantive risk acceptance rationale, an approver with appropriate authority, and a specific expiry date \u2014 not merely an administrative acknowledgment", "Evaluate whether exception renewal requests undergo fresh risk assessment or are routinely approved without re-evaluating whether the underlying gap has been remediated" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Maintaining a single monolithic identity policy document that has not been formally reviewed in over 24 months, making the entire control baseline potentially stale and unenforceable at audit", "Allowing technical identity standards to exist only as informal engineering wiki pages without formal approval, version history, or named ownership, making them non-authoritative for regulatory response", "Granting policy exceptions verbally or via email thread with no formal risk acceptance record, creating gaps in the audit trail that cannot be reconstructed under regulatory or litigation discovery", "Renewing expired exceptions automatically without re-evaluating the underlying risk or escalating to governance, allowing temporary workarounds to harden into permanent shadow policy", "Operating without automated expiry notifications for policy documents and exceptions, leading to undiscovered policy lapses and expired exception grants that remain active" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-03", "layer": "IC", "plane": "lifecycle", "name": "Identity Access Review", "plain": "Conduct structured access reviews on a defined periodic schedule and on-demand when organizational changes occur, ensuring all identity entitlements remain appropriate, authorized, and minimal.", "threat": { "tags": [ "orphaned-credential", "privilege-escalation", "org-change-lag", "lateral-movement" ], "desc": "Stale entitlements from role changes, transfers, and departures are among the most common sources of insider threat and lateral movement opportunities. Periodic-only review cycles create predictable windows where orphaned credentials persist between review periods, particularly after rapid organizational changes such as mergers, reductions in force, or business unit restructuring. Attackers who gain initial access through compromised credentials exploit accumulated privilege to move laterally before the next scheduled review catches the anomaly." }, "standard": [ { "id": "iso_24760", "section": "\u00a710", "title": "Maintenance of identity information \u2014 periodic review" } ], "sources": [ { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-02" }, { "id": "ietf_rfc_7643_7644_scim", "title": "SCIM 2.0 \u2014 System for Cross-domain Identity Management (RFC 7644)", "authority": "IETF", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2015-09-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.rfc-editor.org/rfc/rfc7644", "license": "public-domain", "status": "current", "flagship": false, "source_id": "scim", "relationship": "implementation_pattern", "rationale": "Establishes SCIM 2.0 \u2014 System for Cross-domain Identity Management (RFC 7644) requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_ztmm_v2_2023", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "guidance", "normative_force": "best-practice", "version": "2.0", "published_on": "2023-04-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.cisa.gov/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "informative_reference", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-03 Identity Access Review control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement dual-trigger access review: a quarterly scheduled review for all identities combined with automated org-change-triggered review within 24 hours of any HR event signaling a role change, transfer, departure, or entity restructuring.", "steps": [ "Define org-change triggers from HR systems (HRIS events: job change, transfer, leave, termination, org restructuring) that automatically initiate an access review workflow for the affected identity", "Configure SCIM provisioning events or HR-IGA integration to propagate org-change signals to the IGA platform within 4 hours of the triggering event", "Implement quarterly scheduled access review campaigns covering all human identities, service accounts, and AI system identities, with manager and data owner as reviewers", "Establish escalation and auto-revocation policy: entitlements not reviewed within the campaign window are automatically revoked, with access restoration requiring re-approval", "Subscribe to organizational hierarchy change events from apeiris://authority/controls/PA-01 (delegation of authority integration); when a position changes or a group membership is modified, trigger an immediate access review for all agents operating under affected principals \u2014 do not defer to the next periodic cycle." ], "anti_patterns": [ "Relying solely on annual or semi-annual access review campaigns with no event-driven review between scheduled periods", "Using manual HRIS exports for access review rather than automated SCIM or API-based org-change event integration", "Allowing reviewers to rubber-stamp entitlement continuations without requiring documented business justification for each item" ] }, "validation": { "design_check": [ "Access review policy defines both scheduled cadence and specific org-change triggers that initiate an immediate review workflow", "HR-to-IGA integration is tested to confirm org-change events propagate within the defined SLA window", "Auto-revocation policy for unreviewed entitlements is documented, approved by governance, and technically enforced" ], "runtime_test": [ "Simulate an HRIS job-change event for a test identity and verify the IGA platform initiates a review workflow within 4 hours", "Sample 10 recent terminations and confirm access was revoked within the policy-defined window with IGA evidence", "Review the most recent quarterly campaign completion rate; confirm 100% of entitlements were either confirmed or revoked within the campaign window" ], "evidence": [ "record:Completed access review campaign reports for trailing 12 months with reviewer names and decision audit trail [unverified]", "log:IGA audit log showing org-change-triggered review workflows initiated within SLA for sampled HRIS events [unverified]", "artifact:Auto-revocation policy approval record and technical enforcement configuration from IGA platform [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Access review effectiveness depends on reliable HRIS-to-IGA event integration and well-tuned campaign configuration for org-change triggers.", "actions": [ "Configure SCIM or API-based HRIS integration to emit provisioning events for job changes, transfers, leaves, and terminations", "Set IGA campaign auto-escalation rules so unreviewed items surface to secondary reviewers before the revocation deadline", "Instrument review campaign dashboards to track completion rate, overdue items, and avg time-to-decision in real time" ], "failure_signals": [ "Terminated employees retain active entitlements beyond the policy-defined revocation window due to HRIS-IGA sync lag", "Quarterly review campaigns show completion rates below 85% with no escalation or auto-revocation enforcement" ] }, "security_architect": { "summary": "Org-change-triggered access review is a critical compensating control against lateral movement by reducing the privilege retention window.", "actions": [ "Design HRIS-IGA integration with event-driven architecture rather than batch synchronization to minimize the privilege retention window", "Include AI system and service account identities explicitly in access review scope with technical owner as reviewer", "Define access review scope to include both direct entitlements and inherited role memberships that confer indirect access" ], "failure_signals": [ "AI system identities and service accounts are excluded from access review campaigns", "Indirect role-based entitlements are not enumerated during review, leaving shadow access unchecked" ] }, "legal_counsel": { "summary": "Timely access revocation following org changes is a due diligence obligation under employment law and data protection regulations.", "actions": [ "Confirm access revocation SLAs for departing employees are aligned with employment agreement termination obligations", "Verify access review records can demonstrate timely revocation in response to regulatory or litigation discovery requests", "Ensure contractor and third-party identity reviews are included in scope with contractually defined review obligations" ], "failure_signals": [ "Audit reveals departed employees retained system access beyond their final work date", "Access review records do not exist for third-party contractor identities with access to regulated data" ] }, "grc_auditor": { "summary": "Access review evidence must demonstrate both scheduled completeness and event-triggered timeliness to satisfy audit requirements.", "actions": [ "Collect quarterly campaign completion reports with reviewer attestations and decision audit trails for all review cycles", "Request IGA logs showing org-change-triggered reviews for a sample of HRIS events to verify SLA compliance", "Test the auto-revocation control by verifying that entitlements not reviewed within the campaign window were revoked automatically" ], "metrics": [ "Quarterly campaign completion rate (target: 100% of in-scope entitlements reviewed or revoked within window)", "Org-change-triggered review initiation SLA adherence (target: 100% of trigger events initiate review within 4 hours)" ], "failure_signals": [ "Terminated employee access revocation evidence is missing or shows revocation occurring more than 24 hours after departure", "Review campaigns show the same reviewer approving their own access entitlements without a secondary approval step" ] }, "it_operations": { "summary": "Operations must ensure HRIS-IGA integration remains reliable and that access review campaigns do not create operational outages from bulk revocations.", "actions": [ "Monitor HRIS-to-IGA event queue health and alert on processing delays exceeding 1 hour for termination events", "Stage auto-revocation enforcement to avoid simultaneous bulk revocations during peak operational windows", "Maintain a fast-track access restoration process for cases where auto-revocation incorrectly revokes business-critical access" ], "failure_signals": [ "HRIS-IGA integration silently fails during org restructuring events, delaying access revocation for affected identities", "Bulk access revocations following review campaigns create operational disruptions without advance change notification" ] } }, "maturity": { "current": "developing", "target": "managed", "notes": "Most enterprises have periodic review campaigns; the maturity progression requires event-driven org-change triggers, auto-revocation enforcement, and measurable SLA compliance." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "scim", "requirement_id": "RFC 7644 \u00a73.4", "title": "SCIM Provisioning Events for Org-Change Integration", "rationale": "SCIM RFC 7644 \u00a73.4 defines how provisioned resources are retrieved and queried; these operations give IGA access-review workflows a standard way to enumerate current identities and entitlements. SCIM itself does not mandate periodic reviews.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "fit": "partial", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Access Management", "title": "Continuous Identity Validation \u2014 CISA ZTMM Identity Pillar", "rationale": "The CISA ZTMM Identity pillar's Access Management function expects access to be continuously validated and right-sized; event-driven access review beyond calendar cycles is the corresponding maturity indicator.", "mapping_fit": "direct", "normative_force": "supervisory-guidance", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "CISA ZTMM Identity Access Management expects continuously validated, right-sized access including event-driven review - the access review IC-03 conducts.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Access Certifications \u2014 Service Account Reviews", "rationale": "Okta Access Certifications natively support access reviews for both human and non-human identities including service accounts managed in Okta Privileged Access. Reviews can be triggered automatically on schedule or in response to security events, routed to the accountable owner recorded in the registry, and remediated automatically when certification is not completed within the SLA.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Access Certifications natively run scheduled and event-triggered access reviews for human and non-human identities - the review IC-03 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM Access Analyzer \u2014 Continuous Access Review", "rationale": "AWS IAM Access Analyzer continuously evaluates IAM policies to identify overprivileged roles, unused permissions, and external access, providing automated access review findings that complement manual certification campaigns. Access Analyzer unused access findings integrate into Security Hub for centralized review queue management across the organization.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Access Analyzer continuously flags over-privileged and unused access, complementing but not constituting the structured certification campaign required.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Privilege scoping (Review and certify permissions periodically; Remove unused permissions)", "fit": "direct", "rationale": "Foundation privilege scoping reviews/certifies permissions periodically and removes unused permissions \u2014 identity access review.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-03", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "cross_domain": { "upstream": [ "apeiris://authority/controls/PA-01" ] }, "validation_objective": "All identity entitlements are subject to dual-trigger review: a quarterly scheduled campaign covering all identity types (human, service account, AI system) with 100% completion or auto-revocation enforcement; and an org-change-triggered review initiated within 4 hours of any HRIS termination, job-change, or transfer event. No entitlement exists for a departed identity beyond the policy-defined revocation window, and no quarterly campaign closes with uncertified items that remain active.", "evidence_required": [ "access_review_campaign_reports: quarterly campaign completion reports for the trailing 12 months showing reviewer_name, decision audit trail per entitlement, completion_rate, and auto_revocation_records for all uncertified items", "iga_org_change_trigger_log: IGA audit log entries for HRIS-triggered review workflows showing triggering_event_id, trigger_timestamp, review_workflow_initiated_timestamp, and sla_met flag for each event in a representative sample", "termination_access_revocation_sample: records for 10 recent identity terminations showing credential_id, termination_date, revocation_timestamp, and time_delta confirming revocation within the policy-defined window", "auto_revocation_policy_configuration: IGA platform configuration record confirming auto-revocation is enabled for uncertified entitlements with the policy-approved campaign window, and the governance approval record for the auto-revocation policy" ], "machine_tests": [ "Inject a synthetic HRIS termination event for a test identity into the IGA integration \u2192 assert a review workflow is initiated within 4 hours and access is revoked within the policy-defined revocation window", "Create a test entitlement and leave it uncertified through a quarterly campaign cycle \u2192 assert the auto-revocation policy revokes the entitlement at campaign close with an IGA log entry", "Query IGA for entitlements owned by identities whose HRIS status is terminated \u2192 assert zero active entitlements exist for terminated identities beyond the policy-defined revocation window" ], "human_review": [ "Review five recent quarterly campaign completion reports for evidence of substantive reviewer decisions: confirm each reviewed item has a documented business justification for continuation or revocation, not a bulk approval without per-item rationale", "Assess the HRIS-to-IGA integration architecture for reliability: verify event propagation is monitored with alerts for processing delays exceeding 1 hour on termination events, and that integration health is tested regularly", "Evaluate the access review scope to confirm AI system identities and service accounts are included with a named technical owner as reviewer, not excluded on the grounds that they are non-human" ], "blocking_effect": "requires-review", "normative_status": "voluntary-standard", "anti_patterns": [ "Relying on annual or semi-annual review campaigns with no event-driven org-change triggers, creating predictable windows where terminated and transferred employee entitlements persist unchecked between review cycles", "Processing HRIS org-change signals through batch synchronization jobs rather than event-driven integration, introducing delays of 24 hours or more in access revocation after departure or role change", "Allowing reviewers to approve continuation of their own access entitlements without a mandatory secondary approval step, undermining review independence and creating self-certification risk", "Excluding AI system identities and service accounts from access review scope, leaving high-privilege non-human identities unchecked between PAM audits", "Closing access review campaigns without auto-revocation enforcement for uncertified items, allowing campaigns to complete with active uncertified entitlements that no reviewer has examined" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-04", "layer": "IC", "plane": "lifecycle", "name": "Privileged Identity Management for AI", "plain": "Apply privileged access management controls specifically to AI system identities, requiring just-in-time elevation, ephemeral credentials, and enhanced monitoring for all AI agent access to sensitive resources.", "threat": { "tags": [ "privilege-escalation", "delegation-abuse", "lateral-movement", "credential-compromise" ], "desc": "AI systems are routinely provisioned with standing privileged access that far exceeds what any individual task requires, creating high-value credential targets. Compromised AI service credentials are particularly dangerous because automated agents operate at machine speed and can exhaust access paths before detection. Delegation chains in agentic systems allow privilege to cascade from an orchestrator to sub-agents in ways that no single access review or PAM control was designed to govern." }, "standard": [ { "id": "nist_zt", "section": "\u00a75.7", "title": "Use of Non-person Entities in ZTA Administration" }, { "id": "iso_24760", "section": "\u00a77.2", "title": "Managing identity information \u2014 lifecycle stages for privileged credentials" } ], "sources": [ { "id": "nist_sp_800_207_2020", "title": "NIST SP 800-207 Zero Trust Architecture", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-08-01", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-207", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_zt", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-207 Zero Trust Architecture requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_ztmm_v2_2023", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "guidance", "normative_force": "best-practice", "version": "2.0", "published_on": "2023-04-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.cisa.gov/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "informative_reference", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "ietf_rfc_6749_oauth2", "title": "OAuth 2.0 Authorization Framework (RFC 6749)", "authority": "IETF OAuth Working Group", "source_type": "standard", "normative_force": "voluntary-standard", "version": "RFC 6749", "published_on": "2012-10-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.rfc-editor.org/rfc/rfc6749", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ietf_rfc_6749_oauth2", "relationship": "implementation_pattern", "rationale": "Establishes OAuth 2.0 Authorization Framework (RFC 6749) requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "ietf_rfc_9449_dpop", "title": "RFC 9449 \u2014 OAuth 2.0 Demonstrating Proof of Possession (DPoP)", "authority": "IETF", "source_type": "standard", "normative_force": "voluntary-standard", "version": "RFC 9449", "published_on": "2023-09-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9449", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ietf_rfc_9449_dpop", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9449 \u2014 OAuth 2.0 Demonstrating Proof of Possession (DPoP) requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy (RSP) v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy (RSP) requirements informing the apeiris://identity/controls/IC-04 Privileged Identity Management for AI control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Replace standing AI service account credentials with just-in-time, scope-limited, ephemeral tokens bound to specific task contexts, governed through a PAM platform with enhanced session monitoring and automatic expiry.", "steps": [ "Inventory all AI system identities, service accounts, and agent workload identities with their current privilege scope and standing access grants", "Migrate AI service account authentication to short-lived OAuth 2.0 tokens with DPoP binding, maximum 15-minute TTL for high-privilege operations", "Implement just-in-time privilege elevation for AI tasks requiring elevated access, with the requesting system and task context logged before elevation is granted", "Deploy enhanced monitoring for all AI privileged identity sessions including anomaly detection on access patterns, volume, and resource targets" ], "anti_patterns": [ "Provisioning AI agents with static long-lived API keys or service account passwords with no rotation schedule", "Granting AI systems broad standing IAM roles rather than task-scoped, time-bound tokens", "Excluding AI service accounts from PAM governance on the grounds that they are non-human and do not require privileged access controls" ] }, "validation": { "design_check": [ "AI identity inventory is complete and includes all agent workload identities, service accounts, and orchestration system credentials", "All AI privileged tokens have a defined maximum TTL and scope restriction enforced at the authorization server", "PAM platform coverage includes AI workload identities with session recording or API call logging enabled" ], "runtime_test": [ "Verify that a sample AI service account cannot authenticate with credentials older than the defined TTL without re-authorization", "Attempt to use an AI access token outside its defined resource scope and confirm the authorization server rejects the request", "Review PAM session logs for a sampled AI agent operation and confirm task context, elevation reason, and token issuance are all recorded" ], "evidence": [ "record:PAM platform enrollment log confirming all AI identities above privilege tier 2 are under JIT control [unverified]", "log:Authorization server token issuance log showing TTL and scope constraints for AI service account tokens [unverified]", "artifact:AI identity privilege review report from PAM platform for the trailing 90 days [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "AI privileged identity management requires extending PAM workflows to support machine-speed token lifecycle management and task-context-aware elevation.", "actions": [ "Onboard all AI service accounts and agent workload identities to the PAM platform with defined privilege tiers", "Configure OAuth authorization server to issue DPoP-bound tokens with task-specific scope claims for AI system authentication", "Implement token lifecycle webhooks so AI agents automatically request re-authorization when approaching token expiry rather than caching long-lived credentials" ], "failure_signals": [ "AI service accounts are found outside PAM governance with static credentials not enrolled in any rotation schedule", "AI agent access tokens are discovered cached in application memory or configuration files beyond their defined TTL" ] }, "security_architect": { "summary": "AI privileged identity architecture must account for delegation chains, orchestrator-sub-agent relationships, and the machine-speed blast radius of compromised credentials.", "actions": [ "Design AI agent credential architecture to enforce scope narrowing at each delegation hop in orchestrator-sub-agent chains", "Integrate AI identity session monitoring with SIEM to alert on anomalous access volume or resource targeting patterns", "Require architecture review for any AI system design that requires standing privileged access rather than JIT elevation" ], "failure_signals": [ "Orchestrator AI systems pass their full privilege scope to sub-agents without scope narrowing at each delegation boundary", "SIEM has no detection rules tuned for AI service account anomalous behavior patterns" ] }, "legal_counsel": { "summary": "AI privileged identity controls establish the technical non-repudiation basis for demonstrating that autonomous system actions were authorized and scope-bounded.", "actions": [ "Ensure PAM session logs for AI agents are retained at a fidelity sufficient to reconstruct the authorization chain for any action taken", "Confirm AI identity JIT elevation records meet evidence preservation requirements for regulatory response and litigation", "Review AI system identity agreements with third-party providers to confirm they include equivalent PAM obligations" ], "failure_signals": [ "PAM logs for AI agent sessions are not retained at sufficient fidelity to reconstruct the authorization basis for disputed actions", "Third-party AI service providers have no contractual obligation to apply equivalent privileged identity controls" ] }, "grc_auditor": { "summary": "AI privileged identity audit must verify both technical PAM enrollment and ongoing JIT compliance across all AI workload identities.", "actions": [ "Enumerate all AI system identities from the IGA platform and cross-reference against PAM enrollment to identify gaps", "Test JIT enforcement by sampling recent AI privilege elevation events and verifying each has a documented task context and approver record", "Review AI identity token TTL settings and confirm no standing tokens exceed the policy-defined maximum lifetime" ], "metrics": [ "Percentage of AI system identities with privilege tier above read-only enrolled in PAM JIT governance (target: 100%)", "Mean TTL of active AI service account tokens (target: within policy-defined maximum, typically 15 minutes for high-privilege operations)" ], "failure_signals": [ "AI service accounts with broad IAM role assignments are found outside PAM governance scope", "JIT elevation requests for AI agents show no task context, requesting system, or approver recorded in PAM logs" ] }, "it_operations": { "summary": "AI PAM operational reliability requires robust token lifecycle automation so AI agents do not suffer authentication failures from expired credentials during production tasks.", "actions": [ "Implement AI agent token refresh automation with pre-expiry re-authorization triggered at 80% of token TTL", "Monitor PAM authorization server for AI token issuance latency and alert when latency would cause agent timeout failures", "Maintain a documented break-glass procedure for restoring AI system access when PAM authorization is unavailable" ], "failure_signals": [ "AI agent tasks fail in production due to token expiry because no automatic re-authorization mechanism was implemented", "Break-glass procedures for AI identity are undocumented or grant broader access than the JIT policy normally permits" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most AI identity governance is nascent; target state requires full PAM enrollment of AI workload identities with JIT enforcement and enhanced session monitoring." }, "capability_risk": { "capability_level": "narrow", "autonomy": "supervised-autonomous", "access_mode": "api-key", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_zt", "requirement_id": "\u00a75.7", "title": "Non-Human Subject Identity Management", "rationale": "NIST SP 800-207 \u00a75.7 (Use of Non-person Entities in ZTA Administration) addresses the risk of NPEs \u2014 including AI agents \u2014 interacting with ZTA administration, warning that automated agents with administrative access need stronger authentication and least-privilege constraints. IC-04's privileged identity management for AI directly addresses this threat.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "NIST SP 800-207 section 5.7 addresses non-person entities in ZTA administration needing stronger controls; IC-04 applies PAM to AI system identities.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9449 (DPoP)", "title": "OAuth 2.0 DPoP Binding for AI Service Credentials", "rationale": "RFC 9449 DPoP binding prevents stolen token replay, directly addressing the credential compromise threat for AI privileged service accounts.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "RFC 9449 DPoP binding prevents stolen-token replay, directly addressing the credential-compromise threat for privileged AI service accounts.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Identity Pillar \u2014 Access Management", "title": "Privileged Access Management \u2014 CISA ZTMM Identity Pillar", "rationale": "The CISA ZTMM Identity pillar's Access Management function covers privileged access expectations, including just-in-time elevation and enhanced monitoring, which apply to AI workload identities as non-human subjects.", "mapping_fit": "direct", "normative_force": "supervisory-guidance", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "CISA ZTMM Identity Access Management covers just-in-time elevation and enhanced monitoring for privileged access, applied to AI workload identities.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Privileged Access \u2014 Zero Standing Privilege", "rationale": "Okta Privileged Access (OPA) manages high-privilege AI agent identities through just-in-time access workflows, multi-level approval chains for sensitive operations, time-limited access windows with automatic revocation, and zero-standing-privilege enforcement. OPA's integration with Okta Identity Governance enables access certifications to cover non-human privileged identities on the same cadence as human privileged accounts.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "Okta Privileged Access manages high-privilege agent identities via JIT, approval chains, time-limited access and zero standing privilege - the control exactly.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS IAM \u2014 Privileged Role MFA Condition", "rationale": "AWS IAM privileged access patterns for high-consequence AI agents require MFA-conditional role assumption (aws:MultiFactorAuthPresent: true), permission boundaries to limit blast radius, maximum 1-hour session duration for high-privilege operations, and CloudWatch alarms on any privileged role assumption. These controls limit the window of exposure for compromised high-privilege AI agent credentials.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS MFA-conditional role assumption with boundaries and short sessions provides privileged patterns, but not PAM-platform JIT enrollment across identities.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Anthropic RSP v3.3 \u2014 ASL-3 Security Standard", "rationale": "Anthropic's RSP v3.3 defines ASL Security Standards \u2014 access and egress restrictions that protect model weights and constrain what high-capability systems can autonomously reach \u2014 and Deployment Standards that narrow autonomous action scope at higher ASLs. These map directly to privileged identity management requirements for high-capability AI agents.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic RSP ASL-3 security standard restricts weight access and autonomous reach, an analogous constraint but not PAM for AI system identities.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III \u2014 Privilege scoping (JIT/JEA, dynamic elevation); Part IV Phase 6 \u2014 Just-in-time (JIT) access", "fit": "direct", "rationale": "Dynamic privilege elevation and JIT/JEA with automatic expiration \u2014 privileged identity management for AI.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-04", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "All AI system identities with privilege above read-only are enrolled in the PAM platform under JIT governance with no standing credentials exceeding the policy-defined maximum TTL for their privilege tier; every privilege elevation event is logged with the requesting system, task context, and elevation reason before access is granted; and no AI service account or agent workload identity holds a static long-lived credential outside PAM enrollment.", "evidence_required": [ "pam_enrollment_log: PAM platform record confirming all AI identities above privilege tier 2 are enrolled under JIT control, with enrollment_date and privilege_tier for each entry; zero gaps against the AI identity inventory", "authorization_server_token_issuance_log: log of OAuth token issuance events for AI service accounts showing token_id, scope, ttl_seconds, dpop_bound flag, and issued_at; all TTL values at or below the policy-defined maximum for the applicable privilege tier", "jit_elevation_event_log: PAM log of AI privilege elevation events showing requesting_system, task_context, elevation_reason, approver where required, and granted_access_window for each event in the trailing 90 days", "ai_identity_privilege_review_report: PAM platform report for the trailing 90 days confirming no standing tokens exceed policy TTL and no AI identities hold broad standing IAM roles outside JIT governance" ], "machine_tests": [ "Attempt to authenticate an AI service account using a credential with age > policy_maximum_ttl_seconds \u2192 assert the authorization server returns 401 with error=token_expired", "Present a valid AI access token to a resource endpoint outside its declared scope claim \u2192 assert the resource server rejects the request with 403 and the scope mismatch is logged", "Submit a JIT privilege elevation request for a test AI agent without a task_context field \u2192 assert the PAM platform rejects the elevation request with error=missing_task_context", "Scan the AI identity inventory for credentials with ttl_seconds > policy_maximum_by_tier \u2192 assert zero credentials exceed the defined maximum for their privilege tier" ], "human_review": [ "Review the AI identity inventory against the PAM enrollment log to identify any AI workload identities with privilege above read-only that are not enrolled in JIT governance or that retain static credentials alongside JIT-managed ones", "Assess a sample of JIT elevation event records for quality: confirm each records the requesting system, task context, and that the granted access window does not exceed the estimated task duration", "Evaluate break-glass procedures for AI privileged access: verify documented procedures exist, are tested at least annually, and grant time-limited emergency access rather than permanent broad access" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Provisioning AI agents with static, long-lived API keys or service account passwords with no rotation schedule, creating persistent high-value credential targets that are exploitable at machine speed if compromised", "Granting AI systems broad standing IAM roles (such as read-write access across an entire namespace) rather than issuing task-scoped, time-bound tokens for each operation", "Excluding AI service accounts from PAM governance on the grounds that they are non-human and do not require privileged access controls, leaving machine-speed high-privilege access entirely ungoverned", "Propagating an orchestrating agent's full privilege scope to sub-agents in a delegation chain without scope narrowing at each hop, enabling privilege amplification across delegation boundaries", "Implementing break-glass procedures that grant permanent broad access rather than time-limited emergency access, creating a persistent privilege bypass path that outlasts the emergency" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-05", "layer": "IC", "plane": "lifecycle", "name": "Identity Compliance Mapping", "plain": "Maintain a structured mapping between enterprise identity controls and applicable regulatory obligations, enabling continuous compliance evidence production and gap identification across all relevant frameworks.", "threat": { "tags": [ "federation-bypass", "delegation-abuse", "identity-spoofing" ], "desc": "Untracked regulatory obligations for identity management create blind spots where compliance gaps accumulate undetected until audit. Identity federation configurations that satisfy one regulatory framework may inadvertently violate another when cross-jurisdictional obligations are not mapped together. Delegation and federation bypass techniques exploit compliance gaps where no single framework mandates the missing control, and without a unified compliance map no team identifies the gap." }, "standard": [ { "id": "nist_800_63", "section": "\u00a73", "title": "Digital identity risk management \u2014 regulatory and mission context" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Compliance and regulatory requirements for identity management" } ], "sources": [ { "id": "eu_dora_2022_2554", "title": "DORA \u2014 Digital Operational Resilience Act (EU) 2022/2554, Article 9", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2022/2554", "published_on": "2022-12-14", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554", "license": "open-access", "status": "current", "flagship": false, "source_id": "dora", "relationship": "normative_requirement", "rationale": "Establishes DORA \u2014 Digital Operational Resilience Act (EU) 2022/2554, Article 9 requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "eu_nis2_2022_2555", "title": "NIS2 Directive (EU) 2022/2555, Article 21", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2022/2555", "published_on": "2022-12-14", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555", "license": "open-access", "status": "current", "flagship": false, "source_id": "nis2", "relationship": "normative_requirement", "rationale": "Establishes NIS2 Directive (EU) 2022/2555, Article 21 requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024_1689", "title": "EU AI Act (EU) 2024/1689, Article 14", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "open-access", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (EU) 2024/1689, Article 14 requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "openai_preparedness_fw_v2", "title": "OpenAI Preparedness Framework v2", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2025-04-15", "retrieved_on": "2026-06-28", "canonical_url": "https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_preparedness", "relationship": "informative_reference", "rationale": "Establishes OpenAI Preparedness Framework v2 requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy (RSP) v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy (RSP) requirements informing the apeiris://identity/controls/IC-05 Identity Compliance Mapping control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Build and maintain a compliance mapping matrix that links each identity control to its applicable regulatory obligations (DORA Art 9, NIS2 Art 21, EU AI Act Art 14, and others), with evidence status, gap identification, and owner assignment for each mapping.", "steps": [ "Enumerate all applicable regulatory frameworks with identity-related obligations, including DORA Art 9, NIS2 Art 21, EU AI Act Art 14, NIST 800-63-4, and sector-specific requirements", "Map each identity control in the IC layer to the specific articles and clauses of each applicable framework, documenting the mapping rationale and fit classification", "Assess evidence status for each regulatory obligation: covered, partially covered, or gap \u2014 with a named owner and remediation timeline for each gap", "Schedule compliance mapping reviews aligned with regulatory change cycles and integrate mapping updates into the IC-02 policy review process" ], "anti_patterns": [ "Maintaining separate compliance mapping spreadsheets per regulatory framework with no unified view of cross-framework gaps", "Treating compliance mapping as a point-in-time audit exercise rather than a continuously maintained program artifact", "Mapping identity controls to regulatory requirements at a framework level without tracing to specific articles, clauses, and obligations" ] }, "validation": { "design_check": [ "Compliance mapping matrix exists and covers all regulatory frameworks applicable to the organization's identity program", "Each mapping entry cites a specific regulatory article or clause rather than mapping to a framework name alone", "Gap entries in the compliance mapping have a named owner and remediation timeline recorded" ], "runtime_test": [ "Cross-reference the compliance mapping for DORA Art 9 and verify that the cited identity controls have current supporting evidence in the evidence register", "Request a compliance mapping update and verify the process completes within the policy-defined review window", "Sample 3 identity control configurations and trace each back to the specific regulatory obligations they satisfy in the compliance mapping" ], "evidence": [ "document:Current identity compliance mapping matrix with regulatory citations to article and clause level [unverified]", "record:Gap register derived from compliance mapping with owner, remediation status, and target close date for each open item [unverified]", "artifact:Compliance mapping review completion record with effective date and approver signature [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Compliance mapping tells you which regulatory obligations your identity configurations must satisfy and provides traceability for audit evidence.", "actions": [ "Reference the compliance mapping when designing new identity controls to confirm regulatory obligations are addressed in the design", "Tag identity system configuration items with regulatory obligation references from the compliance mapping for automated compliance reporting", "Flag configuration changes that affect mappings to DORA Art 9 or NIS2 Art 21 for mandatory legal review before deployment" ], "failure_signals": [ "Identity system configuration changes are deployed with no check against the compliance mapping for regulatory impact", "Compliance mapping contains no entries for EU AI Act Art 14 despite organization deploying high-risk AI systems" ] }, "security_architect": { "summary": "Compliance mapping reveals conflicts between regulatory identity requirements across jurisdictions that must be resolved in system architecture.", "actions": [ "Use the compliance mapping to identify cross-framework conflicts where satisfying one regulation's identity requirement may create tension with another", "Include compliance mapping review in architecture decision records for new identity systems and federation configurations", "Design identity federation architectures to satisfy the most stringent applicable obligation across all mapped regulatory frameworks" ], "failure_signals": [ "Architecture decisions for cross-border identity federation are made without reviewing the compliance mapping for DORA and NIS2 obligations", "Cross-framework conflicts in the compliance matrix remain unresolved and are not tracked as architecture risks" ] }, "legal_counsel": { "summary": "The compliance mapping is the primary legal evidence document for demonstrating that identity controls satisfy specific regulatory obligations.", "actions": [ "Review the compliance mapping annually and after any material regulatory change to confirm coverage is current and accurate", "Ensure DORA Art 9, NIS2 Art 21, and EU AI Act Art 14 obligations are mapped to specific identity controls with evidence status documented", "Use compliance mapping gap records as the basis for regulatory disclosure decisions when evidence of non-compliance is identified" ], "failure_signals": [ "Compliance mapping has not been updated following enactment of DORA, NIS2, or EU AI Act obligations applicable to the organization", "Gap entries in the compliance mapping affecting binding-law obligations have no remediation timeline or named owner" ] }, "grc_auditor": { "summary": "Compliance mapping is the audit anchor that connects individual identity control test results to specific regulatory requirement satisfaction.", "actions": [ "Use the compliance mapping as the audit scope definition document to confirm all applicable regulatory obligations are tested", "For each regulatory gap in the mapping, verify whether a compensating control or risk acceptance is documented and approved", "Test compliance mapping currency by cross-referencing against the most recent version of each cited regulation" ], "metrics": [ "Percentage of applicable regulatory identity obligations with documented evidence status in the compliance mapping (target: 100%)", "Number of binding-law compliance mapping gaps with no owner or remediation timeline (target: zero)" ], "failure_signals": [ "Compliance mapping does not include DORA Art 9, NIS2 Art 21, or EU AI Act Art 14 despite organizational applicability", "Audit cannot trace tested identity controls back to specific regulatory articles through the compliance mapping" ] }, "it_operations": { "summary": "Compliance mapping outputs determine operational configuration requirements and change control gates for identity infrastructure.", "actions": [ "Integrate compliance mapping obligation references into the change management process for identity system modifications", "Alert operations on compliance mapping updates that create new configuration requirements for operational identity systems", "Maintain configuration baseline documentation linked to compliance mapping obligations for each identity system in scope" ], "failure_signals": [ "Identity system configuration changes are approved in change management without compliance mapping impact assessment", "Operations team is unaware of DORA Art 9 or NIS2 Art 21 configuration requirements mapped to systems they manage" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Target state requires a unified, article-level compliance mapping with evidence status, gap tracking, and regular update cycles synchronized with regulatory change calendars." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 \u00a73", "title": "Regulatory and Policy Alignment for Identity Programs", "rationale": "SP 800-63-4 \u00a73's digital identity risk management process requires tailoring assurance decisions to the organization's mission, regulatory, and risk context; IC-05's compliance mapping matrix records that regulatory alignment for identity controls.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "SP 800-63-4 section 3 requires tailoring assurance decisions to regulatory context; IC-05 records that regulatory alignment for identity controls.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eidas2", "requirement_id": "Regulation (EU) 2024/1183", "title": "eIDAS 2.0 Identity and Trust Service Compliance", "rationale": "eIDAS 2.0 creates cross-border identity compliance obligations that must be captured in IC-05 for organizations operating in EU member states.", "mapping_fit": "partial", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "eIDAS 2.0 creates cross-border identity compliance obligations IC-05 must capture, but is one framework among the many the mapping covers.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "title": "Compliance and Regulatory Requirements", "rationale": "ISO/IEC 24760-2:2015 requires identity management to operate within applicable legal and regulatory constraints; IC-05's compliance mapping matrix records that alignment.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "ISO/IEC 24760-2 requires identity management within legal and regulatory constraints; IC-05 records that alignment in its compliance mapping matrix.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Anthropic RSP v3.3 \u2014 Risk Reports", "rationale": "Anthropic's RSP v3.3 requires internal Risk Reports documenting capability assessments and safeguard adequacy for deployed models. The operator accountability framework maps Claude deployments to specific responsible-party obligations. These reports constitute a compliance evidence baseline for enterprises mapping Claude deployments to regulatory identity governance requirements (ISO 27001, SOC 2, GDPR).", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic RSP risk reports document capability and safeguard adequacy, tangential to the article-level identity regulatory compliance mapping IC-05 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_sf", "requirement_id": "Preparedness Framework v2 \u2014 'Building trust' public disclosures", "rationale": "OpenAI's Preparedness Framework v2 commits to public disclosures of capability evaluation results (e.g., in system cards) under its 'Building trust' commitments, with ongoing monitoring against documented capability thresholds. These disclosures provide a compliance evidence trail for enterprises auditing AI identity governance: evaluation methodology, validation status, and monitoring results are documented in a form suitable for regulatory compliance mapping.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI Preparedness public disclosures report capability evaluations, not the article-and-clause identity regulatory compliance mapping IC-05 requires.", "fit_assessed_on": "2026-07-03", "basis": "asserted", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part I \u2014 Regulated industries and compliance requirements; Part III \u2014 AI governance policies", "fit": "partial", "rationale": "Doc maps Zero Trust to HIPAA/FINRA/GDPR/FedRAMP/EU AI Act and notes governing bodies will integrate Zero Trust into requirements. Partial: doc aligns with regimes rather than providing a control-to-obligation mapping.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-05", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A current identity compliance mapping matrix exists that covers all applicable regulatory frameworks at specific article and clause level (including DORA Art. 9, NIS2 Art. 21, EU AI Act Art. 14, and sector-specific requirements); each mapping entry cites a specific regulatory article and clause rather than a framework name alone; all gap entries have a named owner and remediation timeline; and zero binding-law gap entries lack an owner or target close date.", "evidence_required": [ "identity_compliance_mapping_matrix: document mapping each identity control to specific regulatory articles and clauses with mapping_fit (direct/partial), evidence_status (covered/partially-covered/gap), and last_reviewed_date for each entry; covers DORA Art. 9, NIS2 Art. 21, EU AI Act Art. 14 at minimum", "gap_register: extracted list of all gap entries from the compliance mapping with named_owner, remediation_plan, target_close_date, and current_status; zero binding-law gap entries with owner=null or target_close_date=null", "compliance_mapping_review_record: signed review completion record with effective_date, approver name and role, and confirmation that all applicable frameworks have been assessed against the current regulatory text version", "regulatory_change_log: record of regulatory updates reviewed and incorporated since the last compliance mapping review, confirming the matrix reflects current regulatory text and applicability dates" ], "machine_tests": [ "Query the compliance mapping for entries with framework=DORA and regulatory_article=Art.9 \u2192 assert at least one direct-fit mapping entry exists, or a gap entry with non-null owner and target_close_date", "Query the gap_register for entries with normative_force=binding-law and owner=null \u2192 assert zero such entries exist", "Check each compliance mapping entry's last_reviewed_date against the defined review cycle length \u2192 assert no entry has last_reviewed_date older than the cycle maximum" ], "human_review": [ "Review the compliance mapping entries for DORA Art. 9, NIS2 Art. 21, and EU AI Act Art. 14 to confirm each cites the specific article text and section, not just the framework name, and that evidence_status reflects the actual current evidence state", "Assess gap_register entries for binding-law obligations: verify each has a credible remediation plan with an achievable target close date and that gaps are not being deferred across successive review cycles without escalation", "Verify that the compliance mapping was updated following material regulatory applicability milestones (DORA effective date, EU AI Act Article 6 applicability, NIS2 national transposition) and that updates are version-controlled" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Mapping identity controls to regulatory frameworks at the framework-name level (asserting 'satisfies DORA' without tracing to Art. 9 specifically), making the mapping non-auditable and legally undefendable", "Treating compliance mapping as a point-in-time audit preparation exercise rather than a continuously maintained program artifact, allowing the matrix to become stale between audit cycles when regulations change or expand", "Maintaining separate compliance spreadsheets for each regulatory framework with no unified cross-framework view, making cross-jurisdictional conflict identification impossible and creating duplicate or contradictory entries", "Leaving binding-law compliance gaps (DORA, NIS2, EU AI Act) in the gap register with no named owner or remediation timeline, creating documented regulatory exposure without accountability or remediation trajectory", "Failing to update the compliance mapping after regulatory applicability dates pass (EU AI Act Article 6 applicability, DORA financial entity scope expansion), leaving the matrix citing superseded or inapplicable regulatory text" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-06", "layer": "IC", "plane": "lifecycle", "name": "Third-Party Identity Provider Audit", "plain": "Conduct structured annual audits of all federated third-party identity providers to verify security posture, trust configuration, and compliance obligations remain aligned with enterprise identity policy.", "threat": { "tags": [ "federation-bypass", "identity-spoofing", "credential-compromise" ], "desc": "Federated identity trust relationships extend the enterprise attack surface to every external identity provider whose tokens are accepted. A compromised or misconfigured third-party IdP can issue fraudulent tokens that bypass enterprise authentication controls entirely, as the relying party trusts the federation without verifying the IdP's security posture. Stale trust configurations, overly broad SAML assertion mappings, and unreviewed OAuth client registrations create persistent bypass opportunities that neither party detects between formal audit cycles." }, "standard": [ { "id": "nist_800_63", "section": "SP 800-63C-4 \u00a73.5", "title": "Federation trust agreements" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Requirements for identity information managed by external providers" } ], "sources": [ { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines \u2014 Federation", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines \u2014 Federation requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-01" }, { "id": "openid_connect_core_1_0", "title": "OpenID Connect Core 1.0", "authority": "OpenID Foundation", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2014-11-08", "retrieved_on": "2026-06-29", "canonical_url": "https://openid.net/specs/openid-connect-core-1_0.html", "license": "open-access", "status": "current", "flagship": false, "source_id": "openid_connect_core_1_0", "relationship": "implementation_pattern", "rationale": "Establishes OpenID Connect Core 1.0 requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-02" }, { "id": "eu_eidas2_2024_1183", "title": "eIDAS 2.0 Regulation (EU) 2024/1183", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2024/1183", "published_on": "2024-04-11", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1183", "license": "open-access", "status": "current", "flagship": false, "source_id": "eidas2_2024_1183", "relationship": "normative_requirement", "rationale": "Establishes eIDAS 2.0 Regulation (EU) 2024/1183 requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-01" }, { "id": "ping_machine_identity_2026", "title": "Ping Identity: Identity for AI", "authority": "Ping Identity", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2026", "published_on": "2026", "retrieved_on": "2026-06-28", "canonical_url": "https://www.pingidentity.com/en/solution/agentic-ai-identity.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "ping_machine_identity_2026", "relationship": "informative_reference", "rationale": "Establishes Ping Identity: Machine Identity & Agentic AI Identity Guidance requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-06 Third-Party Identity Provider Audit control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a third-party IdP registry with annual audit cycles covering security posture, trust configuration review, contract obligations, and technical validation of token issuance and attribute assertion accuracy.", "steps": [ "Create and maintain a third-party IdP registry listing all federated providers, trust relationship type (SAML, OIDC, WS-Fed), integration scope, and last audit date", "Conduct annual technical audits of each IdP covering: JWKS endpoint currency, token signature verification, assertion attribute mappings, and OAuth client registration scope", "Obtain security assurance evidence from each IdP annually: SOC 2 Type II report, penetration test executive summary, or equivalent third-party audit artifact", "Review and re-execute trust configuration for each IdP at least annually, revoking any registrations not actively used in the preceding 12 months" ], "anti_patterns": [ "Onboarding a third-party IdP with a one-time security review and no scheduled re-audit obligation", "Accepting SAML assertions from federated providers without validating assertion attribute mappings against the current federation agreement", "Maintaining OAuth client registrations for third-party IdPs that are no longer in active use rather than revoking them" ] }, "validation": { "design_check": [ "Third-party IdP registry is complete and includes all active federation relationships with audit date, type, and scope documented", "Annual audit procedures exist and cover both security posture (SOC 2 or equivalent) and technical configuration validation", "A defined process exists for suspending a federated IdP pending remediation if the audit reveals material security gaps" ], "runtime_test": [ "Review the IdP registry and confirm every active federation relationship has a completed audit within the trailing 12 months", "Technical-test SAML or OIDC token validation for a sampled IdP: verify issuer, audience, signature, and lifetime validation are enforced by the relying party", "Confirm that a revoked or expired OAuth client registration from a third-party IdP is rejected by the authorization server within the defined remediation window" ], "evidence": [ "document:Third-party IdP registry with federation type, scope, last audit date, and security assurance evidence status for each provider [unverified]", "artifact:Annual security assurance evidence (SOC 2 Type II or equivalent) received from each active federated IdP [unverified]", "record:Trust configuration review records confirming JWKS, assertion mappings, and OAuth client registrations were validated within the trailing 12 months [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "Third-party IdP audit health depends on maintaining accurate registry records and automating configuration drift detection for federation trust relationships.", "actions": [ "Automate JWKS endpoint monitoring for all federated IdPs to alert on unexpected key rotation or signing algorithm changes", "Schedule OAuth client registration reviews in the IdP registry calendar so no registration ages beyond 12 months without revalidation", "Implement relying party token validation testing in integration test pipelines to catch assertion mapping changes before they reach production" ], "failure_signals": [ "JWKS signing key rotation by a third-party IdP causes authentication failures because no monitoring detected the change in advance", "OAuth client registrations in the IdP registry have not been reviewed in over 12 months with no explanation or exemption" ] }, "security_architect": { "summary": "Third-party IdP trust architecture must enforce relying party validation controls that cannot be bypassed even if the IdP is fully compromised.", "actions": [ "Architect relying party validation to enforce issuer pinning, audience binding, and token lifetime limits independent of the IdP configuration", "Require that third-party IdP integrations use the most restrictive token lifetime and scope settings achievable under the federation protocol", "Include third-party IdP relationships in the enterprise threat model and define detection controls for federated token abuse" ], "failure_signals": [ "Relying party token validation does not enforce issuer pinning, allowing tokens from unauthorized issuers to be accepted", "Third-party IdP compromise is not included in the enterprise threat model for federation security" ] }, "legal_counsel": { "summary": "Third-party IdP contracts must establish audit rights, security obligations, and incident notification requirements as legally enforceable terms.", "actions": [ "Ensure every third-party IdP contract includes audit rights, annual security assurance evidence obligations, and defined breach notification timelines", "Review eIDAS 2.0 qualified trust service obligations for EU-operating IdPs and confirm contracts address supervisory body requirements", "Verify that IdP contracts define data processing obligations for identity assertion attributes transmitted during federation" ], "failure_signals": [ "Third-party IdP agreements do not include annual security audit evidence obligations or audit right clauses", "IdP contracts are silent on data processing obligations for identity attributes in SAML or OIDC assertions" ] }, "grc_auditor": { "summary": "Third-party IdP audit must produce evidence of both security posture assessment and technical configuration validation for each active federation relationship.", "actions": [ "Collect the IdP registry and verify completeness against active SAML, OIDC, and OAuth federation configurations in the authorization server", "Confirm SOC 2 Type II reports or equivalent evidence have been received from each IdP within the trailing 12 months", "Test relying party token validation controls for a sampled IdP to verify issuer, signature, and audience checks are enforced" ], "metrics": [ "Percentage of active third-party IdP relationships with current security assurance evidence (target: 100%)", "Number of active OAuth client registrations with no revalidation in the trailing 12 months (target: zero)" ], "failure_signals": [ "IdP registry is incomplete or does not match the active federation configurations in the authorization server", "Security assurance evidence is missing for one or more active federated IdPs with no documented risk acceptance" ] }, "it_operations": { "summary": "Third-party IdP operational health depends on proactive monitoring of trust configuration changes and rapid response to IdP-issued security advisories.", "actions": [ "Subscribe to security advisories from all third-party IdP vendors and establish a process for evaluating identity security impact within 24 hours", "Monitor IdP endpoint availability and JWKS key currency with automated alerting for anomalies that could indicate IdP compromise", "Maintain a documented IdP suspension procedure that can isolate a compromised IdP federation without disrupting other authentication flows" ], "failure_signals": [ "Third-party IdP issues a security advisory affecting federation token security and operations has no established response process", "JWKS endpoint monitoring is not configured, allowing silent key rotation to go undetected until authentication failures occur" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Target state requires a complete IdP registry with annual audit cycles, automated trust configuration monitoring, and contractually enforced security assurance obligations." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "federated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63C-4 \u00a73.5", "title": "Federation and Identity Provider Assurance", "rationale": "SP 800-63C-4 \u00a73.5 requires federation trust agreements establishing the responsibilities and security obligations of IdPs and relying parties; IC-06's third-party IdP audit verifies those obligations are met on an ongoing basis.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "SP 800-63C-4 section 3.5 requires federation trust agreements defining IdP and RP obligations; IC-06 verifies those obligations via third-party audit.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "OpenID Connect Core 1.0 \u00a73.1", "title": "OpenID Connect ID Token Validation", "rationale": "OpenID Connect Core Section 3.1 token validation requirements are the technical foundation for the relying party controls tested in IC-06.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "OpenID Connect Core section 3.1 token-validation requirements are the technical foundation for the relying-party controls IC-06 audits.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eidas2", "requirement_id": "Arts. 20\u201324", "title": "eIDAS 2.0 Trust Service Provider Requirements", "rationale": "eIDAS 2.0 Articles 20\u201324 establish supervision and audit obligations for (qualified) trust service providers, extending IC-06's third-party audit requirements for EU cross-border identity federation.", "mapping_fit": "partial", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "eIDAS 2.0 Arts 20-24 set trust-service-provider supervision and audit obligations, extending IC-06 third-party audit for EU cross-border federation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "satisfies" }, { "framework": "okta_iam", "requirement_id": "Okta trust page (trust.okta.com) \u2014 third-party audit certifications", "rationale": "Okta maintains SOC 2 Type II, ISO 27001, FedRAMP, and CSA STAR certifications documented on its trust and compliance site (trust.okta.com). Okta's HealthInsight feature provides automated configuration recommendations for IdP security posture. Enterprises should review Okta's third-party audit reports annually and use HealthInsight findings as the basis for IdP configuration audits.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta trust-page SOC 2/ISO/FedRAMP certifications supply the assurance evidence IC-06 consumes, but do not constitute the enterprise audit process itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "ping_identity", "requirement_id": "Ping Identity compliance certifications (SOC 2 Type II, ISO 27001)", "rationale": "Ping Identity maintains SOC 2 Type II and ISO 27001 certifications documented in its published security and compliance materials, and its cloud platforms undergo regular third-party penetration testing. Enterprises relying on Ping as an IdP should incorporate these audit certifications and penetration test summaries into their third-party identity provider audit evidence packages.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Ping SOC 2/ISO 27001 certifications and pen-test reports supply IdP assurance evidence IC-06 consumes, but not the enterprise-run audit process itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 2 \u2014 Vendor assessments", "fit": "partial", "rationale": "Doc requires reviewing security practices of providers before adoption (incident history, vulnerability response). Partial: doc's vendor assessment is general supply-chain, not IdP-specific audit.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-06", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "Every active federated identity provider in the enterprise trust registry must have a completed security audit within the trailing 12 months, including technical validation of token issuance and a current security assurance artifact (SOC 2 Type II or equivalent) received from that provider. The relying party must enforce issuer pinning, audience binding, and token lifetime limits independently of IdP configuration.", "evidence_required": [ "third_party_idp_registry listing all active federation relationships with provider name, protocol (SAML/OIDC/WS-Fed), integration scope, last_audit_date, and security_assurance_evidence_status for each entry", "security_assurance_artifact (SOC 2 Type II report or equivalent penetration test summary) received from each active federated IdP with document date within the trailing 12 months", "trust_configuration_review_record for each IdP confirming JWKS endpoint validation, assertion attribute mapping review, and OAuth client registration scope revalidation with reviewer name and completion date", "token_validation_test_log for a sampled IdP showing enforcement of issuer, audience, signature algorithm, and token lifetime checks at the relying party" ], "machine_tests": [ "Submit SAML assertion from an unregistered issuer to the relying party \u2192 assert 401 response with error=invalid_issuer", "Query IdP registry for all active federation entries and compare each last_audit_date against today minus 365 days \u2192 assert zero entries exceed the 12-month window", "Present an OIDC token with exp claim set to now minus 300 seconds \u2192 assert relying party returns 401 with error=token_expired", "Query the authorization server for OAuth client registrations not matched by any active IdP registry entry \u2192 assert zero orphaned client registrations exist" ], "human_review": [ "Review the third-party IdP registry for completeness against the authorization server's active SAML, OIDC, and OAuth federation configurations to identify unregistered trust relationships", "Assess the security assurance evidence received from each IdP for recency, scope relevance, and adequacy given the enterprise's tolerance for third-party identity risk", "Evaluate IdP contract terms to confirm audit rights, annual security evidence obligations, and breach notification timelines are legally enforceable" ], "blocking_effect": "requires-review", "normative_status": "voluntary-standard", "anti_patterns": [ "Onboarding a third-party IdP with a one-time security review and no recurring annual audit obligation, allowing trust relationships to persist indefinitely without reassessment", "Accepting SAML assertion attribute mappings from federated providers without validating them against the current federation agreement, creating privilege escalation risk", "Maintaining active OAuth client registrations for IdPs that are no longer in use rather than revoking them, accumulating dormant federation attack surface", "Relying on the IdP to enforce token validation constraints rather than implementing issuer pinning and audience binding at the relying party, enabling full bypass if the IdP is compromised", "Using a single shared annual review date for multiple IdPs with different risk profiles instead of per-provider audit cycles reflecting each relationship's criticality" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-07", "layer": "IC", "plane": "lifecycle", "name": "Identity Program Metrics and KPIs", "plain": "Define, collect, and report a standard set of identity program KPIs on a defined cadence to enable governance oversight, trend analysis, and evidence-based prioritization of identity risk remediation.", "threat": { "tags": [ "orphaned-credential", "org-change-lag" ], "desc": "Identity programs without measurable KPIs cannot detect accumulating risk from orphaned credentials, access review lag, or governance process failures until a breach or audit finding surfaces the problem. Org-change lag goes undetected when no metric tracks time-to-revocation after departure events, allowing access retention windows to grow silently. Without program-level metrics, identity governance committees lack the data to prioritize remediation or demonstrate program health to regulatory bodies." }, "standard": [ { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Monitoring and review of the identity management system" }, { "id": "cisa_zt", "section": "Visibility and Analytics (cross-cutting)", "title": "Measurement and analytics capability across pillars" } ], "sources": [ { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-07 Identity Program Metrics and KPIs control.", "reviewed_on": "2026-07-02" }, { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-07 Identity Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "cisa_ztmm_v2_2023", "title": "CISA Zero Trust Maturity Model v2.0", "authority": "Cybersecurity and Infrastructure Security Agency (CISA)", "source_type": "guidance", "normative_force": "best-practice", "version": "2.0", "published_on": "2023-04-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.cisa.gov/zero-trust-maturity-model", "license": "public-domain", "status": "current", "flagship": false, "source_id": "cisa_zt", "relationship": "informative_reference", "rationale": "Establishes CISA Zero Trust Maturity Model v2.0 requirements informing the apeiris://identity/controls/IC-07 Identity Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "aws_well_arch_security_iam_2024", "title": "AWS Well-Architected Security Pillar: Identity and Access Management", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_well_arch_security_iam_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Well-Architected Security Pillar: Identity and Access Management requirements informing the apeiris://identity/controls/IC-07 Identity Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-07 Identity Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a standard identity KPI set across five categories (provisioning velocity, orphan rate, review completion, privilege hygiene, and incident response), automate collection from IGA and PAM platforms, and publish a monthly governance dashboard.", "steps": [ "Define the canonical identity KPI set covering: provisioning SLA adherence, orphaned account rate, access review completion rate, privilege scope reduction trend, time-to-revocation after departure events, and MFA enrollment rate", "Instrument IGA, PAM, and directory platforms to export KPI source data to a central reporting data store with defined refresh cadence", "Build a governance dashboard presenting KPIs with trend lines, target thresholds, and red/amber/green status for IGC review", "Report KPIs to the Identity Governance Committee monthly and include identity program metric summary in the quarterly enterprise risk report" ], "anti_patterns": [ "Collecting identity metrics only when preparing for an audit rather than maintaining continuous measurement against defined targets", "Defining KPIs that cannot be automatically extracted from IGA or PAM systems, requiring manual data collection that is inconsistent and error-prone", "Reporting only pass/fail compliance metrics without trend data that would reveal deteriorating program health before a threshold is breached" ] }, "validation": { "design_check": [ "A canonical KPI set is formally defined and approved by the Identity Governance Committee with named metric owners", "Each KPI has a defined target threshold, red/amber/green status definition, and data source documented", "A monthly reporting cadence is established with governance distribution list and dashboard access confirmed" ], "runtime_test": [ "Pull the most recent governance dashboard and verify all defined KPIs are present with current-period values and trend lines", "Cross-reference the orphaned account rate metric against a manual IGA query to verify the metric source data is accurate", "Confirm the most recent quarterly enterprise risk report includes the identity program metric summary section" ], "evidence": [ "artifact:Identity program KPI definition document with metric names, targets, data sources, and named owners approved by IGC [unverified]", "record:Trailing 12 months of monthly governance dashboard snapshots showing KPI values, trends, and status [unverified]", "document:Quarterly enterprise risk report sections including identity program metrics for the trailing four quarters [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "KPI instrumentation requires reliable data extraction from IGA and PAM platforms that reflects the true operational state of the identity program.", "actions": [ "Validate KPI data extraction queries against known reference datasets to confirm metric calculations are accurate and complete", "Automate KPI data refresh with alerting on extraction failures so governance dashboards never display stale metrics without flagging the issue", "Align IGA campaign completion data exports with the KPI access review completion rate calculation to ensure the metric is reproducible" ], "failure_signals": [ "KPI values on the governance dashboard cannot be reproduced from IGA platform source data due to calculation discrepancies", "Orphaned account rate metric does not include AI service accounts or contractor identities in its denominator" ] }, "security_architect": { "summary": "Identity KPIs provide leading indicators for architectural risk accumulation that engineering changes alone cannot detect.", "actions": [ "Include privilege scope reduction trend as a KPI to measure progress of JIT and least-privilege architecture rollout over time", "Design KPI thresholds that trigger mandatory security architecture review when identity risk indicators exceed defined bounds", "Integrate identity KPI trends with the broader enterprise security metrics program to enable cross-domain risk correlation" ], "failure_signals": [ "No KPI tracks privilege scope reduction, leaving least-privilege architecture progress unmeasurable", "Identity KPI threshold breaches do not trigger any escalation or review process in the governance model" ] }, "legal_counsel": { "summary": "Identity program metrics provide the continuous monitoring evidence required to demonstrate due diligence under regulatory frameworks.", "actions": [ "Confirm the KPI set includes time-to-revocation and access review completion metrics that directly support regulatory compliance demonstration", "Verify KPI historical data is retained sufficiently long to support regulatory lookback periods and litigation discovery", "Use identity program metric trends in regulatory response documentation to demonstrate proactive governance rather than reactive compliance" ], "failure_signals": [ "Identity KPI history is not retained beyond 12 months, preventing regulatory lookback compliance evidence production", "KPI set does not include time-to-revocation metric despite regulatory obligations requiring timely access revocation evidence" ] }, "grc_auditor": { "summary": "Identity program KPIs are the primary mechanism for converting continuous control operation into auditable, time-stamped evidence of program health.", "actions": [ "Collect trailing 12-month KPI dashboard snapshots as audit evidence demonstrating continuous identity program performance", "For any KPI that exceeded its red threshold during the audit period, verify a documented remediation action was taken", "Test KPI calculation accuracy for at least two metrics by independently querying source data and comparing against dashboard values" ], "metrics": [ "Number of months in trailing 12 where access review completion KPI was below target (target: zero months below target)", "Orphaned account rate trend (target: declining quarter-over-quarter)" ], "failure_signals": [ "KPI dashboard snapshots are not retained and cannot be produced for the audit period", "KPI threshold breaches during the audit period have no corresponding remediation action or risk acceptance record" ] }, "it_operations": { "summary": "Operational identity teams depend on KPI dashboards to detect identity system degradation before it becomes a service-affecting incident.", "actions": [ "Configure operational alerting on KPI threshold breaches so operations teams are notified before governance reporting cycles detect the issue", "Include key identity KPIs in operational NOC dashboards alongside infrastructure health metrics for unified visibility", "Maintain runbooks for responding to KPI threshold breaches in each category (provisioning lag, review backlog, orphan spike)" ], "failure_signals": [ "Operations teams are unaware of KPI threshold breaches until they appear in the monthly governance report", "No operational runbooks exist for responding to identity KPI degradation before it reaches a governance escalation threshold" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Target state requires a fully defined KPI set with automated data collection, monthly governance reporting, and documented threshold-based escalation procedures." }, "capability_risk": { "capability_level": "none", "autonomy": "human-directed", "access_mode": "delegated", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "iso_24760", "requirement_id": "ISO/IEC 24760-2:2015", "title": "Identity Management Performance Measurement", "rationale": "ISO/IEC 24760-2:2015 calls for monitoring and review of the identity management system; IC-07's KPI program supplies the measurement layer for that review.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "ISO/IEC 24760-2 calls for monitoring and review of the identity management system; IC-07 supplies the KPI measurement layer for that review.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_zt", "requirement_id": "Visibility and Analytics (cross-cutting capability)", "title": "Identity Program Metrics \u2014 CISA ZTMM Managed Maturity", "rationale": "The CISA ZTMM v2.0 Visibility and Analytics cross-cutting capability requires measurable visibility into identity posture as maturity advances; IC-07's KPI program provides that measurement.", "mapping_fit": "direct", "normative_force": "supervisory-guidance", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "CISA ZTMM Visibility and Analytics requires measurable visibility into identity posture; IC-07 provides that measurement via its KPI program.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Identity Governance \u2014 Program Metrics", "rationale": "Okta Identity Governance provides built-in reporting on identity program KPIs including access certification completion rates, orphaned account counts, over-provisioned access findings, provisioning cycle time, and access request SLA compliance. These metrics are exportable via API for integration into executive dashboards and GRC platforms.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Identity Governance reports several identity KPIs (certification, orphaned accounts, cycle time), part of the governance dashboard IC-07 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_iam", "requirement_id": "AWS Security Hub \u2014 Identity Security Metrics", "rationale": "AWS Security Hub aggregates IAM-related findings from IAM Access Analyzer, GuardDuty, and Config Rules into a unified security score. Security Hub provides programmatic access to identity security metrics including unused permission finding counts, overprivileged role counts, and external access finding trends \u2014 suitable inputs for an identity program KPI dashboard.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Security Hub aggregates IAM findings into metrics, supplying part of the identity KPI set but not the owner-and-target governance program IC-07 defines.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 8 \u2014 Measure what matters (Dwell time and coverage; Detection speed)", "fit": "partial", "rationale": "Phase 8 metrics (dwell time, coverage, detection speed) apply to identity-monitoring KPIs. Partial: doc's metrics are program-wide, not identity-program-specific.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://identity/controls/IC-07", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A formally defined identity KPI set with named metric owners, target thresholds, and automated data extraction from IGA and PAM systems must produce a monthly governance dashboard covering at least six metric categories: provisioning SLA adherence, orphaned account rate, access review completion, privilege scope reduction trend, time-to-revocation after departure events, and MFA enrollment rate. Dashboard KPI values must be reproducible from authoritative source system data within a 2% variance tolerance.", "evidence_required": [ "identity_kpi_definition_document listing each KPI name, definition, target threshold, red/amber/green status boundaries, data source, and named metric owner \u2014 formally approved by the Identity Governance Committee", "trailing_12_months_governance_dashboard_snapshots showing monthly KPI values, trend lines, and status indicators for each defined metric across the full audit period", "kpi_source_extraction_log for the current period confirming automated data pull from IGA and PAM platforms with extraction timestamps, record counts, and any extraction failures flagged", "quarterly_enterprise_risk_report excerpt for each of the trailing four quarters containing the identity program metrics summary section with current KPI status" ], "machine_tests": [ "Query IGA platform for orphaned accounts independently and compare result against the orphaned account rate KPI value on the current-period dashboard \u2192 assert variance is within 2%", "Retrieve the governance dashboard data store for the current month \u2192 assert all six canonical KPI categories are present with non-null values and trend data spanning at least three prior periods", "Inject a test orphaned account count exceeding the defined red threshold into the KPI data pipeline \u2192 assert automated governance alert fires within the SLA window defined in the escalation procedure" ], "human_review": [ "Review the KPI definition document to confirm metric definitions are unambiguous, data sources are authoritative, and thresholds reflect current least-privilege business requirements rather than legacy baselines", "Assess whether the KPI set covers non-human and AI agent identities in addition to human identities, since orphaned NHI accounts and AI agent credentials represent a distinct and growing risk category", "Evaluate KPI trend data for any metric consistently near the red threshold to determine whether the threshold or the underlying control posture requires adjustment and formal risk acceptance" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Collecting identity KPI data only in preparation for an audit rather than maintaining automated, continuous measurement against defined thresholds throughout the program year", "Defining KPI metrics that require manual data extraction from IGA or PAM platforms, introducing inconsistency and making the dashboard values non-reproducible between reporting cycles", "Reporting only binary pass/fail compliance metrics without trend lines, masking gradual deterioration in identity program health before a threshold is formally crossed", "Excluding AI agent and non-human identities from orphaned account rate and access review completion KPI denominators, systematically understating the actual identity risk posture", "Treating KPI threshold breaches as informational without a documented escalation path, allowing red-status metrics to persist across multiple reporting cycles without remediation" ], "update_status": "current", "layer_code": "IC" }, { "id": "IC-08", "layer": "IC", "plane": "lifecycle", "name": "Identity Attestation Production", "plain": "Produce a signed IdentityAttestation artifact that aggregates evidence from all IC layer controls, attesting to the identity governance posture of the enterprise; consumed by apeiris://agentic/controls/AA-01 and AA-02 for capability manifest validation and by Compliance AU-08 for dossier assembly. Requires peer DV-08 attestation for evidence completeness.", "threat": { "tags": [ "identity-spoofing", "federation-bypass", "credential-compromise", "delegation-abuse" ], "desc": "Without a composable, machine-verifiable identity attestation artifact, downstream AI systems and compliance consumers cannot independently verify that the identity controls underlying an action were valid at the moment the action occurred. Unsigned attestation artifacts are vulnerable to tampering, and attestations with no defined validity window create stale-evidence risks where outdated identity posture data is accepted as current. Peer dependency on DV-08 ensures that data governance provenance is co-attested with identity governance, preventing evidence fabrication through selective attestation." }, "standard": [ { "id": "nist_800_63", "section": "\u00a73.4.4", "title": "Digital Identity Acceptance Statement" }, { "id": "iso_24760", "section": "ISO/IEC 24760-2:2015", "title": "Records and audit supporting identity management attestation" } ], "sources": [ { "id": "w3c_did_v1_2022", "title": "W3C Decentralized Identifiers (DIDs) v1.0", "authority": "World Wide Web Consortium (W3C)", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2022-07-19", "retrieved_on": "2026-06-29", "canonical_url": "https://www.w3.org/TR/did-core/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_did", "relationship": "implementation_pattern", "rationale": "Establishes W3C Decentralized Identifiers (DIDs) v1.0 requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "nist_sp_800_63_4_2025", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "authority": "National Institute of Standards and Technology", "source_type": "standard", "normative_force": "voluntary-standard", "version": "4", "published_on": "2025-07-31", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.SP.800-63-4", "license": "public-domain", "status": "current", "flagship": false, "source_id": "nist_800_63", "relationship": "implementation_pattern", "rationale": "Establishes NIST SP 800-63-4 Digital Identity Guidelines requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "iso_24760_2019", "title": "ISO/IEC 24760 \u2014 A framework for identity management (Part 1:2019, replaced by Part 1:2025; Part 2:2015)", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2019", "published_on": "2019-05-29", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/77582.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_24760", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 24760-1:2019 \u2014 A Framework for Identity Management requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "ietf_rfc_9396_rar", "title": "RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests", "authority": "IETF", "source_type": "standard", "normative_force": "voluntary-standard", "version": "RFC 9396", "published_on": "2023-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.rfc-editor.org/rfc/rfc9396", "license": "public-domain", "status": "current", "flagship": false, "source_id": "openid", "relationship": "implementation_pattern", "rationale": "Establishes RFC 9396 \u2014 OAuth 2.0 Rich Authorization Requests requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "openai_preparedness_fw_v2", "title": "OpenAI Preparedness Framework v2", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2025-04-15", "retrieved_on": "2026-06-28", "canonical_url": "https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_preparedness", "relationship": "informative_reference", "rationale": "Establishes OpenAI Preparedness Framework v2 requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Okta: Non-Human Identity & AI Agent Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Okta: Non-Human Identity & AI Agent Governance requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy (RSP) v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy (RSP) requirements informing the apeiris://identity/controls/IC-08 Identity Attestation Production control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Aggregate evidence from all IC layer controls (IC-01 through IC-07) into a structured IdentityAttestation artifact, co-attest with DV-08 data governance evidence, sign with Ed25519, and publish to the enterprise evidence store with a defined validity window.", "steps": [ "Collect attestation inputs from all IC layer controls: governance charter status (IC-01), policy review completion (IC-02), access review campaign results (IC-03), PAM enrollment rate (IC-04), compliance mapping coverage (IC-05), IdP audit completion (IC-06), and KPI threshold status (IC-07)", "Request DV-08 data governance attestation from the data domain evidence store as a required peer dependency and embed the DV-08 artifact reference in the IC-08 attestation header", "Compose the IdentityAttestation artifact using the Apeiris evidence ontology fields (evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, valid_from, valid_until, integrity.hash, integrity.signature) and sign with Ed25519", "Publish the signed IdentityAttestation to the enterprise evidence store and notify downstream consumers (AG-08 agentic domain, AU-08 compliance domain) via the Apeiris cross-domain change event protocol" ], "anti_patterns": [ "Producing an identity attestation that covers only a subset of IC layer controls without documenting which controls are excluded and why", "Publishing identity attestation artifacts without a defined validity window, allowing stale attestations to be accepted indefinitely by downstream consumers", "Signing the IdentityAttestation with a certificate rather than an Ed25519 key, creating revocation complexity and reducing verification performance for machine-speed downstream consumers" ] }, "validation": { "design_check": [ "IdentityAttestation artifact schema includes all required Apeiris evidence ontology fields including integrity.hash and integrity.signature", "DV-08 attestation reference is required in the IC-08 artifact header and the production pipeline fails if DV-08 is unavailable", "Valid_from and valid_until fields are enforced with a maximum validity window defined in policy and rejected by downstream consumers if exceeded" ], "runtime_test": [ "Produce a test IdentityAttestation artifact and verify the Ed25519 signature validates correctly against the published verification key", "Simulate DV-08 unavailability and confirm the IC-08 production pipeline halts with a documented error rather than producing an attestation with a missing peer dependency", "Verify that an expired IdentityAttestation is rejected by the AG-08 agentic domain consumer with an appropriate error response" ], "evidence": [ "artifact:Signed IdentityAttestation (IC-08) artifact with valid Ed25519 signature, complete ontology fields, and DV-08 peer reference for the current period [unverified]", "log:Evidence store ingestion record confirming IC-08 artifact publication and downstream consumer notification to AG-08 and AU-08 [unverified]", "record:IC-08 production run log showing all seven IC control evidence inputs collected and DV-08 peer dependency satisfied before signing [unverified]" ] }, "lenses": { "iam_engineer": { "summary": "IC-08 production requires automating evidence collection from all IC layer controls and maintaining a reliable integration with the DV-08 data governance evidence store.", "actions": [ "Build automated evidence collection adapters for each IC layer control so attestation production does not depend on manual data gathering", "Implement the DV-08 peer dependency check as a blocking gate in the IC-08 production pipeline with clear error messaging on failure", "Automate IC-08 attestation publication to the evidence store with downstream consumer notification on each successful signing cycle" ], "failure_signals": [ "IC-08 attestation production requires manual steps to collect evidence from any of the seven IC control inputs", "DV-08 peer dependency check is bypassed or treated as advisory, allowing IC-08 to be produced with a missing required co-attestation" ] }, "security_architect": { "summary": "IC-08 is a critical trust anchor for downstream AI and compliance systems; its integrity architecture must prevent forgery and enforce validity windows.", "actions": [ "Architect IC-08 key management using HSM-backed Ed25519 signing keys with defined rotation schedule and revocation procedures", "Design the IC-08 validity window to be short enough that downstream consumers are forced to re-verify frequently, reducing stale attestation risk", "Include IC-08 attestation verification in the AG-08 agentic domain's pre-action authorization checks as an architectural requirement" ], "failure_signals": [ "IC-08 signing keys are stored in software keystores without HSM protection, creating a forgery risk for the attestation trust chain", "Downstream agentic systems do not verify IC-08 validity before taking actions governed by identity controls" ] }, "legal_counsel": { "summary": "IC-08 produces the signed legal evidence artifact that demonstrates identity governance posture at a specific point in time for regulatory and litigation purposes.", "actions": [ "Confirm IC-08 attestation artifacts are retained according to the enterprise evidence retention policy covering applicable regulatory lookback periods", "Ensure the IC-08 artifact schema captures the legal entity responsible for the identity program and the attestation authority as named fields", "Use IC-08 artifacts as primary evidence in regulatory submissions demonstrating identity governance compliance at the time of any disputed AI-driven action" ], "failure_signals": [ "IC-08 attestation artifacts are not retained beyond 90 days, preventing their use in regulatory submissions or litigation discovery", "IC-08 artifact schema does not capture a named attestation authority, undermining its legal weight as a governance evidence document" ] }, "grc_auditor": { "summary": "IC-08 is the baseline attestation artifact for the IC layer and the primary audit evidence of identity governance posture completeness.", "actions": [ "Collect the most recent IC-08 artifact and verify its Ed25519 signature validates against the published verification key", "Confirm the DV-08 peer dependency reference in the IC-08 header resolves to a current, valid DV-08 attestation", "Trace each IC layer control evidence input in the IC-08 artifact back to its source control to verify the aggregated posture claim is accurate" ], "metrics": [ "IC-08 production SLA adherence: percentage of defined production cycles where IC-08 was successfully produced and signed within the validity window (target: 100%)", "DV-08 peer dependency satisfaction rate: percentage of IC-08 production runs where DV-08 was present and current (target: 100%)" ], "failure_signals": [ "IC-08 signature validation fails, indicating the artifact was modified after signing or the signing key has been compromised", "IC-08 artifact does not include a DV-08 peer reference, indicating the peer dependency gate was bypassed during production" ] }, "it_operations": { "summary": "IC-08 production pipeline operational health is critical because downstream agentic and compliance systems depend on the attestation being current and available.", "actions": [ "Monitor IC-08 production pipeline execution time and alert on failures within 15 minutes to minimize downstream consumer impact", "Implement a read-only evidence store endpoint for IC-08 artifact serving with defined SLA and caching rules for downstream consumer availability", "Maintain a break-glass procedure for manually producing an IC-08 artifact when automated pipeline failure threatens downstream consumer availability" ], "failure_signals": [ "IC-08 production pipeline failure goes undetected for more than one validity window cycle, causing downstream consumers to operate on expired attestations", "No SLA is defined for the IC-08 evidence store serving endpoint, making downstream consumer availability unpredictable" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "IC-08 is the layer baseline control; target state requires automated evidence aggregation, signed artifact production with DV-08 peer dependency enforcement, and defined downstream consumer notification." }, "capability_risk": { "capability_level": "narrow", "autonomy": "supervised-autonomous", "access_mode": "api-key", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "internal-and-external" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IAM Team", "Security Engineering", "GRC" ], "frameworks": [ { "framework": "nist_800_63", "requirement_id": "SP 800-63-4 \u00a73.4.4", "title": "Identity Assurance Documentation and Attestation", "rationale": "SP 800-63-4 \u00a73.4.4 requires a Digital Identity Acceptance Statement documenting the assurance levels selected and the basis for accepting them; IC-08's IdentityAttestation is the machine-readable analogue of that acceptance record for AI agent identities.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "SP 800-63-4 section 3.4.4 requires a Digital Identity Acceptance Statement; IC-08 IdentityAttestation is the machine-readable analogue of that record.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_did", "requirement_id": "\u00a75.3", "title": "DID Document Integrity and Verification Relationships", "rationale": "W3C DID Core \u00a75.3 defines verification relationships (e.g., authentication, assertionMethod) \u2014 the cryptographic verification relationship framework used for Ed25519 signing of IC-08 attestation artifacts.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "W3C DID Core section 5.3 verification relationships provide the assertionMethod framework used for the Ed25519 signing of the IC-08 attestation artifact.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openid", "requirement_id": "RFC 9396", "title": "OAuth 2.0 Rich Authorization Requests for Attestation Propagation", "rationale": "RFC 9396 RAR provides the structured authorization request format for propagating IC-08 attestation claims to downstream AI system authorization flows.", "mapping_fit": "direct", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "RFC 9396 RAR provides the structured authorization-request format for propagating IC-08 attestation claims into downstream AI authorization flows.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Anthropic Transparency Hub \u2014 Model Reports", "rationale": "Anthropic's Transparency Hub and system cards document capability evaluations, safety assessments, and responsible deployment decisions for Claude models as formal attestations of AI behavior. Enterprises deploying Claude should reference these attestations \u2014 specifically the evaluation methodology, third-party validation status, and capability level determinations \u2014 as evidence inputs in their IdentityAttestation artifacts.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic Transparency Hub model reports attest AI behavior, an analogous artifact but not the aggregated IC-layer identity governance attestation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_sf", "requirement_id": "OpenAI Enterprise Compliance API \u2014 audit and auth log export", "rationale": "OpenAI's Compliance Logs Platform provides immutable JSONL audit and authentication logs (Auth logs, Audit logs, Codex logs) via API export, serving as machine-readable evidence of identity events within OpenAI enterprise deployments. These logs can be incorporated into IdentityAttestation evidence packages for audits requiring proof of access governance over OpenAI-powered agents.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI Compliance API exports immutable auth/audit logs that supply identity-event evidence feeding, but not producing, the aggregated IC-08 attestation.", "fit_assessed_on": "2026-07-03", "basis": "asserted", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Identity Governance \u2014 Attestation Evidence", "rationale": "Okta Identity Governance generates access certification artifacts and provisioning audit exports that constitute formal attestation evidence for identity governance compliance. The SCIM export of non-human identity records, combined with certification campaign completion reports, provides the structured evidence base required to produce a complete IdentityAttestation for AI agent deployments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Identity Governance produces certification and provisioning-export artifacts that form part of the evidence IC-08 aggregates into the signed attestation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "cross_domain": { "requires": [ "apeiris://data/controls/DV-08" ], "feeds": [ "apeiris://agentic/controls/AA-01", "apeiris://agentic/controls/AA-02", "apeiris://agentic/controls/AG-08", "apeiris://compliance/controls/AU-08", "apeiris://security/controls/AS-08" ] }, "canonical_id": "apeiris://identity/controls/IC-08", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "validation_objective": "A signed IdentityAttestation artifact must aggregate evidence from all seven IC layer controls (IC-01 through IC-07), include a valid DV-08 peer dependency reference, carry an Ed25519 signature verifiable against a published HSM-backed key, and define valid_from/valid_until fields within the maximum policy-defined validity window. Downstream consumers at AG-08 and AU-08 must reject expired or unsigned IdentityAttestation artifacts before granting authorization.", "evidence_required": [ "signed_identity_attestation_artifact (IC-08) containing all 14 required Apeiris evidence ontology fields (evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, valid_from, valid_until, integrity.hash, integrity.signature) with a verifiable Ed25519 signature and DV-08 peer dependency reference", "ic08_production_run_log showing successful evidence collection from all seven IC control inputs (IC-01 through IC-07), DV-08 peer dependency resolution, and signing event with key_id and timestamp", "evidence_store_ingestion_record confirming IC-08 artifact publication and downstream consumer notification events transmitted to AG-08 and AU-08 within the defined SLA window", "key_management_record for the Ed25519 signing key confirming HSM backing, last rotation date, rotation schedule, and current key status" ], "machine_tests": [ "Retrieve the most recent IC-08 artifact from the evidence store and verify its Ed25519 signature against the published verification key \u2192 assert signature_valid=true", "Simulate DV-08 unavailability during IC-08 production pipeline execution \u2192 assert pipeline halts with error_code=peer_dependency_missing and no artifact is written to the evidence store", "Submit an expired IC-08 artifact (valid_until < now) to an AG-08 pre-action authorization check \u2192 assert authorization is denied with error=attestation_expired", "Inspect IC-08 artifact field inventory \u2192 assert all 14 required Apeiris evidence ontology fields are present and non-null, and valid_until minus valid_from does not exceed the policy-defined maximum window" ], "human_review": [ "Verify that the IC-08 signing key is stored in an HSM-backed keystore and review the key rotation schedule and revocation procedure documentation for completeness and operational readiness", "Review IC-08 artifact retention policy against applicable regulatory lookback periods and confirm archived artifacts include a named attestation authority as a structured, non-nullable field", "Assess whether the IC-08 validity window is appropriately short given the downstream agentic systems' re-verification cadence, balancing attestation freshness against production pipeline throughput" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Producing an IdentityAttestation without requiring all seven IC layer control evidence inputs, generating a false posture claim when some controls have not been evaluated in the current period", "Signing the IC-08 artifact with a software-stored private key rather than an HSM-backed Ed25519 key, undermining the integrity guarantee that downstream consumers depend on", "Publishing IC-08 attestation artifacts without a defined validity window, allowing stale attestations to be accepted indefinitely by AG-08 and AU-08 consumers as evidence of current posture", "Treating the DV-08 peer dependency as optional or advisory, allowing IC-08 to be produced without co-attestation of data governance provenance and enabling selective evidence fabrication", "Bypassing IC-08 signature verification in downstream agentic authorization checks when the evidence store is temporarily unavailable rather than failing closed and denying the action" ], "update_status": "current", "layer_code": "IC" } ] } }