{ "dataset": { "meta": { "domain": "agentic", "domain_slug": "agentic", "domain_number": 6, "title": "Apeiris Agentic Control Matrix", "description": "Apeiris Agentic Control Matrix: 50 machine-readable controls across 6 layers.", "version": "1.5.0", "published": "2026-07-02", "layers": 6, "controls_count": 50, "baseline_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AT-01", "AT-08", "AO-01", "AO-08", "AM-01" ], "canonical_prefix": "apeiris://agentic/controls/", "attestation_artifact": "BehavioralAttestation", "attestation_control": "AG-08", "alias_domain": "agenticverifier.ai", "frameworks": [ "anthropic_rsp", "aws_bedrock_guardrails", "cisa_ai_guidance", "eu_ai_act", "google_saif", "iso_31000", "iso_42001", "microsoft_rai", "mitre_atlas", "nist_ai_600_1", "nist_rmf", "openai_preparedness", "owasp_aisvs", "owasp_llm10", "salesforce_trust" ], "lenses": [ "legal_counsel", "grc_auditor", "ai_engineer", "security_architect", "platform_engineer" ], "license": "CC BY 4.0", "source": "https://apeiris.ai/domains/agentic/", "integration_endpoint": "https://apeiris.ai/integration/domains/agentic-controls-full.json", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "baseline_control_count": 9, "generated_at": "2026-07-02T00:00:00.000Z", "subtitle": "apeiris.ai/domains/agentic — Apeiris Agentic", "site": "https://apeiris.ai/domains/agentic", "corpus_url": "https://apeiris.ai/integration/domains/agentic-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": "AA-01", "layer": "AA", "plane": "control", "name": "Agent Identity Presentation at Tool Invocation", "plain": "Every AI agent must cryptographically prove its identity at the moment it invokes a tool, API, or downstream system by presenting a signed credential — such as a JWT, PASETO token, or client certificate — that the receiving system can independently verify before executing any action.", "threat": { "tags": [ "identity-spoofing", "unauthorized-tool-access", "unauthenticated-invocation", "impersonation" ], "desc": "Without mandatory identity presentation at invocation time, any process able to reach a tool endpoint can invoke it without attribution. Prompt-injected agents, rogue subprocesses, and compromised orchestration layers gain tool access without a verifiable identity claim, eliminating the basis for authorization decisions, audit trails, and post-incident attribution." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 4.2", "title": "Documentation and communication of AI risks and impacts" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — enforcing authorization at tool boundaries" }, { "id": "google_saif", "section": "Element 1", "title": "Expand strong security foundations to the AI ecosystem" } ], "sources": [ { "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-29", "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://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AA-01 Agent Identity Presentation at Tool Invocation control.", "reviewed_on": "2026-07-02" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds agent identity presentation at tool invocation in the Foundation identity capability and Phase 3.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Enforce a signed bearer assertion (JWT or PASETO) carrying agent_id, instance_id, and invocation_nonce at every tool call boundary. The tool endpoint validates the signature against a trusted key registry before processing any request.", "steps": [ "Define a canonical agent assertion schema: agent_id (UUID), instance_id, principal_type=agent, invocation_nonce, iat, exp (≤15 min), and scope claim listing allowed tools.", "Issue short-lived signed assertions from a dedicated agent identity service at session setup; inject into tool call Authorization headers automatically from the agent runtime.", "Instrument all tool endpoints with middleware that validates signature, checks nonce freshness, and rejects expired or unsigned requests with HTTP 401 and a structured error body.", "Log each assertion presentation to an immutable audit store: agent_id, tool_id, nonce, verdict, and ISO 8601 timestamp." ], "ai_engineer": { "summary": "You own the assertion minting and injection logic within the agent runtime. Every tool call must carry a fresh signed assertion; assertions must never be reused across invocations.", "actions": [ "Implement assertion minting in a shared agent runtime library so all agent types receive it automatically without per-agent implementation.", "Configure assertion exp to ≤15 minutes and include a cryptographically random nonce per invocation.", "Write integration tests that confirm tool calls without a valid assertion return 401 and are never executed." ], "failure_signals": [ "Tool calls succeeding without Authorization header in test harness.", "Expired assertions being accepted by any tool endpoint in integration tests.", "Agent runtime exceptions bypassing the assertion injection code path." ] }, "security_architect": { "summary": "Design the trust boundary so that tool endpoints are unreachable without a valid assertion. Network-level controls reinforce but do not replace cryptographic validation.", "actions": [ "Define the central key registry as the root of trust; only keys registered there are valid for assertion signing.", "Require tool endpoints to perform signature validation locally without a remote call on the hot path.", "Ensure the assertion schema is forward-compatible with workload identity tokens (AA-04)." ], "failure_signals": [ "Tool endpoints accepting unsigned requests from any internal network source.", "Key registry not integrated into the certificate lifecycle management process.", "Assertions with missing or empty scope claims being accepted by tool middleware." ] }, "grc_auditor": { "summary": "AA-01 establishes that every AI agent action is attributed to a verified identity. Sample audit logs to confirm every tool invocation carries a resolved and verified agent_id.", "actions": [ "Pull a 30-day sample of tool invocation audit logs and verify agent_id is present, non-null, and resolves to a registry entry on every record.", "Confirm enforcement tests were run against each tool endpoint verifying 401 rejection on missing and invalid assertions.", "Review key registry entries and confirm all signing keys carry expiry dates and rotation records." ], "metrics": [ "Tool invocations with verified agent_id: target 100%.", "Unsigned tool calls reaching execution: target 0.", "Assertion enforcement test coverage across registered tool endpoints: target 100%." ], "failure_signals": [ "Any tool invocation audit record with null or absent agent_id.", "Tool endpoints without documented assertion validation middleware.", "Key registry entries with no expiry date or stale rotation records." ] }, "legal_counsel": { "summary": "Verified agent identity at every tool invocation is what makes agent actions legally attributable. Without it, the enterprise cannot demonstrate which system actor took a consequential action — undermining both regulatory defenses and any allocation of liability to vendors or counterparties.", "actions": [ "Confirm that contracts with agent platform and tool vendors do not disclaim the identity-attribution guarantees this control depends on, and that logging of agent_id survives any vendor data-retention limits.", "Verify that attribution records (agent_id, tool, timestamp, verdict) are retained long enough to support regulatory inquiries and litigation holds in all operating jurisdictions.", "Assess whether unauthenticated tool invocations, if discovered, would constitute reportable security incidents under applicable breach-notification or AI incident rules." ], "failure_signals": [ "Consequential agent actions that cannot be attributed to a verified identity when a regulator, court, or counterparty asks who acted.", "Vendor agreements silent on identity-verification responsibilities at tool boundaries, leaving attribution gaps unallocated.", "Attribution logs expiring before the limitation periods of the claims they would be needed to defend." ] }, "platform_engineer": { "summary": "Build assertion validation middleware as a shared platform component so every tool endpoint inherits enforcement without per-team implementation.", "actions": [ "Package assertion validation as a sidecar or shared middleware library deployed to all tool endpoint services via the standard platform stack.", "Integrate with the central key registry for public key fetching with aggressive caching and revocation check support.", "Expose an assertion enforcement status metric on each tool service health endpoint." ], "failure_signals": [ "Teams deploying tool endpoints outside the standard platform stack without documented assertion middleware.", "Key registry cache invalidation failures causing stale or revoked keys to remain accepted.", "Assertion validation middleware not forwarding rejection events to the central audit store." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agentic frameworks invoke tools without any credential presentation; this control establishes the foundational baseline." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 4.2", "fit": "partial", "rationale": "NIST AI RMF GOVERN 4.2 requires organizational teams to document and communicate the risks and impacts of the AI technology they deploy. Verifiable identity presentation at every tool invocation gives that documentation an accurate factual basis: each recorded action is attributable to a specific, cryptographically verified agent.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "partial", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) identifies excessive permissions and unverified tool access as root enablers of unintended agent actions, and its mitigations require enforcing authorization in downstream systems rather than relying on the model. AA-01's mandatory signed assertions implement that enforcement at every tool boundary.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "google_saif", "requirement_id": "Element 1 — Expand strong security foundations to the AI ecosystem", "fit": "direct", "rationale": "Google SAIF element 1 calls for extending strong security foundations — including authentication — to the AI ecosystem. AA-01 operationalizes this by applying established cryptographic identity patterns to the agent-to-tool invocation boundary.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0012", "fit": "adjacent", "rationale": "MITRE ATLAS AML.T0012 (Valid Accounts) describes adversaries reusing legitimate credentials to access ML system components. Mandatory cryptographic identity presentation with short-lived assertions significantly reduces the window during which captured credentials can be reused against tool endpoints.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 (Human oversight and control) requires that systems be designed so humans can oversee and control system behavior. Verified agent identity at every tool invocation is a precondition for that oversight: an action can only be reviewed, attributed, or halted if it is bound to a known agent.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. That record supports after-the-fact attribution of agent activity within Salesforce; cryptographic identity presentation at invocation time, as AA-01 requires, is a stronger, preventive control implemented in the agent runtime.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Agent identity verification; Part IV Phase 3 — Assign a unique identity", "fit": "direct", "rationale": "Doc requires verifiable per-agent identity, backed by cryptographic material, presented at every access/tool invocation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-01", "validation_objective": "Every registered tool endpoint must reject unsigned or invalidly signed requests with HTTP 401 before processing any action, and every successful tool invocation in the audit log must carry a non-null, registry-resolvable agent_id. The control passes when 100% of tool invocations in a 30-day sample carry verified assertions and zero unsigned calls reached execution.", "evidence_required": [ "Tool invocation audit log export from the immutable audit store showing non-null agent_id on 100% of records for the past 30 days", "Assertion enforcement test results confirming HTTP 401 on unsigned and expired requests for each registered tool endpoint", "Key registry configuration export showing all signing keys with documented expiry dates and rotation records", "Agent runtime code or configuration artifact demonstrating assertion minting and injection on every outbound tool call", "SIEM records of at least one 401 rejection event from a controlled unsigned call test, confirming end-to-end enforcement" ], "machine_tests": [ "Send an unsigned tool call (no Authorization header) to each registered tool endpoint and assert HTTP 401 on all", "Send a tool call with an expired assertion (exp set to past timestamp) to each endpoint and assert HTTP 401 on all", "Query the tool invocation audit log for records with NULL or absent agent_id over the past 30 days — count must be 0", "Resubmit a previously used invocation_nonce to each tool endpoint and assert HTTP 401 on all, confirming nonce freshness enforcement" ], "human_review": [ "Review key registry entries and confirm all signing keys carry documented expiry dates and rotation schedule with at least one completed rotation event", "Inspect the agent runtime assertion minting code to confirm invocation_nonce is cryptographically random and unique per call, never reused across invocations", "Sample 10 audit log records and manually verify each agent_id resolves to a current, active registry entry with no stale or deleted matches" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Implementing assertion validation in the agent application layer rather than shared platform middleware, creating inconsistent enforcement across tool endpoints where some accept unsigned requests", "Using a single shared long-lived API key for all agents instead of per-agent short-lived signed assertions with unique nonces, collapsing attribution to a fleet-level identity", "Logging assertion presence in audit records without validating the signature, so audit logs show agent_id even when forged or tampered assertions are accepted", "Setting assertion exp to 24 hours or longer to avoid frequent re-issuance, eliminating the token freshness protection the nonce and expiry are designed to provide" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-02", "layer": "AA", "plane": "lifecycle", "name": "API Key and Bearer Token Lifecycle Management", "plain": "API keys and bearer tokens used by AI agents must have enforced short lifetimes, be rotated automatically before expiry, be stored exclusively in secrets management systems, and be revocable within minutes of a compromise signal — with zero tolerance for hardcoded credentials in agent code or container images.", "threat": { "tags": [ "credential-theft", "key-sprawl", "stale-credential", "rotation-failure" ], "desc": "Long-lived API keys embedded in agent configuration or code are the most common initial access vector for compromised AI agent deployments. Keys that are never rotated and not stored in secrets managers accumulate across environments, persist after personnel changes, and provide indefinite access if extracted from code repositories, container images, or log files." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 2.4", "title": "Mechanisms to supersede, disengage, or deactivate AI systems" }, { "id": "microsoft_rai", "section": "PS2", "title": "Security Policy compliance — credential lifecycle management" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control" } ], "sources": [ { "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-29", "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://agentic/controls/AA-02 API Key and Bearer Token Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-02 API Key and Bearer Token Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-02 API Key and Bearer Token Lifecycle Management control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-02 API Key and Bearer Token Lifecycle Management control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-02 API Key and Bearer Token Lifecycle Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Store all agent API keys in a managed secrets service (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Set automated rotation schedules: 30-day maximum for long-lived service keys and 60-minute maximum for programmatically issued bearer tokens. Implement a revocation endpoint reachable within 60 seconds of a compromise signal.", "steps": [ "Inventory all agent API keys and bearer tokens across all environments; migrate any hardcoded or file-based secrets to a managed secrets service within 30 days.", "Configure automated rotation for all agent API keys: maximum 30-day lifetime for service-to-service keys, 60-minute lifetime for session bearer tokens, with automated pre-rotation triggered at 80% of lifetime.", "Implement a revocation API that propagates invalidation to all consuming agent instances within 60 seconds; test revocation end-to-end on a quarterly cadence.", "Integrate secrets scanning into CI/CD gates: block artifact promotion that contains hardcoded credential patterns via pre-commit hooks and pipeline secret-scanning tools." ], "ai_engineer": { "summary": "Never embed API keys in agent code, configuration files, or environment variables baked into container images. Always fetch from the secrets service at startup with short in-memory cache TTLs.", "actions": [ "Refactor all agent credential fetching to pull from the secrets service at agent initialization with a maximum 5-minute in-memory cache.", "Implement credential refresh handlers that automatically fetch new tokens before expiry without agent restart.", "Add startup checks that abort agent launch if any hardcoded credential pattern is detected in the agent's configuration." ], "failure_signals": [ "Secrets found in source control or container image layers during security scans.", "Agent failing to launch after key rotation due to missing refresh logic.", "Bearer tokens with exp values exceeding the 60-minute policy appearing in production telemetry." ] }, "security_architect": { "summary": "Design the secrets management architecture so that agent processes receive credentials through a consistent, audited path. Enforce the architecture through platform controls that make the insecure path harder than the secure path.", "actions": [ "Establish a credential lifecycle policy specifying maximum lifetimes per credential class and required storage locations.", "Configure the CI/CD pipeline to fail on detected secrets using tools such as truffleHog, gitleaks, or Semgrep secrets rules.", "Design a revocation propagation mechanism with a contractual SLA of ≤60 seconds from compromise signal to universal invalidation." ], "failure_signals": [ "Agent service accounts with API keys older than 30 days in production.", "No documented revocation playbook or revocation SLA for agent credentials.", "Secrets management system not integrated with the agent deployment pipeline." ] }, "grc_auditor": { "summary": "Credential lifecycle management is a foundational audit control. Verify that no agent credential lives outside the approved secrets management system and that rotation and revocation SLAs are documented and tested.", "actions": [ "Request a secrets inventory report from the platform team and verify 100% of agent API keys are stored in the approved secrets management system.", "Sample 10 agent service accounts and check creation and last-rotation timestamps; confirm no key exceeds its defined maximum lifetime.", "Review the revocation runbook and confirm a live revocation drill was performed within the last 90 days." ], "metrics": [ "Agent API keys outside approved secrets management: target 0.", "Keys exceeding defined maximum lifetime in production: target 0.", "Time from compromise signal to universal key revocation: target ≤60 seconds." ], "failure_signals": [ "API keys found in source code, container images, or configuration files outside secrets management.", "No rotation records for agent service credentials in the secrets manager audit log.", "Revocation drill not completed within the required cadence." ] }, "legal_counsel": { "summary": "Credential lifecycle discipline is part of the enterprise's duty of care for systems that act autonomously. A stale or orphaned agent credential that enables unauthorized action is difficult to defend as anything other than a governance failure.", "actions": [ "Confirm the credential inventory and rotation records would satisfy a security-controls representation made to customers, insurers, or regulators.", "Verify that credential revocation on agent decommissioning is documented, so terminated systems cannot be the source of post-termination liability.", "Review incident disclosure obligations triggered if a long-lived agent credential is confirmed compromised." ], "failure_signals": [ "Security questionnaires or audit responses asserting credential rotation that the rotation logs cannot substantiate.", "Decommissioned agents with credentials still valid — a standing unauthorized-access exposure with no responsible owner.", "No documented decision on whether a compromised agent credential is a notifiable incident in the jurisdictions where the agent operates." ] }, "platform_engineer": { "summary": "Build the secrets management infrastructure and enforce usage through deployment guardrails. Make the secure path the default for all agent deployments.", "actions": [ "Deploy a managed secrets service with agent-accessible APIs and automatic rotation support for common credential types.", "Add a deployment gate that scans agent artifacts for hardcoded credential patterns and blocks promotion on findings.", "Implement audit logging on all secrets access: agent_id, secret_id, access_time, and rotation event records." ], "failure_signals": [ "Secrets management service availability below 99.9% SLA causing agent startup failures.", "Rotation automation failures not triggering alerts within 5 minutes.", "Credential access audit logs missing for any agent service account." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have secrets management for human accounts but have not systematically extended it to AI agent credentials with automated rotation." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector" ], "implementers": [ "Platform Engineering", "AI Engineering", "Security Operations" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 2.4", "fit": "partial", "rationale": "NIST AI RMF MANAGE 2.4 requires mechanisms to supersede, disengage, or deactivate AI systems whose behavior is inconsistent with intended use. Short-lived credentials with enforced rotation and immediate revocation are the identity-layer mechanism that makes rapid disengagement of a specific agent practical.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "PS2 — Security Policy compliance", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal PS2 requires AI systems to comply with the organization's security policy. Managed credential lifecycles — scoped issuance, rotation, and revocation for agent API keys and tokens — are core security-policy controls applied to the agent identity layer.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "direct", "rationale": "ISO/IEC 42001 §8.1 requires the processes needed to meet AI management system requirements to be planned, implemented, and controlled, with documented information demonstrating they were carried out as planned. Credential lifecycle management is one of those documented operational controls for agent deployments.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 4 — Harmonize platform-level controls to ensure consistent security", "fit": "direct", "rationale": "Google SAIF element 4 (Harmonize platform-level controls) calls for applying consistent security controls — including credential management — across all AI system components. AA-02 implements a uniform credential lifecycle for every agent credential rather than per-team ad hoc practice.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Service authentication (short-lived tokens, OAuth 2.0)", "fit": "direct", "rationale": "Foundation service authentication = OAuth 2.0 / short-lived tokens with automatic refresh and minute-scale expiration; no embedded credentials — the token lifecycle this control manages.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-02", "validation_objective": "No agent API key or bearer token may exist outside an approved secrets management system, all active keys must fall within their defined maximum lifetime with documented automated rotation, and any key must be revocable within 60 seconds of a compromise signal. The control passes when a secrets inventory confirms 100% coverage and zero hardcoded credentials are found in agent artifacts.", "evidence_required": [ "Secrets inventory report from the approved secrets management platform listing all agent API keys with creation date, last-rotation timestamp, and confirmation no key exceeds its defined maximum lifetime", "CI/CD pipeline secret-scanning logs for the past 30 days showing zero hardcoded credential findings across all agent source repositories and container images", "Revocation drill report from the past 90 days confirming end-to-end key revocation reached all consuming agent instances within 60 seconds", "Agent service account IAM or platform report confirming zero active static keys attached to any agent identity across all environments" ], "machine_tests": [ "Run a secrets scanning tool (gitleaks, truffleHog) across all agent container image layers and source repositories — count of credential findings must be 0", "Query the secrets management audit log for all agent key creation events and assert no key has a last-rotation timestamp older than the defined maximum lifetime for its credential class", "Trigger automated key rotation for a canary agent credential and verify the consuming agent picks up the new key without a process restart within the rotation completion window", "Revoke a canary agent credential and confirm all consuming agent instances reject the revoked key within 60 seconds, measured from revocation timestamp to first observed rejection" ], "human_review": [ "Review the credential lifecycle policy document and confirm it specifies maximum lifetimes per credential class (30-day service keys, 60-minute bearer tokens) and the approved storage systems", "Inspect the revocation runbook and confirm it has been tested end-to-end within the past 90 days with a documented result meeting the 60-second SLA", "Review the secrets management audit log for anomalous access patterns on agent credential records, including unexpected access times or principals" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using environment variables baked into container images to store API keys rather than fetching from the secrets manager at runtime, so keys are extractable from container layers via image scanning", "Configuring automated rotation schedules in the secrets manager without implementing credential refresh handlers in the agent runtime, causing agents to fail silently after rotation", "Storing all agent credentials under a single secrets manager principal without per-agent isolation, making fine-grained revocation of one agent's credentials impossible without revoking all agents", "Treating the 60-second revocation SLA as aspirational rather than validating it through quarterly automated drill procedures with documented pass/fail outcomes" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-03", "layer": "AA", "plane": "control", "name": "mTLS and Certificate-Based Agent Authentication", "plain": "AI agents establishing service-to-service connections must use mutual TLS with X.509 certificates issued by a trusted PKI, ensuring that both the agent and the receiving service cryptographically authenticate each other before transmitting any data or accepting any request.", "threat": { "tags": [ "man-in-the-middle", "impersonation", "network-interception", "certificate-abuse" ], "desc": "Agents communicating over TLS without mutual authentication are vulnerable to impersonation of the target service and to injection of malicious responses. An adversary who can intercept or terminate agent traffic — including a compromised sidecar or network component — can redirect agent calls, inject fabricated responses, or silently replay previous responses without the agent detecting the attack." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE 2.5", "title": "Demonstrated validity and reliability of the AI system" }, { "id": "eu_ai_act", "section": "Art. 15(5)", "title": "Cybersecurity measures for high-risk AI systems" }, { "id": "google_saif", "section": "Element 2", "title": "Extend detection and response to the AI ecosystem" } ], "sources": [ { "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-29", "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://agentic/controls/AA-03 mTLS and Certificate-Based Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-03 mTLS and Certificate-Based Agent Authentication control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-03 mTLS and Certificate-Based Agent Authentication control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-03 mTLS and Certificate-Based Agent Authentication control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-03 mTLS and Certificate-Based Agent Authentication control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy a PKI with an intermediate CA dedicated to agent identities. Issue agent certificates from this CA with CN=agent-id, O=org, and SANs including the agent workload identity URI. Enforce mTLS at the service mesh or API gateway layer with automatic certificate rotation via cert-manager or SPIFFE/SPIRE.", "steps": [ "Establish a dedicated agent identity intermediate CA, separate from human and server certificate chains, to allow independent revocation and policy control.", "Issue X.509 certificates to each agent with CN=agent_id, subject alternative name including the agent's SPIFFE SVID URI, and maximum validity of 24 hours with automated renewal at 75% of lifetime.", "Configure all agent-to-service endpoints to require mTLS: reject connections presenting no client certificate or a certificate from an untrusted CA with a TLS handshake failure.", "Deploy CRL distribution points and OCSP responders with ≤15-minute freshness so revocation of a compromised agent certificate propagates promptly." ], "ai_engineer": { "summary": "Your agent runtime must load and present its X.509 certificate in every outbound connection. Certificates must be rotated automatically; the agent must handle certificate reload without a process restart.", "actions": [ "Integrate certificate fetching from the PKI or SPIRE agent into the agent startup sequence; mount certificates at a known path and watch for renewal events.", "Implement graceful certificate reload so the agent picks up renewed certificates without process restart.", "Test that the agent rejects connections to services presenting expired or untrusted server certificates." ], "failure_signals": [ "Agent startup failing when certificate path is unavailable.", "Agent using an expired certificate because a reload handler is not implemented.", "Agent accepting connections to services with self-signed or untrusted certificates." ] }, "security_architect": { "summary": "Design the PKI hierarchy specifically for agent identities with an isolated intermediate CA. Encode agent identity attributes in certificates to enable attribute-based access control at the receiving service.", "actions": [ "Define certificate policy (CP) and certification practice statement (CPS) for the agent identity CA covering issuance, renewal, and revocation procedures.", "Encode agent attributes in X.509 extensions: principal_type, domain, tier, and authorization scope for use by mTLS-aware service mesh policies.", "Establish a certificate transparency log or equivalent audit record for all issued agent certificates." ], "failure_signals": [ "Agent certificates issued from the same CA as human user certificates, preventing independent revocation.", "No OCSP or CRL infrastructure deployed, making revocation dependent solely on certificate expiry.", "Service mesh mTLS policies not enforcing client certificate validation." ] }, "grc_auditor": { "summary": "mTLS is the strongest broadly deployed authentication mechanism for service-to-service communication. Verify that all inter-agent and agent-to-service connections in classified or high-risk tiers operate under mTLS.", "actions": [ "Review the agent PKI certificate inventory and verify all active agent certificates are within their defined validity period and issued from the approved intermediate CA.", "Sample 5 agent service connections and confirm mTLS is enforced by testing connection rejection with no client certificate.", "Confirm OCSP freshness SLA is met by checking the most recent OCSP response timestamps across active certificates." ], "metrics": [ "Agent connections in high-risk and classified tiers operating under mTLS: target 100%.", "Agent certificates with validity exceeding 24 hours: target 0.", "OCSP freshness SLA compliance (≤15 minutes): target ≥99%." ], "failure_signals": [ "Agent-to-service connections discovered not using mTLS in network traffic analysis.", "Revoked agent certificates not propagated within the freshness SLA.", "Certificate issuance not logged in the certificate transparency or equivalent audit record." ] }, "legal_counsel": { "summary": "Mutually authenticated, encrypted transport for agent traffic is a baseline technical measure regulators expect for high-risk AI systems (EU AI Act Art. 15(5)) and for personal data in transit. Its absence is hard to defend after an interception incident.", "actions": [ "Confirm data-protection assessments and Article 15 cybersecurity documentation cite mTLS coverage for agent communication paths that carry personal or regulated data.", "Verify certificate management responsibilities are contractually assigned where agent traffic crosses vendor or partner infrastructure.", "Assess whether any unencrypted or one-way-authenticated agent channels would undermine security representations already made externally." ], "failure_signals": [ "Security or DPIA documentation claiming encrypted agent communications while exempted plaintext channels exist.", "Cross-organization agent traffic with no contractual allocation of certificate and trust-store management duties.", "Interception of agent traffic that must be disclosed as affecting data whose protection was contractually promised." ] }, "platform_engineer": { "summary": "Run the PKI and automate certificate issuance and renewal through the service mesh or SPIRE. Certificate lifecycle must be invisible to the agent developer.", "actions": [ "Deploy cert-manager or SPIRE with an agent-facing workload attestor that issues certificates based on verified workload attributes such as container image digest and namespace.", "Configure the service mesh (Istio, Linkerd, or Consul Connect) to enforce mTLS between all agent workloads using the agent PKI.", "Implement certificate expiry monitoring with alerts at 6-hour and 1-hour pre-expiry to enable emergency renewal before outage." ], "failure_signals": [ "Certificate renewal automation failing silently, discovered only when agents begin rejecting connections.", "Service mesh mTLS policy misconfiguration allowing plaintext fallback.", "SPIRE or cert-manager availability below SLA causing certificate issuance backlogs." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "mTLS is well-understood in microservices but is rarely extended explicitly to AI agent identity; this control adapts established patterns to the agent authentication context." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Platform Engineering", "Security Architecture", "Network Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE 2.5", "fit": "partial", "rationale": "NIST AI RMF MEASURE 2.5 requires the AI system to be demonstrated as valid and reliable under expected operating conditions. Mutually authenticated, encrypted transport protects that reliability claim end to end: agent-to-service communications cannot be silently intercepted or altered by an unauthenticated party.", "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. 15(5)", "fit": "direct", "rationale": "EU AI Act Article 15(5) requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities. Mutually authenticated, encrypted transport is a baseline technical measure against interception and manipulation of agent communications.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "direct", "rationale": "Google SAIF element 2 (Extend detection and response) requires that communications within AI systems be secured and observable. mTLS establishes verified identity on both ends of every agent connection, giving detection infrastructure trustworthy attribution for network events.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0040 — AI Model Inference API Access", "fit": "adjacent", "rationale": "MITRE ATLAS AML.T0040 (AI Model Inference API Access) describes adversaries obtaining access to model inference APIs as a staging step for further attacks. Certificate-based mutual authentication restricts inference and tool APIs to verified workloads, cutting off unauthenticated API access.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "microsoft_rai", "requirement_id": "PS2 — Security Policy compliance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal PS2 requires compliance with organizational security policy, which for service-to-service communication means authenticated, encrypted transport. mTLS between agents and the services they call implements that policy at the transport layer.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Agent identity and authentication (Enterprise: mutual TLS with certificate pinning; X.509 per agent)", "fit": "direct", "rationale": "Enterprise identity tier issues X.509 certificates per agent and requires mutual TLS with certificate pinning plus lifecycle management (rotation/revocation).", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-03", "validation_objective": "Every agent-to-service connection in cloud-native and high-risk-sector tiers must be established using mTLS with an X.509 certificate issued by the approved agent identity intermediate CA, and connections attempted without a valid client certificate must be rejected at the TLS handshake layer before any application data is exchanged. The control passes when all sampled connections show mutual certificate verification with no plaintext or one-way-TLS fallback.", "evidence_required": [ "Service mesh or API gateway mTLS enforcement configuration export showing client certificate requirement is active on all agent-facing endpoints with no permissive-mode exceptions", "Agent identity CA certificate inventory listing all active agent certificates with validity periods confirmed within the 24-hour maximum and SPIFFE SVID SANs present", "Network connection log or traffic capture showing TLS 1.2+ with bidirectional certificate exchange on a 30-day sample of agent-service connections", "OCSP responder freshness log confirming response timestamps are within the 15-minute SLA for all active agent certificates over the past 30 days" ], "machine_tests": [ "Attempt a connection to each agent-facing endpoint without presenting a client certificate and assert TLS handshake failure with no HTTP response returned", "Present an agent certificate signed by an untrusted CA to each endpoint and assert TLS handshake failure", "Query the agent identity CA certificate inventory for certificates with validity period exceeding 24 hours — count must be 0", "Retrieve the most recent OCSP response for each active agent certificate and assert freshness timestamp is within 15 minutes of the check time" ], "human_review": [ "Review the agent identity CA certificate policy (CP) and confirm it specifies the 24-hour maximum validity, required SPIFFE SVID SAN encoding, and independence from the human user certificate chain", "Inspect the certificate transparency log or equivalent audit record to confirm all active agent certificates appear as issued entries", "Verify that the service mesh mTLS policy has no permissive or plaintext-fallback mode configured on any agent workload namespace or service" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Configuring the service mesh mTLS policy in permissive mode that logs missing client certificates but still allows the connection, treating mTLS as observability rather than enforcement", "Issuing agent certificates from the same intermediate CA as human user or server certificates, preventing independent revocation and per-agent policy control", "Setting certificate validity to 90 days or more to reduce automation complexity, eliminating the security benefit of short-lived certificates for limiting blast radius after key compromise", "Relying exclusively on certificate expiry for revocation with no OCSP or CRL infrastructure deployed, leaving a multi-day window during which a compromised private key remains trusted" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-04", "layer": "AA", "plane": "control", "name": "Workload Identity for Agent Processes", "plain": "AI agent processes must authenticate to cloud and on-premises services using platform-native workload identity mechanisms — SPIFFE/SPIRE, AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, or Azure Managed Identity — eliminating static secrets from agent code and configuration entirely.", "threat": { "tags": [ "static-secret-exposure", "credential-sprawl", "identity-impersonation", "privilege-escalation" ], "desc": "Static API keys and service account credentials stored in agent configuration or environment variables are routinely exposed through container image scanning, configuration drift, log aggregation, and developer tooling. Once extracted, these static credentials grant indefinite access until manually rotated. Workload identity eliminates the static credential entirely by binding authentication to the verified execution context of the agent process." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 1.2", "title": "Trustworthy-AI characteristics integrated into organizational policies" }, { "id": "google_saif", "section": "Element 1", "title": "Expand strong security foundations to the AI ecosystem" } ], "sources": [ { "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-29", "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://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AA-04 Workload Identity for Agent Processes control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Bind each agent workload to a dedicated service account or workload identity principal with the minimum required permissions. Use the cloud provider's native workload identity federation or SPIFFE/SPIRE for cross-platform scenarios. Validate workload identity token claims at the receiving service before granting any permissions.", "steps": [ "Inventory all agent service accounts and map each to a workload identity principal; remove any static key bindings and replace with workload identity federation tokens within 30 days.", "Create a dedicated service account or IAM role per agent type — not per instance — with a permission set scoped to only the resources that agent type legitimately needs.", "Deploy SPIFFE/SPIRE node and workload agents for multi-cloud or on-premises agents; configure workload attestors appropriate to each execution environment (Kubernetes pod, EC2 instance, GKE pod).", "Validate workload identity tokens at all service endpoints: check issuer, audience, and subject claims against the expected agent identity before processing any request." ], "ai_engineer": { "summary": "Remove all static credentials from agent code and configuration. Use the workload identity SDK for your cloud platform to fetch tokens at runtime; these tokens are automatically refreshed by the platform.", "actions": [ "Replace all static API key usage with workload identity token fetching using the platform SDK (e.g., boto3 AssumeRoleWithWebIdentity, GCP ADC, Azure DefaultAzureCredential).", "Confirm no static credentials exist in Dockerfile, environment variable configuration, or agent config files via pre-commit secret scanning.", "Test that the agent fails gracefully with a clear error when workload identity is unavailable rather than falling back to static credentials." ], "failure_signals": [ "Static credentials found in agent code, Dockerfile, or configuration during security scan.", "Agent silently falling back to a static credential file when workload identity is unavailable.", "Workload identity tokens not being refreshed before expiry, causing agent authentication failures." ] }, "security_architect": { "summary": "Design the workload identity architecture to enforce least privilege: each agent type gets a distinct identity with the minimum permissions needed. Prevent identity reuse across agent types.", "actions": [ "Define one service account or IAM role per agent type and enforce this as a deployment policy via infrastructure-as-code linting.", "Configure permission boundaries (AWS) or organization policies (GCP) to prevent any agent workload identity from escalating its own permissions.", "Establish a workload identity attestation policy that ties identity issuance to verified execution context attributes: container image digest, pod namespace, and node label." ], "failure_signals": [ "Multiple agent types sharing a single service account or IAM role.", "Agent workload identities with wildcard (*) resource grants in any attached policy.", "No permission boundary or organization policy constraining agent identity privilege escalation." ] }, "grc_auditor": { "summary": "Workload identity eliminates the static credential class from the agent attack surface. Verify that no agent process authenticates using static keys and that workload identity assignments follow least-privilege.", "actions": [ "Request an IAM audit report for all agent service accounts; confirm zero static keys are attached and all authentication uses workload identity federation.", "Sample 5 agent workload identities and review their attached permission policies; confirm each follows least-privilege with no overly broad resource grants.", "Verify SPIFFE/SPIRE or cloud workload identity attestation policies are configured and that unattested workloads cannot receive identity tokens." ], "metrics": [ "Agent service accounts with active static keys: target 0.", "Agent workload identities with wildcard resource grants: target 0.", "Workload identity coverage across agent fleet: target 100%." ], "failure_signals": [ "Any agent service account with an active static API key.", "Workload identity tokens being issued to unattested or unregistered workloads.", "Agent permission policies not reviewed in the last 90 days." ] }, "legal_counsel": { "summary": "Workload identity replaces static secrets with attested identities — reducing the class of incidents where a leaked credential lets an unknown party act as the enterprise's agent. That directly limits exposure to claims arising from actions the enterprise cannot disown.", "actions": [ "Confirm that representations about least-privilege and secrets management in customer and regulator communications reflect the actual workload-identity coverage for agents.", "Verify that identity-issuance records (which workload, which attestation, when) are retained as evidence for post-incident attribution and defense.", "Review whether agent actions taken under platform-issued identities are properly attributable to the enterprise or a vendor under existing contracts." ], "failure_signals": [ "Static agent secrets in production contradicting external security representations.", "Inability to establish, after an incident, whether an action was taken by an attested workload or a copied credential.", "Vendor-operated agent workloads whose identity issuance the enterprise cannot audit or contractually compel." ] }, "platform_engineer": { "summary": "Provision and manage workload identity infrastructure as a platform capability. Agent teams should consume workload identity through a standardized interface without managing the underlying PKI or token issuance mechanics.", "actions": [ "Deploy SPIFFE/SPIRE or configure cloud workload identity federation for all agent execution environments with automated node and workload attestation.", "Provide a platform-level interface (Kubernetes operator or Terraform module) for agent teams to declare their workload identity requirements declaratively.", "Implement workload identity audit logging: record every token issuance with workload attestation claims, agent_id, and timestamp." ], "failure_signals": [ "SPIRE server or cloud workload identity service availability below SLA, forcing fallback to static credentials.", "Workload attestation policies not enforced, allowing any pod to claim any agent identity.", "Token issuance events not appearing in the central audit log." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Cloud workload identity for traditional microservices is mature; extending it explicitly to AI agent processes with appropriate attestation policies is an emerging practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "cloud-native", "high-risk-sector", "federated-enterprise", "universal-enterprise" ], "implementers": [ "Platform Engineering", "Cloud Infrastructure", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 1.2", "fit": "partial", "rationale": "NIST AI RMF GOVERN 1.2 requires the characteristics of trustworthy AI — including secure and resilient operation — to be integrated into organizational policies, processes, and practices. Workload identity embeds a secure-operation policy directly into how agent processes authenticate: attested, short-lived identities instead of static secrets.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 1 — Expand strong security foundations to the AI ecosystem", "fit": "partial", "rationale": "Google SAIF element 1 calls for extending established security foundations — identity, authentication, and access management — to AI systems. Workload identity applies the platform identity foundation to agent processes, replacing static secrets with attested, short-lived identities.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§6.1", "fit": "direct", "rationale": "ISO 42001 §6.1 requires organizations to identify and address risks associated with AI system operation. The risk of static credential exposure is a primary operational risk for AI agent deployments; workload identity is the standard technical countermeasure that eliminates this risk class.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "PS2 — Security Policy compliance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal PS2 requires AI systems to comply with security policy, including least-privilege access to resources. Workload identity binds agent processes to attested, short-lived identities so access is granted to verified workloads rather than to whoever holds a static secret.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Resource boundaries (identity-based isolation: every workload carries its own cryptographic identity); Part III — Agent identity and authentication", "fit": "direct", "rationale": "Doc: every agent workload carries its own cryptographic identity and services accept connections only from named callers — workload identity for agent processes.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-04", "validation_objective": "Every agent process must authenticate to cloud and on-premises services exclusively via platform-attested workload identity tokens bound to verified execution context attributes, with zero active static keys attached to any agent service account. The control passes when an IAM audit confirms 100% workload identity coverage and the workload attestation policy requires image digest and namespace verification before token issuance.", "evidence_required": [ "IAM audit report for all agent service accounts across all environments showing zero active static API keys and 100% workload identity federation binding", "Workload identity attestation policy configuration export showing required attributes (container image digest, pod namespace, node labels) enforced before token issuance", "Token issuance audit log for the past 30 days with agent_id, attestation claim values, and issuer metadata confirming all issuances are to attested workloads", "CI/CD pipeline secret-scanning results confirming zero static credentials in agent Dockerfiles, environment variable configurations, and deployment manifests" ], "machine_tests": [ "List all agent service accounts via cloud IAM API and assert zero active static access keys on any account across all environments", "Attempt to obtain a workload identity token without required attestation attributes (valid container image digest, approved namespace) and assert rejection", "Run secrets scanning (gitleaks, truffleHog) across all agent Dockerfiles, Helm charts, and deployment manifests — count of static credential findings must be 0", "Verify agent authentication succeeds after workload identity token renewal by testing the automatic refresh cycle end-to-end in a staging environment without agent restart" ], "human_review": [ "Review the permission policy attached to 5 sampled agent workload identity principals and confirm no wildcard resource grants and no iam:PassRole or equivalent privilege escalation paths", "Inspect the workload attestation policy configuration and confirm that workloads without expected image digest or namespace labels cannot receive identity tokens", "Verify that a permission boundary or organization-level policy prevents any agent workload identity from modifying its own IAM permissions or creating new credentials" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Assigning a shared IAM role or service account to multiple agent types rather than creating a dedicated identity per agent type, collapsing least-privilege boundaries and making targeted revocation impossible", "Implementing workload identity federation but leaving a static key file as a fallback for environments where the identity provider is unavailable, preserving the credential exposure the control is designed to eliminate", "Configuring workload attestation policies using only namespace labels without including container image digest, allowing any container deployed into the namespace to claim the agent identity regardless of content", "Not testing agent behavior when workload identity is unavailable, discovering only in production that the agent silently falls back to a hardcoded credential file on the container filesystem" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-05", "layer": "AA", "plane": "control", "name": "Session Token Binding and Anti-Replay Controls", "plain": "Agent session tokens must be cryptographically bound to the specific agent instance and session context, include a unique nonce on every issuance, and be validated for nonce freshness on every use to prevent replay attacks from capturing and resubmitting valid tokens outside their intended scope.", "threat": { "tags": [ "token-replay", "session-hijacking", "credential-reuse", "cross-session-token-theft" ], "desc": "An agent session token captured from an audit log, network trace, or memory dump can be replayed by an attacker to impersonate the agent in subsequent calls if the receiving service does not validate nonce uniqueness and token binding. Multi-agent orchestration layers compound this risk: a token issued for one agent in a chain can be used by a compromised intermediate agent to impersonate the original agent to downstream services." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 1.2", "title": "Prioritized treatment of documented AI risks" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — session scope enforcement" }, { "id": "microsoft_rai", "section": "PS2", "title": "Security Policy compliance — session integrity controls" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-05 Session Token Binding and Anti-Replay Controls control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-05 Session Token Binding and Anti-Replay Controls control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-05 Session Token Binding and Anti-Replay Controls control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-05 Session Token Binding and Anti-Replay Controls control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-05 Session Token Binding and Anti-Replay Controls control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Include a UUID v4 nonce (jti claim) and a binding claim (HMAC of agent_id + instance_id + session_id) in every issued session token. The receiving service checks the nonce against a distributed nonce store (TTL matching token lifetime) before processing. Tokens with a previously seen nonce or mismatched binding claim are rejected with HTTP 401.", "steps": [ "Add a jti (JWT ID) claim containing a UUID v4 nonce to every agent session token at issuance; include a binding claim derived from agent_id, instance_id, session_id, and a server-side secret.", "Deploy a distributed nonce store (Redis cluster or DynamoDB) with TTL equal to token lifetime plus clock skew tolerance (token_exp - token_iat + 30 seconds).", "Instrument every token-consuming endpoint to check the nonce against the store before processing; reject duplicate nonces with HTTP 401 and log the replay attempt with full context.", "Validate the binding claim at the endpoint: reject any token where the binding claim does not match the expected agent_id and session_id for the current interaction." ], "ai_engineer": { "summary": "Ensure every session token you generate includes a unique jti nonce and a binding claim. Never cache or reuse tokens — fetch a fresh token for each distinct interaction or session.", "actions": [ "Generate a cryptographically random UUID v4 jti claim for every token at issuance; never reuse jti values across invocations.", "Include a binding claim in the token payload: HMAC-SHA256(agent_id || instance_id || session_id, server_secret).", "Test replay prevention end-to-end: capture a token from a completed session and confirm it is rejected with 401 on resubmission." ], "failure_signals": [ "Tokens reused across multiple sessions or invocations in integration tests.", "Absent or static jti claims in issued tokens.", "Binding claim missing from token payload, allowing cross-agent token reuse in testing." ] }, "security_architect": { "summary": "Design the nonce validation architecture to prevent both replay and cross-agent binding attacks. The nonce store must be distributed with high availability so validation never becomes a latency bottleneck.", "actions": [ "Design the nonce store with a TTL-based expiry policy aligned to token lifetimes to prevent unbounded storage growth.", "Define the binding claim construction algorithm centrally and publish it as a shared library to prevent inconsistent implementations.", "Specify that replay attempts trigger a security alert in the SIEM (see AA-07) and initiate automatic token revocation for the affected agent instance." ], "failure_signals": [ "Nonce store unavailability causing validation to fall back to accepting any token.", "Inconsistent binding claim implementations across services allowing cross-service token reuse.", "Replay attempt logs not flowing to the SIEM for correlation with other authentication anomalies." ] }, "grc_auditor": { "summary": "Anti-replay is a critical assurance control for the agent authentication layer. Verify that nonce validation infrastructure is operational and that replay attempts are detected, logged, and responded to.", "actions": [ "Review the nonce store architecture documentation and confirm TTLs are correctly aligned with token lifetimes across all token classes.", "Request logs showing at least one replay attempt detection in the last 90 days, or confirm via a controlled replay test if none have occurred naturally.", "Confirm replay detection events are forwarded to the SIEM and correlated with agent identity records within the defined SLA." ], "metrics": [ "Replayed tokens reaching execution: target 0.", "Nonce store availability: target ≥99.9%.", "Replay attempt events forwarded to SIEM within 60 seconds: target 100%." ], "failure_signals": [ "No evidence of nonce validation in token-consuming endpoint code or configuration.", "Nonce store missing or disabled due to performance concerns.", "Replay attempt logs not appearing in the SIEM event stream within the defined latency window." ] }, "legal_counsel": { "summary": "Anti-replay controls determine whether the enterprise can disown actions performed with captured tokens. If a replayed token produces a harmful transaction, the presence or absence of binding controls will shape both liability and regulatory findings.", "actions": [ "Confirm the enterprise's fraud and unauthorized-transaction defenses reference session-binding controls for agent-initiated transactions.", "Verify replay-rejection events are logged and retained — they are exculpatory evidence that an attack was resisted.", "Assess notification obligations if replayed agent tokens are used against customer-facing systems." ], "failure_signals": [ "Harmful transactions executed with replayed agent tokens in scope of contracts that assumed effective session controls.", "No retained evidence distinguishing legitimate agent sessions from replayed ones after a dispute arises.", "Customer agreements promising transaction integrity controls that agent session handling does not actually provide." ] }, "platform_engineer": { "summary": "Build and operate the distributed nonce store as a shared platform service. Ensure high availability, consistent TTL management, and integration with the audit log pipeline.", "actions": [ "Deploy a Redis cluster or DynamoDB table as the nonce store with automatic TTL expiry and cross-region replication for high availability.", "Publish a nonce validation library that all token-consuming services import rather than implementing independently.", "Monitor nonce store write and read latency; ensure validation adds less than 5 ms to the request path at p99." ], "failure_signals": [ "Nonce store latency exceeding 5 ms at p99, prompting teams to disable validation for performance.", "TTL misconfigurations causing nonces to expire before token lifetime, creating false-positive rejections.", "Nonce store not replicated across availability zones, creating a single point of failure." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Anti-replay is standard in OAuth and OIDC flows but is not routinely applied to agent session tokens in current agentic frameworks." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant" ], "implementers": [ "AI Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 1.2", "fit": "partial", "rationale": "NIST AI RMF MANAGE 1.2 requires treatment of documented AI risks to be prioritized by impact, likelihood, and available methods. Token replay against multi-agent orchestration is a high-likelihood, well-understood risk with mature countermeasures; token binding and anti-replay controls are the prioritized treatment.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "adjacent", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) addresses agents exercising access beyond what was intended. Token binding prevents a captured session token from being replayed outside its bound context, closing one path by which an agent's effective agency silently expands.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "microsoft_rai", "requirement_id": "PS2 — Security Policy compliance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal PS2 requires security-policy compliance for AI systems. Session token binding and anti-replay controls are standard session-security policy applied to agent authentication, preventing captured tokens from being reused outside their bound context.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_600_1", "requirement_id": "MS-2.5", "fit": "adjacent", "rationale": "NIST AI 600-1 MS-2.5 addresses measurement and validation for generative AI system components. Session token binding provides a measurable integrity control that can be evaluated through controlled replay testing, fitting within the measurement-oriented security assurance framework of AI 600-1.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Permissions control requires that agent access be scoped and enforced so agents cannot act outside granted permissions. Session token binding enforces that scoping temporally: a captured token cannot be replayed outside the session and context it was bound to.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Service authentication (short-lived tokens); Part IV Phase 6 — Protect agent credentials (session-scoped tokens expire)", "fit": "partial", "rationale": "Short-lived/session-scoped tokens that expire limit replay windows. Partial: doc does not prescribe token binding / anti-replay nonce mechanics specifically.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-05", "validation_objective": "Every issued agent session token must carry a unique UUID v4 jti claim and a cryptographic binding claim derived from agent_id, instance_id, and session_id, and the receiving endpoint must reject any token whose jti has been recorded in the distributed nonce store within the token's lifetime window. The control passes when no replayed token reaches execution, the nonce store maintains ≥99.9% availability, and controlled replay tests produce HTTP 401 within the defined response window.", "evidence_required": [ "Token issuance log showing 100% of session tokens carry a UUID v4 jti claim and a binding claim for the past 30 days, with no repeated jti values across distinct issuances", "Nonce store configuration documentation showing TTL alignment with token lifetimes, cross-availability-zone replication, and 30-day availability metric", "Replay attempt log from a controlled replay test confirming HTTP 401 response and corresponding SIEM event within 60 seconds of the replay attempt", "Nonce store availability metric for the past 30 days confirming ≥99.9% uptime with no validation bypass events during downtime periods" ], "machine_tests": [ "Capture a valid session token from a completed transaction and resubmit it to the same endpoint — assert HTTP 401 with a replay rejection reason code in the response body", "Submit two sequential calls using a token with a static (constant) jti value — assert HTTP 401 on the second call", "Query the nonce store for the jti of a recently submitted token and confirm the record exists with a TTL correctly aligned to the token's remaining lifetime", "Submit a token with a binding claim whose agent_id does not match the session context established at the receiving endpoint and assert HTTP 401" ], "human_review": [ "Review the binding claim construction specification and confirm it binds agent_id, instance_id, and session_id to a server-side secret using HMAC-SHA256 or equivalent", "Inspect the nonce store TTL configuration and confirm it is set to token_exp minus token_iat plus 30-second clock skew tolerance for every token class in use", "Verify that the nonce validation library is a shared platform component imported by all token-consuming services rather than independently reimplemented per team" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using a predictable or sequential counter as the jti claim rather than a cryptographically random UUID v4, allowing an attacker to pre-compute nonces before they are consumed", "Disabling nonce validation during high-traffic periods or nonce-store maintenance windows and accepting tokens without jti check, silently opening a replay window during peak load", "Implementing nonce validation in per-instance application memory rather than a distributed nonce store, so replay protection only applies within a single server process and not across a load-balanced fleet", "Setting nonce store TTL to a fixed value such as one hour regardless of token lifetime class, creating a window where long-lived tokens can be replayed after their nonce expires but before the token itself expires" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-06", "layer": "AA", "plane": "control", "name": "Cross-System Authentication Chaining", "plain": "When an AI agent calls across multiple downstream services, APIs, or microservices, the original agent identity must be preserved and verifiable at each hop using standard token exchange protocols, and authorization scopes must be reduced — never expanded — as the call chain propagates.", "threat": { "tags": [ "confused-deputy", "identity-propagation-failure", "privilege-escalation", "token-amplification" ], "desc": "In multi-system agent workflows, intermediate services often re-authenticate to downstream systems using their own broad service account credentials, silently discarding the original agent identity. This confused-deputy pattern allows a compromised or prompt-injected agent to trigger high-privilege actions in downstream systems the original agent was never authorized to perform. Token amplification — where authorization scopes expand across hops — is the primary exploitation vector." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 3.1", "title": "Third-party AI risks monitored with documented controls" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control across multi-system workflows" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — scope expansion in multi-system calls" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AA-06 Cross-System Authentication Chaining control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement OAuth 2.0 Token Exchange (RFC 8693) for cross-system identity delegation. The original agent token is the subject_token; each intermediate service exchanges it for a narrower-scoped actor_token specific to the next hop. The original agent_id is preserved in the act claim throughout the chain. Each downstream service validates the full delegation chain before executing any action.", "steps": [ "Implement a token exchange service (or configure the authorization server) to support RFC 8693 token exchange with scope reduction enforcement: issued tokens must be a strict subset of the input token's scope.", "Encode the original agent_id in the act (actor) claim of every exchanged token so the terminal service can verify the origin of the request chain without ambiguity.", "Configure intermediate services to perform token exchange for each downstream call rather than using their own service account credentials; enforce this through service mesh policy.", "Audit the complete delegation chain at each terminal service: log the full act claim chain, all intermediate actor_ids, and the original subject agent_id alongside every action taken." ], "ai_engineer": { "summary": "When your agent calls a downstream service, use token exchange rather than presenting your top-level service account credentials. The downstream token must be narrower in scope than your current token.", "actions": [ "Integrate the RFC 8693 token exchange flow into the agent runtime library's downstream call abstraction so all agents use it automatically.", "Pass the original agent_id forward in the act claim on every token exchange — never strip identity context even for internal service calls.", "Write tests that confirm exchanged tokens have strictly narrower scopes than the input token." ], "failure_signals": [ "Downstream calls using the agent's top-level service account credentials rather than exchanged tokens.", "Token exchange resulting in tokens with equal or broader scope than the input token.", "act claim absent from exchanged tokens, breaking the delegation chain audit trail." ] }, "security_architect": { "summary": "Design the token exchange architecture to enforce scope reduction as an invariant. No token in a delegation chain should have broader scope than any predecessor in the chain.", "actions": [ "Implement scope intersection as a mandatory step in the token exchange service: the output scope must be the intersection of the requested scope and the input token scope.", "Define a maximum delegation depth (recommended: 5 hops) beyond which token exchange is rejected, to prevent runaway delegation chains.", "Require all services that are both callers and callees to implement symmetric token exchange: they accept scoped tokens from upstream and issue scoped tokens to downstream." ], "failure_signals": [ "Token exchange service permitting scope expansion under any input condition.", "No configured maximum delegation depth, allowing unbounded chain propagation.", "Services calling downstream using their own service account without performing token exchange." ] }, "grc_auditor": { "summary": "Cross-system identity chaining is an audit gap in most agentic deployments. Verify that terminal action logs contain the original agent identity, not just the last intermediate service identity.", "actions": [ "Sample 10 terminal action audit records from multi-system agent workflows; confirm the original agent_id is present in the act claim chain on every record.", "Review the token exchange service configuration and confirm scope reduction is enforced as an invariant.", "Check that delegation depth limits are configured and that no exception to the limit exists in production." ], "metrics": [ "Terminal action records with original agent_id traceable in the delegation chain: target 100%.", "Token exchange operations resulting in scope expansion: target 0.", "Delegation chains exceeding configured maximum depth: target 0." ], "failure_signals": [ "Terminal service audit logs showing only the last intermediate service identity, not the originating agent.", "Any token exchange event producing a token with broader scope than the subject_token.", "Multi-system workflows bypassing token exchange and using service account credentials directly." ] }, "legal_counsel": { "summary": "Cross-system identity chaining is the technical mechanism that supports legal accountability in multi-system AI workflows. In regulated industries, the ability to attribute a downstream action to its originating agent is a compliance requirement under GDPR, EU AI Act, and sector-specific regulations.", "actions": [ "Confirm with the technical team that the act claim chain provides an unbroken, non-repudiable attribution trail from any terminal action back to the originating agent identity.", "Review data processing agreements with downstream service providers to confirm they preserve and log the delegation chain context required for regulatory accountability.", "Assess whether delegation depth limits and scope reduction policies satisfy the proportionality requirements of applicable data protection and AI regulations." ], "failure_signals": [ "Inability to produce a complete delegation chain audit trail in response to a regulatory inquiry.", "Downstream service providers contractually disclaiming responsibility for logging agent identity context.", "Delegation chain gaps making it impossible to attribute a terminal action to its originating agent for GDPR data subject access request responses." ] }, "platform_engineer": { "summary": "You operate the token-exchange infrastructure that authentication chaining depends on. The exchange service is on the hot path of every cross-system agent action — it must be highly available, fast, and impossible to bypass.", "actions": [ "Deploy the token exchange service (RFC 8693) as a hardened, horizontally scaled component with p99 latency budgets, so teams have no performance excuse to bypass it.", "Enforce at the service mesh / gateway layer that downstream systems accept only exchanged, scope-reduced tokens — never the agent's original credential.", "Emit exchange events (subject, audience, scopes before/after) to the audit pipeline with the same durability guarantees as the systems they protect." ], "failure_signals": [ "Services accepting the originating agent token directly because the exchange path was slow or unavailable.", "Token exchange logs sampled or dropped under load, breaking the delegation chain record.", "Exchange service configuration allowing scope-preserving or scope-widening exchanges." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "RFC 8693 token exchange is well-specified but rarely implemented in agentic frameworks; most multi-agent systems use service account credentials throughout the call chain." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "federated-enterprise", "cloud-native", "high-risk-sector", "multi-tenant" ], "implementers": [ "AI Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 3.1", "fit": "partial", "rationale": "NIST AI RMF MANAGE 3.1 requires AI risks from third-party resources to be monitored, with risk controls applied and documented. Cross-system authentication chaining applies a documented control — token exchange with mandatory scope reduction — at exactly the boundaries where an agent's actions cross into systems operated by other teams or parties.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) directly addresses agents acquiring or exercising permissions beyond their intended scope. Token exchange with mandatory scope reduction is the transitive-boundary mitigation: effective permissions can only narrow as actions cross systems.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "eu_ai_act", "requirement_id": "Art. 13", "fit": "adjacent", "rationale": "EU AI Act Article 13 requires that high-risk AI systems provide sufficient transparency about their operation to allow for meaningful oversight. Cross-system identity chaining provides the technical substrate for this transparency by making the complete delegation chain of any AI action auditable and attributable.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "partial", "rationale": "ISO/IEC 42001 §8.1 requires operational processes affecting AI systems to be controlled and documented. Identity propagation with scope reduction across multi-system workflows is a controlled, auditable operational process at exactly the boundaries where control is usually lost.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 requires effective human oversight of system behavior. When agent actions cross system boundaries, oversight depends on the originating identity surviving the chain; token exchange with preserved provenance keeps multi-system actions attributable and therefore overseeable.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0012", "fit": "direct", "rationale": "MITRE ATLAS AML.T0012 (Valid Accounts) describes adversaries exploiting legitimate credentials to move laterally through ML system components. Token exchange with scope reduction limits lateral movement by ensuring that compromised intermediate agents cannot use their position in the chain to acquire broader permissions in downstream systems.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy and Autonomous Replication and Adaptation", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Research Categories track Long-range Autonomy and Autonomous Replication and Adaptation — capability classes whose core concern is AI systems acquiring privileges and resources beyond what was intended. AA-06's mandatory scope reduction at every cross-system boundary is the deployer-side control against exactly that expansion.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Permissions control requires scoped, enforceable agent permissions. AA-06 extends the permission boundary across system hops: token exchange with mandatory scope reduction ensures an agent's effective permissions can only narrow, never widen, as actions traverse services.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. It records agent activity within the platform boundary; it does not propagate identity across external systems. AA-06's token-exchange chain is the control that keeps attribution intact when agent actions leave the platform.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 — Explicit trust boundaries; Part II — Unscoped privilege inheritance (confused deputy)", "fit": "direct", "rationale": "Cross-system authentication chaining is the confused-deputy / unscoped-inheritance risk; doc requires verifying identity and authorization at each hop rather than trusting the initiating agent.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-06", "validation_objective": "Every multi-system agent call chain must propagate the original agent_id in the RFC 8693 act claim through every token exchange hop with strictly narrowing scope at each exchange, and the delegation depth must not exceed the configured maximum. The control passes when 100% of sampled terminal service action records contain the originating agent_id in a complete, unbroken delegation chain.", "evidence_required": [ "Terminal service action audit records from a 30-day sample showing the complete RFC 8693 act claim chain with originating agent_id present on 100% of multi-system workflow records", "Token exchange service configuration export confirming scope intersection enforcement as an invariant (output scope ⊆ input scope) with no exception conditions or override flags", "Maximum delegation depth configuration document with enforcement evidence showing no production call chain exceeded the configured limit in the past 30 days", "Service mesh or API gateway policy export showing token exchange is required at all intermediate service boundaries with no service-account bypass path permitted" ], "machine_tests": [ "Execute a 3-hop agent workflow and query the terminal service audit log — assert the original agent_id appears in the act claim chain on the terminal record with no identity gaps", "Attempt a token exchange requesting a scope superset of the subject_token scope and assert the exchange service rejects the request with a scope validation error", "Simulate a delegation chain that exceeds the configured maximum depth and assert the token exchange service rejects the request at the depth limit", "Configure a test intermediate service to bypass token exchange and call downstream with its own service account — confirm the terminal audit record lacks the original agent_id and that the bypass pattern is detectable" ], "human_review": [ "Review the token exchange service scope reduction logic and confirm it computes the strict intersection of requested scope and subject_token scope for all scope formats in use, with no additive operations permitted", "Verify that downstream service contracts or data processing agreements require logging the full act claim chain to support audit attribution under applicable regulatory frameworks", "Inspect the maximum delegation depth configuration and confirm it has been validated against the deepest observed production multi-system workflow with documented headroom" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Intermediate services re-authenticating to downstream systems using their own broad service account credentials rather than performing RFC 8693 token exchange, silently discarding the original agent identity at every hop", "Configuring the token exchange service to issue tokens with the same scope as the subject_token (union or copy) rather than the intersection, allowing permission accumulation across a multi-hop call chain", "Preserving the act claim in token payloads but not validating it at terminal services, treating identity propagation as an audit trail feature rather than an enforceable authorization input used in access decisions", "Applying RFC 8693 token exchange only for external API calls while using internal service accounts for microservice-to-microservice calls, creating an identity propagation blind spot within the internal service mesh" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-07", "layer": "AA", "plane": "control", "name": "Authentication Failure Monitoring and Alerting", "plain": "All AI agent authentication events — including failures, anomalies, and unusual patterns — must be collected, analyzed in near-real-time, and trigger automated alerts when authentication failure rates, credential usage patterns, or geographic anomalies exceed defined behavioral thresholds.", "threat": { "tags": [ "credential-stuffing", "authentication-bypass", "anomalous-auth-pattern", "brute-force-auth" ], "desc": "Authentication failures that go unmonitored provide cover for credential stuffing campaigns, systematic authentication bypass attempts, and slow-burn credential exfiltration through log analysis. An agent whose credentials have been compromised may exhibit subtle authentication pattern changes — calls from unexpected sources, at unusual times, or with unusually high frequency — that are only detectable through behavioral baselining and anomaly detection." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE 2.4", "title": "Production monitoring of AI system functionality and behavior" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, analysis, and evaluation of AI system operations" }, { "id": "mitre_atlas", "section": "AML.T0012", "title": "Valid Accounts — detection of credential misuse through authentication monitoring" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AA-07 Authentication Failure Monitoring and Alerting control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Forward all agent authentication events to a central SIEM. Establish per-agent behavioral baselines using 30-day rolling windows. Alert on: failure rate exceeding 10% over any 5-minute window, authentication from a source IP not seen in the baseline window, impossible geographic travel between consecutive authentications, and token presentation outside normal operating hours by more than 3 standard deviations.", "steps": [ "Instrument every authentication point (tool endpoints, API gateways, mTLS terminators, workload identity issuers) to emit structured authentication events: agent_id, auth_method, source_ip, verdict, timestamp, credential_id.", "Route authentication events to the central SIEM within 30 seconds of occurrence; configure retention for at least 90 days for near-term investigation and 1 year for compliance requirements.", "Build per-agent behavioral baselines over a 30-day rolling window; configure anomaly detection rules for: failure rate spikes, new source IP, impossible geographic travel, and off-hours usage.", "Define automated response playbooks for each alert type: auto-suspend agent on critical anomaly, notify security operations, and create an investigation ticket with authentication evidence attached." ], "ai_engineer": { "summary": "Ensure your agent emits structured, queryable authentication events for every authentication attempt, including the credential identifier used. Do not suppress or aggregate authentication failure events in the agent runtime.", "actions": [ "Emit a structured JSON authentication event on every attempt: agent_id, instance_id, auth_method, credential_id, source_ip, target_service, verdict, and ISO 8601 timestamp.", "Do not retry authentication silently on failure — surface each failure as a distinct event and let the monitoring layer determine the response.", "Test that authentication failure events from your agent appear in the SIEM within 30 seconds using a controlled failure test in the staging environment." ], "failure_signals": [ "Authentication events missing from the SIEM for any agent instance during a test period.", "Agent runtime suppressing or batching authentication failure events, delaying detection.", "credential_id absent from authentication events, preventing credential-level anomaly correlation." ] }, "security_architect": { "summary": "Design the monitoring architecture to provide full coverage across all authentication methods (JWT, mTLS, workload identity) used in the agent layer. A single canonical authentication event schema across all methods is essential for effective correlation.", "actions": [ "Define a canonical authentication event schema for all AA-layer authentication methods; require all authentication points to normalize to this schema before forwarding to the SIEM.", "Configure SIEM correlation rules that join authentication events with the agent identity registry so anomalies are contextualized with agent metadata and ownership.", "Establish alert thresholds collaboratively with the AI engineering team using observed baseline data — never use generic thresholds that generate excessive noise." ], "failure_signals": [ "Multiple incompatible authentication event formats reaching the SIEM, preventing effective correlation.", "Alert thresholds set without baseline data, generating more than 50 false positive alerts per day.", "SIEM not receiving authentication events from mTLS termination points or workload identity issuance services." ] }, "grc_auditor": { "summary": "Authentication monitoring is the detective control that validates all preventive AA-layer controls are operating correctly. Verify that monitoring coverage is complete and that alerts are responded to within SLA.", "actions": [ "Review SIEM coverage reports and confirm authentication events are flowing from 100% of registered agent authentication points.", "Sample 5 recent authentication anomaly alerts and trace each from alert to investigation ticket to resolution; confirm mean time to acknowledge meets the defined SLA.", "Verify that authentication event retention meets the 90-day near-term and 1-year compliance retention requirements." ], "metrics": [ "Authentication event coverage across registered agent authentication points: target 100%.", "Mean time to acknowledge authentication anomaly alert: target ≤15 minutes.", "False positive alert rate: target ≤5% of total authentication alerts.", "Authentication event retention compliance: target 100%." ], "failure_signals": [ "Authentication events not reaching the SIEM from any registered agent authentication point.", "Authentication anomaly alerts going unacknowledged beyond the defined SLA.", "No documented alert threshold tuning process, resulting in chronic high false-positive rates." ] }, "legal_counsel": { "summary": "Authentication failure monitoring creates the record showing the enterprise watched for credential abuse — evidence of ongoing due diligence that matters when an incident occurs despite controls. Silence in the logs is indefensible; alerts that were ignored are worse.", "actions": [ "Confirm alert-handling procedures document who must respond to agent authentication anomalies and within what timeframe, so ignored alerts do not become negligence evidence.", "Verify monitoring records are retained to the same standard as other security evidence relied on in audits and certifications.", "Assess whether patterns of failed agent authentication targeting regulated systems trigger reporting duties before any confirmed compromise." ], "failure_signals": [ "Documented alerts on anomalous agent authentication with no recorded response — discoverable evidence of ignored warnings.", "Monitoring coverage gaps for exactly the agent identities with access to regulated data.", "Retention of authentication monitoring records shorter than the periods for which security effectiveness must be demonstrated." ] }, "platform_engineer": { "summary": "Build the authentication event pipeline as a platform service: normalized event collection, SIEM forwarding, and baseline computation infrastructure shared across all agent teams.", "actions": [ "Deploy a centralized log aggregation pipeline (Fluentd, Vector, or equivalent) with the canonical authentication event schema as a required normalization layer before SIEM ingestion.", "Implement per-agent baseline computation using a streaming analytics platform; publish baseline metrics to a dashboard accessible to security operations.", "Ensure the authentication event pipeline is resilient: buffer events locally if the SIEM is unavailable and replay on reconnection with zero event loss." ], "failure_signals": [ "Authentication events lost during SIEM maintenance windows due to absent local buffering.", "Per-agent baseline computation not updated after significant agent behavior changes such as new deployment regions.", "Authentication event pipeline latency exceeding 30 seconds, delaying anomaly detection." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "General authentication monitoring exists in most enterprises, but per-agent behavioral baselining and AI-specific anomaly rules are not yet standard practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "Platform Engineering", "AI Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE 2.4", "fit": "direct", "rationale": "NIST AI RMF MEASURE 2.4 requires the functionality and behavior of the AI system and its components to be monitored when in production. Authentication failure monitoring with per-agent baselines implements this production-monitoring requirement at the agent identity layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "direct", "rationale": "ISO 42001 §9.1 requires organizations to determine what needs to be monitored and measured to demonstrate AI system performance. Authentication monitoring with per-agent behavioral baselines provides the measurement infrastructure required to evaluate authentication control effectiveness over time.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12", "fit": "direct", "rationale": "EU AI Act Article 12 requires high-risk AI systems to maintain logs enabling post-market monitoring and investigation of incidents. Authentication event logging with structured, queryable records and 1-year retention satisfies this requirement for the agent authentication layer.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0012", "fit": "direct", "rationale": "MITRE ATLAS AML.T0012 (Valid Accounts) describes adversaries using legitimate or captured credentials to access ML system components. Per-agent behavioral baselining provides early detection of this technique by identifying deviations from normal credential usage patterns before full exploitation is achieved.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "MS-2.5", "fit": "adjacent", "rationale": "NIST AI 600-1 MS-2.5 addresses ongoing measurement and monitoring for AI system components. The behavioral baselining and anomaly detection infrastructure developed for authentication monitoring aligns with the measurement-oriented assurance approach recommended for generative AI deployments.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard — misuse detection and rapid response", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. Its ASL-3 Deployment Standard pairs deployment safeguards with monitoring and rapid response to observed misuse. AA-07 establishes the same detection-and-response posture for agent authentication anomalies, so that credential misuse is detected while intervention is still possible.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "direct", "rationale": "Google SAIF element 2 explicitly requires extending detection and response to AI system components. Authentication failure monitoring with per-agent behavioral baselines brings agent identity events into the organization's detection and alerting pipeline.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires ongoing monitoring, feedback, and evaluation of deployed systems. Authentication failure monitoring with per-agent baselines implements RS3 at the agent identity layer, surfacing credential misuse and anomalous authentication patterns for evaluation.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. Those logs are an event source that monitoring can consume; per-agent authentication baselining and alerting, as AA-07 requires, are built on top of such sources rather than provided by the Trust Layer itself.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Anomaly detection (alert when thresholds exceeded)", "fit": "partial", "rationale": "Threshold-based alerting covers authentication-failure spikes as an anomaly signal. Partial: doc does not call out authentication-failure monitoring as a distinct control.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-07", "validation_objective": "All agent authentication events must reach the central SIEM within 30 seconds of occurrence with 100% coverage across registered authentication points, and automated alerts must fire within 60 seconds when per-agent failure rates exceed 10% over any 5-minute window or behavioral baselines deviate beyond defined thresholds. The control passes when mean time to acknowledge is ≤15 minutes and false-positive alert rate is ≤5%.", "evidence_required": [ "SIEM coverage report showing structured authentication events flowing from 100% of registered agent authentication points (tool endpoints, API gateways, mTLS terminators, workload identity issuers) for the past 30 days", "Per-agent behavioral baseline configuration showing 30-day rolling window computation with alert thresholds derived from observed baseline data for each agent", "Sample of 5 authentication anomaly alerts from the past 90 days with linked investigation tickets and resolution records confirming ≤15-minute mean time to acknowledge", "Authentication event retention policy and compliance evidence confirming 90-day queryable near-term retention and 1-year archival retention across all event sources" ], "machine_tests": [ "Inject a burst of 10 failed authentication attempts for a canary agent within a 5-minute window and confirm an alert is generated in the SIEM and acknowledged within 60 seconds", "Submit a canary agent authentication event from a source IP not present in the agent's 30-day baseline and confirm an anomaly alert fires", "Query the SIEM for authentication events from each registered agent authentication point over the past 24 hours and assert zero coverage gaps across all points", "Block SIEM connectivity for 60 seconds while injecting authentication events and confirm all events are buffered and replayed with zero loss upon reconnection" ], "human_review": [ "Review per-agent alert threshold configuration and confirm each threshold was derived from observed baseline data rather than generic defaults, with a documented tuning process", "Inspect the automated response playbook for critical authentication anomalies and confirm agent auto-suspension, security operations notification, and investigation ticket creation steps are each tested at least quarterly", "Verify the SIEM correlation rules join authentication events with the agent identity registry so each anomaly alert includes agent metadata, ownership, and associated controls as context", "Sample the past 90 days of stored authentication event records and confirm they are queryable by agent_id, credential_id, source_ip, and verdict without data gaps or early deletion" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Applying generic authentication monitoring thresholds not calibrated to per-agent behavioral baselines, generating false-positive rates above 5% that cause security operations teams to suppress or ignore agent authentication alerts", "Collecting authentication failure events only at the API gateway layer while omitting mTLS termination points and workload identity issuance services, creating detection blind spots for the most targeted authentication mechanisms", "Deploying monitoring without defining or testing automated response playbooks, so the control produces detection signals but has no operational response path and anomalies go unacted upon within SLA", "Batching or aggregating authentication failure events in the agent runtime before forwarding to the SIEM pipeline, introducing multi-minute delays that obscure the real-time pattern signatures of credential stuffing and brute-force attacks" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AA-08", "layer": "AA", "plane": "lifecycle", "name": "Agent Authentication Evidence Package", "plain": "The AA-layer evidence package compiles structured, timestamped, hash-linked attestation artifacts from AA-01 through AA-07 into a single signed evidence package that demonstrates the agent authentication controls are implemented, tested, and current — suitable for regulatory submission, audit response, and cross-domain attestation.", "threat": { "tags": [ "evidence-gap", "audit-failure", "compliance-accountability-gap", "authentication-drift" ], "desc": "Without a compiled evidence package, authentication controls that exist in code may have no corresponding operational evidence — no test records, no configuration snapshots, no incident response confirmations. Regulatory inquiries and audit events then require emergency evidence collection under time pressure, increasing the likelihood of gaps and misrepresentations. Authentication drift — controls degrading between review cycles — is undetectable without a cadenced evidence compilation process." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 4.2", "title": "Documentation and communication of AI risks and impacts" }, { "id": "iso_42001", "section": "§9.2", "title": "Internal audit — evidence of conformity to AI management controls" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management system documentation for high-risk AI" } ], "sources": [ { "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-29", "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://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AA-08 Agent Authentication Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Produce a BehavioralAttestation (AG-08) evidence package on a quarterly cadence or triggered by any AA-layer control change or incident. The package includes: control status snapshot for AA-01 through AA-07, test execution records with pass/fail verdicts, configuration snapshots with SHA-256 hashes, incident and anomaly summaries from AA-07, and a signed attestation record with Ed25519 signature from the responsible reviewer.", "steps": [ "Define the evidence collection runbook for each control AA-01 through AA-07: specify the exact artifacts, queries, or exports that constitute evidence for each control, the freshness window, and the responsible owner.", "Implement automated evidence collection for machine-readable artifacts (audit log exports, configuration snapshots, CI/CD test results); document the manual evidence steps for items requiring human judgment.", "Compile all artifacts into a structured evidence bundle: a JSON index with artifact paths, SHA-256 hashes, collection timestamps, and control-to-artifact mappings; sign the index with the reviewer's Ed25519 key.", "Store the evidence package in an append-only evidence repository with immutable object retention for the compliance period (aligned to EU AI Act retention obligations: technical documentation kept for 10 years under Article 18; automatically generated logs kept at least six months under Articles 19 and 26(6)); record the package_id and hash in the cross-domain attestation registry." ], "ai_engineer": { "summary": "Your contribution to the evidence package is test execution records and configuration exports. Maintain CI/CD pipelines that produce machine-readable test results for AA-01 through AA-05 assertions on every deployment.", "actions": [ "Ensure CI/CD pipelines produce JUnit XML or equivalent test result files for all AA-layer authentication control tests on every main branch merge.", "Generate a configuration snapshot export (JSON) of the agent assertion schema, token lifetime configurations, and nonce store settings at each deployment; include a SHA-256 hash of the snapshot.", "Tag all AA-layer test artifacts with the control IDs they evidence (e.g., 'AA-01', 'AA-05') for automated evidence bundle assembly." ], "failure_signals": [ "CI/CD pipelines not producing machine-readable test result artifacts for AA-layer controls.", "Configuration snapshots missing from recent deployments.", "Test artifacts not tagged with control IDs, requiring manual evidence mapping at audit time." ] }, "security_architect": { "summary": "Define the evidence architecture: what constitutes sufficient evidence for each AA-layer control, how evidence is signed, and how the evidence package integrates with the broader cross-domain attestation infrastructure.", "actions": [ "Author an evidence taxonomy for the AA layer: for each control, specify the minimum evidence artifacts, their acceptable age (freshness window), and the evaluation criteria for pass/fail/conditional verdicts.", "Define the signing ceremony: who holds the Ed25519 signing key, what attestation statement they are endorsing, and under what conditions the attestation verdict can be 'pass' versus 'conditional'.", "Integrate the AA evidence package into the BehavioralAttestation (AG-08) cross-domain attestation schema." ], "failure_signals": [ "No documented evidence taxonomy specifying minimum artifacts per control.", "Evidence package signed without a defined attestation statement, making the signature meaningless.", "AA evidence not integrated into the cross-domain attestation registry." ] }, "grc_auditor": { "summary": "The evidence package is your primary audit artifact for the AA layer. Verify that it covers all seven AA-layer controls, all artifacts are within defined freshness windows, and the package is signed by an accountable and authorized reviewer.", "actions": [ "Review the most recent AA evidence package index; confirm artifacts exist for each of AA-01 through AA-07 with collection timestamps within the defined freshness window.", "Verify the Ed25519 signature on the package index against the reviewer's registered public key and confirm the reviewer's identity matches the assigned control owner.", "Trace 3 evidence artifacts from the index to their source systems (SIEM, CI/CD, secrets manager) to confirm the artifacts are genuine and unmodified." ], "metrics": [ "AA-layer controls with current evidence artifacts in the most recent package: target 100%.", "Evidence packages produced on quarterly cadence without gaps: target 100%.", "Evidence packages with valid Ed25519 signature from an authorized reviewer: target 100%.", "Evidence artifact freshness compliance (within defined freshness window): target 100%." ], "failure_signals": [ "Any AA-layer control with no corresponding evidence artifact in the current package.", "Evidence package older than 90 days with no interim update despite AA-layer control changes or incidents.", "Evidence package lacking a valid cryptographic signature or signed by an unauthorized key." ] }, "legal_counsel": { "summary": "The evidence package is the legal record of authentication control compliance. For EU AI Act high-risk AI systems, the quality management documentation requirements of Article 17 require that this package be produced, retained, and made available to national competent authorities on request.", "actions": [ "Confirm with the GRC team that the evidence package retention period meets the minimum regulatory retention requirement for all applicable jurisdictions (EU AI Act: 10 years for technical documentation under Article 18; at least six months for automatically generated logs under Articles 19 and 26(6), or longer where other applicable law requires).", "Review the attestation statement in the package to confirm it makes only claims supportable by the enclosed artifacts and does not overstate control effectiveness.", "Assess whether the evidence package format and content would satisfy a data protection authority inquiry or notified body assessment under EU AI Act supervisory procedures." ], "failure_signals": [ "Evidence package retention shorter than the applicable EU AI Act obligations (10-year technical documentation under Article 18; six-month minimum log retention under Articles 19 and 26(6)), creating regulatory exposure for historical compliance claims.", "Attestation statement containing claims not supported by the enclosed artifacts.", "Evidence package format not understandable by a non-technical regulatory reviewer without significant expert interpretation." ] }, "platform_engineer": { "summary": "Build the evidence collection and bundle assembly automation so the quarterly evidence package is largely machine-assembled, requiring human review and signature only at the final attestation step.", "actions": [ "Deploy an evidence collection pipeline that fetches machine-readable artifacts from the SIEM, CI/CD, secrets manager, and certificate inventory on a scheduled basis aligned to the quarterly evidence cadence.", "Implement the evidence bundle assembler: constructs the JSON index, computes SHA-256 hashes for all artifacts, and prepares a signing request for the responsible reviewer.", "Store the assembled evidence bundle in the append-only evidence repository with immutable object storage (S3 Object Lock, GCS Object Hold) for the compliance retention period." ], "failure_signals": [ "Evidence collection pipeline failing silently, producing a bundle with missing artifacts discovered only at audit time.", "Mutable evidence storage allowing artifact modification after the bundle is signed.", "No automated notification to the responsible reviewer when the bundle is ready for signature." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Formal compliance evidence packages for AI agent authentication are not yet standard practice; most organizations rely on ad-hoc audit response rather than pre-assembled, signed evidence packages." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "GRC / Compliance", "AI Engineering", "Security Operations" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 4.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 4.2 requires organizational teams to document the risks and impacts of the AI technology they deploy and to communicate about them. The authentication evidence package is that documentation for the agent identity layer: structured, signed, and reviewable.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§9.2", "fit": "direct", "rationale": "ISO 42001 §9.2 requires internal audits to produce evidence of conformity to AI management system requirements. The AA evidence package provides the structured evidence artifacts required by internal and external auditors to evaluate authentication control conformity against the ISO 42001 standard.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Article 17 requires high-risk AI system providers to maintain a quality management system including documented evidence of the implementation and testing of risk management measures. The AA evidence package fulfills this requirement for the agent authentication layer with immutable retention.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require documented processes and review artifacts demonstrating responsible operation. The agent authentication evidence package is the documented artifact demonstrating that identity controls were implemented, tested, and reviewed.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 5 — Adapt controls to adjust mitigations and create faster feedback loops", "fit": "adjacent", "rationale": "Google SAIF element 5 (Adapt controls) centers on feedback loops that keep mitigations current. A quarterly authentication evidence package institutionalizes that loop: control effectiveness is measured, documented, and fed back into control tuning.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3) — documented capability and safeguard evidence", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3 (Risk Reports) requires documented reports describing capability findings and the safeguards applied before deployment decisions are made. AA-08 applies the same evidence-before-assurance discipline to agent authentication: claims of control effectiveness must be backed by a compiled, reviewable evidence package.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Capabilities and Safeguards Reports (§3–§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. The framework's Capabilities Reports (§3) and Safeguards Reports (§4) make documented evidence the basis for deployment decisions. AA-08 applies the same evidence-artifact discipline to agent authentication controls.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. Retained audit records of this kind are one evidence input for compliance reporting; AA-08's signed, structured evidence package is assembled by the enterprise from such inputs.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AA-08", "validation_objective": "Prove that all seven AA-layer authentication controls (AA-01 through AA-07) have been implemented, tested, and remain operationally current by producing a cryptographically signed, hash-linked evidence package on a defined quarterly cadence. The signed package must be verifiable as tamper-evident and confirmed as stored in immutable storage before any deployment promotion is permitted.", "evidence_required": [ "Signed evidence package file (Ed25519 signature over sha256 hash manifest) referencing and hash-linking artifacts from AA-01 through AA-07", "CI/CD pipeline test records for AA-01 through AA-07 controls, timestamped within the reporting quarter", "Configuration snapshots for authentication infrastructure (mTLS certs, JWT signing keys, SPIFFE trust bundles) as of package compilation date", "Immutable storage receipt or write-once audit log confirming package persistence after signing", "SIEM/anomaly detection performance metrics and incident log excerpts satisfying the AA-07 evidence requirement within the package" ], "machine_tests": [ "Verify Ed25519 signature on the evidence package validates against the organization's registered signing key", "Assert sha256 hash of each included artifact matches the corresponding entry in the package manifest", "Check package compilation timestamp is within the last 90 days relative to the attestation assertion date", "Confirm the package contains canonical_id references for all seven AA-layer controls with non-empty artifact pointers" ], "human_review": [ "Verify that included artifacts are substantive and not stub or placeholder files — test records must reflect actual test execution", "Assess whether incident response records in the AA-07 section reflect genuine operational events rather than fabricated log entries", "Confirm the signing key identity matches the organization's registered key in the Apeiris domain registry and has not expired" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Producing an evidence package that references artifact paths without embedding hashes or verifiable links to the artifacts themselves", "Signing the package with a development or CI key not registered in the production identity store", "Including configuration snapshots that are outdated relative to the currently deployed authentication infrastructure", "Treating the quarterly cadence as optional in the absence of active regulatory inquiry rather than as a continuous assurance obligation" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AA" }, { "id": "AB-01", "layer": "AB", "plane": "control", "name": "Authorized Action Scope Manifest", "plain": "Every deployed agent must maintain a machine-readable manifest declaring the exact set of actions it is authorized to take, linked to its registry entry, owner, and version. Execution of any action not listed in the manifest must be blocked at the enforcement layer.", "threat": { "tags": [ "unauthorized-action", "scope-creep", "privilege-escalation", "capability-drift" ], "desc": "Agents without explicit action scope declarations accumulate implied permissions over time. Developers add capabilities without governance review, and the effective permission set drifts beyond what was originally authorized. An attacker who influences agent behavior can trigger actions the enterprise never intended to permit, since no manifest boundary exists to enforce against." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 1.2", "title": "Trustworthy-AI characteristics integrated into organizational policies" }, { "id": "eu_ai_act", "section": "Article 9(2)", "title": "Risk management system for high-risk AI" }, { "id": "iso_42001", "section": "§6.1.3", "title": "AI risk treatment" }, { "id": "microsoft_rai", "section": "RS1", "title": "Reliability and safety guidance — defined safe operational envelope" } ], "sources": [ { "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-29", "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://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-02" }, { "id": "mitre_atlas_v4", "title": "MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems v4", "authority": "MITRE Corporation", "source_type": "framework", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2024-05-01", "retrieved_on": "2026-06-29", "canonical_url": "https://atlas.mitre.org/", "license": "open-access", "status": "current", "flagship": false, "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems v4 requirements informing the apeiris://agentic/controls/AB-01 Authorized Action Scope Manifest control.", "reviewed_on": "2026-07-02" }, { "id": "databricks_omnigent_2026", "title": "Databricks Omnigent — 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 session-scoped write confinement (writes limited by default to documents the agent created during the session) illustrates enforcement-layer blocking of out-of-scope actions — a runtime complement to a declared action-scope manifest, not the manifest itself.", "reviewed_on": "2026-07-07" } ], "implementation": { "pattern": "Manifest-first deployment: each agent ships with a signed JSON/YAML action scope manifest (ASM) declaring permitted action types, target resource classes, parameter constraints, and a hash linking to the registry entry. The runtime enforcement layer validates every action invocation against the ASM before execution.", "steps": [ "Define the ASM schema with required fields: action_type, allowed_targets, parameter_constraints, max_concurrency, and registry_entry_ref.", "Integrate ASM signing into the CI/CD pipeline so agents cannot be deployed without a valid, signed manifest.", "Deploy a runtime enforcement sidecar or gateway that validates every agent action call against the ASM and logs violations.", "Implement an ASM version control process requiring re-authorization for any capability additions.", "Configure alerting for any action blocked by ASM enforcement to trigger immediate security review." ], "ai_engineer": { "summary": "The ASM is the authoritative behavioral contract for the agent. Design agent code to request actions declaratively so the enforcement layer can validate them before execution.", "actions": [ "Instrument all agent tool calls to pass through the ASM enforcement middleware.", "Write unit tests that verify blocked actions are rejected and logged correctly.", "Version the ASM alongside agent code in the same repository and require approval workflows for scope changes." ], "failure_signals": [ "Actions executed by the agent that are not present in its ASM.", "ASM version mismatch between deployed agent and registry entry.", "CI/CD pipeline allowing deployment without a signed ASM." ] }, "security_architect": { "summary": "The ASM provides the enforcement boundary that prevents agents from acting outside their authorized scope. Design the enforcement layer as a mandatory, non-bypassable gateway.", "actions": [ "Design the enforcement gateway as a mandatory intercept point with no admin bypass.", "Establish ASM change management policy requiring security sign-off for scope expansions.", "Integrate ASM violation events into the SIEM for anomaly detection." ], "failure_signals": [ "Enforcement gateway deployed in monitor-only mode without blocking enforcement.", "ASM updates applied without change management approval.", "Gap between ASM-declared scope and actual agent capability observed in testing." ] }, "grc_auditor": { "summary": "The ASM is the primary evidence artifact demonstrating that agent capability is bounded, authorized, and reviewed. Audit completeness and version accuracy.", "actions": [ "Request ASM exports for all deployed agents and cross-reference against the agent registry.", "Verify ASM signatures match the provisioned signing key for each agent.", "Sample action logs and confirm all executed actions are listed in the current ASM version." ], "metrics": [ "ASM coverage rate: percentage of deployed agents with a valid, signed manifest — target 100%.", "ASM staleness rate: percentage of manifests not reviewed within the policy window — target 0%.", "ASM violation rate: actions blocked per 10,000 invocations — tracked as a risk indicator." ], "failure_signals": [ "Any deployed agent without a current, signed ASM.", "ASM not updated following agent capability change.", "Enforcement gateway not blocking violations in production." ] }, "legal_counsel": { "summary": "The Action Scope Manifest is the enterprise's documented statement of what an agent was authorized to do. In any dispute over an agent's harmful action, the signed manifest is the first artifact that establishes whether the action was sanctioned or a control failure.", "actions": [ "Confirm each production agent has a signed, versioned manifest and that manifest approval authority is documented — an unsigned or informal scope is not a defensible authorization record.", "Verify manifests for agents touching regulated processes align with the legal basis and permissions the enterprise actually holds for those processes.", "Ensure manifest versions are retained immutably so the scope in force at the time of a disputed action can be proven." ], "failure_signals": [ "Agents operating with no manifest, or with manifests that were never formally approved by an identifiable authority.", "A disputed agent action for which the enterprise cannot produce the scope document in force at execution time.", "Manifests authorizing actions the enterprise has no legal basis to perform on the affected data or systems." ] }, "platform_engineer": { "summary": "The ASM enforcement layer must be embedded in the deployment platform as a non-optional runtime control, not a per-agent configuration choice.", "actions": [ "Build ASM validation into the agent deployment pipeline as a required gate.", "Deploy the enforcement sidecar as a platform-managed component that agents cannot disable.", "Provide tooling for developers to test their ASM against sample action traces before deployment." ], "failure_signals": [ "Enforcement sidecar not present on deployed agent instances.", "ASM schema validation errors not failing deployment pipeline.", "No tooling available for ASM pre-deployment testing." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises deploy agents with implicit capability assumptions rather than explicit, machine-readable scope declarations." }, "capability_risk": { "capability_level": "limited" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI/Agent Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 1.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.2 requires trustworthy-AI characteristics to be integrated into organizational policies, processes, and practices. A signed Action Scope Manifest turns the policy statement of what an agent may do into a machine-enforceable artifact, integrating the safe-operation policy into deployment practice itself.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 9(2)", "fit": "direct", "rationale": "The EU AI Act requires high-risk AI systems to implement risk management systems including identification and analysis of foreseeable risks associated with intended use. A signed ASM constitutes the operational manifestation of the intended-use boundary required by Article 9.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§6.1.3 — AI risk treatment", "fit": "direct", "rationale": "ISO/IEC 42001 §6.1.3 requires the organization to select and implement AI risk treatment options and produce a risk treatment plan. The Action Scope Manifest is an implemented treatment for the excessive-agency risk identified during AI risk assessment: permitted actions are made explicit and machine-enforceable.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1 — Reliability and safety guidance", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 requires teams to define the system's safe operational envelope and design it to operate reliably within it. A signed Action Scope Manifest is that envelope made machine-enforceable: the agent's permitted actions are declared, approved, and enforced.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Permissions control requires that what an agent is allowed to do be explicitly granted and enforced. The signed Action Scope Manifest is a portable implementation of that grant: permitted actions are declared, approved, and machine-enforced at runtime.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy research category tracks the risk of AI systems independently pursuing objectives over extended horizons. A signed, enforced action scope manifest is the deployer-side bound on that autonomy: an agent can act only within an explicitly declared envelope.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. The record gives Salesforce-hosted agents an activity log against which declared action scope can be checked after the fact; it does not itself declare or enforce scope, which is AB-01's function.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "mitre_atlas", "requirement_id": "AML.M0015 — Adversarial Input Detection", "fit": "adjacent", "rationale": "MITRE ATLAS mitigation AML.M0015 (Adversarial Input Detection) recommends detecting and blocking adversarial inputs before they drive model or tool behavior. An enforced action scope manifest gives that detection a precise decision boundary: any requested action outside the signed manifest is rejected and flagged.", "normative_force": "best-practice", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 — Approved/prohibited actions; Part IV Phase 3 — Scope limits / Least Agency", "fit": "direct", "rationale": "Doc requires writing down permitted/denied actions and enforcing them at a granular permission level (deny by default) — the authorized action scope manifest.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "direct", "rationale": "AB-01 confines each agent to a machine-readable manifest of its authorized actions and blocks anything outside it, the least-privilege posture AI Exchange requires for the model/agent.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every deployed agent has a machine-readable action scope manifest enumerating…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every deployed agent has a machine-readable action scope manifest enumerating…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every deployed agent has a machine-readable action scope manifest enumerating…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-01", "validation_objective": "Prove that every deployed agent has a machine-readable action scope manifest enumerating its complete authorized action set, and that the platform enforcement layer blocks any attempt to execute an action not listed in the manifest. No action outside the manifest may execute without a manifest update that passes governance review.", "evidence_required": [ "Machine-readable action scope manifest (JSON or YAML) signed and linked to the agent's registry entry with a version-matched reference", "Platform enforcement log showing at least one blocked out-of-manifest action attempt during the test period, or a probed block event from a compliance test", "Change history records for the manifest showing governance review approvals and approver identities for each scope expansion", "Agent registry entry with version identifier that matches the manifest reference exactly" ], "machine_tests": [ "Attempt to invoke an action not listed in the agent's manifest and assert the enforcement layer returns a block response with an appropriate error code", "Verify the manifest is well-formed, signed, and references a valid agent registry entry with a matching version hash", "Assert that no undocumented actions appear in recent agent execution logs by diffing the log action set against the manifest", "Confirm the manifest is stored outside the agent container and cannot be modified by the agent identity at runtime" ], "human_review": [ "Review whether the manifest accurately reflects the agent's actual operational requirements without excess scope beyond what the deployment use case requires", "Confirm that governance review records for scope expansions include identified approvers, timestamps, and documented rationale", "Assess whether the manifest boundary would prevent the unauthorized-action and capability-drift scenarios identified in the control's threat model" ], "blocking_effect": "blocks-runtime-action", "normative_status": "industry-framework", "anti_patterns": [ "Defining the manifest with wildcard or glob action patterns that implicitly authorize large classes of unlisted actions", "Storing the manifest inside the agent container or in storage writable by the agent's runtime identity", "Updating the manifest without triggering the change governance process, relying on developer discretion instead", "Linking manifests to agent versions by display name rather than cryptographic hash, allowing version drift to go undetected" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-02", "layer": "AB", "plane": "control", "name": "Tool-Call Authorization Policy", "plain": "Each tool available to an agent must have an explicit authorization policy specifying which agent roles may call it, under what conditions, with what parameter constraints, and whether human approval is required before execution.", "threat": { "tags": [ "unauthorized-tool-use", "parameter-injection", "privilege-escalation", "lateral-movement" ], "desc": "Agents with broad tool access become attack multipliers: a single compromised prompt can chain multiple high-privilege tool calls across systems. Without per-tool authorization policies, parameter constraints are absent, meaning an attacker can manipulate tool arguments to target unauthorized resources. High-impact tools like code execution, file write, or external API calls are reachable without commensurate authorization gates." }, "standard": [ { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency via unconstrained tool access" }, { "id": "nist_rmf", "section": "GOVERN 3.2", "title": "Human-AI oversight roles and responsibilities" }, { "id": "eu_ai_act", "section": "Article 14", "title": "Human oversight of high-risk AI systems" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-02 Tool-Call Authorization Policy control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-02 Tool-Call Authorization Policy control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-02 Tool-Call Authorization Policy control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-02 Tool-Call Authorization Policy 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-29", "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://agentic/controls/AB-02 Tool-Call Authorization Policy control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-02 Tool-Call Authorization Policy control.", "reviewed_on": "2026-07-02" }, { "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 — provides concrete IaC patterns for the controls in this layer.", "reviewed_on": "2026-07-02", "title": "HashiCorp Vault AI Agent Authorization Pattern", "version": "2026", "canonical_url": "https://www.hashicorp.com/en/blog/advancing-ai-agent-security-in-vault", "published_on": "2026-01-01" }, { "source_id": "ms_ifc_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds tool-call authorization policy: IFC evaluates labels through a policy engine before each tool call to allow, block, or escalate.", "reviewed_on": "2026-07-03" } ], "implementation": { "pattern": "Policy-per-tool registry: each tool entry in the agent capability manifest includes an authorization block specifying caller_roles, allowed_parameters (with type and range constraints), rate_limit, and human_approval_required flag. The enforcement layer evaluates these policies before dispatching any tool call.", "steps": [ "Create a tool authorization policy schema with fields: tool_id, caller_role_allowlist, parameter_schema (JSON Schema), human_approval_required, max_calls_per_session, and audit_required.", "Register all tools in a central tool catalog with their authorization policies before they can be bound to any agent.", "Deploy a policy evaluation engine that intercepts every tool call, validates caller identity, parameters, and approval state before dispatch.", "Implement a human approval workflow (synchronous or async) for tools flagged human_approval_required=true.", "Log every tool call attempt with policy decision, parameter snapshot, and approver identity for the audit trail." ], "ai_engineer": { "summary": "Design agent tool calls to be declarative and self-describing so the policy engine can evaluate them without agent-side logic handling authorization.", "actions": [ "Wrap all tool calls in a unified dispatch interface that includes caller context and parameter metadata.", "Test tool authorization policies with both valid and adversarial parameter inputs.", "Ensure agents surface policy denial reasons to the orchestration layer, not to end users, to prevent policy enumeration." ], "failure_signals": [ "Tool calls dispatched without passing through the policy evaluation engine.", "Parameter validation errors not triggering policy denial.", "Human approval workflow bypassed for high-risk tool types." ] }, "security_architect": { "summary": "Tool-call authorization policies are the primary defense against agents being weaponized to perform actions the enterprise did not sanction. Design the policy engine as the single mandatory decision point.", "actions": [ "Classify all tools by risk tier (read/write/execute/external) and set baseline authorization requirements per tier.", "Require dual approval for irreversible high-risk tools such as file deletion, external payment, and code execution in production.", "Integrate policy denial events into the threat detection pipeline as high-priority signals." ], "failure_signals": [ "High-risk tools accessible without elevated authorization.", "Parameter schema absent for any registered tool.", "Tool catalog not keeping pace with newly deployed tools, creating an ungoverned gap." ] }, "legal_counsel": { "summary": "Per-tool authorization policies create a defensible record that the enterprise maintained meaningful human oversight over consequential AI-driven actions, which is increasingly required by regulation.", "actions": [ "Review the tool catalog to confirm high-risk categories align with the enterprise's regulatory obligations under the EU AI Act and sector-specific rules.", "Confirm human approval workflows are documented and auditable for tools affecting legal, financial, or privacy-sensitive operations.", "Verify that tool-call audit logs are retained for the period required by applicable regulations." ], "failure_signals": [ "Tools affecting regulated data or transactions lacking human approval requirements.", "No documented legal basis for agent tool calls that access or process personal data.", "Audit log retention policy not aligned with regulatory minimums." ] }, "grc_auditor": { "summary": "The tool authorization policy catalog is the primary evidence that agent capability is bounded, reviewed, and subject to human oversight where required by policy.", "actions": [ "Request the tool catalog and verify every tool bound to deployed agents has a current authorization policy.", "Sample tool call logs and confirm policy decisions match the catalog entries in force at call time.", "Test the human approval workflow end-to-end for at least one high-risk tool type." ], "metrics": [ "Tool catalog coverage rate: percentage of agent-bound tools with active authorization policies — target 100%.", "Human approval compliance rate: percentage of high-risk tool calls that received documented approval — target 100%.", "Unauthorized tool call attempt rate: policy denials per 10,000 tool invocations — tracked as a risk indicator." ], "failure_signals": [ "Any agent-bound tool missing an authorization policy.", "Human approval log entries absent for mandatory-approval tools.", "Policy evaluation engine operating in audit-only mode without blocking enforcement." ] }, "platform_engineer": { "summary": "The tool catalog and policy evaluation engine must be platform infrastructure, not optional per-agent configuration. Build them into the agent runtime as mandatory intercepts.", "actions": [ "Deploy the policy evaluation engine as a platform-managed service with no agent-side opt-out.", "Automate tool catalog population from infrastructure-as-code declarations to prevent ungoverned tools.", "Provide developer tooling to simulate tool call authorization decisions against the policy catalog before deployment." ], "failure_signals": [ "Policy evaluation engine deployed as optional middleware that agents can bypass.", "Tool catalog populated manually without automation, leading to coverage gaps.", "No pre-deployment simulation tooling available for policy testing." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agent frameworks provide tool binding but lack per-tool authorization policy enforcement; this control requires dedicated policy infrastructure." }, "capability_risk": { "capability_level": "limited" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI/Agent Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) directly addresses LLM agents granted excessive functionality, permissions, or autonomy. Per-tool authorization policies with parameter constraints and human approval for high-risk calls are the primary mitigations OWASP recommends for this risk.", "normative_force": "industry-framework", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "eu_ai_act", "requirement_id": "Article 14 — Human Oversight", "fit": "direct", "rationale": "The EU AI Act requires meaningful human oversight measures for high-risk AI systems, including the ability to intervene or halt automated actions. Human approval requirements for high-risk tool calls operationalize this Article 14 obligation.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 3.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 3.2 requires policies that define and differentiate human roles and responsibilities for oversight of AI systems. The tool-call authorization policy encodes exactly that differentiation: which tool invocations an agent may perform autonomously, and which require a named human approver before execution.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "PS2 — Security Policy compliance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal PS2 requires AI systems to comply with organizational security policy, including least-privilege access. Per-tool authorization policies with parameter constraints enforce least privilege at the boundary where an agent's decision becomes an action.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Agent Permissions control requires authorization policies governing which agents can invoke which tools, under what conditions. The tool-call authorization policy is the direct implementation, adding parameter constraints and human approval tiers for high-risk invocations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. Logging of agent activity supports review of tool usage; per-tool authorization policy with parameter constraints and human approval tiers, as AB-02 requires, is enforced in the agent platform layer, not by the Trust Layer's logging.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 5 — Tool allow-listing; Part IV Phase 5 — Capability restrictions", "fit": "direct", "rationale": "Deny-by-default tool allow-listing plus per-tool capability restrictions define the tool-call authorization policy.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "ms_ifc_agents", "requirement_id": "Check before acting — policy engine inspects labels before each tool call to allow, block, or request human review (Communicating policies)", "fit": "direct", "rationale": "IFC's check-before-acting step is exactly a tool-call authorization policy: a policy engine inspects the relevant labels before each tool call and allows, blocks, or asks a human to review.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "supporting", "rationale": "AB-02's per-tool authorization policy constrains permitted callers and parameter values at the invocation layer, narrowing the agent's effective privilege.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every tool available to an agent has an explicit authorization policy…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every tool available to an agent has an explicit authorization policy…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every tool available to an agent has an explicit authorization policy…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-02", "validation_objective": "Prove that every tool available to an agent has an explicit authorization policy specifying permitted caller roles, parameter value constraints, and human-approval requirements, and that the policy is enforced at the platform invocation layer rather than relying on agent model reasoning or system prompt instructions.", "evidence_required": [ "Tool authorization policy registry listing every tool in the agent's scope with permitted caller roles, parameter constraints, and human-approval flags", "Platform enforcement log showing policy evaluations for tool calls during the test period, including both allow and deny outcomes with tool identifiers", "CI/CD test results demonstrating parameter constraint rejection for out-of-bounds values across all high-impact tools (code execution, file write, external API)", "Human-approval workflow records for any tools flagged as requiring human gate, showing approval or denial events with approver identity" ], "machine_tests": [ "Invoke a tool as an agent role not listed in the tool's permitted-roles set and assert the platform blocks the call", "Submit a tool call with parameter values outside the declared constraint bounds and assert the enforcement layer rejects it before the tool executes", "Verify every tool in the agent's action scope manifest has a corresponding policy entry in the tool authorization registry", "Confirm tool policy versions are pinned in the enforcement configuration and a policy rollback requires a governance action" ], "human_review": [ "Review that parameter constraints for high-impact tools (code execution, file write, external API calls) are sufficiently narrow to prevent abuse under adversarial prompting", "Assess whether human-approval requirements are assigned proportionally to tool impact level, with irreversible or high-blast-radius tools requiring mandatory gates", "Confirm that policy update procedures require governance review and produce a change record before taking effect in production" ], "blocking_effect": "blocks-runtime-action", "normative_status": "industry-framework", "anti_patterns": [ "Defining tool authorization policies that place no constraints on parameter values for high-impact tools", "Implementing policy enforcement in the agent's system prompt rather than at a separate platform enforcement layer", "Creating a single permissive umbrella policy covering multiple tools to reduce configuration overhead", "Exempting internal or first-party tools from the policy registry on the assumption that internal tools carry no abuse risk" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "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" } ], "layer_code": "AB" }, { "id": "AB-03", "layer": "AB", "plane": "control", "name": "Action Reversibility Classification and Gates", "plain": "Every action type available to an agent must be classified as reversible or irreversible. Actions classified as irreversible must pass through an explicit authorization gate — requiring either pre-authorized scope, elevated approval, or a confirmable dry-run result — before execution proceeds.", "threat": { "tags": [ "irreversible-action", "data-destruction", "unintended-side-effect", "cascading-failure" ], "desc": "Agents that execute irreversible actions without additional gates create permanent consequences from transient errors: deleted records, sent communications, financial transactions, and infrastructure changes cannot be undone. An adversary who influences an agent through prompt injection or logic manipulation can trigger irreversible actions before any human review is possible. The harm compounds in autonomous multi-step pipelines where a single irreversible step early in the chain corrupts all downstream state." }, "standard": [ { "id": "eu_ai_act", "section": "Article 14(4)", "title": "Human override of high-risk automated decisions" }, { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment monitoring incl. override and intervention mechanisms" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control" }, { "id": "iso_31000", "section": "§6.5.2", "title": "Selection of risk treatment options" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-03 Action Reversibility Classification and Gates control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-03 Action Reversibility Classification and Gates control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-03 Action Reversibility Classification and Gates control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-03 Action Reversibility Classification and Gates 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-29", "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://agentic/controls/AB-03 Action Reversibility Classification and Gates control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-03 Action Reversibility Classification and Gates control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Reversibility taxonomy enforced at the action dispatcher: each action in the tool catalog is tagged with reversibility_class (reversible / conditionally-reversible / irreversible) and rollback_mechanism if reversible. The dispatcher applies a gate policy based on reversibility_class: irreversible actions require an authorization token from the approval workflow before the call is dispatched.", "steps": [ "Define the reversibility taxonomy: reversible (idempotent, undoable), conditionally-reversible (soft-delete, staging), irreversible (hard-delete, send, external commit).", "Tag every tool in the tool catalog with a reversibility_class and, where applicable, a rollback_mechanism reference.", "Implement gate logic in the action dispatcher that blocks irreversible actions pending receipt of an approval token, with configurable timeout.", "Deploy a dry-run execution mode for conditionally-reversible actions so agents can confirm expected side effects before final commit.", "Emit irreversibility events to the audit log and the agent session state so the evidence record captures every irreversible action taken." ], "ai_engineer": { "summary": "Design agent action flows to request irreversible actions explicitly and await approval tokens. Build dry-run support into tool implementations.", "actions": [ "Implement a dry-run flag in all tool call interfaces so conditionally-reversible actions can be previewed.", "Wire the agent action loop to hold irreversible action calls until an approval token is present in session state.", "Write integration tests that verify the agent does not execute irreversible actions when the approval token is absent." ], "failure_signals": [ "Irreversible actions dispatched without a recorded approval token.", "Dry-run mode not implemented for conditionally-reversible tools.", "Agent logic bypassing the gate by re-classifying irreversible actions at runtime." ] }, "security_architect": { "summary": "Irreversibility gates are the last defense before permanent harm occurs. They must be architecturally enforced, not advisory, and must not be bypassable by the agent or by degraded-mode logic.", "actions": [ "Enforce irreversibility classification as a required field in the tool catalog schema so tools without a classification cannot be deployed.", "Design the gate as a cryptographic token check, not a logic flag that can be overridden in code.", "Test gate bypass scenarios including token replay, clock manipulation, and approval workflow degradation." ], "failure_signals": [ "Gate implemented as a flag in agent code rather than as a dispatcher-level enforcement mechanism.", "Approval workflow outage causing gates to fail-open rather than fail-closed.", "No irreversibility classification on newly added tools." ] }, "legal_counsel": { "summary": "Irreversibility gates create a defensible record of human oversight before consequential automated actions, which is the core of human oversight obligations under the EU AI Act and sector regulations.", "actions": [ "Review the irreversibility taxonomy to confirm legally consequential actions such as contract execution, data deletion, and financial transactions are classified irreversible.", "Confirm approval workflow records are legally admissible evidence of human authorization.", "Assess whether dry-run mode satisfies the enterprise's informed consent obligations before consequential data actions." ], "failure_signals": [ "Legally consequential actions not classified as irreversible in the taxonomy.", "Approval workflow records not retained or not attributable to a specific authorizing human.", "Gap between regulatory definition of consequential action and enterprise reversibility taxonomy." ] }, "grc_auditor": { "summary": "The reversibility taxonomy and gate approval logs are the evidence base for demonstrating that irreversible automated actions were authorized by appropriate human oversight before execution.", "actions": [ "Request the tool catalog with reversibility classifications and verify completeness against the deployed tool inventory.", "Sample irreversible action events from agent logs and confirm each has a corresponding approval token record.", "Test gate behavior under approval workflow failure conditions to confirm fail-closed posture." ], "metrics": [ "Reversibility classification coverage: percentage of tools with explicit reversibility_class — target 100%.", "Gate compliance rate: percentage of irreversible action executions with a valid approval token — target 100%.", "Unauthorized irreversible action rate: gate bypasses or unapproved irreversible actions per audit period — target 0." ], "failure_signals": [ "Any irreversible tool action logged without a corresponding approval token.", "Reversibility taxonomy not reviewed following tool catalog additions.", "Gate operating in advisory-only mode in any environment." ] }, "platform_engineer": { "summary": "The reversibility gate must be enforced at the platform dispatch layer, not within individual agent implementations, to prevent circumvention.", "actions": [ "Implement the gate as a platform-level dispatcher intercept using cryptographic approval tokens.", "Build fail-closed logic into the dispatcher: if the approval workflow is unreachable, irreversible actions are blocked, not passed.", "Provide a dry-run execution harness for the CI/CD pipeline so agents can be tested against reversibility gates before production deployment." ], "failure_signals": [ "Dispatcher implemented in agent code, allowing the agent to modify gate logic.", "Approval workflow failure causing fail-open behavior in production.", "No dry-run test harness available in the CI/CD pipeline." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agentic frameworks have no native concept of reversibility classification; this is an emerging control requiring custom implementation." }, "capability_risk": { "capability_level": "limited" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "AI/Agent Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Article 14(4) — Human Override", "fit": "direct", "rationale": "EU AI Act Article 14(4) requires high-risk AI systems to allow human operators to intervene or halt automated decisions. Irreversibility gates operationalize this by requiring affirmative human authorization before the AI system can take actions that cannot be reversed.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for override and human intervention. Reversibility classification with human authorization gates on irreversible actions is a concrete intervention mechanism that bounds the permanent impact of agent failures.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "direct", "rationale": "ISO/IEC 42001 §8.1 requires operational control of processes needed to meet AI management requirements. Reversibility classification and gating are operational controls that bound the permanent impact of AI-driven actions to those explicitly authorized.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.5.2 — Selection of risk treatment options", "fit": "partial", "rationale": "ISO 31000:2018 §6.5.2 addresses selecting risk treatment options that balance benefits against costs and residual risk. Irreversibility gates are a selected treatment that reduces expected loss by ensuring the most severe consequence class requires elevated authorization.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 requires that humans retain effective oversight and control over system behavior. Requiring affirmative human authorization before irreversible actions is a direct A5 mechanism: the class of action with the highest cost of error stays under human control.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds and Required Safeguards", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP conditions deployment on Required Safeguards proportionate to evaluated Capability Thresholds — controls scale with potential for harm. AB-03 applies the same proportionality inside a single agent deployment: the least reversible action classes carry the strongest authorization gates.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Contextual grounding checks", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' contextual grounding checks validate that model responses are grounded in and relevant to supplied source material before being returned. That is a response-level validation, not a pre-execution action gate — AB-03's reversibility classification and human gates must be built at the orchestration layer; grounding checks are an adjacent input-quality safeguard.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent User Control (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent User Control requires that consequential agent actions remain under effective user/principal control. Reversibility classification with human authorization gates keeps the least reversible action classes under affirmative human control before execution.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Safeguarding against severe harm (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §4 requires safeguards sufficient to minimize the risk of severe harm before highly capable systems are deployed. AB-03 applies the same principle inside an agent deployment: the actions with the most severe, least reversible consequences require affirmative human authorization before execution.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Secure data retrieval and dynamic grounding", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's secure data retrieval and dynamic grounding anchor generative responses in permissioned CRM data — improving the quality of context agents act on. Reversibility classification and human gates on irreversible actions, as AB-03 requires, are separate orchestration-layer controls.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 — Escalation triggers; Part IV Phase 5 — Approval escalation", "fit": "direct", "rationale": "High-value/irreversible actions require human approval (escalation triggers, approval escalation, HITL for high-risk actions) — reversibility classification and gates.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AB-03", "validation_objective": "Prove that every action type in an agent's authorized scope has been formally classified as reversible or irreversible, and that all irreversible actions are blocked from execution until an explicit authorization gate is satisfied — pre-authorized scope approval, elevated human approval, or a confirmed dry-run result reviewed before live execution.", "evidence_required": [ "Action reversibility classification register covering every action type in the agent's authorized scope with classification rationale and responsible owner", "Platform enforcement records confirming irreversible actions were gated prior to execution during the test period, with gate condition and outcome logged", "Dry-run execution logs for irreversible actions showing dry-run output was produced and reviewed before live execution proceeded", "Governance sign-off records authorizing each irreversible action type for the agent's deployment context, with approver identity and validity period" ], "machine_tests": [ "Trigger an irreversible action type without satisfying any gate condition and assert the enforcement layer blocks it before execution", "Verify that a dry-run is produced and its output is logged before any live irreversible action executes in the test harness", "Confirm the classification register is versioned and the current version matches the enforcement configuration for the active deployment", "Assert that the gate condition check is performed by the platform enforcement layer and cannot be bypassed by model-generated output alone" ], "human_review": [ "Review the classification register for completeness — confirm no action type is unclassified, and that default-reversible assignments are explicitly justified", "Assess whether the gate conditions applied to each irreversible action type are commensurate with the action's potential impact and blast radius", "Confirm that classification decisions have an identified responsible owner and a defined periodic review cadence tied to the agent's deployment lifecycle" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Defaulting newly introduced action types to reversible classification pending evidence of harm rather than requiring explicit classification before deployment", "Implementing irreversibility gates in the agent's system prompt instructions, allowing the gate to be bypassed by prompt injection or model reasoning errors", "Treating soft-delete or draft-mode outputs as satisfying the dry-run requirement without an explicit human confirmation step", "Granting pre-authorization for irreversible actions with indefinite validity and no re-review requirement tied to deployment version changes" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-04", "layer": "AB", "plane": "data", "name": "Output Policy Enforcement", "plain": "All agent outputs — text responses, generated content, data extracts, and API payloads — must pass through a policy enforcement layer that applies content filtering, PII detection and scrubbing, sensitive data classification checks, and output sanitization before delivery to any downstream consumer.", "threat": { "tags": [ "data-exfiltration", "pii-exposure", "sensitive-data-leak", "content-policy-bypass" ], "desc": "Agents with access to sensitive enterprise data can inadvertently or adversarially include protected information in outputs consumed by unauthorized parties. An attacker using prompt injection or indirect injection can instruct the agent to include sensitive context in outputs that are then delivered to attacker-controlled channels. Without output filtering, the agent becomes a data exfiltration vector that bypasses traditional DLP controls because the data is synthesized rather than directly copied." }, "standard": [ { "id": "eu_ai_act", "section": "Article 10(3)", "title": "Data governance for high-risk AI training and operation" }, { "id": "owasp_llm10", "section": "LLM02:2025", "title": "Sensitive Information Disclosure" }, { "id": "nist_ai_600_1", "section": "2.4", "title": "Data Privacy" }, { "id": "salesforce_trust", "section": "Data masking", "title": "PII and sensitive data scrubbed from prompts and responses" } ], "sources": [ { "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-29", "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://agentic/controls/AB-04 Output Policy Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-04 Output Policy Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-04 Output Policy Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-04 Output Policy Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-04 Output Policy Enforcement 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-29", "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://agentic/controls/AB-04 Output Policy Enforcement control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Output interception pipeline: all agent outputs pass through a multi-stage filter chain before delivery. Stages include: (1) PII detection using named entity recognition, (2) sensitive data pattern matching for credentials, keys, and internal IDs, (3) content policy classification, (4) output sanitization and redaction, and (5) policy verdict logging. Outputs failing policy evaluation are blocked and replaced with a policy notice.", "steps": [ "Deploy an output interception layer in the agent response path that is applied before any output reaches the consumer, including internal orchestration consumers.", "Implement PII detection covering at minimum: names, email addresses, phone numbers, national identifiers, financial account numbers, and health information.", "Configure sensitive data pattern matching for enterprise-specific sensitive strings including internal system IDs, API keys, credential patterns, and classification-marked content.", "Define content policy rules aligned with the enterprise acceptable use policy, including prohibited output categories.", "Log every output policy event with the redaction decision, detected category, and agent session identifier for audit and feedback loop." ], "ai_engineer": { "summary": "Treat output policy as a required filter stage in the response pipeline, not an optional feature. Design agent prompts to minimize sensitive data inclusion in responses, and test against known data exfiltration patterns.", "actions": [ "Integrate the output filter as a mandatory post-processing step in the agent response chain with no bypass path.", "Test the filter against a library of known PII patterns, credential formats, and indirect injection exfiltration attempts.", "Build feedback from filter denials into agent evaluation metrics to guide prompt and instruction improvement." ], "failure_signals": [ "PII detected in agent outputs after the filter stage.", "Output filter operating in logging-only mode without blocking in production.", "No test coverage for indirect injection data exfiltration patterns." ] }, "security_architect": { "summary": "The output policy layer is the enterprise's last line of defense against AI-driven data exfiltration. It must operate on all output channels including APIs, webhooks, email integrations, and embedded responses.", "actions": [ "Map all output channels used by deployed agents and confirm the filter is applied uniformly across every channel.", "Integrate output filter denial events into the SIEM as high-priority signals indicating potential data exfiltration attempts.", "Commission red team exercises specifically targeting output filter bypass through prompt engineering and format manipulation." ], "failure_signals": [ "Output channels discovered that do not route through the filter layer.", "Filter bypass demonstrated through format manipulation such as encoding or structured data embedding.", "SIEM alert volume indicating filter denials not reviewed within SLA." ] }, "legal_counsel": { "summary": "Output filtering and PII scrubbing are direct obligations under GDPR, CCPA, and sector data protection regulations. The filter implementation must be documented as a technical safeguard in privacy impact assessments.", "actions": [ "Confirm the PII detection scope covers all personal data categories relevant to the enterprise's regulatory jurisdictions.", "Document the output filter as a technical safeguard in GDPR Article 32 compliance records and DPIA documentation.", "Verify that filter logs retaining detected PII strings do not themselves create a new privacy risk requiring separate controls." ], "failure_signals": [ "PII categories relevant to the enterprise's jurisdiction not covered by the detection model.", "Output filter not documented in DPIA or Article 32 technical safeguard records.", "Filter event logs retaining raw PII strings without secondary protection." ] }, "grc_auditor": { "summary": "Output policy enforcement generates the evidence that the enterprise is actively preventing AI systems from disclosing sensitive data to unauthorized parties.", "actions": [ "Review the output filter configuration against the enterprise's data classification taxonomy to confirm coverage.", "Sample output filter logs and verify denial events are reviewed and escalated per the incident response SLA.", "Test the filter against a set of known-PII synthetic data and confirm all instances are detected and redacted." ], "metrics": [ "PII detection false-negative rate: synthetic PII strings reaching output after filter — target 0%.", "Output filter coverage rate: percentage of agent output channels covered by the filter — target 100%.", "Policy denial review rate: percentage of filter denial events reviewed within SLA — target 100%." ], "failure_signals": [ "PII strings passing through the output filter in test scenarios.", "Output channels not covered by the filter policy.", "Filter operating in advisory mode without blocking enforcement." ] }, "platform_engineer": { "summary": "The output filter must be deployed as a platform-managed intercept point that applies uniformly to all agent output channels, regardless of how the agent is accessed.", "actions": [ "Implement the filter as platform infrastructure rather than an agent-side library to prevent accidental or intentional omission.", "Apply the filter to all egress paths including REST responses, streaming chunks, webhook payloads, and async callback results.", "Provide a configuration interface allowing security teams to update filter rules without redeploying agent code." ], "failure_signals": [ "Filter implemented as an optional agent-side library rather than mandatory platform intercept.", "Streaming output chunks not subject to the same filter policy as full responses.", "No mechanism for security teams to update filter rules independently of agent deployments." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Enterprise DLP tools generally do not cover AI-generated output; output policy enforcement for agents is an emerging requirement requiring dedicated implementation." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI/Agent Engineering", "Platform Engineering", "Data Privacy Team" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM02:2025 — Sensitive Information Disclosure", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM02 (Sensitive Information Disclosure) directly addresses LLMs disclosing sensitive information in responses. Output policy enforcement with PII scrubbing is the primary technical control category recommended for this risk.", "normative_force": "industry-framework", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "eu_ai_act", "requirement_id": "Article 10(3) — Data Governance", "fit": "adjacent", "rationale": "EU AI Act Article 10(3) requires high-risk AI systems to implement governance over data used in and produced by the system. Output policy enforcement extends this data governance requirement to the AI system's output stream, preventing unauthorized disclosure of training or operational data.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-08", "basis": "anchored", "correction": "ai-exchange-verify 2026-07-08", "relation": "satisfies" }, { "framework": "nist_ai_600_1", "requirement_id": "2.4 — Data Privacy", "fit": "direct", "rationale": "NIST AI 600-1 §2.4 (Data Privacy) addresses privacy risks specific to generative AI, including leakage of sensitive or memorized data in outputs. Output policy enforcement with PII detection and scrubbing directly mitigates that leakage channel at the agent output boundary.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Data masking", "fit": "direct", "rationale": "The Salesforce Einstein Trust Layer's data masking replaces sensitive data with placeholders before prompts leave the trust boundary, with zero-data-retention arrangements for external model calls. AB-04 implements the equivalent output-policy pattern platform-neutrally, covering agent outputs as well as prompts.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Sensitive information filters", "fit": "partial", "rationale": "Amazon Bedrock Guardrails provides sensitive information filters that detect and mask or block PII in model inputs and responses — a managed implementation of the output-policy pattern. AB-04 generalizes the pattern beyond Bedrock-hosted agents and adds classification-aware policy.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 5 — Adapt controls to adjust mitigations and create faster feedback loops", "fit": "partial", "rationale": "Google SAIF element 5 (Adapt controls) emphasizes adapting existing mitigations to AI-specific risks. Output policy enforcement is the AI-specific adaptation of traditional DLP: classification-aware scanning applied to agent outputs before they leave the trust boundary.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard — misuse-prevention safeguards", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The ASL-3 Deployment Standard requires layered safeguards against misuse of deployed models, including output-level defenses such as classifiers. AB-04's output policy enforcement is the deployer-side analog of that output-safeguard layer at the agent boundary.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "PS1 — Privacy Standard compliance", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal PS1 requires AI systems to comply with the organization's privacy standard. Output policy enforcement with PII detection and scrubbing implements privacy-standard compliance at the agent output boundary, before responses leave the trust boundary.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Safeguarding against severe harm (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §4 requires safeguards sufficient to minimize the risk of severe harm before deployment, including misuse safeguards applied at the output level. AB-04's output policy enforcement is the corresponding output-layer safeguard for enterprise agent deployments.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Output filtering", "fit": "direct", "rationale": "Output filtering/semantic analysis enforces output policy: block/redact sensitive data and require human review for high-risk outputs.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "sensitiveoutputhandling", "fit": "direct", "rationale": "AB-04 routes all agent outputs through PII detection, scrubbing, and sensitive-data classification before release, directly the sensitive-output handling AI Exchange requires.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "encodemodeloutput", "fit": "supporting", "rationale": "AB-04's output sanitization before release also reduces downstream conventional-injection payloads in agent output, supporting AI Exchange's encode-model-output control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that all agent outputs — text responses, generated content, data extracts, and API…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (sensitiveoutputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0002", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that all agent outputs — text responses, generated content, data extracts, and API…\" enacts ATLAS mitigation AML.M0002 Passive AI Output Obfuscation; OpenCRE crosswalks this control’s OWASP AI Exchange concept (encodemodeloutput) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-04", "validation_objective": "Prove that all agent outputs — text responses, generated content, data extracts, and API payloads — pass through an enforcement layer that applies content filtering, PII detection and scrubbing, sensitive data classification checks, and output sanitization before delivery to any downstream consumer, and that this enforcement layer operates independently of the agent's model logic.", "evidence_required": [ "Output policy enforcement configuration showing active content filter rules, PII detection patterns (covering at least five entity types), and sensitive data classification thresholds", "Enforcement log from the test period showing output policy evaluations including scrub events, redaction events, and block events with content hashes", "PII detection test results confirming detection of at least five PII entity types (e.g., SSN, email, phone, credit card, health identifier) against labeled test output samples", "Architecture diagram or deployment evidence confirming the enforcement layer runs on a separate runtime path from the agent model process" ], "machine_tests": [ "Submit an agent request designed to elicit known PII in the output and assert the enforcement layer scrubs it before delivery to the caller", "Embed a prompt injection payload in user input designed to redirect agent output to an attacker-controlled channel and verify the enforcement layer intercepts or blocks delivery", "Verify the enforcement layer's access control configuration excludes the agent runtime identity from modifying enforcement rules", "Confirm enforcement evaluation is applied to all output channels — user-facing responses, downstream API payloads, and logged artifacts equally" ], "human_review": [ "Review whether the output policy rules cover the organization's full data classification taxonomy, including domain-specific sensitive categories beyond standard PII", "Assess whether enforcement scrub and redaction events are retained in an audit log accessible to the security monitoring function", "Confirm that silent scrubbing of sensitive content is reported to the security team rather than only to the requesting consumer" ], "blocking_effect": "blocks-runtime-action", "normative_status": "industry-framework", "anti_patterns": [ "Relying on the agent's system prompt to instruct the model not to output sensitive data rather than enforcing at the output layer", "Configuring output enforcement in allow-by-default mode where only explicitly enumerated blocked patterns are intercepted", "Applying output policy enforcement only to final user-facing responses rather than to all downstream API payloads and logged artifacts", "Using enforcement rules that match only exact string literals rather than semantic classification or pattern-based detection for sensitive data categories" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-05", "layer": "AB", "plane": "control", "name": "Prompt Injection Detection and Defense", "plain": "Agents must implement detection and mitigation controls for prompt injection attacks — including direct user injection and indirect injection via retrieved documents or tool outputs — that attempt to override the agent's authorized instructions, escalate privileges, or redirect behavior to attacker-specified goals.", "threat": { "tags": [ "prompt-injection", "indirect-injection", "instruction-override", "jailbreak" ], "desc": "Prompt injection is the primary attack vector for subverting agent behavior without compromising the underlying infrastructure. An attacker who can influence any input to the agent — including retrieved documents, tool outputs, database records, or web content — can embed instructions that the model interprets as authoritative, causing it to override its system prompt, bypass authorization controls, or execute attacker-specified actions under the agent's identity and authority. Indirect injection via retrieved content is particularly severe because the attack surface extends to every document or data source the agent can read." }, "standard": [ { "id": "owasp_llm10", "section": "LLM01:2025", "title": "Prompt Injection" }, { "id": "mitre_atlas", "section": "AML.T0051", "title": "LLM Prompt Injection" }, { "id": "nist_ai_600_1", "section": "2.9", "title": "Information Security — adversarial input and prompt manipulation" } ], "sources": [ { "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-29", "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://agentic/controls/AB-05 Prompt Injection Detection and Defense control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-05 Prompt Injection Detection and Defense control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-05 Prompt Injection Detection and Defense control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-05 Prompt Injection Detection and Defense 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-29", "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://agentic/controls/AB-05 Prompt Injection Detection and Defense control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-05 Prompt Injection Detection and Defense control.", "reviewed_on": "2026-07-02" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds prompt-injection detection and defense in Phase 4's input isolation and constitutional classifiers.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Multi-layer injection defense: (1) input classification layer detects injection patterns in all inputs before they reach the model context; (2) context isolation separates system prompt, user input, and retrieved content using structural markers; (3) output monitoring detects behavioral indicators of successful injection; (4) privilege-sensitive operations require re-authentication that cannot be satisfied by injected text.", "steps": [ "Deploy an input classification model or rule engine that scores each input for prompt injection risk before context assembly.", "Implement context isolation using explicit structural markers such as XML tags, delimiters, or system-level separators to distinguish trusted system context from untrusted user and retrieved content.", "Apply injection risk scoring to all retrieved content in RAG pipelines, tool outputs, and database responses before they are inserted into the agent context.", "Require independent re-authentication — not model-mediated — for any privileged action requested by the agent, so injected instructions cannot satisfy authorization gates.", "Monitor agent output streams for behavioral signatures of successful injection: unexpected tool calls, instruction leakage, goal redirection, and policy override attempts." ], "ai_engineer": { "summary": "Prompt injection defense must be built into the agent architecture, not bolted on. Design context assembly to structurally separate trust levels and test against a library of injection payloads.", "actions": [ "Implement strict context assembly with labeled sections for system, user, and retrieved content, preventing untrusted content from occupying positions where it can be misinterpreted as instructions.", "Maintain and run an injection test library covering direct, indirect, and multi-turn injection patterns against every agent build.", "Instrument the agent action selection loop to flag unexpected tool call sequences as injection indicators." ], "failure_signals": [ "Retrieved content passed to the model without injection risk scoring.", "System prompt instructions overridden by content from user or retrieval inputs in testing.", "Injection test library not updated in the last 60 days or not run against current build." ] }, "security_architect": { "summary": "Prompt injection defense must assume model-layer controls are insufficient; architectural controls that do not rely on model instruction-following are required for security-critical boundaries.", "actions": [ "Define security-critical operations that require cryptographic re-authentication rather than model-mediated authorization, making them immune to injected authorization claims.", "Commission adversarial red team exercises targeting indirect injection via every data source the agent can retrieve from.", "Integrate injection detection events into the threat detection pipeline and treat evidence of successful injection as a high-severity incident." ], "failure_signals": [ "Privileged operations authorized solely through model-interpreted instructions with no independent authentication gate.", "No red team exercise covering indirect injection via the agent's retrieval data sources.", "Injection detection operating in logging-only mode without alerting." ] }, "legal_counsel": { "summary": "Prompt injection attacks that cause agents to take unauthorized actions expose the enterprise to liability for actions taken outside the agent's authorization scope. Documentation of injection defense measures supports the argument that the enterprise exercised reasonable security care.", "actions": [ "Document prompt injection defense measures in the enterprise's AI risk management records for regulatory and litigation readiness.", "Confirm incident response procedures address prompt injection as a distinct attack class requiring specific containment and evidence preservation steps.", "Assess whether successful prompt injection incidents that cause data disclosure or unauthorized actions trigger breach notification obligations." ], "failure_signals": [ "No documented incident response procedure for prompt injection events.", "AI risk assessment not classifying prompt injection as a threat category.", "Breach notification analysis not considering prompt injection as a potential trigger." ] }, "grc_auditor": { "summary": "Prompt injection defense controls are auditable through testing, detection log review, and architecture assessment. The key evidence is that architectural controls — not just model instructions — enforce security-critical boundaries.", "actions": [ "Review the context assembly architecture and confirm structural separation of trusted and untrusted content.", "Request injection detection logs and verify injection events are reviewed and escalated per SLA.", "Conduct or commission an injection test against deployed agents using the current injection test library." ], "metrics": [ "Injection detection coverage: percentage of input channels scanned for injection patterns — target 100%.", "Architecture review finding: structural trust separation confirmed in context assembly — pass/fail.", "Red team injection success rate: successful injections bypassing defenses in the latest exercise — target 0." ], "failure_signals": [ "Injection detection not applied to retrieved content and tool outputs.", "Privileged actions found to be authorizable solely through injected model instructions.", "No documented injection test results for currently deployed agents." ] }, "platform_engineer": { "summary": "Platform-level injection defenses provide consistent protection across all agents without relying on individual agent implementations. Build injection scoring into the platform context assembly service.", "actions": [ "Implement injection risk scoring as a platform-managed pre-processing step in the context assembly pipeline.", "Provide structural context isolation as a platform default that agents cannot disable.", "Build injection detection signal integration into the platform observability stack for centralized monitoring." ], "failure_signals": [ "Injection risk scoring implemented as an optional agent-side library rather than a mandatory platform service.", "Context assembly not enforcing structural separation between trust levels by default.", "Injection detection signals not visible in the platform monitoring dashboard." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Prompt injection defense is an emerging discipline with no settled best practice; structural architectural controls currently provide more reliable protection than model-layer mitigations alone." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI/Agent Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM01:2025 — Prompt Injection", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM01 (Prompt Injection) is the definitive industry classification of prompt injection risk for LLM applications. AB-05 directly implements the layered defensive architecture described in OWASP's mitigations.", "normative_force": "industry-framework", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051 — LLM Prompt Injection", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 classifies prompt injection as a documented adversarial ML technique with tracked real-world use. This control addresses the detection and mitigation of the exact technique class catalogued in ATLAS, providing the defensive response to this documented threat.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "direct", "rationale": "NIST AI 600-1 §2.9 (Information Security) identifies prompt injection — direct and indirect — as a core generative-AI information security risk, with suggested actions spanning input handling and monitoring. AB-05 implements the defensive architecture for exactly that risk class.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 15 — Accuracy, Robustness, Cybersecurity", "fit": "partial", "rationale": "EU AI Act Article 15 requires high-risk AI systems to be resilient against attempts by third parties to alter their use, outputs, or performance through adversarial attacks. Prompt injection defense directly implements this cybersecurity resilience requirement.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Input Validation and Sanitization (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Input Validation and Sanitization control addresses adversarial content entering AI systems, with prompt injection as the primary agent-facing risk. AB-05 implements layered detection and defense for exactly that risk class.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard — robustness to jailbreak and misuse", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The ASL-3 Deployment Standard requires defenses that make persistent jailbreaks and misuse difficult, with rapid remediation when they are found. AB-05 implements the corresponding deployer-side defense: detecting and blocking prompt injection before it redirects an agent's authorized behavior.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters — prompt attack detection", "fit": "direct", "rationale": "Amazon Bedrock Guardrails' content filters include a prompt-attack filter that detects prompt injection and jailbreak attempts in inputs. AB-05's layered injection defense uses exactly this class of managed detection as one layer, combined with architectural separation of trusted and untrusted context.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires identifying predictable failure modes and defining remediations. Prompt injection is the most predictable adversarial failure mode for deployed agents; AB-05's layered detection and defense is the documented remediation for that failure class.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Safeguarding against severe harm (§4) — safeguard robustness", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §4 requires that safeguards be robust against circumvention attempts. Prompt injection is the primary circumvention vector for deployed agents, and AB-05's layered injection defense is the agent-layer robustness control.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Prompt defense", "fit": "partial", "rationale": "The Salesforce Einstein Trust Layer's prompt defense hardens system prompts against manipulation and injection attempts for platform-hosted generative AI. AB-05 generalizes injection detection and defense across agent deployments, adding detection, provenance separation, and response layers.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 4 — Defend against prompt injection (Input isolation; Constitutional classifiers)", "fit": "direct", "rationale": "Direct and indirect injection defense: input isolation/spotlighting (indirect injection >50% to <2%) and constitutional classifiers (95% jailbreak block).", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "ms_ifc_agents", "requirement_id": "Information-flow control as deterministic defense against prompt injection; Dual LLM pattern / Quarantined LLM", "fit": "partial", "rationale": "IFC and the Dual LLM / Quarantined LLM pattern provide a deterministic defense that limits the impact of prompt injection. It is a preventive design rather than an injection detector, so the fit is partial.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "promptinjectioniohandling", "fit": "direct", "rationale": "AB-05 detects and blocks both direct and indirect prompt injection in the agent's input pipeline before it influences behavior, precisely the AI Exchange prompt-injection I/O control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "inputsegregation", "fit": "supporting", "rationale": "AB-05 treats retrieved documents, tool outputs, and external data as untrusted injection vectors distinct from user intent, embodying the trusted/untrusted input segregation AI Exchange calls for.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0015", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that the agent's input processing pipeline detects and mitigates prompt injection…\" enacts ATLAS mitigation AML.M0015 Adversarial Input Detection; OpenCRE crosswalks this control’s OWASP AI Exchange concept (promptinjectioniohandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-05", "validation_objective": "Prove that the agent's input processing pipeline detects and mitigates prompt injection attempts — both direct user injection and indirect injection via retrieved documents, tool outputs, or external data sources — and that detected injection attempts are blocked and logged before influencing agent behavior, with alerts routed to the security monitoring function.", "evidence_required": [ "Prompt injection detection configuration with active detection rules or classifiers covering direct instruction-override patterns and indirect injection via retrieved content", "Detection log from the test period showing injection attempt events with outcome (blocked, flagged, or allowed with rationale), content hashes, and timestamps", "Red team or automated adversarial test results covering indirect injection via at least one document retrieval or tool output vector specific to the agent's data sources", "Alert routing records confirming injection detection events are delivered to the security monitoring function within a defined SLA" ], "machine_tests": [ "Inject a direct instruction-override payload in a user message and assert the detection layer flags and blocks it before it influences agent reasoning", "Embed an indirect injection payload in a document the agent retrieves during task execution and assert the detection layer identifies and neutralizes it", "Verify that retrieved content is structurally separated from instruction-bearing context in the model's context window, or sanitized before inclusion", "Confirm that detection events are written to an immutable audit log with timestamps, content fingerprints, and detection rule identifiers" ], "human_review": [ "Review red team test coverage to confirm that indirect injection vectors specific to the agent's actual data sources and retrieval patterns were included in scope", "Assess whether detection rules can distinguish between legitimate user instructions and injected overrides in the agent's operational context", "Confirm that escalation procedures exist for injection attempts that evade automated detection, including criteria for human review and agent suspension" ], "blocking_effect": "blocks-runtime-action", "normative_status": "industry-framework", "anti_patterns": [ "Relying solely on model-side refusal training as the injection defense without a platform-layer detection and blocking path", "Treating indirect injection from trusted internal document repositories or first-party tool outputs as out of scope", "Configuring injection detection in monitor-only mode without a blocking path for high-confidence injection classifications", "Applying injection detection only to user-facing chat inputs while excluding tool response content and RAG retrieval results from the detection pipeline" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-06", "layer": "AB", "plane": "control", "name": "Rate Limiting and Resource Budget Enforcement", "plain": "Each deployed agent must operate under explicit per-agent limits on API call rates, token consumption, cost expenditure, and compute time. Limits must be enforced by the platform rather than by agent-side logic, with automated circuit-breaker behavior when budgets are exhausted.", "threat": { "tags": [ "resource-exhaustion", "cost-explosion", "runaway-agent", "denial-of-service" ], "desc": "Autonomous agents can enter runaway loops, be manipulated into excessive resource consumption by adversarial inputs, or simply be misconfigured to perform work at a scale that was not authorized or anticipated. Without enforced resource budgets, a single compromised or misconfigured agent can exhaust organization-wide API quotas, incur unbounded costs, saturate shared infrastructure, or deny service to other workloads. The risk compounds in multi-agent systems where one agent spawning others can cause exponential resource consumption." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 2.4", "title": "Mechanisms to supersede, disengage, or deactivate AI systems" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control — resource governance" }, { "id": "iso_31000", "section": "§6.6", "title": "Monitoring and review" } ], "sources": [ { "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-29", "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://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-06 Rate Limiting and Resource Budget Enforcement control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Per-agent resource budget enforcement: each agent registry entry includes a resource_budget block specifying token_budget_per_session, api_calls_per_minute, cumulative_cost_limit, max_session_duration, and max_subagent_spawns. The platform enforces these limits via a budget ledger; when any limit is reached, the agent session is paused and the orchestrating system is notified with the budget exhaustion reason.", "steps": [ "Define resource budget schema fields: token_budget_per_session, api_call_rate_limit, cost_limit_per_session, cost_limit_per_day, max_session_duration_seconds, max_concurrent_sessions, max_subagent_spawns.", "Integrate budget enforcement into the agent runtime platform so limits are applied server-side, not in agent code.", "Implement a budget ledger that tracks consumption in real time and enforces circuit-breaker behavior at limit thresholds.", "Configure graduated alerts: warning at 70% of any limit, hard stop at 100%, with escalation to the agent's owner and the operations team.", "Require budget policy review and re-authorization when any limit is increased, treating the change as a formal change management event." ], "ai_engineer": { "summary": "Design agents to be budget-aware: emit progress events against resource budgets so the orchestration layer can make graceful shutdown decisions before hard limits are hit.", "actions": [ "Instrument the agent to report current resource consumption in each response frame so orchestration can track budget utilization.", "Implement graceful shutdown logic that saves session state before the hard budget limit triggers forced termination.", "Test agent behavior under each budget exhaustion condition to verify predictable, non-error shutdown responses." ], "failure_signals": [ "Agent code containing self-modifying logic to increase its own resource limits.", "No graceful shutdown behavior implemented for budget exhaustion scenarios.", "Resource consumption events not emitted in the agent telemetry stream." ] }, "security_architect": { "summary": "Resource budget enforcement is a security control, not just a cost control. It limits the blast radius of compromised or adversarially manipulated agents by capping the resources available to execute attacker-directed work.", "actions": [ "Define resource budget baselines based on legitimate workload characterization, keeping limits tight enough to detect anomalous consumption.", "Treat budget exhaustion events as security signals: sudden limit-hitting that deviates from baseline should trigger threat investigation, not just operational alerting.", "Limit subagent spawn depth and concurrency as a defense against exponential resource consumption in recursive multi-agent attacks." ], "failure_signals": [ "Resource budgets set so high they provide no meaningful constraint on abnormal behavior.", "Budget exhaustion events treated as operational noise rather than potential security signals.", "No subagent spawn limit configured, allowing recursive agent spawning." ] }, "grc_auditor": { "summary": "Resource budget enforcement evidence demonstrates that the enterprise has bounded the operational and financial risk of autonomous AI agents through policy-driven controls.", "actions": [ "Review the agent registry and confirm every deployed agent has a resource_budget entry with all required fields populated.", "Sample budget enforcement logs and verify that limit-hit events trigger the configured notification and circuit-breaker behavior.", "Confirm budget increase requests are processed through change management with documented re-authorization." ], "metrics": [ "Budget policy coverage: percentage of deployed agents with complete resource_budget entries — target 100%.", "Budget enforcement effectiveness: percentage of limit-hit events that triggered circuit-breaker behavior — target 100%.", "Unauthorized budget increase rate: budget increases applied without change management approval — target 0." ], "failure_signals": [ "Deployed agents without resource_budget entries in the registry.", "Budget limits set to values that would never be reached in practice, rendering them ineffective.", "Budget limit increases applied without change management authorization." ] }, "legal_counsel": { "summary": "Resource budgets and circuit breakers bound the financial and operational blast radius of a malfunctioning or hijacked agent. They convert a potentially unbounded loss event into a capped, insurable one — which matters for risk transfer and for demonstrating proportionate risk management.", "actions": [ "Confirm documented budget limits exist for agents capable of incurring spend or consuming metered services, and that limit-setting authority is defined.", "Verify cyber and technology-E&O insurance positions reflect the capped-loss architecture; uncapped autonomous spend may sit outside coverage assumptions.", "Review whether budget-exhaustion suspensions of agents serving customers trigger any service-level or availability obligations." ], "failure_signals": [ "Agents with unbounded spend or API consumption authority and no documented acceptance of that risk.", "Loss events exceeding what insurers were told the architecture made possible.", "Circuit-breaker suspensions causing SLA breaches that no contract contemplated." ] }, "platform_engineer": { "summary": "Budget enforcement must be implemented at the platform level so agents cannot exceed their limits regardless of how they are coded. The budget ledger must be server-side, durable, and consistent.", "actions": [ "Implement the budget ledger as a server-side, durable store that agents cannot modify.", "Build circuit-breaker enforcement into the API gateway layer so budget exhaustion terminates the request before the agent processes it.", "Provide real-time budget consumption dashboards for agent owners and the operations team." ], "failure_signals": [ "Budget tracking implemented in agent-side code that the agent can modify.", "No circuit-breaker behavior implemented — budget exhaustion logged but not enforced.", "No real-time visibility into budget consumption for agents in production." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations enforce API rate limits at the account level but lack per-agent granular budgets; this control requires dedicated budget ledger infrastructure." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "federated-enterprise" ], "implementers": [ "Platform Engineering", "AI/Agent Engineering", "FinOps" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 2.4", "fit": "direct", "rationale": "NIST AI RMF MANAGE 2.4 requires mechanisms to supersede, disengage, or deactivate AI systems whose behavior is inconsistent with intended use. Budget exhaustion and rate-limit circuit breakers are exactly such mechanisms: they disengage an agent automatically when consumption departs from its authorized envelope.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "direct", "rationale": "ISO/IEC 42001 §8.1 requires the organization to plan, implement, and control the operational processes of its AI systems. Per-agent resource budgets and rate limits are concrete operational controls bounding agent execution during the operational lifecycle.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.6 — Monitoring and review", "fit": "partial", "rationale": "ISO 31000:2018 §6.6 requires ongoing monitoring and review of risks and controls. Resource consumption metrics and budget exhaustion events are operational risk indicators for agentic systems; monitoring them with defined escalation implements §6.6 for this risk class.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1 — Reliability and safety guidance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 requires systems to operate within a defined safe operational envelope. Per-agent resource budgets and rate limits are the operational-envelope enforcement for agents: consumption beyond the defined bounds trips a circuit breaker rather than continuing unbounded.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 4 — Harmonize platform-level controls to ensure consistent security", "fit": "adjacent", "rationale": "Google SAIF element 4 (Harmonize platform-level controls) calls for consistent, platform-enforced limits across AI deployments. Per-agent resource budgets and rate limits applied uniformly at the platform layer prevent per-team gaps in operational bounds.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Autonomous Replication and Adaptation", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Autonomous Replication and Adaptation research category is centrally concerned with AI systems acquiring compute and resources without authorization. Per-agent resource budgets with hard circuit breakers bound that failure mode operationally in enterprise deployments.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II — Resource exhaustion attacks; Part IV Phase 5 — Secure tool access (rate limiting, circuit breakers, spending controls)", "fit": "partial", "rationale": "Doc prescribes rate limiting/circuit breakers/spending controls against resource exhaustion. Partial: doc stresses rate limits are friction, not hard barriers.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "ratelimit", "fit": "supporting", "rationale": "AB-06 enforces per-agent limits on API call rate with automated circuit-breaking, directly implementing AI Exchange's rate limiting of requests to the model.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "limitresources", "fit": "direct", "rationale": "AB-06 also caps token consumption, cost, and compute time and suspends on budget exhaustion, limiting resources to prevent exhaustion as AI Exchange requires.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0004", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every deployed agent operates under platform-enforced per-agent limits on API…\" enacts ATLAS mitigation AML.M0004 Restrict Number of AI Model Queries; OpenCRE crosswalks this control’s OWASP AI Exchange concept (ratelimit) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-06", "validation_objective": "Prove that every deployed agent operates under platform-enforced per-agent limits on API call rate, token consumption, cost expenditure, and compute time — and that automated circuit-breaker behavior suspends the agent when any budget is exhausted without relying on agent-side logic as the enforcement mechanism.", "evidence_required": [ "Per-agent resource budget configuration showing explicit API call rate limits, token consumption caps, cost ceilings, and compute time limits stored in platform infrastructure", "Platform enforcement logs from the test period showing budget enforcement events including circuit-breaker activations, with agent identifier, limit type, and threshold crossed", "Alert configuration records showing budget threshold alerts are wired to an on-call operations response path with defined SLA", "Load test results confirming circuit-breaker behavior triggers at or within the configured thresholds under simulated overload without agent-side intervention" ], "machine_tests": [ "Drive an agent to exceed its configured per-agent API call rate limit and assert the platform blocks further calls without any agent-side logic being invoked", "Simulate token consumption exceeding the per-agent cap within a session and assert the platform suspends the agent session before the cap is exceeded by more than a defined tolerance", "Verify budget configuration is stored in platform infrastructure inaccessible to the agent runtime identity and cannot be modified through agent-callable APIs", "Confirm that circuit-breaker activation events generate alerts delivered to the operations team within the configured SLA window" ], "human_review": [ "Review that budget limits reflect the agent's authorized operational workload scope rather than the maximum technically available under the platform's service quotas", "Assess whether circuit-breaker response procedures include investigation and root-cause analysis steps before the agent is permitted to resume operation", "Confirm that multi-agent orchestration configurations have aggregate budget enforcement to prevent a single agent from spawning sub-agents to evade individual-agent limits" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Setting per-agent budget limits at the platform service quota maximum rather than scoping them to the agent's authorized operational workload", "Implementing rate limiting or cost controls in the agent's own application code rather than at the platform enforcement layer", "Using soft limits that log budget overages without blocking, relying on manual operator intervention to stop runaway agents", "Defining per-agent limits on a per-call basis only, without aggregate cost or token budget caps that cover sustained burst consumption patterns" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-07", "layer": "AB", "plane": "both", "name": "Behavioral Drift Monitoring", "plain": "Agents must be continuously monitored for behavioral drift — statistically significant divergence from the established behavioral baseline across sessions. Detected drift must trigger automated alerts and a defined investigation and response procedure, since it may indicate model compromise, emergent capability, adversarial manipulation, or unauthorized model substitution.", "threat": { "tags": [ "behavioral-drift", "model-compromise", "emergent-behavior", "supply-chain-substitution" ], "desc": "Agent behavior is not static: models can behave differently across sessions due to prompt context variation, model updates, capability emergence at scale, adversarial fine-tuning, or supply chain substitution of the underlying model. Without continuous behavioral monitoring against a baseline, the enterprise cannot detect when an agent is no longer behaving as authorized. Gradual drift is particularly dangerous because it may go undetected through normal operational review, allowing compromised behavior to become entrenched." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment AI system monitoring" }, { "id": "nist_ai_600_1", "section": "2.9", "title": "Information Security — behavioral compromise signals" }, { "id": "eu_ai_act", "section": "Art. 9(2)(d) & Art. 72", "title": "Risk evaluation from post-market monitoring data" }, { "id": "iso_42001", "section": "§9.1", "title": "AI system monitoring, measurement, and evaluation" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-07 Behavioral Drift Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-07 Behavioral Drift Monitoring control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-07 Behavioral Drift Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-07 Behavioral Drift Monitoring 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-29", "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://agentic/controls/AB-07 Behavioral Drift Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-07 Behavioral Drift Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Behavioral baseline and drift detection pipeline: agent sessions are logged with behavioral fingerprints covering action distribution, tool call patterns, token usage distribution, refusal rate, and response latency. A drift detection service computes statistical distance between current session fingerprints and the registered baseline, alerting when drift exceeds defined thresholds. Baselines are versioned and updated only through authorized change management.", "steps": [ "Define the behavioral fingerprint schema: action_distribution, tool_call_frequency_vector, refusal_rate, token_length_distribution, latency_percentiles, topic_category_distribution.", "Establish a behavioral baseline during initial deployment by collecting fingerprints from a representative sample of authorized sessions.", "Deploy a drift detection service that computes distance between session fingerprints and the baseline using statistical measures such as KL divergence or cosine distance.", "Configure alert thresholds for drift severity levels: advisory (investigation within 5 business days), elevated (investigation within 24 hours), critical (agent suspension pending review).", "Version and protect the behavioral baseline as a controlled artifact; changes to the baseline require the same authorization process as changes to the agent's ASM." ], "ai_engineer": { "summary": "Behavioral fingerprinting must be instrumented in the agent telemetry layer. Design the fingerprint schema to capture the behavioral dimensions most relevant to detecting compromise and emergent capability.", "actions": [ "Instrument the agent runtime to emit behavioral fingerprint events at defined intervals and upon session completion.", "Implement anomaly probes — synthetic inputs with known expected behaviors — that run periodically to detect behavioral changes not visible in normal operational traffic.", "Ensure the drift detection service uses the fingerprint schema version that matches the agent version to prevent false positives from legitimate updates." ], "failure_signals": [ "Agent telemetry not including behavioral fingerprint data in session records.", "No anomaly probes deployed for behavioral regression testing.", "Drift detection service using an outdated baseline following an authorized agent update." ] }, "security_architect": { "summary": "Behavioral drift monitoring is the detection layer for model-layer attacks including adversarial fine-tuning, model substitution, and emergent capability. It must be designed to detect subtle, gradual drift as well as acute behavioral changes.", "actions": [ "Define the threat model for behavioral drift, including expected signatures of model substitution, adversarial fine-tuning, and capability emergence.", "Set drift alert thresholds based on the threat model rather than operational convenience — low false positive rates must not come at the cost of missing genuine compromise.", "Integrate drift alerts into the incident response workflow with a defined playbook for behavioral drift investigation, including model integrity verification steps." ], "failure_signals": [ "Drift thresholds set so high that gradual behavioral manipulation goes undetected.", "No incident response playbook for behavioral drift events.", "Drift detection not covering all deployed agent instances." ] }, "legal_counsel": { "summary": "Behavioral drift monitoring creates a continuous record demonstrating that the enterprise actively monitors AI system behavior — supporting the argument that the enterprise exercised ongoing due diligence over its AI systems.", "actions": [ "Document behavioral drift monitoring as part of the enterprise's AI system post-deployment monitoring procedures required by the EU AI Act and ISO 42001.", "Confirm the drift monitoring record is retained for the period required by applicable regulations and is available for regulatory inspection.", "Assess whether behavioral drift events that result in unauthorized actions trigger incident reporting obligations." ], "failure_signals": [ "No documented post-deployment monitoring procedure referencing behavioral drift detection.", "Behavioral drift records not retained for the regulatory retention period.", "No assessment of whether drift-induced unauthorized actions constitute reportable incidents." ] }, "grc_auditor": { "summary": "Behavioral drift monitoring evidence demonstrates continuous post-deployment oversight of AI agent behavior. Audit baseline integrity, drift alert coverage, and investigation close rates.", "actions": [ "Request the behavioral baseline artifacts for deployed agents and verify they are version-controlled and access-controlled.", "Review the drift alert log and confirm all elevated and critical alerts were investigated and closed within SLA.", "Verify the drift detection service is running and producing signal for all deployed agent instances." ], "metrics": [ "Drift detection coverage: percentage of deployed agents with active behavioral monitoring — target 100%.", "Alert investigation close rate: percentage of drift alerts investigated within SLA — target 100%.", "Baseline integrity: percentage of baselines with valid authorization records for their current version — target 100%." ], "failure_signals": [ "Deployed agents not covered by behavioral monitoring.", "Drift alerts not investigated within SLA.", "Behavioral baseline modified without change management authorization." ] }, "platform_engineer": { "summary": "Behavioral monitoring infrastructure must be deployed as a platform service that collects telemetry from all agents and runs the drift detection pipeline continuously.", "actions": [ "Deploy the fingerprint collection and drift detection pipeline as platform infrastructure, not per-agent tooling.", "Ensure behavioral telemetry is collected from all agent instances, including multi-region deployments, with centralized drift detection.", "Provide an API for security teams to query behavioral baselines, current drift scores, and historical fingerprint data for investigation." ], "failure_signals": [ "Behavioral monitoring deployed as an optional per-agent configuration rather than platform-wide infrastructure.", "Multi-region agent deployments not centrally monitored for behavioral consistency.", "No API for security teams to query behavioral history for investigation support." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Behavioral drift monitoring for AI agents is an emerging capability with limited tooling; most enterprises rely on operational metrics rather than behavioral fingerprinting." }, "capability_risk": { "capability_level": "limited" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI/Agent Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1 — Monitoring and Review", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.1 requires organizations to monitor and track AI systems for changes in performance, accuracy, and behavior. Behavioral drift monitoring directly implements this requirement by establishing baseline performance signatures and detecting statistically significant deviations.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "partial", "rationale": "NIST AI 600-1 §2.9 (Information Security) covers security risks of generative AI, including model compromise and adversarial manipulation that surface as behavioral change. Drift monitoring provides the production detection signal for those compromises.", "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. 9(2)(d) & Art. 72", "fit": "direct", "rationale": "EU AI Act Article 9(2)(d) requires the risk management system to evaluate risks emerging from data gathered through the post-market monitoring system established under Article 72. Behavioral drift monitoring is the operational capability that produces that post-market behavioral data for deployed agents.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.1 — Monitoring and Measurement", "fit": "direct", "rationale": "ISO 42001 requires organizations to evaluate the performance of their AI management system through monitoring and measurement. Behavioral drift monitoring provides the measurement data required to assess whether AI systems continue to perform within their authorized behavioral envelope.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0018 — Backdoor ML Model", "fit": "partial", "rationale": "MITRE ATLAS AML.T0018 (Backdoor ML Model) documents models altered to behave differently under specific trigger conditions. Behavioral drift monitoring, particularly anomaly probes, provides the production-side detection signal for such conditional behavior changes.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard — ongoing monitoring", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The ASL-3 Deployment Standard couples safeguards with ongoing monitoring so that behavioral changes and safeguard failures are detected in production. AB-07's drift monitoring gives an enterprise the same production signal for its own deployed agents.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters and contextual grounding checks — per-request screening", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails evaluates individual requests and responses (content filters, contextual grounding checks); it does not track behavior across time. AB-07's drift monitoring must be built from telemetry outside Guardrails — per-request screening results are one useful input signal, not a drift detector.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent Observability (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Agent Observability control requires continuous visibility into agent behavior in production. Behavioral drift monitoring implements it with baselines and anomaly probes, so behavior change is detected rather than assumed away.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires ongoing monitoring and evaluation of deployed AI systems. Behavioral drift monitoring implements RS3 for agents: baseline behavior is measured, production behavior is continuously compared, and deviations feed evaluation and response.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Measuring capabilities (§3) — ongoing evaluation", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §3 requires ongoing capability measurement so that threshold crossings are detected rather than discovered after the fact. AB-07's behavioral drift monitoring is the production-side counterpart: continuous measurement of whether a deployed agent's behavior has changed.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail and toxicity detection", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer logs agent activity and scores outputs for toxicity — per-event signals a drift-monitoring system can consume. Baseline construction and longitudinal drift comparison, as AB-07 requires, are built outside the Trust Layer.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Baseline establishment; Part IV Phase 8 — Behavior (behavioral conformance, drift)", "fit": "direct", "rationale": "Establish behavioral baselines and measure drift over time (tool-usage patterns, output characteristics, decision distributions), flagging deviations — behavioral drift monitoring.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "AB-07 continuously compares active behavioral fingerprints to a baseline and routes drift alerts to investigation, monitoring model use for anomalous behavior.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that the agent platform continuously compares active behavioral fingerprints…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AB-07", "validation_objective": "Proves that the agent platform continuously compares active behavioral fingerprints against the registered baseline and that all alerts above advisory severity are routed to a documented investigation procedure within the defined SLA. The control is satisfied when the drift detection pipeline produces signal for 100% of deployed agent instances and when all elevated and critical alerts have investigation close records.", "evidence_required": [ "Behavioral baseline artifact with version identifier, sha256 hash, and authorization record confirming the baseline was established through an approved change management process", "Sample of behavioral fingerprint events from at least 10 agent sessions in the audit period containing action_distribution, tool_call_frequency_vector, refusal_rate, token_length_distribution, and latency_percentiles fields", "Drift detection service configuration showing defined threshold levels for advisory, elevated, and critical severity tiers", "Alert log with investigation close records confirming SLA compliance for all elevated and critical alerts in the audit period", "Anomaly probe results demonstrating the detection pipeline returns expected signals on at least one known behavioral deviation scenario" ], "machine_tests": [ "Query the telemetry pipeline and confirm behavioral fingerprint schema fields (action_distribution, tool_call_frequency_vector, refusal_rate, token_length_distribution, latency_percentiles) are present in at least 95% of session records from the past 30 days", "Inject a synthetic session with simulated behavioral drift exceeding the critical threshold and verify an alert is generated and routed within 60 seconds", "Compare the deployed agent version in the registry against the baseline artifact version and fail if the baseline predates the most recent authorized agent update without a corresponding rebaselining record", "Enumerate all production agent instances and confirm each has an active entry in the drift detection service's monitored agent list, flagging any gaps in coverage" ], "human_review": [ "Assess whether drift alert thresholds are calibrated to the threat model — specifically whether they would detect gradual adversarial fine-tuning accumulating over multiple sessions — or are set primarily for operational convenience with low false-positive rate", "Review the incident response playbook for behavioral drift events and confirm it includes model integrity verification steps and criteria for agent suspension pending investigation", "Confirm that behavioral baseline update records exist for every baseline version change and that each change carries an authorization record predating the update" ], "blocking_effect": "requires-review", "normative_status": "voluntary-standard", "anti_patterns": [ "Setting drift thresholds so high that gradual adversarial fine-tuning or model substitution accumulates across sessions without generating alerts, prioritizing operational quiet over detection fidelity", "Using only operational metrics such as latency and error rate as a proxy for behavioral monitoring rather than maintaining behavioral fingerprints that capture action distribution and decision patterns", "Updating the behavioral baseline without authorization records after a detected drift event, which masks the drift rather than investigating its cause and allows compromised behavior to become the new norm", "Running drift detection on a sampled subset of agent instances rather than all deployed instances, leaving gaps where compromised agents may operate undetected" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AB-08", "layer": "AB", "plane": "lifecycle", "name": "BehavioralAttestation Production", "plain": "The BehavioralAttestation (AG-08) artifact must be produced by compiling verified evidence from AB-01 through AB-07, attesting that behavioral controls were in force and operating within defined parameters for the agent session or operational period. The attestation is the consumable compliance evidence package for the AB layer.", "threat": { "tags": [ "attestation-gap", "evidence-tampering", "compliance-failure" ], "desc": "Without a formal attestation artifact, compliance with behavioral controls is asserted rather than evidenced. Assertions cannot be verified by downstream consumers — regulators, auditors, partners, or federated orchestration systems — who need machine-verifiable proof that behavioral controls were operative when an agent acted. A gap in attestation production also creates the risk that behavioral control failures go unrecorded, allowing a compromised or non-compliant period to be obscured from post-incident analysis." }, "standard": [ { "id": "eu_ai_act", "section": "Article 11", "title": "Technical documentation for high-risk AI systems" }, { "id": "iso_42001", "section": "§9.3", "title": "AI management review and evidence compilation" }, { "id": "nist_rmf", "section": "GOVERN 4.2", "title": "Documentation and communication of AI risks and impacts" } ], "sources": [ { "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-29", "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://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AB-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Attestation compilation pipeline: at the end of each agent session — or at a defined interval for long-running agents — the BehavioralAttestation compiler collects evidence records from AB-01 (ASM hash), AB-02 (tool policy decisions), AB-03 (reversibility gate records), AB-04 (output filter verdicts), AB-05 (injection detection results), AB-06 (resource budget ledger snapshot), and AB-07 (drift score and baseline ref). Evidence is canonicalized, a sha256 integrity hash is computed, and the attestation is signed with Ed25519 before being stored in the evidence registry.", "steps": [ "Deploy the BehavioralAttestation compiler as a platform service that collects evidence from all AB-layer control event streams.", "Define the BehavioralAttestation schema with required fields from the Apeiris evidence ontology: evidence_id, actor (agent canonical ID), intent, action, resource, policy (ASM ref), verdict, blocking_effect, confidence, collected_at, valid_until, integrity.hash (sha256), integrity.signature (Ed25519).", "Implement evidence completeness validation: the compiler must verify that all seven AB-layer evidence sources are present before producing a passing verdict; missing sources result in evidence_completeness_status=incomplete.", "Sign completed attestations with the production signing key and publish to the evidence registry with a canonical URI following the pattern apeiris://agentic/controls/AB-08/[session_id].", "Expose the attestation retrieval API with proper authentication so downstream consumers including federated orchestration, auditors, and regulators can verify attestations independently." ], "ai_engineer": { "summary": "Design agent session telemetry to produce clean, structured evidence records from each AB-layer control that the attestation compiler can consume without human intervention.", "actions": [ "Ensure each AB-layer control in the agent runtime emits structured evidence events to the attestation event stream.", "Test attestation compilation end-to-end for both full-evidence (passing verdict) and incomplete-evidence (incomplete status) scenarios.", "Implement session-close events that trigger attestation compilation within the defined SLA." ], "failure_signals": [ "AB-layer controls not emitting structured evidence events to the attestation stream.", "Attestation compiler producing passing verdicts with incomplete evidence sets.", "Attestation compilation SLA exceeded in production." ] }, "security_architect": { "summary": "The BehavioralAttestation is a security artifact — its integrity and non-repudiability must be protected with cryptographic controls. Design the signing infrastructure to prevent attestation forgery or post-hoc modification.", "actions": [ "Implement Ed25519 signing for all attestation artifacts using a hardware-protected signing key.", "Enforce append-only storage for attestation artifacts with immutable audit logs.", "Design the attestation retrieval API with authentication and authorization controls appropriate to the sensitivity of the evidence content." ], "failure_signals": [ "Attestation artifacts stored in mutable storage that allows post-hoc modification.", "Signing key stored in software without hardware protection.", "Attestation retrieval API accessible without authentication." ] }, "legal_counsel": { "summary": "BehavioralAttestation artifacts are the primary legal evidence of behavioral control compliance. Their format, retention, and accessibility must meet the evidentiary standards required by applicable regulations.", "actions": [ "Review the BehavioralAttestation schema and confirm it captures the documentation elements required by EU AI Act Article 11 for high-risk AI systems.", "Confirm attestation retention policy meets the minimum retention period required under the EU AI Act and applicable sector regulations.", "Assess whether the attestation artifact constitutes a valid compliance record for regulatory inspection under the applicable legal framework." ], "failure_signals": [ "BehavioralAttestation schema missing fields required by EU AI Act Article 11 technical documentation requirements.", "Attestation retention period shorter than the minimum regulatory requirement.", "No defined process for producing attestation records in response to a regulatory inspection request." ] }, "grc_auditor": { "summary": "BehavioralAttestation artifacts are the evidence package auditors use to verify AB-layer control compliance. Audit completeness, signing integrity, and retrieval accessibility.", "actions": [ "Request BehavioralAttestation artifacts for a sample of agent sessions and verify signature validity using the published public key.", "Confirm evidence_completeness_status is present in every attestation and that incomplete attestations are flagged for investigation.", "Verify the attestation registry API is functional and that auditors can independently retrieve and verify attestations." ], "metrics": [ "Attestation production rate: percentage of agent sessions producing a BehavioralAttestation within SLA — target 100%.", "Attestation completeness rate: percentage of attestations with evidence_completeness_status=complete — tracked and improving toward target.", "Signature validity rate: percentage of retrieved attestations with valid signatures — target 100%." ], "failure_signals": [ "Agent sessions with no corresponding BehavioralAttestation.", "Attestations with invalid or missing signatures.", "Incomplete attestations not flagged or investigated." ] }, "platform_engineer": { "summary": "The attestation compilation and storage infrastructure must be reliable, append-only, and accessible to authorized consumers. It is a compliance-critical platform component.", "actions": [ "Deploy the attestation compiler as a high-availability platform service with monitoring and alerting for compilation failures.", "Implement append-only evidence storage with immutable audit trails using write-once storage or equivalent controls.", "Expose a standards-compliant attestation retrieval API with versioning and SLA guarantees appropriate to a compliance evidence system." ], "failure_signals": [ "Attestation compiler having service interruptions with no compensating recovery mechanism.", "Evidence storage allowing modification or deletion of existing attestation records.", "Attestation retrieval API not meeting the availability SLA required for regulatory inspection scenarios." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Behavioral attestation as a formally produced, cryptographically signed artifact is a novel control; most enterprises produce compliance documentation manually rather than as continuous automated evidence." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Platform Engineering", "GRC Team", "AI/Agent Engineering" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Article 11 — Technical Documentation", "fit": "direct", "rationale": "EU AI Act Article 11 requires providers of high-risk AI systems to maintain technical documentation demonstrating conformity with regulatory requirements. The BehavioralAttestation artifact is the machine-readable technical documentation for the AB-layer behavioral controls, compiled per-session to demonstrate continuous compliance.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.3 — Management Review", "fit": "direct", "rationale": "ISO 42001 requires management review of AI system performance evidence. BehavioralAttestation artifacts provide the structured performance and compliance evidence that feeds the ISO 42001 management review process, replacing ad-hoc evidence collection with systematically produced attestations.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 4.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 4.2 requires teams to document the risks and impacts of deployed AI technology and communicate about them. The BehavioralAttestation is the per-deployment documentation artifact recording which behavioral controls operated and what they observed.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require records demonstrating that responsible AI practices were followed. The BehavioralAttestation is that record for agent behavior: a per-deployment artifact documenting which behavioral controls operated and what they observed.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 6 — Contextualize AI system risks in surrounding business processes", "fit": "adjacent", "rationale": "Google SAIF element 6 (Contextualize AI system risks) requires understanding AI behavior in the context of surrounding business processes. Per-session BehavioralAttestations provide the contextual record needed to assess whether agent behavior stayed within business-process expectations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3 (Risk Reports) institutionalizes documented, reviewable evidence that safeguards were in place for a given deployment decision. The BehavioralAttestation applies the same pattern per agent deployment: a structured artifact recording which behavioral controls operated and what they observed.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "ApplyGuardrail API — per-request policy evaluation results", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails returns per-request policy evaluation results (via the ApplyGuardrail API and guardrail trace in agent invocations). Those results are evidence inputs a BehavioralAttestation can cite for Bedrock-hosted agents; the attestation artifact itself is produced by AB-08, not by Guardrails.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Safeguards Reports (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. The framework's Safeguards Reports document which safeguards were in place and how they performed, supporting deployment decisions. The BehavioralAttestation applies the same documented-safeguards pattern per enterprise agent deployment.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. Such retained records are evidence inputs to a BehavioralAttestation for Salesforce-hosted agents; the attestation artifact itself is produced by the enterprise's evidence pipeline, not by the Trust Layer.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AB-08", "validation_objective": "Proves that the BehavioralAttestation (AG-08) artifact is produced for every agent session within the defined SLA, contains cryptographically verified evidence from all seven AB-layer controls, and is stored in append-only evidence storage with a valid Ed25519 signature that downstream consumers can independently verify.", "evidence_required": [ "BehavioralAttestation artifact sample covering at least five agent sessions, each with evidence_id, actor, intent, action, resource, policy, verdict, blocking_effect, confidence, collected_at, valid_until, integrity.hash (sha256), and integrity.signature (Ed25519) fields populated", "Evidence completeness validation log confirming all seven AB-layer evidence sources were verified as present before any passing verdict was issued in the sample period", "Signing key management record demonstrating the Ed25519 signing key is hardware-protected and access is restricted to the attestation compiler service identity", "Attestation storage configuration or audit log confirming append-only enforcement with no modification or deletion operations permitted on existing attestation records", "Attestation retrieval API documentation and authentication configuration showing that only authorized consumers can retrieve attestation content" ], "machine_tests": [ "Fetch a random sample of BehavioralAttestation artifacts from the retrieval API and verify Ed25519 signature validity against the published public key, failing if any signature is invalid or absent", "Attempt to modify or delete an existing attestation record in the evidence store and confirm the operation is rejected with an access control or immutability error before any change is persisted", "Submit an AB-layer evidence package with one missing source to the attestation compiler and verify evidence_completeness_status is set to incomplete and the verdict is not set to pass", "Measure attestation compilation latency from session close event to attestation publication and confirm it does not exceed the defined SLA threshold for the sampled sessions" ], "human_review": [ "Assess whether the BehavioralAttestation schema captures all documentation elements required by EU AI Act Article 11 for the agent's risk classification tier, including the fields needed to demonstrate conformity with applicable requirements", "Review the attestation retention schedule and confirm the defined retention period meets the minimum required under the EU AI Act and any applicable sector regulations", "Confirm that a documented procedure exists for producing attestation records in response to a regulatory inspection request within a timeframe consistent with applicable statutory response obligations" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Producing attestations that assert behavioral compliance without verifying evidence completeness — issuing a passing verdict when evidence from one or more AB-layer controls is absent or unverified", "Storing attestation artifacts in mutable storage that allows post-hoc modification, making the attestation unreliable as legal or regulatory evidence because its integrity cannot be independently confirmed", "Issuing a single attestation per deployment period rather than per agent session, preventing downstream consumers from tracing a specific agent action to a verified and time-bounded evidence state", "Omitting the Ed25519 signature field or substituting a sha256 digest without asymmetric signing, which prevents independent signature verification by parties who do not have access to the evidence store" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AB" }, { "id": "AT-01", "layer": "AT", "plane": "control", "name": "Tool and Plugin Registry", "plain": "Every tool and plugin an agent can invoke must have an authoritative registry entry recording its capability description, owner, risk classification, version, and approval status before it is available for use.", "threat": { "tags": [ "shadow-plugin", "unauthorized-tool-invocation", "capability-sprawl", "supply-chain-compromise" ], "desc": "Without a centralized tool registry, agents accumulate access to unreviewed plugins and deprecated endpoints that bypass security review. Untracked tools may carry hidden capabilities, vulnerabilities, or malicious logic introduced through supply chain compromise. Ungoverned capability inventories make it impossible to assess the true action surface of any agentic system, undermining every downstream governance control." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 1.6", "title": "AI system inventory mechanisms" }, { "id": "iso_42001", "section": "§7.1", "title": "Resources" }, { "id": "eu_ai_act", "section": "Art. 11 & 17", "title": "Technical documentation and quality management for high-risk AI" } ], "sources": [ { "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-29", "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://agentic/controls/AT-01 Tool and Plugin Registry control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-01 Tool and Plugin Registry control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-01 Tool and Plugin Registry control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-01 Tool and Plugin Registry control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "title": "OWASP Artificial Intelligence Security Verification Standard v1.0", "authority": "OWASP Foundation", "source_type": "standard", "normative_force": "best-practice", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-29", "canonical_url": "https://github.com/OWASP/AISVS", "license": "open-access", "status": "current", "flagship": false, "source_id": "owasp_aisvs_v1", "relationship": "informative_reference", "rationale": "Establishes OWASP Artificial Intelligence Security Verification Standard v1.0 requirements informing the apeiris://agentic/controls/AT-01 Tool and Plugin Registry control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain an append-only tool registry with versioned entries; each entry records capability manifest, owner, risk tier, approval date, and a cryptographic hash of the tool specification. The registry is the gate — agents cannot invoke unregistered tools at runtime.", "steps": [ "Deploy a centralized tool registry API with create and update operations gated on a formal review workflow; each entry must include tool ID, capability description, owner identity, risk classification (low/medium/high/critical), approval status, and semantic version.", "Integrate registry enforcement into the agent runtime so any tool invocation against an unregistered or unapproved tool ID is blocked and logged before execution — agents must fail closed, not open.", "Establish a quarterly registry reconciliation process comparing active tool invocations from execution logs against registry entries to identify shadow tools, orphaned registrations, and version drift.", "Require a new review cycle and registry update whenever a tool specification changes materially, including changes to its API surface, data access scope, or external integrations." ], "ai_engineer": { "summary": "The registry is the authoritative source of truth for what tools exist and are permitted. Build tool invocation to check registry status before calling any external capability.", "actions": [ "Implement a registry lookup at agent startup that loads the approved tool manifest for the agent's configured role and caches it for the session.", "Add runtime enforcement so invocations to tool IDs absent from the current approved manifest return a blocked error rather than silently failing or falling through." ], "failure_signals": [ "Agent successfully calls a tool ID not present in the registry.", "Registry entries exist without owner or risk classification fields populated." ] }, "security_architect": { "summary": "The registry is a security boundary. Treat unapproved tools as untrusted surfaces — they must never be reachable by production agents regardless of configuration.", "actions": [ "Define risk classification criteria for tools: low (read-only, internal data), medium (external reads, write to internal state), high (external writes, irreversible actions), critical (financial, deletion, privileged system access).", "Require dual-approval sign-off for high and critical risk tools before a registry entry can be set to approved status." ], "failure_signals": [ "High or critical risk tools approved without dual sign-off evidence in the review record.", "Production agents calling tools classified as deprecated or pending-review." ] }, "grc_auditor": { "summary": "The registry is the primary artifact for demonstrating tool governance completeness. Audit against it to confirm all active tools are inventoried, risk-classified, and owner-assigned.", "actions": [ "Request a full registry export and cross-reference against agent execution logs to identify any invocations of unregistered tools in the audit period.", "Sample 15% of registry entries and verify that the owner identity is active, risk classification is populated, and approval date is within the current annual review cycle." ], "metrics": [ "Registry completeness rate: percentage of tools invoked in the last 90 days with a registry entry; target 100%.", "Orphaned tools rate (no active owner): target zero at end of each quarter." ], "failure_signals": [ "Registry completeness below 95% of tools appearing in execution logs.", "More than 5% of registry entries missing risk classification or owner binding." ] }, "legal_counsel": { "summary": "The tool registry is the authoritative record of the enterprise's agent action surface. Regulators and auditors will ask what the agents could do; an incomplete registry means the enterprise cannot answer — and unregistered tools are ungoverned capabilities operating without documented approval.", "actions": [ "Confirm the registry's approval workflow creates a documented authorization trail for every tool, including who accepted the risk classification.", "Verify third-party tool entries record the vendor, license terms, and data-handling posture needed for supply-chain and privacy compliance.", "Ensure registry history is retained so the tool set available to an agent at a past date can be reconstructed for investigations." ], "failure_signals": [ "Tools invocable by production agents that do not appear in the registry — capabilities with no authorization record.", "Registry entries missing vendor and data-handling terms for tools that transmit regulated data.", "Inability to reconstruct the historical tool surface when an incident or regulator asks what an agent could do last quarter." ] }, "platform_engineer": { "summary": "The registry must be operationally reliable and integrated into deployment pipelines so tool additions require a registry gate before reaching production.", "actions": [ "Deploy the registry as a high-availability service with an SLA matching the agent platform; implement a read-only cache so agent startup is not blocked by transient registry unavailability.", "Add a CI/CD gate that fails builds referencing tool IDs not present in the approved registry, preventing deployment of agents with unregistered tool configurations." ], "failure_signals": [ "Registry service downtime causing agents to fail open and allow all tool invocations.", "Tool IDs in merged agent configurations that do not resolve in the registry at deploy time." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have no formal tool registry separate from agent configuration files, leading to untracked capability accumulation and ungoverned shadow plugins." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Platform Engineering", "Security Architecture", "AI/ML Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 1.6", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.6 requires mechanisms to inventory AI systems and resource them according to organizational risk priorities. A governed tool and plugin registry is that inventory for the agent tool layer: every tool an agent can invoke is registered, risk-classified, and owned.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§7.1 — Resources", "fit": "partial", "rationale": "ISO/IEC 42001 §7.1 requires the organization to determine and provide the resources needed for the AI management system. A governed tool registry determines and documents exactly which tool resources agent systems depend on, with ownership, risk classification, and approval state.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11 & 17", "fit": "direct", "rationale": "EU AI Act Articles 11 and 17 require high-risk AI providers to maintain technical documentation covering all integrated components and to implement a quality management system for dependencies. A tool registry supports both requirements by providing documented traceability of every integrated tool and plugin. For high-risk systems, the registry forms part of the technical documentation that national authorities may request for conformity assessment.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Element 1 — Expand strong security foundations to the AI ecosystem", "fit": "direct", "rationale": "Google SAIF element 1 includes maintaining foundational visibility into the components and dependencies of AI systems. A governed tool registry with risk classification and approval workflow establishes that visibility for the agent tool supply chain.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0010 — AI Supply Chain Compromise", "fit": "partial", "rationale": "MITRE ATLAS AML.T0010 (AI Supply Chain Compromise) documents compromise of AI system components — including tools and integrations — as an adversarial technique. A tool registry with cryptographic hashes of tool specifications enables detection of tampered tool definitions.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "source_version": "v2026.06", "basis": "anchored", "relation": "defends_against" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require organizations to understand and document what their AI systems can do and who owns those capabilities. A governed tool registry documents the full action surface of deployed agents with named ownership and approval state.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C9.3.3 / C9.3.7", "fit": "direct", "rationale": "OWASP AISVS v1.0 requires agent tools to be described by registered manifests (C9.3.3) and constrained to a registry-backed allowlist (C9.3.7). AT-01's governed tool registry with cryptographic manifests and approval workflow is the direct implementation of both requirements.", "normative_force": "best-practice", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 5 — Tool allow-listing (explicit lists of permitted tools per agent function)", "fit": "direct", "rationale": "Doc requires maintaining explicit lists of permitted tools per agent function and governing the tool/plugin registry (reject unlisted).", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AT-01", "validation_objective": "Proves that every tool invoked by any agent in the deployment has an authoritative registry entry with populated capability description, owner identity, risk classification, version, and approval status, and that the agent runtime blocks invocations of unregistered or unapproved tools before execution reaches any tool executor.", "evidence_required": [ "Full tool registry export with all entries showing tool ID, capability description, owner identity, risk classification (low/medium/high/critical), semantic version, approval status, and approval date", "Execution log extract from the past 90 days cross-referenced against the registry, confirming all invoked tool IDs have a corresponding registry entry with approved status", "Runtime enforcement log showing at least one blocked invocation attempt on an unregistered or unapproved tool ID, or an adversarial test artifact demonstrating enforcement is active", "Dual-approval sign-off records for all tools classified as high or critical risk in the registry", "Most recent quarterly registry reconciliation report identifying any shadow tools, orphaned registrations, or version drift, with documented remediation records" ], "machine_tests": [ "Attempt to invoke a tool ID not present in the registry from a test agent session and confirm the call is blocked and logged before any tool executor is reached, with the agent receiving a structured blocked-tool error", "Cross-reference all tool IDs appearing in agent execution logs from the past 90 days against the registry export and report any tool IDs that have no matching registry entry or have a non-approved status", "Validate every registry entry has owner identity, risk classification, and approval status fields populated and fail if any entry has a null or empty value in those required fields", "Simulate registry service unavailability and confirm the agent runtime fails closed — blocking all tool invocations rather than allowing unapproved calls through during the outage window" ], "human_review": [ "Assess whether risk classification criteria are applied consistently across all high and critical risk tools, or whether classification decisions appear driven by operational convenience rather than capability and impact analysis", "Review the quarterly registry reconciliation report and confirm that identified shadow tools or orphaned registrations have documented remediation records with completion dates", "Confirm the approval workflow for new registry entries enforces dual sign-off for high and critical risk tools and that this requirement is not routinely bypassed through emergency approval exceptions" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating agent configuration files such as tool spec lists in deployment YAML as equivalent to a governed registry — configuration files have no formal review workflow, risk classification, or owner accountability and do not constitute a registry for governance purposes", "Allowing agents to fail open when the registry service is unavailable, granting all tool invocations rather than blocking unapproved calls, which defeats the registry's security function during the most likely attack window", "Maintaining a registry with entries that are used as documentation artifacts rather than enforced at runtime, so tools can be invoked regardless of their registry approval status", "Approving tools at the tool-class level rather than per-version, allowing updated tool versions with materially changed capability surfaces to enter production without triggering a new risk classification and approval cycle" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-02", "layer": "AT", "plane": "control", "name": "Tool Permission Scoping", "plain": "Each agent must be granted access only to the specific tools, operations, and parameter ranges it requires to perform its defined function, with permissions denied by default and explicitly granted at the minimum scope necessary.", "threat": { "tags": [ "privilege-escalation", "over-permissioned-agent", "lateral-movement", "excessive-agency" ], "desc": "Agents granted broad tool access beyond their operational requirements create a large blast radius when compromised or manipulated. A prompt-injected or malfunctioning agent with excessive permissions can invoke destructive operations outside its intended scope without any additional authorization barrier. Over-permissioned agents are a primary vector for lateral movement in agentic environments, where surplus permissions allow a compromised agent to affect systems entirely unrelated to its purpose." }, "standard": [ { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — over-permissioned tool access" }, { "id": "nist_rmf", "section": "MANAGE 1.3", "title": "Planned, documented responses to prioritized AI risks" }, { "id": "microsoft_rai", "section": "RS1", "title": "Reliability and safety guidance — operating within the approved envelope" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system and proportionality of AI system capabilities" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-02 Tool Permission Scoping control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-02 Tool Permission Scoping control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-02 Tool Permission Scoping control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-02 Tool Permission Scoping control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-02 Tool Permission Scoping control.", "reviewed_on": "2026-07-02" }, { "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 — provides concrete IaC patterns for the controls in this layer.", "reviewed_on": "2026-07-02", "title": "HashiCorp Vault AI Agent Authorization Pattern", "version": "2026", "canonical_url": "https://www.hashicorp.com/en/blog/advancing-ai-agent-security-in-vault", "published_on": "2026-01-01" }, { "id": "databricks_omnigent_2026", "title": "Databricks Omnigent — 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 evaluates each tool call against session-state contextual policies that return ALLOW / DENY / transform based on accumulated session context, illustrating runtime tool-permission scoping.", "reviewed_on": "2026-07-07" } ], "implementation": { "pattern": "Define per-agent permission profiles that enumerate allowed tool IDs, permitted operations per tool, and acceptable parameter value ranges; enforce profiles at the agent runtime layer so requests outside the profile are rejected before execution.", "steps": [ "For each agent role, enumerate only the tool IDs it legitimately requires and document the business justification; within each tool grant, specify permitted operations (e.g., read-only vs. read-write) and any parameter-level constraints such as allowed target schemas or maximum transaction values.", "Implement an enforcement layer in the agent runtime that validates every tool call against the agent's permission profile before forwarding to the tool executor; out-of-profile requests must be blocked, logged with full call context, and trigger an alert.", "Review permission profiles quarterly and after any significant change to agent function; use tool usage logs to identify surplus grants and revoke permissions unused for 90 or more consecutive days.", "Establish a formal exceptions process for temporary elevated permissions: grants must be time-bounded, approved by a designated authority, and automatically expire without manual renewal." ], "ai_engineer": { "summary": "Build agents with the minimum tool set required. Resist pre-granting tools speculatively — permissions must reflect actual operational requirements proven by design review.", "actions": [ "Enumerate the exact tools and operations required for each agent task during design; record this as the permission profile specification before any code is written.", "Implement the enforcement layer to reject tool calls against the permission profile at runtime prior to invoking any tool executor, and surface clear error context for debugging without exposing sensitive profile details." ], "failure_signals": [ "Permission profiles containing tools not invoked in any execution log over 90 days.", "Tool calls blocked by the enforcement layer at a rate suggesting profiles are misconfigured rather than attacks being repelled." ] }, "security_architect": { "summary": "Tool permission scoping is the primary blast-radius control for agentic systems. Treat it as a segmentation boundary — agents should only reach the tools their function requires.", "actions": [ "Design permission profiles using an allowlist model — deny by default, explicitly permit only what is required with supporting justification.", "Implement parameter-level constraints for high-risk tools to limit scope even when the tool itself is permitted, such as restricting file-write tools to a defined directory tree." ], "failure_signals": [ "Any agent permission profile that includes wildcard grants covering all operations on a tool.", "High-risk tools permitted to agents whose documented function does not require them." ] }, "grc_auditor": { "summary": "Permission scoping evidence demonstrates least-privilege compliance for agentic systems. Audit profiles against actual usage to identify over-provisioning and verify review cadence.", "actions": [ "Request permission profile exports for all production agents and compare granted tool operations against tool usage logs for the trailing 90 days.", "Identify tools granted but never used and raise them as over-provisioning findings requiring remediation within 30 days; track remediation to closure." ], "metrics": [ "Over-provisioning rate: percentage of granted tool permissions unused in 90 days; target below 5%.", "Profile review coverage: percentage of profiles reviewed within the last 12 months; target 100%." ], "failure_signals": [ "Over-provisioning rate exceeds 20% of granted permissions across the production agent fleet.", "Agents with wildcard or all-operations grants on any tool classified as medium risk or above." ] }, "legal_counsel": { "summary": "Least-privilege tool permission profiles are how the enterprise demonstrates proportionality: each agent holds only the capabilities its approved function requires. Over-permissioned agents convert every compromise into a broader legal event than it needed to be.", "actions": [ "Confirm permission profiles are documented and mapped to each agent's approved business function, so grants can be justified individually.", "Verify periodic recertification of agent permissions is recorded — stale grants are the norm without forced review.", "Assess whether any agent's permission set exceeds the enterprise's legal authority over the affected data or systems." ], "failure_signals": [ "Agents holding tool permissions with no documented link to an approved function.", "No recorded recertification cycle, leaving permission sprawl undetected and indefensible.", "Permission grants enabling processing that privacy notices or contracts do not permit." ] }, "platform_engineer": { "summary": "The enforcement layer must be deeply integrated into the tool execution pathway so it cannot be bypassed by misconfiguration or direct tool calls that skip the agent runtime.", "actions": [ "Deploy permission enforcement as a middleware component in the tool execution pipeline, not as an optional agent-level check that could be omitted in custom agent implementations.", "Implement automated profile drift detection that alerts when a deployed agent's actual invocation patterns diverge significantly from its declared permission profile." ], "failure_signals": [ "Tool executor components reachable by agents without passing through the permission enforcement middleware.", "Deployed permission profiles that differ from the profiles reviewed and approved in the registry." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most deployments grant agents broad tool access at creation and never revisit; per-operation and parameter-level constraints are rare even in security-conscious organizations." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI/ML Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) identifies over-permissioned tool access as a top risk, where agents can take unintended actions through excessive function grants. Least-privilege permission profiles are the direct mitigation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2025", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_rmf", "requirement_id": "MANAGE 1.3", "fit": "partial", "rationale": "NIST AI RMF MANAGE 1.3 requires responses to high-priority AI risks to be developed, planned, and documented. Excessive tool permissions are a documented top risk for LLM agents (OWASP LLM06:2025); least-privilege permission profiles are the planned, documented treatment for that risk.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1 — Reliability and safety guidance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 requires systems to be designed to operate within their intended envelope. Least-privilege tool permission profiles keep each agent's effective capability inside the envelope its review approved, rather than inheriting the union of all available tools.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9 Risk Management System", "fit": "direct", "rationale": "EU AI Act Article 9 requires high-risk AI systems to implement risk management measures proportionate to the risks they pose, including controlling the scope of system actions. The Act's proportionality principle directly supports the least-privilege approach of granting only the permissions required for the system's intended purpose. Overly broad tool permissions would constitute an inadequate risk management measure under Article 9.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.1 — Monitoring, measurement, analysis and evaluation", "fit": "partial", "rationale": "ISO/IEC 42001 §9.1 requires determining what needs to be monitored and evaluated for the AI management system. Verifying that agents operate within their granted permission profiles — and detecting grants that exceed the defined function — is a monitoring obligation this control makes testable.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "partial", "rationale": "NIST AI 600-1 §2.9 (Information Security) recommends applying established security practices — including least-privilege access — to generative AI systems. Tool permission scoping applies least privilege at the agent tool boundary, bounding what a compromised or manipulated agent can do.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy category treats the breadth of capability an AI system can exercise independently as a core risk driver. Least-privilege tool permission profiles directly narrow that breadth for deployed agents.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Agent Permissions control explicitly calls for agents to receive only the tool access required for their defined function. Least-privilege permission profiles are the direct implementation of that recommendation.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Denied topics", "fit": "partial", "rationale": "Amazon Bedrock Guardrails' denied topics restrict the content domains an agent will engage with — a content-level analog of permission scoping. Tool-level least privilege (which functions an agent can call) is configured in Bedrock Agents and IAM, outside Guardrails; AT-02 defines the platform-neutral permission-profile pattern.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 5 — Capability restrictions; Part IV Phase 3 — Scope limits / Least Agency", "fit": "direct", "rationale": "Capability restrictions limit what permitted tools can do (read-only; send requires separate authorization; RBAC on the provisioned account) — tool permission scoping.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "direct", "rationale": "AT-02 binds each agent role to a permission profile enumerating only the specific tools and operations it needs and rejects the rest, directly implementing least model privilege.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that each deployed agent role is bound to a permission profile that enumerates…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that each deployed agent role is bound to a permission profile that enumerates…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that each deployed agent role is bound to a permission profile that enumerates…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AT-02", "validation_objective": "Proves that each deployed agent role is bound to a permission profile that enumerates only the specific tool IDs, operations, and parameter constraints it requires, and that the agent runtime rejects and logs any tool call outside the defined profile before execution reaches any tool executor.", "evidence_required": [ "Per-agent permission profile specifications for all deployed agent roles documenting allowed tool IDs, permitted operations per tool, parameter-level constraints, and business justification for each grant", "Runtime enforcement log confirming that out-of-profile tool calls are blocked and logged with full call context including tool ID, operation, parameters, and agent session ID", "Permission review records from the most recent quarterly review cycle including evidence of surplus grant identification and revocation decisions", "Exceptions log for temporary elevated permissions showing time-bounded grants, the designated approving authority, and expiration timestamps confirming automatic revocation", "Tool usage log analysis from the past 90 days identifying permissions unused for 90 or more consecutive days and documented remediation records for each identified surplus grant" ], "machine_tests": [ "Attempt to invoke a tool operation outside the agent's permission profile from a test session and confirm the call is blocked and logged before the tool executor is reached, with a structured rejection error returned to the agent", "Scan all active permission profiles and report any tool ID grants where no matching invocation appears in the past 90-day execution log, flagging them as potential surplus permissions requiring review", "Verify that all temporary elevated permission grant records include an expiration timestamp and confirm that no expired temporary grants remain in an active state in the permission enforcement layer", "Confirm that deployed permission profile versions are versioned and that each agent's deployed profile version matches the most recently reviewed and authorized version in the approval record" ], "human_review": [ "Assess whether permission profiles reflect the agent's actual operational requirements as demonstrated by execution logs, or contain speculative pre-grants added during initial configuration without documented business justification", "Review surplus permission candidates identified by automated scanning and confirm that revocation decisions are appropriately authorized and that remediation timelines are consistent with the quarterly review SLA", "Confirm that the exceptions process for temporary elevated permissions requires time-binding and approval by a designated authority rather than allowing self-service escalation by the agent owner or operator" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Granting all tools registered in the registry to a new agent role as a default starting point and expecting permission trimming to occur post-deployment, which inverts the principle of least privilege and creates an over-permissioned window during initial operation", "Scoping permissions at the tool level without restricting operations within each tool, allowing a read-only agent to perform write operations on a tool that supports both read and write without any additional authorization", "Using shared permission profiles across agent roles with different operational requirements, which creates over-permission for lower-risk roles and makes the profile useless as evidence of least-privilege enforcement", "Failing to review and update permission profiles after changes to agent function, leaving stale grants in place that expand the blast radius beyond the agent's current operational purpose" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "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" } ], "layer_code": "AT" }, { "id": "AT-03", "layer": "AT", "plane": "control", "name": "Tool Input Validation and Schema Enforcement", "plain": "All inputs passed to tools by an agent must be validated against the tool's declared parameter schema before execution, rejecting malformed, out-of-range, or structurally invalid calls to prevent injection attacks and unintended tool behavior.", "threat": { "tags": [ "prompt-injection-to-tool", "schema-bypass", "malformed-call-exploitation", "indirect-injection" ], "desc": "Agents that pass unvalidated inputs to tools can be weaponized through prompt injection to construct malicious tool calls that exploit downstream systems. Attackers who inject content into an agent's context can craft parameters that cause tools to operate on unintended targets, exfiltrate data, or trigger unsafe states in connected services. Without schema enforcement, tool interfaces become a direct path from attacker-controlled input to backend system exploitation." }, "standard": [ { "id": "owasp_llm10", "section": "LLM01:2025 & LLM05:2025", "title": "Prompt Injection and Improper Output Handling leading to tool exploitation" }, { "id": "nist_ai_600_1", "section": "2.9", "title": "Information Security — input validation for generative AI" }, { "id": "google_saif", "section": "Input Validation and Sanitization", "title": "SAIF control — validating content entering AI systems" } ], "sources": [ { "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-29", "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://agentic/controls/AT-03 Tool Input Validation and Schema Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-03 Tool Input Validation and Schema Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-03 Tool Input Validation and Schema Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-03 Tool Input Validation and Schema Enforcement control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a schema registry for each tool's accepted parameters; implement validation middleware that checks all agent-generated tool calls against the registered schema before the call reaches the tool executor. Reject and log all calls that fail validation.", "steps": [ "Publish a formal parameter schema for every registered tool, specifying field names, types, value constraints (min/max, enum sets, regex patterns), and required vs. optional fields; version schemas alongside tool versions in the registry.", "Deploy a validation middleware layer that receives all agent-generated tool calls, resolves the appropriate schema from the registry, and validates the call against it before passing to the tool executor; validation failures must produce a blocked result with structured error context.", "Implement context-aware validation for string parameters that may carry attacker-influenced content: apply length limits, character-set restrictions, and pattern matching to prevent injection payloads from passing through as structurally valid strings.", "Log all validation failures with the full call context including agent identity, tool ID, parameter name, and the nature of the violation to enable injection attempt detection and pattern analysis." ], "ai_engineer": { "summary": "Treat every value passed to a tool as untrusted regardless of where it originated in the agent's context. Schema enforcement is a non-negotiable defense layer between the agent's reasoning and tool execution.", "actions": [ "Integrate schema validation as a blocking middleware step in the tool invocation pipeline; the tool executor must never receive a call that has not passed schema validation.", "For string parameters, implement additional content-level checks beyond structural validation: limit lengths, restrict to expected character sets, and flag patterns consistent with injection payloads." ], "failure_signals": [ "Tool executor receiving calls that were not passed through the validation middleware.", "Schema validation pass rates of 100% for all calls — this may indicate schemas are too permissive rather than that inputs are genuinely clean." ] }, "security_architect": { "summary": "Schema enforcement is the primary defense against prompt injection reaching downstream tool systems. Design it as a mandatory, bypass-proof layer in the execution pipeline.", "actions": [ "Require that all tool schemas include explicit value constraints beyond data types — bare type schemas that accept any string of any length are insufficient for security purposes.", "Implement anomaly detection on validation failure patterns: a spike in validation failures for a specific agent or tool is a signal of active injection attempts." ], "failure_signals": [ "Tool schemas with string parameters that lack length limits, character-set restrictions, or pattern constraints.", "No alerting on elevated validation failure rates that could signal injection campaigns." ] }, "grc_auditor": { "summary": "Tool input validation is a foundational secure-design control. Audit for schema completeness, middleware deployment, and failure logging to verify the control is operational rather than nominal.", "actions": [ "Request schema exports for all registered tools and assess completeness: verify that string fields have length limits and pattern constraints, not just type declarations.", "Sample tool call execution logs and verify the presence of validation middleware records for every call; absence of validation log entries for some calls indicates bypass paths exist." ], "metrics": [ "Schema completeness rate: percentage of registered tools with fully constrained parameter schemas; target 100%.", "Validation coverage rate: percentage of tool call log entries with corresponding validation middleware records; target 100%." ], "failure_signals": [ "Registered tools with parameter schemas lacking value constraints beyond basic type checks.", "Tool call log entries without corresponding validation middleware records indicating bypass paths." ] }, "legal_counsel": { "summary": "Schema validation at the tool boundary is a technical control with legal significance: it is the mechanism that prevents attacker-controlled content from becoming enterprise-executed actions. Its documented presence supports the defense that harmful inputs were anticipated and guarded against.", "actions": [ "Confirm the input-validation requirement is stated in the enterprise's secure-development or AI-security standard so its absence in any deployment is a documented deviation.", "Verify rejected-input events are logged and retained; they evidence both attack attempts and control operation.", "Assess disclosure posture if a validation bypass allows injected content to reach regulated backend systems." ], "failure_signals": [ "Tool endpoints accepting unvalidated model-generated parameters in deployments certified as following the secure-AI standard.", "No retained record of blocked malicious inputs when demonstrating control effectiveness to auditors.", "A validation bypass incident with no pre-existing documentation that the control was required and monitored." ] }, "platform_engineer": { "summary": "The validation middleware must be architecturally positioned so it cannot be bypassed by alternative execution paths, direct tool calls, or testing shortcuts that persist into production.", "actions": [ "Deploy the validation middleware as a mandatory gateway component in the tool execution architecture; all paths to any tool executor must pass through it, including internal service-to-service calls.", "Implement schema hot-reload so updated tool schemas are applied without requiring agent restarts; track schema version in validation logs to enable investigation of calls processed under prior schema versions." ], "failure_signals": [ "Internal service calls to tool executors that bypass the validation middleware gateway.", "Validation middleware running with stale schema versions after tool specification updates." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agentic platforms perform basic type checking but lack comprehensive value-constraint schemas and content-level injection filtering for string parameters." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI/ML Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM01:2025 & LLM05:2025", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM01 (Prompt Injection) and LLM05 (Improper Output Handling) together describe the pathway where attacker-controlled content in an agent's context flows unvalidated into tool calls, exploiting backend systems. Schema enforcement and input validation at the tool boundary break that pathway.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2025", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "direct", "rationale": "NIST AI 600-1 §2.9 (Information Security) recommends applying established security practices to generative AI systems, including validation of content crossing trust boundaries. Treating model-generated tool parameters as untrusted input and validating them against schemas is that practice at the agent tool boundary.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Input Validation and Sanitization (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Input Validation and Sanitization control requires validating content flowing into and through AI systems. Schema enforcement on tool inputs treats model-generated parameters as untrusted, validating them before they reach backend systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051 – LLM Prompt Injection", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 documents prompt injection as an adversarial tactic targeting LLM-based agents, specifically including injection attacks that propagate through agent tool calls to backend systems. Tool input schema enforcement is a key detection and prevention technique for this tactic by blocking structurally anomalous calls that may represent injected payloads. ATLAS identifies the tool invocation boundary as a critical defensive checkpoint.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "source_version": "v2026.06", "basis": "anchored", "relation": "defends_against" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires predictable failure modes to be identified and remediated. Malformed or adversarial parameters flowing from model output into backend tools are a predictable failure class; schema validation at the tool boundary is the standing remediation.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters — input screening", "fit": "partial", "rationale": "Amazon Bedrock Guardrails' content filters screen inputs (including the prompt-attack filter) for harmful or policy-violating content before they reach the model. That is content-level screening; AT-03's schema validation of model-generated tool parameters is a structural control enforced at the tool boundary, outside Guardrails.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 5 — Parameter validation; Part III — Input sanitization (validate against expected schemas)", "fit": "direct", "rationale": "Validate tool-call arguments against expected schemas/ranges before execution, agent-side and tool-side.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "anomalousinputhandling", "fit": "supporting", "rationale": "AT-03 validates every tool call against its schema and rejects malformed, out-of-range, or injection-suspect inputs, detecting and handling anomalous inputs at the tool boundary.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0015", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that the agent runtime validates every tool call against the tool's registered…\" enacts ATLAS mitigation AML.M0015 Adversarial Input Detection; OpenCRE crosswalks this control’s OWASP AI Exchange concept (anomalousinputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AT-03", "validation_objective": "Proves that the agent runtime validates every tool call against the tool's registered parameter schema before execution, including content-aware validation for string parameters, and that calls with malformed, out-of-range, structurally invalid, or injection-shaped parameters are rejected and logged before any tool executor processes them.", "evidence_required": [ "Schema registry extract showing formal parameter schemas for all registered tools with field names, types, value constraints (min/max, enum sets, regex patterns), and required versus optional designations versioned alongside tool versions", "Validation middleware deployment evidence showing integration between the agent runtime and the schema registry such that schema resolution occurs before tool executor invocation", "Blocked tool call log entries from the audit period demonstrating schema enforcement is operational, with structured error context captured for each rejection", "Sample of content-aware validation configurations for string parameters showing length limits, character-set restrictions, and pattern matching rules applied to agent-influenced string fields" ], "machine_tests": [ "Submit a tool call with a structurally invalid parameter — wrong type, out-of-range numeric value, or missing required field — and confirm the call is rejected before the tool executor processes it, with a structured validation error returned", "Submit a tool call with a string parameter containing a known prompt injection payload (e.g., an instruction override sequence) and verify that content-aware validation blocks or sanitizes the parameter before it reaches the tool executor", "Verify that schema versions in the registry are aligned with deployed tool versions and flag any mismatches where the schema version does not match the registered tool version", "Confirm that blocked validation events are captured in the audit log with the tool ID, rejection reason, and sufficient parameter context for incident investigation, without exposing sensitive profile details" ], "human_review": [ "Assess whether string parameter validation rules are sufficiently restrictive to resist injection payloads, or are limited to structural checks such as type and length that permit injection-shaped content to pass through as conformant strings", "Review whether tool schema updates go through a formal change review process before being published to the schema registry, or are accepted automatically from tool owners without validation review" ], "blocking_effect": "advisory", "normative_status": "best-practice", "anti_patterns": [ "Validating parameter types and numeric ranges but omitting content-aware validation for string fields, allowing prompt injection payloads to pass through as structurally valid conformant strings", "Publishing tool schemas with permissive constraints such as string length of 10,000 with no pattern restriction, which produces schema conformance without meaningful defense against injection payloads embedded in parameter values", "Running schema validation only in development and test environments and bypassing it in production for performance reasons, removing the enforcement precisely where it is operationally necessary", "Using the same schema definition for both internally-sourced and externally-influenced tool calls, when calls incorporating external data require stricter content-aware constraints than those applied to purely internal inputs" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-04", "layer": "AT", "plane": "data", "name": "Tool Output Sanitization and Integrity Verification", "plain": "All outputs returned by tools to an agent must be verified against expected response schemas, sanitized to remove injected content, and confirmed to be within expected structural bounds before being incorporated into the agent's context or reasoning.", "threat": { "tags": [ "indirect-prompt-injection", "tool-response-poisoning", "data-exfiltration-via-context", "output-integrity-violation" ], "desc": "Adversaries who control data sources accessible to tools can inject content into tool responses that hijacks subsequent agent reasoning, steals context, or causes the agent to take unauthorized actions. Tool responses that violate expected schemas may indicate compromised data sources or man-in-the-middle interference in the tool communication channel. Unsanitized tool outputs that become part of the agent's context create a persistent injection surface that affects all subsequent agent decisions in the session." }, "standard": [ { "id": "owasp_llm10", "section": "LLM05:2025", "title": "Improper Output Handling — indirect injection via tool responses" }, { "id": "nist_ai_600_1", "section": "2.8", "title": "Information Integrity — integrity of tool responses" }, { "id": "mitre_atlas", "section": "AML.T0051", "title": "LLM Prompt Injection — indirect injection via retrieved content" }, { "id": "google_saif", "section": "Element 3", "title": "Automate defenses — automated sanitization of AI data paths" } ], "sources": [ { "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-29", "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://agentic/controls/AT-04 Tool Output Sanitization and Integrity Verification control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-04 Tool Output Sanitization and Integrity Verification control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-04 Tool Output Sanitization and Integrity Verification control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-04 Tool Output Sanitization and Integrity Verification control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AT-04 Tool Output Sanitization and Integrity Verification control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement an output sanitization and verification middleware that intercepts all tool responses before they enter the agent context: validate structure against response schemas, strip or escape content matching injection pattern signatures, and verify integrity where the tool provides response signatures or checksums.", "steps": [ "Publish response schemas for every registered tool alongside the input parameter schemas; define expected field structure, value types, and any field-level content constraints for tool outputs.", "Deploy output sanitization middleware that receives all tool responses before they are incorporated into agent context: validate structure against the response schema, apply HTML/markdown escape and injection-signature stripping to string fields that may carry user-influenced content, and flag structural anomalies.", "For tools that return data from external or third-party sources (web retrieval, database queries, file reads), apply stricter content scanning that looks for patterns consistent with indirect prompt injection: instruction-like phrasing, role-override attempts, and context manipulation commands.", "Where tools support response signing (HMAC, JWS, or equivalent), verify signatures before accepting output; maintain a record of signature verification outcomes in the tool call audit trail." ], "ai_engineer": { "summary": "Never trust a tool response unconditionally. Every value from a tool that enters agent context is a potential injection vector from attacker-controlled external data.", "actions": [ "Implement output sanitization middleware that validates tool responses against response schemas and applies content scanning before responses reach the agent's context assembly stage.", "Build the agent to treat tool response content as data, not as instructions — apply strict separation between agent-authored reasoning and tool-provided data in the context structure." ], "failure_signals": [ "Agent behavior changing unexpectedly after retrieving external data through tools — a possible sign of successful indirect injection.", "Tool responses incorporated into agent context without corresponding sanitization middleware log entries." ] }, "security_architect": { "summary": "Tool output sanitization is the defense against indirect prompt injection — the most operationally difficult attack vector to eliminate in agentic systems. Treat all external data as hostile.", "actions": [ "Develop and maintain an injection pattern library for content scanning: include instruction-like phrasing, role-override attempts, ignore-previous-instructions patterns, and data exfiltration command forms.", "Implement response integrity verification for all tools that support it; for tools that do not, flag the gap in the tool registry as a risk item requiring compensating controls." ], "failure_signals": [ "Content scanning pattern library not updated in the last 90 days despite the rapidly evolving injection technique landscape.", "High-risk tools that return external data without response integrity signing or equivalent verification." ] }, "grc_auditor": { "summary": "Tool output sanitization is an operationally critical control that is frequently nominal. Audit for middleware deployment, pattern library currency, and integrity verification coverage.", "actions": [ "Request sanitization middleware deployment evidence and verify it intercepts responses from all registered tools, not just a subset.", "Assess the injection pattern library for currency and coverage; request evidence of updates in the last 90 days and comparison against current threat intelligence." ], "metrics": [ "Sanitization coverage rate: percentage of tool call log entries with corresponding output sanitization records; target 100%.", "Integrity verification coverage: percentage of tools returning external data with response signing or checksum verification; target 80% within 12 months." ], "failure_signals": [ "Tool responses from external-data tools incorporated into agent context without sanitization middleware records.", "Injection pattern library with no updates in over 90 days." ] }, "legal_counsel": { "summary": "Sanitizing tool outputs before they re-enter agent context guards against the enterprise acting on planted instructions — the indirect injection pathway behind several publicized agent incidents. The control record shows harmful third-party content was anticipated, not ignored.", "actions": [ "Confirm the enterprise's AI risk documentation names indirect injection via retrieved content as an assessed risk with this control as its treatment.", "Verify quarantine/sanitization events are logged with the offending content preserved for evidence.", "Review allocation of responsibility with content and data vendors whose feeds reach agent context." ], "failure_signals": [ "Risk assessments silent on retrieved-content injection while agents consume external feeds.", "Sanitization events with no preserved evidence, leaving attacks unprovable and vendors unaccountable.", "Vendor contracts with no warranty or notice obligations for content that manipulates enterprise agents." ] }, "platform_engineer": { "summary": "The sanitization middleware must be integrated at the response reception boundary, not within individual agent implementations, to ensure uniform coverage regardless of agent framework version.", "actions": [ "Deploy output sanitization as platform-level infrastructure that intercepts all tool responses at the transport layer before any agent-specific code processes them.", "Implement response schema hot-reload so updated schemas are applied to incoming responses without service disruption; log schema version applied to each response for investigation purposes." ], "failure_signals": [ "Agent framework versions in production that process tool responses before the platform-level sanitization middleware.", "Sanitization middleware with stale response schemas after tool specification updates." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Indirect prompt injection via tool outputs is an emerging and underdefended threat; most deployments have no systematic response sanitization or injection-pattern scanning for tool outputs." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI/ML Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM05:2025 — Improper Output Handling", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM05 (Improper Output Handling) addresses insufficient validation and sanitization of model and tool outputs before downstream use, including injection payloads propagating through tool responses into agent context. AT-04 is the direct mitigation at the tool-response boundary.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2025", "basis": "anchored", "relation": "defends_against" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051 — LLM Prompt Injection", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 (LLM Prompt Injection) covers indirect injection, where adversarial instructions are embedded in content the agent retrieves through tools. Output sanitization and integrity verification of tool responses is the direct countermeasure at that boundary.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "source_version": "v2026.06", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "2.8 — Information Integrity", "fit": "direct", "rationale": "NIST AI 600-1 §2.8 (Information Integrity) addresses risks to the integrity of information flowing through generative AI systems. Verifying and sanitizing tool outputs before they re-enter agent context preserves that integrity at the retrieval boundary.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 3 — Automate defenses to keep pace with existing and new threats", "fit": "partial", "rationale": "Google SAIF element 3 (Automate defenses) calls for automated defensive controls in AI data paths rather than manual review. Automated sanitization and integrity verification of tool outputs before they re-enter agent context is a direct application of that automation principle.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Contextual grounding checks", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' contextual grounding checks score whether responses are grounded in supplied source content, catching some classes of corrupted or fabricated retrieval results. Sanitizing and integrity-verifying tool outputs before they re-enter agent context, as AT-04 requires, is a broader control implemented at the orchestration layer.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2024", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires systems to handle failure modes safely, including adversarial or malformed external data. Sanitizing and integrity-checking tool outputs before they re-enter agent context remediates the indirect-injection failure class at its entry point.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Secure data retrieval, dynamic grounding, and toxicity detection", "fit": "partial", "rationale": "The Salesforce Einstein Trust Layer grounds responses in permissioned CRM data and scores outputs for toxicity — reducing the chance that agents act on corrupted or policy-violating content. AT-04's integrity verification of tool outputs generalizes this to arbitrary tool responses with sanitization at the boundary.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II — Tool poisoning; Part III — Input sanitization (treat tool results as untrusted)", "fit": "partial", "rationale": "Tool poisoning/rug-pull motivates treating tool output as untrusted and integrity-checking it. Partial: doc's sanitization emphasis is inbound input; tool-output sanitization is inferred.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "promptinjectioniohandling", "fit": "supporting", "rationale": "AT-04 sanitizes tool outputs and flags injection content before it enters the agent's context, handling the indirect-injection I/O path the AI Exchange control covers.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0015", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that the agent runtime verifies all tool responses against expected response…\" enacts ATLAS mitigation AML.M0015 Adversarial Input Detection; OpenCRE crosswalks this control’s OWASP AI Exchange concept (promptinjectioniohandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AT-04", "validation_objective": "Proves that the agent runtime verifies all tool responses against expected response schemas and applies content sanitization before any tool output is incorporated into the agent's context or reasoning, and that schema violations or detected injection content are quarantined and logged rather than silently processed.", "evidence_required": [ "Tool response schema definitions for all registered tools specifying expected field structures, value constraints, and any fields that must be excluded from the agent's direct context", "Sanitization middleware deployment evidence confirming tool responses pass through content checking before entering the agent's active context window", "Log of response schema violations and suspected injected content detections from the audit period, with the tool ID, violation type, and disposition recorded for each event", "Sample of sanitized tool response records showing the original response and the sanitized version or quarantine disposition" ], "machine_tests": [ "Inject a tool response containing a known indirect prompt injection payload — such as an instruction override sequence embedded in a returned document or structured data field — and confirm the sanitization layer flags or strips the payload before the agent processes the response", "Return a tool response that violates the registered response schema such as an unauthorized extra field or wrong type on a critical field, and confirm the runtime flags the integrity violation and does not silently pass the non-conformant response to the agent", "Verify that tool response validation log entries are present in the audit trail for all tool calls in a test session, confirming sanitization runs for every response and not only for responses that trigger a flag", "Simulate a structurally valid but semantically anomalous tool response — for example a data field whose value pattern is inconsistent with the expected data type semantics — and verify the anomaly is logged as an integrity event" ], "human_review": [ "Assess whether the sanitization approach relies solely on structural schema conformance checks or also applies semantic content analysis appropriate to the content types each tool returns, given that injection payloads can be structurally valid while semantically malicious", "Review the incident response procedure for confirmed tool response poisoning events and assess whether it includes agent session suspension, injection source investigation, and a review of any actions taken by the agent on the basis of the poisoned response" ], "blocking_effect": "advisory", "normative_status": "industry-framework", "anti_patterns": [ "Trusting tool responses unconditionally because they originate from an internal API endpoint, ignoring the risk that the tool's underlying data source — a database, knowledge base, or external feed — is attacker-influenced", "Applying sanitization only to external tool responses and not to internal knowledge base, database, or retrieval tool responses, which are equally valid injection targets in an indirect injection attack chain", "Logging schema violations but allowing the agent to continue processing the flagged response rather than quarantining it pending review, which preserves detection without prevention", "Implementing response schema validation only at agent startup as a configuration validation step rather than at runtime per response, which provides no protection against schema-conformant injection content introduced through the tool's data layer" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-05", "layer": "AT", "plane": "control", "name": "Dangerous and Irreversible Tool Access Controls", "plain": "Tools that can delete data, send external communications, execute financial transactions, or take any other irreversible action must require additional authorization — such as human approval, dual-control confirmation, or time-delayed execution — before an agent call proceeds.", "threat": { "tags": [ "irreversible-action-execution", "autonomous-financial-loss", "prompt-injection-to-destructive-action", "insufficient-human-oversight" ], "desc": "Autonomous execution of irreversible tool actions — mass deletions, financial disbursements, external communications sent in an organization's name — creates loss scenarios that cannot be recovered from even after the underlying cause is identified and corrected. A single successful prompt injection or agent malfunction that reaches a dangerous tool without an authorization gate can cause harm orders of magnitude greater than the attacker's initial access. The asymmetry between ease of agent compromise and severity of irreversible actions makes additional authorization gates a non-negotiable control for this tool class." }, "standard": [ { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — autonomous execution of irreversible actions" }, { "id": "nist_rmf", "section": "GOVERN 3.2", "title": "Human-AI oversight roles and responsibilities" }, { "id": "eu_ai_act", "section": "Art. 14", "title": "Human oversight measures for high-risk AI systems" }, { "id": "anthropic_rsp", "section": "Required Safeguards — ASL-3 Deployment Standard", "title": "Safeguards for high-consequence capabilities (Anthropic RSP v3.3)" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-05 Dangerous and Irreversible Tool Access Controls control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-05 Dangerous and Irreversible Tool Access Controls control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-05 Dangerous and Irreversible Tool Access Controls control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-05 Dangerous and Irreversible Tool Access Controls control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-05 Dangerous and Irreversible Tool Access Controls control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Classify all tools in the registry by reversibility and impact severity; for dangerous and irreversible tools, implement a mandatory authorization gate that pauses execution pending explicit approval before the tool call proceeds.", "steps": [ "Classify every registered tool as reversible or irreversible and assign an impact severity (low/medium/high/critical) based on the maximum realistic harm from a single miscall; document the classification rationale in the tool registry entry.", "Implement an authorization gate workflow for all tools classified as irreversible or high/critical severity: the gate must pause agent execution, present the proposed call with full parameter context to a designated human approver, and require explicit confirmation before the tool executor receives the call.", "For tools classified as dangerous but where real-time human approval is not operationally feasible, implement time-delayed execution with a configurable hold period (default: 15 minutes) during which the pending call is visible to designated operators and can be cancelled.", "Configure dual-control requirements for tools in the critical category: require approval from two independent authorized individuals before execution proceeds, with each approval logged separately with timestamp and identity." ], "ai_engineer": { "summary": "Dangerous tool calls must never be executed autonomously regardless of agent confidence. Build the agent to surface proposed dangerous actions for human review rather than execute them directly.", "actions": [ "Implement tool-class detection in the agent runtime that identifies when a proposed tool call targets a dangerous/irreversible tool and routes it to the authorization gate workflow instead of direct execution.", "Build the agent to provide human approvers with complete context: what action is proposed, why the agent believes it is necessary, what the expected outcome is, and what the irreversible consequences are if it proceeds." ], "failure_signals": [ "Agent executing a tool classified as irreversible without a corresponding authorization gate approval record.", "Authorization gate workflow bypassed due to agent timeout logic that defaults to auto-approve on no response." ] }, "security_architect": { "summary": "Dangerous tool access controls are the last line of defense before an attacker-influenced agent causes irreversible harm. Design them to be bypass-proof and to default to deny on any exception.", "actions": [ "Ensure the authorization gate is implemented at the platform level, not within individual agents — agents must not be able to bypass the gate by invoking tools directly.", "Configure the gate to default to deny for any exception condition: timeout, approval system unavailability, ambiguous classification — never auto-approve on failure." ], "failure_signals": [ "Authorization gate with a failopen configuration for any exception scenario.", "Tools classified as reversible that can be composed to achieve irreversible effects without triggering any gate." ] }, "grc_auditor": { "summary": "Dangerous tool controls are a high-value audit target because failure here has direct, unrecoverable business impact. Verify classification completeness, gate deployment, and approval record quality.", "actions": [ "Request the tool registry export and assess dangerous/irreversible classification coverage; verify every tool capable of external communication, data deletion, or financial action is classified appropriately.", "Sample 20% of authorization gate approval records and assess quality: verify full call context was presented, approval was provided by an authorized individual, and no approvals were auto-generated by the system." ], "metrics": [ "Dangerous tool classification coverage: percentage of tools capable of irreversible actions with appropriate classification in registry; target 100%.", "Authorization gate coverage: percentage of executions of classified dangerous tools with corresponding human approval records; target 100%." ], "failure_signals": [ "Any execution of a dangerous/irreversible tool without a corresponding authorization gate approval record.", "Authorization gate records that are auto-generated or lack human-identity attribution." ] }, "legal_counsel": { "summary": "Autonomous irreversible actions taken by AI agents without human authorization create significant legal exposure: contractual liability, regulatory violations, and reputational harm that cannot be undone. The authorization gate is a legal risk control as much as a technical one.", "actions": [ "Identify all tool categories whose autonomous execution could create legal liability: financial transactions, binding external communications, regulated-data deletions, and any action affecting third parties.", "Verify that authorization gate records are legally sufficient as evidence of human oversight for regulatory purposes, including sufficiency under EU AI Act Article 14 human oversight requirements." ], "failure_signals": [ "Financial transaction tools or legally binding communication tools without authorization gate coverage.", "Authorization gate records that do not capture sufficient context to demonstrate meaningful human review rather than perfunctory click-through approval." ] }, "platform_engineer": { "summary": "You build the gate infrastructure between agents and dangerous tools: the queueing, notification, timeout, and override plumbing that makes human authorization workable at production speed without becoming a rubber stamp.", "actions": [ "Implement the authorization gate as a platform service with pending-action queues, approver notification, expiry timeouts, and a default-deny outcome on timeout.", "Ensure gated tool endpoints are network-isolated so they are reachable only through the gate service — not directly by agent runtimes.", "Record every gate decision (requester, approver, action payload hash, decision, latency) in the tamper-evident audit store." ], "failure_signals": [ "Dangerous tool endpoints reachable by agents through paths that bypass the gate service.", "Gate timeouts defaulting to approve, converting reviewer inattention into authorization.", "Approval latency so high that teams re-classify dangerous tools as safe to escape the gate." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agentic deployments treat all tools equivalently with no additional authorization controls for irreversible actions; human-in-the-loop workflows for dangerous tools are rarely implemented at the platform level." }, "capability_risk": { "capability_level": "limited" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI/ML Engineering", "Security Architecture", "Legal/Compliance", "Platform Engineering" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 14 Human Oversight", "fit": "direct", "rationale": "EU AI Act Article 14 mandates that high-risk AI systems include human oversight measures enabling natural persons to monitor, intervene, and prevent unintended actions. Authorization gates for irreversible tools directly implement this requirement by ensuring a human reviews and approves consequential actions before they execute. The Act specifically requires that AI systems be designed to allow for human intervention before irreversible actions take effect.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) identifies autonomous execution of high-impact actions as the highest-severity manifestation of excessive agency, recommending human-in-the-loop controls as a primary mitigation. Authorization gates on dangerous, irreversible tools implement exactly that.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2025", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 3.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 3.2 requires policies defining and differentiating human roles and responsibilities for oversight of AI systems. Dangerous-tool authorization gates put a named human decision-maker between an agent and every irreversible, high-consequence tool invocation.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards — ASL-3 Deployment Standard", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP conditions deployment of models crossing Capability Thresholds on Required Safeguards that constrain high-consequence misuse. AT-05 applies the same principle at tool granularity: the most dangerous, least reversible tool capabilities carry affirmative authorization gates.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "3.3", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 requires human oversight and control mechanisms, particularly where system actions have significant consequences. Authorization gates on dangerous and irreversible tools put a named human decision between the agent and its highest-consequence capabilities.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6 — AI system operation and monitoring (Annex A)", "fit": "partial", "rationale": "ISO/IEC 42001 Annex A control A.6.2.6 (AI system operation and monitoring) requires defined processes for AI system operation, including the human oversight applied during use. Authorization gates on dangerous tools implement that operational oversight at the point of highest consequence.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Safeguarding against severe harm (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §4 requires safeguards proportionate to severe-harm potential before deployment proceeds. AT-05 applies the proportionality principle at tool granularity: irreversible, high-consequence tool capabilities sit behind affirmative authorization gates.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent User Control (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent User Control requires that high-consequence agent actions remain under effective human/principal control. Authorization gates on dangerous and irreversible tools implement that control at the point of highest cost of error.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Denied topics and content filters", "fit": "partial", "rationale": "Amazon Bedrock Guardrails' denied topics and content filters can block defined classes of requests and responses, providing a platform-level backstop against certain dangerous behaviors. Authorization gates on specific dangerous tools — AT-05's core mechanism — are implemented in the agent/orchestration layer, not in Guardrails.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 5 — Approval escalation; Part IV Phase 5 — Capability restrictions (send capability requiring separate authorization)", "fit": "direct", "rationale": "High-risk/irreversible tool invocations pause for human review; dangerous capabilities (send/delete/schema-change) require separate authorization.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "supporting", "rationale": "AT-05 gates dangerous or irreversible tools behind extra authorization, restricting the agent's high-consequence privileges consistent with least model privilege.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every tool classified as dangerous or irreversible in the registry requires…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every tool classified as dangerous or irreversible in the registry requires…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every tool classified as dangerous or irreversible in the registry requires…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AT-05", "validation_objective": "Proves that every tool classified as dangerous or irreversible in the registry requires an explicit additional authorization gate — human approval, dual-control confirmation, or time-delayed execution with a cancellation window — before an agent call proceeds to execution, and that no dangerous tool can execute through autonomous agent action alone.", "evidence_required": [ "Registry extract listing all tools classified as high or critical risk with the specific irreversibility rationale documented for each tool and the required authorization gate type specified", "Authorization gate implementation evidence for each dangerous tool class showing the gate is enforced at the agent runtime layer and not bypassable through direct tool executor configuration or API calls", "Approval records for dangerous tool calls in the audit period confirming human sign-off, dual-control confirmation, or completed time-delay window preceded every execution", "Penetration test or red team result demonstrating that no prompt injection or agent malfunction sequence caused a dangerous tool to execute without passing through the required authorization gate" ], "machine_tests": [ "Attempt to invoke a tool classified as high or critical risk from a test agent session without initiating or completing the required authorization gate workflow, and confirm the call is blocked before the tool executor is reached", "Verify that time-delayed execution calls for dangerous tools enforce the full delay window and cannot be accelerated or bypassed by subsequent agent-generated inputs during the delay period", "Scan all tools classified as high or critical risk in the registry and confirm each has a documented authorization gate type entry that is distinct from the standard tool invocation path", "Confirm that authorization gate bypass attempts — including attempts to invoke the tool executor directly or to modify the gate decision record — are captured as security events and trigger alerting" ], "human_review": [ "Assess whether the risk classification of tools as dangerous or irreversible is accurate and complete, specifically confirming that financial transaction, bulk deletion, external communication, and privileged system access tools are all classified at high or critical risk rather than lower tiers", "Review whether human approval workflows for dangerous tools represent meaningful oversight — that the approving human receives sufficient context to understand the requested action and its consequences — or are perfunctory checkbox confirmations that do not support informed authorization", "Confirm that the exceptions process for temporarily bypassing dangerous tool authorization gates requires explicit approval from a designated authority above the agent operator level and is not available as a self-service configuration option" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Classifying tools as irreversible only when they are completely unrecoverable, and excluding partially recoverable actions such as bulk email sends that can be recalled for some recipients but not all, underestimating the harm potential of partial irreversibility", "Implementing the authorization gate in the tool executor rather than the agent runtime, which allows a prompt-injected agent to potentially route around the gate by constructing direct executor calls that do not pass through the runtime enforcement layer", "Using a single uniform approval workflow for all dangerous tool classes regardless of severity, granting the same authorization confidence to a low-stakes file operation as to a mass financial disbursement or bulk data deletion", "Failing to update dangerous tool classification when a tool adds new capabilities through API version updates, leaving newly dangerous operations ungated because the tool's registry entry was not re-reviewed following the capability change" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-06", "layer": "AT", "plane": "both", "name": "Third-Party Plugin Vetting and Sandboxing", "plain": "External plugins, MCP servers, and third-party tool integrations must undergo a formal security review before deployment, execute within sandboxed runtime environments that limit their access to agent context and host infrastructure, and be subject to ongoing security monitoring.", "threat": { "tags": [ "malicious-plugin", "mcp-server-compromise", "third-party-supply-chain", "sandbox-escape" ], "desc": "Third-party plugins and MCP servers introduce externally-controlled code into the agent execution environment, creating supply chain risk that extends beyond what first-party tools present. A malicious or compromised plugin can exfiltrate the agent's full context including sensitive session data, manipulate tool call results, or escalate to the host system if sandboxing is inadequate. The MCP protocol's growing ecosystem creates a rapidly expanding surface of community-published servers whose security posture varies widely and may change without notice after initial vetting." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 6.1", "title": "Third-party software AI risk policies" }, { "id": "iso_42001", "section": "A.10.3", "title": "Suppliers (Annex A) — third-party component governance" }, { "id": "google_saif", "section": "Element 1", "title": "Supply-chain security foundations for AI components" } ], "sources": [ { "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-29", "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://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-06 Third-Party Plugin Vetting and Sandboxing control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Require a formal security review gate for all third-party plugins before registry approval; deploy all external plugins in sandboxed runtime environments with limited access to agent context and host infrastructure; implement continuous monitoring for post-approval security posture changes.", "steps": [ "Define a plugin vetting checklist covering: source code review or binary analysis where feasible, declared data access scope, network egress requirements, cryptographic provenance (code signing), vendor security posture assessment, and known vulnerability scan; gate registry approval on completion of this checklist with documented findings.", "Deploy all third-party plugins in sandboxed execution environments with restricted capabilities: no access to the full agent context beyond parameters explicitly passed, no direct filesystem access, controlled and logged network egress, and no ability to invoke other tools directly.", "Implement continuous monitoring for post-approval security changes: subscribe to vulnerability feeds for plugin vendors, monitor plugin version updates for scope changes, and trigger re-review when significant changes are detected.", "Establish a plugin revocation capability that can immediately remove a plugin from the approved registry and block its invocation across all running agents when a security issue is identified; test revocation procedures quarterly." ], "ai_engineer": { "summary": "External plugins are untrusted code. Design the agent-to-plugin interface to pass only the parameters the plugin needs and receive only structured outputs — never expose full agent context to plugins.", "actions": [ "Implement explicit context scoping for each plugin call: pass only the specific data the plugin requires, not the full agent context, session history, or system prompt.", "Build plugin invocation wrappers that enforce the sandboxed interface: structured parameter passing in, structured response out, with no shared memory or direct agent context access." ], "failure_signals": [ "Plugins receiving full agent context or system prompt contents as part of their invocation parameters.", "Plugin responses containing agent context data they were not passed — indicating unauthorized context access." ] }, "security_architect": { "summary": "Third-party plugins represent the highest supply chain risk in agentic systems. Design sandboxing to assume plugins are hostile and limit blast radius accordingly.", "actions": [ "Design sandbox boundaries that enforce process isolation, restrict filesystem and network access to declared requirements, and prevent plugins from enumerating or accessing other plugins or agent components.", "Implement network egress monitoring for sandbox environments: all outbound connections from plugins must be logged with destination and data volume to detect exfiltration." ], "failure_signals": [ "Plugins executing in environments with filesystem access beyond their declared requirements.", "Plugin network egress not monitored or logged with destination-level detail." ] }, "grc_auditor": { "summary": "Third-party plugin governance is a supply chain risk control. Audit for vetting completeness, sandbox deployment, and monitoring coverage across the full plugin inventory.", "actions": [ "Request the registry export for all third-party plugins and verify each has a completed vetting checklist with documented findings and approval authorization.", "Sample sandbox deployment configurations for 20% of registered third-party plugins and verify they implement the required isolation controls including context scoping, filesystem restrictions, and egress monitoring." ], "metrics": [ "Vetting completion rate: percentage of registered third-party plugins with completed security vetting; target 100%.", "Sandbox deployment rate: percentage of third-party plugins executing in sandboxed environments; target 100%." ], "failure_signals": [ "Third-party plugins in the approved registry without completed vetting checklists.", "Third-party plugins executing outside sandboxed environments regardless of risk classification." ] }, "legal_counsel": { "summary": "Third-party plugins execute with agent-granted capabilities, making them supply-chain risk with direct operational reach. Vetting records and sandbox boundaries are what separate 'a vendor compromised us' from 'we installed ungoverned code into an autonomous system'.", "actions": [ "Confirm plugin vendor agreements include security representations, vulnerability disclosure duties, and audit or attestation rights proportionate to the plugin's access.", "Verify the vetting record for each approved plugin is retained and shows who accepted residual risk.", "Assess data-transfer and privacy implications where plugins send agent context to third-party services." ], "failure_signals": [ "Production plugins with no retained vetting record or named risk acceptor.", "Plugin vendors with no contractual security or disclosure obligations despite privileged access.", "Agent context containing personal data flowing to plugin vendors without a documented transfer basis." ] }, "platform_engineer": { "summary": "Sandbox infrastructure must be maintained as a platform capability, not left to individual agent teams, to ensure consistent isolation standards across all third-party plugin deployments.", "actions": [ "Deploy a standard sandbox runtime environment (container-based with seccomp/AppArmor profiles or equivalent) that is mandatory for all third-party plugin execution; provide tooling for agent teams to register plugins into the sandbox rather than implementing isolation themselves.", "Implement egress monitoring infrastructure that captures all network connections from sandbox environments and feeds into security monitoring; alert on connections to destinations not in the plugin's declared egress list." ], "failure_signals": [ "Individual agent teams deploying third-party plugins outside the platform-provided sandbox infrastructure.", "Sandbox environments without egress monitoring connected to security alerting." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "MCP server and third-party plugin ecosystems are growing faster than enterprise governance processes; most deployments have no formal vetting process and rely on implicit trust of community-published plugins." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Security Architecture", "Platform Engineering", "AI/ML Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 6.1", "fit": "direct", "rationale": "NIST AI RMF GOVERN 6.1 requires policies and procedures addressing AI risks associated with third-party software and services. Formal plugin vetting and sandboxing implements those policies for the agent tool supply chain, where third-party code executes with agent-granted capabilities.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17 & 25 Third-Party Obligations", "fit": "direct", "rationale": "EU AI Act Articles 17 and 25 impose quality management and conformity obligations on high-risk AI providers that extend to third-party components integrated into the system. Plugin vetting and sandboxing directly address these obligations by ensuring that integrated external components have been assessed for conformity before deployment. Providers cannot disclaim responsibility for harms caused by inadequately vetted third-party plugins under the Act.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0010 — AI Supply Chain Compromise", "fit": "direct", "rationale": "MITRE ATLAS AML.T0010 (AI Supply Chain Compromise) documents supply chain compromise of AI system components as an adversarial technique, with third-party plugins a primary vector. Vetting and sandboxing directly reduce this attack surface.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "source_version": "v2026.06", "basis": "anchored", "relation": "defends_against" }, { "framework": "iso_42001", "requirement_id": "A.10.3 — Suppliers (Annex A)", "fit": "direct", "rationale": "ISO/IEC 42001 Annex A control A.10.3 (Suppliers) requires processes to manage risks arising from suppliers' products and services used in AI systems. Third-party plugin vetting and sandboxing implements this for the agent tool supply chain.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 1 — Expand strong security foundations to the AI ecosystem", "fit": "direct", "rationale": "Google SAIF element 1 treats supply-chain integrity as part of the security foundations that must extend to AI systems. Vetting and sandboxing third-party plugins applies supply-chain security foundations to the agent tool ecosystem.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1 — Reliability and safety guidance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 requires reliability and safety to be maintained across the system as built — including integrated third-party components. Vetting and sandboxing third-party plugins keeps unvetted code from silently widening an agent's failure surface.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters applied to agent responses", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' content filters apply to agent responses regardless of which action group or third-party integration produced the underlying data, providing one uniform screening layer. Plugin vetting and sandboxing themselves, as AT-06 requires, are deployment-architecture controls outside Guardrails' scope.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 2 — Vendor assessments; Part IV Phase 5 — Sandbox execution", "fit": "direct", "rationale": "Doc requires assessing tool providers before adoption (FOSS code review, provider history) and sandboxing tools with restricted network/filesystem/syscalls — third-party plugin vetting and sandboxing.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AT-06", "validation_objective": "Proves that every third-party plugin and MCP server in the approved registry has a documented security vetting record and executes within a sandboxed environment that limits access to agent context and host infrastructure. The testable claim is that no unapproved or un-sandboxed external plugin can be invoked by any agent in the deployment.", "evidence_required": [ "Plugin registry export listing all registered third-party plugins with completed vetting checklist references and approval authorization records", "Sandbox runtime configuration audit confirming process isolation, context scoping, filesystem restrictions, and egress monitoring for sampled plugins", "Network egress monitoring logs from sandbox environments showing destination-level logging coverage for all plugin invocations over a 30-day window", "Plugin revocation procedure test records demonstrating successful removal and invocation blocking within the defined response window", "Continuous monitoring subscription records for vendor vulnerability feeds and post-approval security change alerts" ], "machine_tests": [ "Scan the approved plugin registry for entries lacking a completed vetting checklist reference and flag any gap as a critical finding", "Probe sandbox isolation for a sample of deployed third-party plugins by attempting to access full agent context or filesystem paths outside declared requirements and confirm rejection", "Verify network egress monitoring coverage by confirming all plugin sandbox environments feed connection logs to security monitoring with destination-level detail", "Execute a controlled plugin revocation and measure time to invocation block across all running agents against the defined SLA" ], "human_review": [ "Review vetting checklist completeness and approval authorization quality for a sample of high-risk plugins, assessing whether findings are substantive or perfunctory", "Assess sandbox design adequacy against the current threat model, particularly for plugins with broad declared egress requirements or network access needs", "Evaluate whether continuous monitoring triggers are calibrated to detect post-approval security posture changes in time to prevent harm" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Treating community download counts or GitHub stars as a proxy for security vetting, without a structured checklist review", "Deploying plugins outside the sandboxed runtime for performance or compatibility reasons without a documented waiver and compensating controls", "Allowing plugins to receive full agent context or system prompt contents as invocation parameters instead of explicitly scoped data", "Relying solely on platform-level guardrails (e.g., AWS Bedrock action group filtering) as a substitute for sandbox isolation and formal vetting" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-07", "layer": "AT", "plane": "data", "name": "Tool Usage Audit Trail", "plain": "A complete, tamper-evident log of all tool calls must be maintained, recording the agent identity, tool ID, full input parameters, response summary, timestamp, authorization records, and outcome for every invocation.", "threat": { "tags": [ "audit-gap", "forensic-obstruction", "non-repudiation-failure", "incident-response-blindness" ], "desc": "Without comprehensive tool usage logs, security incidents involving agent tool abuse cannot be investigated, attribution cannot be established, and the scope of harm cannot be bounded. Attackers who compromise an agent and cause harmful tool calls benefit disproportionately from log gaps, as investigations fail to reconstruct the sequence of events. Non-repudiation failures also expose organizations to liability risk where the burden of proof for AI-caused harm cannot be met without an authoritative audit record." }, "standard": [ { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, analysis and evaluation — audit record requirements" }, { "id": "eu_ai_act", "section": "Art. 12", "title": "Record-keeping obligations for high-risk AI systems" }, { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment monitoring supporting incident response" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AT-07 Tool Usage Audit Trail control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement centralized, append-only tool call logging with tamper-evident integrity protection; each log entry must capture agent identity, tool ID, full parameters, response summary, timing, and authorization records. Logs are the authoritative record for forensic investigation and compliance evidence.", "steps": [ "Define a standard log record schema for tool calls: entry_id, timestamp (ISO 8601 with millisecond precision), agent_id, agent_version, session_id, tool_id, tool_version, input_parameters (full, not truncated for dangerous tools), response_summary, authorization_record_id (if applicable), outcome (success/blocked/error), and blocking_reason if blocked.", "Deploy log storage in an append-only, write-once medium with cryptographic integrity protection: each log batch should be hash-chained so any tampering with past records is detectable; store logs in infrastructure not accessible to agent runtime processes.", "Implement log forwarding to a SIEM or centralized logging platform with retention configured to meet the longest applicable regulatory retention requirement; ensure log forwarding is synchronous for dangerous tool calls so records are captured before execution completes.", "Establish alerting rules on the log stream for patterns indicating misuse: high-frequency tool calls from a single agent, calls to dangerous tools outside business hours, blocked calls followed by repeated attempts with modified parameters, and calls to tools outside the agent's permission profile." ], "ai_engineer": { "summary": "Every tool call must generate a log record regardless of outcome. Build logging as a mandatory, pre-execution step — not an optional post-processing one — so blocked calls are captured even when the tool never executes.", "actions": [ "Implement log record creation at the point of tool call initiation in the middleware pipeline, before validation or permission checks, so all attempted calls are captured including those blocked by upstream controls.", "Ensure log records for dangerous tools capture full input parameters without truncation; for other tools, capture sufficient parameter context to reconstruct the call intent during investigation." ], "failure_signals": [ "Tool call log entries with truncated or redacted parameters that prevent forensic reconstruction of the call.", "Gaps in log record sequences that indicate calls occurring outside the logging middleware." ] }, "security_architect": { "summary": "The audit trail is a security-critical asset. Design it to be independent from agent runtime infrastructure so a compromised agent cannot tamper with or delete its own call records.", "actions": [ "Deploy log storage in infrastructure with a separate access control boundary from the agent runtime; agent processes must have write-only access to the log pipeline and no ability to read or modify past records.", "Implement hash-chaining or equivalent tamper-evidence so log integrity can be verified and any tampering detected; include log integrity verification in incident response procedures." ], "failure_signals": [ "Log storage accessible to agent runtime processes with read or delete permissions.", "No tamper-evidence mechanism on log storage — logs can be modified without detection." ] }, "grc_auditor": { "summary": "The tool usage audit trail is the primary evidence source for AI governance compliance, incident investigation, and regulatory record-keeping. Audit for completeness, integrity, retention, and actionability.", "actions": [ "Request a log completeness verification: compare tool call records against agent execution metrics for the same period to identify gaps where calls are recorded in metrics but not in the audit trail.", "Verify tamper-evidence integrity: request a log hash verification report and confirm no integrity violations have been detected in the audit period; verify log retention is configured to meet applicable regulatory requirements." ], "metrics": [ "Log completeness rate: percentage of tool calls in execution metrics with corresponding audit trail records; target 100%.", "Log integrity violation rate: target zero integrity violations per audit period; any violation triggers an incident investigation." ], "failure_signals": [ "Tool call counts in execution metrics materially exceeding audit trail record counts for the same period.", "Log retention configured below the longest applicable regulatory requirement." ] }, "legal_counsel": { "summary": "The tool usage audit trail is the primary evidentiary record of what enterprise agents actually did. Its completeness and integrity determine whether the enterprise can reconstruct events, satisfy EU AI Act record-keeping duties, and defend or pursue claims.", "actions": [ "Confirm audit trail retention meets EU AI Act log obligations (Art. 12/19; deployer minimum six months under Art. 26(6)) and the longer limitation periods of foreseeable claims.", "Verify the trail's tamper-evidence would withstand evidentiary challenge — provenance, integrity verification, and access controls documented.", "Ensure legal hold procedures cover agent audit trails so relevant records survive routine expiry once litigation is anticipated." ], "failure_signals": [ "Audit records expiring on schedules shorter than the disputes they would decide.", "Integrity mechanisms that cannot be explained or verified when the record is challenged.", "Legal holds that fail to reach agent tool logs because they were never mapped as a record class." ] }, "platform_engineer": { "summary": "Audit trail infrastructure must be maintained as a platform service with guaranteed durability and availability that exceeds the agent platform itself — if logs are lost, the audit capability is unrecoverable.", "actions": [ "Deploy log pipeline with durability guarantees that exceed the agent platform: use write-ahead logging, cross-region replication, and retention locks to prevent accidental or adversarial deletion.", "Instrument the log pipeline for monitoring: alert on pipeline lag, write failures, and capacity approaching retention limits; log pipeline failures must be treated as P1 incidents." ], "failure_signals": [ "Log pipeline write failures that result in dropped records rather than queued retry.", "Log retention locks not configured, allowing records to be deleted before the retention period expires." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most agentic deployments have basic execution logging but lack tamper-evidence, full parameter capture for dangerous tools, and integrity verification capabilities required for forensic and regulatory purposes." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Platform Engineering", "Security Architecture", "AI/ML Engineering" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 12 Record-Keeping", "fit": "direct", "rationale": "EU AI Act Article 12 mandates that high-risk AI systems automatically generate logs of their operation to enable post-market monitoring and investigation of incidents. A comprehensive tool usage audit trail directly satisfies this requirement by capturing a complete record of all agent actions through tool invocations. Article 12 specifically requires that log records be sufficient to enable tracing of AI system behavior over the period relevant to regulatory oversight.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.1 Monitoring, Measurement, Analysis and Evaluation", "fit": "direct", "rationale": "ISO 42001 §9.1 requires organizations to monitor and measure AI system performance and behavior, with records retained as evidence of conformity. A tool usage audit trail is the primary monitoring artifact for agentic AI systems, capturing all external actions taken by agents. The standard's requirement for documented evidence of AI system operation is directly satisfied by this control's logging and integrity-protection requirements.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.1 requires implemented post-deployment monitoring plans, including mechanisms that support incident response and recovery. The tamper-evident tool usage audit trail is the record those mechanisms depend on for reconstruction and attribution after an event.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "partial", "rationale": "NIST AI 600-1 §2.9 (Information Security) recommends applying established security practices — including logging and monitoring — to generative AI systems. The tool usage audit trail is that logging practice applied at the agent tool layer.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.7 — Recording and reporting", "fit": "partial", "rationale": "ISO 31000:2018 §6.7 requires risk management activities to be documented, with records maintained to support monitoring and review. Tool usage audit records are the operational documentation of agent risk controls in action, retained for review and investigation.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "2018", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Observability (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Agent Observability control requires visibility into agent actions sufficient to detect anomalous behavior and support investigation. A complete, tamper-evident tool usage audit trail is the record that makes agent tool activity observable and investigable.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require automated actions to be attributable and reviewable. A tamper-evident tool usage audit trail provides the attribution record: which agent invoked which tool, with what parameters, under whose authorization.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Guardrail trace in agent invocation output", "fit": "adjacent", "rationale": "Bedrock agent invocations can return trace output that includes guardrail evaluation results, contributing per-request policy decisions to an audit record. A complete, tamper-evident tool usage audit trail, as AT-07 requires, must be assembled from broader invocation logging outside Guardrails.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "direct", "rationale": "The Salesforce Einstein Trust Layer's audit trail is a named platform feature logging prompts, masked data, outputs, and toxicity scores for generative AI activity — a platform-native implementation of the tool/action logging pattern AT-07 requires. AT-07 adds tamper-evidence and completeness requirements across all agent tool use.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Action logging (Log all tool invocations)", "fit": "direct", "rationale": "Foundation action logging logs all tool invocations with agent identity, action details and request context — the tool usage audit trail.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AT-07", "validation_objective": "Proves that every tool call — including blocked calls — generates a complete, tamper-evident log record containing agent identity, tool ID, full input parameters for dangerous tools, response summary, authorization record reference, timestamp, and outcome, and that the log storage detects any post-write modification. No tool invocation may execute or be blocked without a corresponding audit record.", "evidence_required": [ "Log completeness verification report comparing tool call counts in execution metrics against audit trail records for the same period, with zero unexplained gaps", "Hash chain integrity verification report for recent log batches confirming no tampering has been detected", "Sample log records for dangerous tool invocations confirming full (non-truncated) input parameters are captured", "SIEM or centralized logging retention configuration showing the retention period meets the longest applicable regulatory requirement", "Log pipeline health monitoring records confirming no dropped records due to write failures in the audit period" ], "machine_tests": [ "Compare tool call counts from execution metrics against audit trail record counts for a 7-day window and flag any divergence exceeding 0.01% as an integrity failure", "Verify hash chain integrity for the most recent 30 days of log batches and confirm no integrity violations are present", "Inspect a random sample of dangerous-tool log records and confirm input parameters are captured in full without truncation or redaction", "Induce a log pipeline write failure in a test environment and confirm records are queued for retry rather than dropped silently" ], "human_review": [ "Assess log record schema adequacy for forensic reconstruction: verify a hypothetical incident investigation could reconstruct the sequence of events from log records alone", "Review alerting rule quality for detecting misuse patterns (high-frequency calls, off-hours dangerous tool use, repeated blocked attempts) and assess false positive rate", "Confirm log retention period meets all applicable regulatory requirements including the longest horizon among applicable frameworks" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Truncating input parameters in log records to reduce storage cost, destroying the forensic value of the audit trail for dangerous tool calls", "Writing log records in the same process or infrastructure tier as the agent runtime, allowing a compromised agent to tamper with its own call records", "Logging only successful tool calls and omitting blocked calls, creating gaps that hide the most security-relevant events", "Using mutable log storage without hash-chaining or equivalent integrity protection, making tampering undetectable" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AT-08", "layer": "AT", "plane": "lifecycle", "name": "Tool Governance Evidence Package", "plain": "A structured evidence package must be compiled from AT-01 through AT-07 demonstrating that the tool registry is complete, permissions are scoped to least privilege, inputs and outputs are validated, dangerous tools are controlled, third-party plugins are vetted, and usage is audited.", "threat": { "tags": [ "governance-gap", "compliance-evidence-deficit", "audit-failure", "assurance-without-evidence" ], "desc": "Without a compiled evidence package, tool governance controls exist in isolation — each may operate independently but no authoritative artifact demonstrates that the AT layer as a whole provides effective assurance. Auditors and regulators cannot assess governance posture from fragmented control artifacts scattered across multiple systems. Evidence gaps discovered during regulatory review or post-incident investigation create liability exposure that properly compiled evidence packages would have prevented." }, "standard": [ { "id": "iso_42001", "section": "§9.3 Management Review", "title": "AI management system review and evidence of conformity" }, { "id": "eu_ai_act", "section": "Art. 11 & 18", "title": "Technical documentation and documentation-keeping obligations" }, { "id": "nist_rmf", "section": "GOVERN 1.4", "title": "Transparent, documented risk management processes and outcomes" }, { "id": "iso_31000", "section": "§6.7", "title": "Recording and reporting" } ], "sources": [ { "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-29", "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://agentic/controls/AT-08 Tool Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AT-08 Tool Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AT-08 Tool Governance Evidence Package control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AT-08 Tool Governance Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a standard AT-layer evidence package structure; compile evidence from all seven AT controls on a defined cadence; validate completeness against the package specification; store packages in tamper-evident evidence storage with defined retention.", "steps": [ "Define the AT evidence package specification: list the required artifact type from each of AT-01 through AT-07 (registry export, permission profile inventory, schema completeness report, sanitization coverage report, authorization gate log, plugin vetting records, and audit trail integrity report) along with freshness requirements for each artifact.", "Implement automated evidence collection pipelines that pull current artifacts from each AT control system on the defined package cadence (at minimum: quarterly for compliance reviews, immediately following any material change to the tool set or agent configuration).", "Validate each compiled package against the specification for completeness: verify all required artifacts are present, all freshness requirements are met, and no critical metrics are below defined thresholds; generate a package validation report that summarizes the AT-layer governance posture.", "Store compiled packages in the Apeiris evidence store with package-level integrity signatures, structured metadata (AT-08 artifact ID, compilation timestamp, covered agent scope, package validation outcome), and retention configured to meet the longest applicable regulatory requirement." ], "ai_engineer": { "summary": "The evidence package is the machine-readable proof that AT-layer controls are operational. Ensure all AT controls emit structured, queryable artifacts that can be automatically compiled without manual extraction.", "actions": [ "Instrument each AT control (AT-01 through AT-07) to emit structured, API-accessible artifacts on demand — registry exports, validation reports, coverage metrics, and audit summaries.", "Build the evidence collection pipeline to pull from each control's API and assemble the package without manual steps; manual assembly introduces gaps and delays that defeat the purpose of continuous assurance." ], "failure_signals": [ "Evidence package compilation requiring manual data extraction from any AT control system.", "Package validation reports showing metric thresholds unmet without corresponding remediation records." ] }, "security_architect": { "summary": "The evidence package is also a threat detection artifact — systematic gaps or metric degradations across AT controls visible in the compiled package signal active threats or governance erosion that require investigation.", "actions": [ "Include a trend analysis in each compiled package: compare current metrics against the prior three packages to detect directional degradation in tool governance posture.", "Define package-level risk thresholds: if any AT control's contribution to the package falls below its defined threshold, trigger an escalation to security leadership with a defined remediation timeline." ], "failure_signals": [ "Compiled packages with no trend analysis, making progressive governance erosion invisible.", "Packages with below-threshold metrics that triggered no escalation or remediation record." ] }, "legal_counsel": { "summary": "The AT-08 evidence package is the primary legal artifact demonstrating AI governance compliance. Ensure it meets the evidentiary standards required by applicable regulations and contractual commitments.", "actions": [ "Review the package specification against current regulatory requirements (EU AI Act Article 11, applicable sector regulations) to confirm all required documentation elements are covered.", "Verify that package retention periods and integrity protections are sufficient for the evidentiary purposes the packages are expected to serve in regulatory investigations or litigation." ], "failure_signals": [ "Evidence package specification not reviewed against applicable regulatory requirements in the last 12 months.", "Package retention periods shorter than the limitation period for applicable regulatory violations." ] }, "grc_auditor": { "summary": "AT-08 is the primary audit artifact for the entire AT layer. Request the current and prior three compiled packages; assess completeness, metric trends, and remediation follow-through for identified gaps.", "actions": [ "Request the current and prior three AT evidence packages; assess each for completeness against the specification and trace any gap or below-threshold finding to a remediation record.", "Evaluate the automated compilation evidence: verify pipelines are running on schedule, artifact freshness requirements are being met, and no packages were manually assembled or retroactively completed." ], "metrics": [ "Package completeness rate: percentage of required artifacts present in each compiled package; target 100%.", "Remediation follow-through rate: percentage of below-threshold findings from prior packages with closed remediation records; target 100% within defined SLAs.", "Package compilation cadence compliance: percentage of packages compiled on schedule; target 100%." ], "failure_signals": [ "Compiled packages with missing required artifacts or metrics below defined thresholds and no corresponding remediation records.", "Evidence of retroactive or manual package completion rather than automated, timestamped compilation." ] }, "platform_engineer": { "summary": "Evidence collection pipelines must be as reliable as the controls they collect from. Build them with monitoring, failure alerting, and retry logic so compilation failures are caught immediately rather than discovered at audit time.", "actions": [ "Deploy evidence collection pipelines with health monitoring: alert on collection failures, stale artifacts, and API unavailability from AT control systems before package compilation is attempted.", "Implement package storage with cryptographic integrity signing at both the individual artifact and package levels; provide a verification endpoint that auditors can use to confirm package integrity independently." ], "failure_signals": [ "Evidence collection pipeline failures silently producing incomplete packages without alerting.", "Package storage without artifact-level integrity signatures, preventing independent verification by auditors." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Compiled AT-layer evidence packages are rare; most organizations can produce individual control artifacts on request but have no automated compilation process or defined package specification that covers the full AT control set." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "GRC/Compliance", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 11 & Art. 18", "fit": "direct", "rationale": "EU AI Act Article 11 requires technical documentation demonstrating conformity, and Article 18 requires providers to keep that documentation at the disposal of national competent authorities for ten years. AT-08 evidence packages produce and preserve the tool-governance portion of this documentation.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "source_version": "2024/1689", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.3 Management Review", "fit": "direct", "rationale": "ISO 42001 §9.3 requires top management to review the AI management system at planned intervals using evidence of system performance and conformity. AT-08 evidence packages provide the structured evidence base required for management review of the tool governance layer. The package compilation and validation process this control mandates directly supports ISO 42001's continual improvement cycle.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.4", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.4 requires the risk management process and its outcomes to be established through transparent, documented policies and controls. The tool governance evidence package is the documented outcome demonstrating that registry, vetting, and audit controls operated as designed.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "1.0", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.7 Recording and Reporting", "fit": "direct", "rationale": "ISO 31000:2018 §6.7 requires that risk management activities be documented and reported to enable oversight, informed decision-making, and continual improvement. AT-08 evidence packages fulfill this requirement for agentic tool risk by providing a periodic compiled record of all AT-layer risk management activities and their outcomes. The package's trend analysis component directly supports ISO 31000's emphasis on monitoring risk management effectiveness over time.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "source_version": "2018", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require documented evidence that governance processes operate. The tool governance evidence package compiles registry, vetting, and audit records into a reviewable accountability artifact.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 3 — Automate defenses to keep pace with existing and new threats", "fit": "adjacent", "rationale": "Google SAIF element 3 (Automate defenses) favors continuous, automated assurance over point-in-time checks. AT-08's automated evidence compilation makes tool-governance assurance continuous: registry, vetting, and audit evidence is machine-assembled on a defined cadence.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "source_version": "2023", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3.1 Scope and Timing) — recurring evidence cadence", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3.1 establishes a recurring cadence for producing risk reports rather than treating assurance as a one-time gate. AT-08's periodically compiled tool-governance evidence package brings the same recurring-evidence discipline to the agent tool layer.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Safeguards Reports (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Safeguards Reports (§4) institutionalize documented evidence that safeguards are operating. AT-08's tool governance evidence package brings the same standing-evidence discipline to registry, vetting, and audit controls for agent tools.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AT-08", "validation_objective": "Proves that the AT-layer tool governance controls collectively provide effective assurance by demonstrating that a compiled, integrity-signed evidence package covering all AT-01 through AT-07 artifacts has been produced on the defined cadence with no missing artifacts and no critical metrics below defined thresholds. The testable claim is that the AT-layer governance posture can be verified at any time from the current evidence package without manual reconstruction.", "evidence_required": [ "Current compiled AT evidence package containing all seven required artifact types (registry export, permission profile inventory, schema completeness report, sanitization coverage report, authorization gate log, plugin vetting records, and audit trail integrity report)", "Automated pipeline run logs showing on-schedule, non-manual compilation for the current and prior three packages", "Package validation report with metric summary confirming all AT control thresholds are met or showing remediation records for any gaps", "Package integrity signature verification records confirming tamper-evidence at both artifact and package levels", "Trend comparison across prior three packages showing no directional degradation in AT governance posture" ], "machine_tests": [ "Verify all seven required AT artifact types are present in the current package and none exceed their defined freshness TTL", "Validate package integrity signature and confirm it matches the expected signing key from the evidence infrastructure", "Confirm the package was produced by the automated pipeline (not manually assembled) by verifying pipeline run timestamps in CI/CD logs match package metadata", "Check prior three packages for below-threshold metric findings and verify each has a corresponding closed remediation record within the defined SLA" ], "human_review": [ "Assess metric trend direction across prior packages for evidence of progressive governance erosion that may not yet breach individual thresholds", "Evaluate whether below-threshold findings from prior packages have substantive remediation records or only nominal closure", "Confirm the package specification has been reviewed against current regulatory requirements within the last 12 months and covers all applicable documentation elements" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating the AT-08 evidence package as a one-time audit artifact rather than a recurring, automated compilation that must remain current", "Manually assembling packages retroactively when audit requests arrive, rather than through timestamped automated pipelines", "Scoping the evidence package narrower than the full deployed agent population, leaving ungoverned agent deployments outside the AT-layer assurance boundary", "Allowing below-threshold AT control metrics to persist across multiple package cycles without closed remediation records" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AT" }, { "id": "AO-01", "layer": "AO", "plane": "control", "name": "Multi-Agent Trust Chain Documentation", "plain": "Every multi-agent deployment must maintain an explicit, machine-readable trust graph documenting which agents can direct other agents, under what conditions, and with what scope constraints — forming the authoritative record of orchestration authority.", "threat": { "tags": [ "unauthorized-delegation", "trust-chain-confusion", "privilege-escalation", "shadow-orchestration" ], "desc": "Without a documented trust graph, orchestrators accumulate implicit authority over worker agents that was never explicitly granted. Attackers who compromise a low-privilege agent can invoke higher-privilege orchestrators if trust relationships are undocumented and unenforced. Trust chain confusion allows a rogue agent to impersonate a legitimate orchestrator, redirecting workers to attacker-controlled tasks." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 2.1", "title": "Documented roles, responsibilities, and lines of authority" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control — documented system interrelationships" }, { "id": "eu_ai_act", "section": "Article 13", "title": "Transparency and provision of information to deployers" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — undocumented capability grants" } ], "sources": [ { "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-29", "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://agentic/controls/AO-01 Multi-Agent Trust Chain Documentation control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-01 Multi-Agent Trust Chain Documentation control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-01 Multi-Agent Trust Chain Documentation control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-01 Multi-Agent Trust Chain Documentation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a versioned, machine-readable trust graph (JSON-LD or equivalent) stored in a controlled repository. Each node represents a deployed agent identity; each directed edge encodes permitted delegation scope, capability constraints, and expiry. Trust graph changes require signed approval from the system owner and trigger an automated re-evaluation of all downstream delegation paths.", "steps": [ "Define a trust graph schema capturing agent identity, permitted orchestration targets, delegated capability set, expiry, and approval provenance.", "Store the trust graph in a version-controlled repository with signed commits; gate all agent deployments on a current valid graph entry.", "Instrument the orchestration runtime to load and validate the trust graph at startup and on each agent-to-agent invocation.", "Automate weekly reconciliation between the trust graph and active agent deployments, alerting on undocumented relationships." ], "ai_engineer": { "summary": "The trust graph is the source of truth for which agents can call which other agents. Every inter-agent invocation must be validated against it at runtime.", "actions": [ "Implement a trust graph loader in the orchestration framework that validates caller-callee pairs before routing.", "Emit structured log events on every trust graph lookup, including the evaluation result.", "Write unit tests for trust graph boundary cases: expired edges, missing nodes, scope overflow." ], "failure_signals": [ "Agent invocations succeeding without a corresponding trust graph edge.", "Trust graph staleness exceeding the defined TTL.", "Reconciliation diffs showing undocumented agent relationships." ] }, "security_architect": { "summary": "The trust graph enforces the principle of least authority at the orchestration layer. It must be treated as a security-sensitive artifact with integrity protection.", "actions": [ "Require cryptographic signing of trust graph entries; validate signatures at load time.", "Classify the trust graph as a critical security artifact; apply change-management controls equivalent to IAM policy.", "Define a threat model entry for trust graph poisoning and ensure detection controls are in place." ], "failure_signals": [ "Unsigned or self-signed trust graph entries accepted in production.", "Trust graph stored without access controls or integrity verification.", "No alerting on trust graph modification events." ] }, "grc_auditor": { "summary": "The trust graph is the primary artifact for demonstrating that orchestration authority is bounded, documented, and governed.", "actions": [ "Request the current trust graph export and verify it covers all deployed agent identities.", "Sample 15% of trust graph edges and confirm each has a corresponding approval record.", "Verify that trust graph change events are logged with actor, timestamp, and rationale." ], "metrics": [ "Trust graph coverage: target 100% of deployed agents.", "Unapproved trust graph edges: target 0.", "Mean time to reconcile undocumented relationships: target < 24 hours." ], "failure_signals": [ "Trust graph coverage below 95% for two consecutive review cycles.", "Approved records missing for sampled edges.", "No change log available for trust graph modifications." ] }, "legal_counsel": { "summary": "The multi-agent trust graph documents who authorized which agent to direct which other agents — the authority chain a regulator or court will walk when an orchestrated workflow causes harm. Undocumented delegation reads as unaccountable autonomy.", "actions": [ "Confirm every production delegation path appears in the approved trust graph and that graph changes carry documented approval.", "Verify the graph is versioned and retained so the authority chain in force at any past moment can be proven.", "Assess whether delegation to vendor-operated agents is backed by contracts allocating responsibility for the sub-agent's actions." ], "failure_signals": [ "Delegation relationships discovered in production that the documented trust graph does not contain.", "Inability to produce the historical trust graph for the date of a disputed orchestrated action.", "Vendor sub-agents acting under enterprise delegation with no contractual responsibility allocation." ] }, "platform_engineer": { "summary": "The trust graph must be operationally integrated into deployment pipelines so that no agent ships without a valid trust graph entry.", "actions": [ "Add a trust graph validation step to the CI/CD pipeline that blocks deployment if the agent lacks a valid graph entry.", "Automate trust graph snapshot archival on each production deployment event.", "Build a dashboard showing trust graph coverage, edge counts, and reconciliation status." ], "failure_signals": [ "Agents deployed to production without trust graph entries.", "CI/CD trust graph gate disabled or bypassed.", "Dashboard showing stale trust graph snapshots." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have no machine-readable trust graph for multi-agent systems; trust is implicit in code." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "federated-enterprise", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "AI Platform Team", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 2.1", "fit": "direct", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A machine-readable multi-agent trust graph documents exactly those lines for agent-to-agent authority: who may delegate to whom, and under what constraints.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "partial", "rationale": "ISO/IEC 42001 §8.1 requires documented operational control of AI system processes. A machine-readable trust graph documents the interrelationships and delegation paths among agent components, giving the operational control requirement a concrete artifact for multi-agent deployments.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 13", "fit": "partial", "rationale": "EU AI Act Article 13 requires high-risk AI systems to be transparent and to provide deployers with information necessary to ensure appropriate use. Documenting agent trust chains is a prerequisite for deployers to understand system boundaries.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) identifies undocumented capability grants as a primary attack surface. An explicit trust graph constrains agency to documented, approved delegation paths.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy category is concerned with AI systems directing other systems over extended horizons without human visibility. A documented, machine-readable multi-agent trust graph is the deployer-side control that keeps such delegation chains explicit and reviewable.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require organizations to attribute automated actions to defined authority chains. A machine-readable multi-agent trust graph documents those chains for orchestrated deployments, making every delegation path explicit and reviewable.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 — Explicit trust boundaries; Part II — Unscoped privilege inheritance", "fit": "direct", "rationale": "Multi-agent trust relationships are dynamic and often implicit; doc requires documenting and verifying explicit trust boundaries across the agent chain.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AO-01", "validation_objective": "Proves that every agent-to-agent delegation relationship in the production deployment is documented in a versioned, cryptographically signed trust graph, and that the orchestration runtime validates trust graph edges before routing any inter-agent invocation. No agent invocation may succeed without a corresponding valid trust graph edge in the current signed graph.", "evidence_required": [ "Trust graph export covering 100% of deployed agent identities with signed entries and version metadata", "Trust graph version history with signed commit provenance showing change authorization records for all modifications", "Sample of trust graph edge approval records covering at least 15% of edges, each with documented approver identity and rationale", "Weekly reconciliation report confirming no undocumented agent relationships exist between the trust graph and active agent deployments", "Orchestration runtime invocation logs confirming trust graph lookups are performed and logged on each inter-agent call" ], "machine_tests": [ "Reconcile trust graph node inventory against the deployed agent registry and flag any deployed agent without a trust graph entry as a critical finding", "Verify all trust graph entries carry valid cryptographic signatures from the authorized signing key and reject any self-signed or unsigned entries", "Confirm the orchestration runtime logs trust graph lookup events for 100% of inter-agent invocations by sampling a 7-day invocation window", "Attempt a synthetic inter-agent invocation with no corresponding trust graph edge and verify the runtime rejects it with a structured security event" ], "human_review": [ "Assess whether the trust graph accurately captures all orchestration patterns in production, including ad-hoc and event-driven pipelines that may not follow standard deployment paths", "Review trust graph change authorization records for appropriateness of the approval chain relative to the operational impact of each change", "Evaluate trust graph TTL and refresh cadence against the rate of operational change to confirm the graph does not become stale between reconciliation cycles" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Encoding inter-agent trust relationships implicitly in code or service mesh configuration rather than in a separate, machine-readable, version-controlled trust graph", "Accepting self-signed or unsigned trust graph entries in production, removing the integrity guarantee that signed entries provide", "Treating trust graph reconciliation as a quarterly compliance exercise rather than a weekly operational control that keeps the graph current with production", "Using the trust graph only as documentation and not as a runtime enforcement source, so undocumented relationships can still succeed at invocation time" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-02", "layer": "AO", "plane": "control", "name": "Sub-Agent Authorization and Capability Delegation", "plain": "Orchestrator agents must only delegate explicitly authorized capability subsets to worker agents, with delegation tokens that encode scope, expiry, and revocation conditions — preventing workers from exceeding the authority the orchestrator itself holds.", "threat": { "tags": [ "capability-overgrant", "privilege-escalation", "confused-deputy", "scope-creep" ], "desc": "Without enforced capability delegation, an orchestrator may grant a worker agent capabilities the orchestrator was never authorized to delegate, creating a confused-deputy vulnerability. Workers accumulate permissions across task invocations if tokens are not scoped and time-bounded. A compromised worker agent with an overly broad delegation token can pivot to high-value resources outside the intended task scope." }, "standard": [ { "id": "nist_rmf", "section": "§3.4 — Accountable and Transparent", "title": "Traceable accountability for AI outcomes" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — capability overgrant" }, { "id": "eu_ai_act", "section": "Article 9", "title": "Risk management system — capability constraints" } ], "sources": [ { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AO-02 Sub-Agent Authorization and Capability Delegation control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-02 Sub-Agent Authorization and Capability Delegation control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-02 Sub-Agent Authorization and Capability Delegation control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-02 Sub-Agent Authorization and Capability Delegation control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-02 Sub-Agent Authorization and Capability Delegation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Issue short-lived, scoped delegation tokens on each orchestrator-to-worker invocation. Tokens encode: issuing orchestrator identity, worker identity, permitted capability set (allow-list), resource scope, expiry (max 15 minutes for synchronous tasks), and a revocation handle. Workers present tokens to capability enforcement points; enforcement points validate token signature, scope, and expiry before permitting action.", "steps": [ "Define a delegation token schema that encodes issuer, subject, capability allow-list, resource scope, iat, exp, and a revocation nonce.", "Implement a token issuance service within the orchestration runtime that mints tokens at invocation time and registers revocation handles.", "Deploy capability enforcement middleware at all tool and resource access points that validates delegation tokens before permitting actions.", "Establish a revocation endpoint allowing orchestrators to invalidate active delegation tokens when a worker task is cancelled or anomalous behavior is detected." ], "ai_engineer": { "summary": "Delegation tokens are the technical mechanism enforcing least-privilege at every orchestrator-to-worker call. They must be minted fresh per invocation and validated at every capability use.", "actions": [ "Integrate delegation token minting into the agent SDK's task dispatch method so tokens are issued automatically.", "Implement capability enforcement middleware that parses and validates tokens before any tool call executes.", "Add token scope violation events to the agent's structured log output." ], "failure_signals": [ "Workers accessing capabilities not listed in their delegation token.", "Delegation tokens with expiry exceeding policy maximum.", "Tool calls succeeding without a valid delegation token present." ] }, "security_architect": { "summary": "Delegation tokens enforce confused-deputy protection and least-privilege. The token issuance service is a critical security boundary and must be hardened accordingly.", "actions": [ "Require delegation tokens to be signed by the orchestration runtime using a key stored in a hardware security module or equivalent.", "Model the token issuance service as a privileged component in the system threat model.", "Define maximum delegation depth (e.g., orchestrator → worker → tool; no further sub-delegation) to prevent privilege amplification chains." ], "failure_signals": [ "Tokens signed with software-only keys without HSM backing in production.", "Sub-delegation depth exceeding policy maximum.", "No revocation pathway for active delegation tokens." ] }, "grc_auditor": { "summary": "Delegation token controls demonstrate that the principle of least privilege is operationally enforced across the orchestration layer.", "actions": [ "Review delegation token policy documentation and verify it covers all orchestrator types in production.", "Sample 10% of task execution logs and verify each worker invocation carried a valid scoped token.", "Test revocation by requesting a token invalidation and verifying the worker loses access within the defined revocation propagation window." ], "metrics": [ "Percentage of worker invocations with valid scoped delegation tokens: target 100%.", "Mean token expiry: target ≤ 15 minutes for synchronous tasks.", "Revocation propagation time: target < 60 seconds." ], "failure_signals": [ "Worker invocations logged without delegation token validation.", "Tokens found with expiry > 1 hour in audit samples.", "Revocation events not reflected in enforcement points within SLA." ] }, "legal_counsel": { "summary": "Delegation scope controls are a legal prerequisite for demonstrating that AI agents operated within their authorized scope — essential for liability containment when agents take consequential actions.", "actions": [ "Confirm delegation token scope documentation exists for all high-risk orchestration workflows.", "Verify that token scope boundaries align with contractual limits on AI agent authority in customer agreements.", "Ensure delegation logs are retained for the duration required by applicable regulatory frameworks." ], "failure_signals": [ "No documented scope constraints for agents performing consequential actions.", "Delegation token scope exceeding contractually permitted agent authority.", "Delegation logs not retained per regulatory retention requirements." ] }, "platform_engineer": { "summary": "You provide the delegation-token infrastructure for multi-tier orchestration: minting, verifying, and expiring scoped tokens at every parent-to-sub-agent handoff, uniformly across orchestrators.", "actions": [ "Ship delegation-token minting and verification as a shared platform library/service so every orchestrator enforces subset-scoping identically.", "Enforce verification at sub-agent runtime entry: no delegation token, or scopes exceeding the parent's, means the sub-agent does not start.", "Propagate delegation-chain identifiers into all downstream telemetry so any action can be traced to its originating grant." ], "failure_signals": [ "Orchestrators spawning sub-agents with inherited parent credentials instead of scoped delegation tokens.", "Scope-subset validation implemented differently (or not at all) across orchestration frameworks.", "Telemetry that cannot connect a sub-agent's action back to the delegation grant that authorized it." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most agent frameworks rely on ambient credentials rather than per-invocation scoped delegation tokens." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Platform Team", "Security Architecture", "Identity Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "§3.4 — Accountable and Transparent", "fit": "partial", "rationale": "NIST AI RMF §3.4 defines Accountable and Transparent as trustworthiness characteristics: responsibility for AI outcomes must remain traceable. Scoped delegation tokens keep every sub-agent action traceable to an explicit, bounded grant from its parent, preserving accountability through the delegation chain.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) identifies capability overgrant as a primary agentic risk. Scoped delegation tokens with explicit allow-lists directly mitigate overgrant by making capability boundaries enforceable at every delegation event.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "eu_ai_act", "requirement_id": "Article 9", "fit": "partial", "rationale": "EU AI Act Article 9 requires risk management systems for high-risk AI to include measures limiting agent capabilities to those necessary for the intended purpose. Delegation scope constraints are a direct technical implementation of this requirement.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy category treats unsupervised expansion of an AI system's effective authority as a key risk. Scoped delegation tokens with explicit capability allow-lists prevent sub-agents from accumulating authority beyond the parent's grant.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent Permissions (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Permissions control requires enforceable scoping of what each agent may do. Scoped delegation tokens carry that enforcement into multi-agent orchestration: each sub-agent's permissions are an explicit, verifiable subset of its parent's grant.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS1 — Reliability and safety guidance", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS1 requires systems to operate within defined boundaries. Scoped delegation tokens enforce those boundaries transitively: a sub-agent's authority is always a documented subset of its parent's, so orchestration cannot silently widen the operating envelope.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II — Unscoped privilege inheritance; Part IV Phase 6 — Explicit trust boundaries", "fit": "direct", "rationale": "Unscoped privilege inheritance: a manager agent delegates its full access context to a worker without least-privilege scoping; doc requires per-step authorization and least-privilege sub-agent delegation.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "supporting", "rationale": "AO-02 requires that a delegated sub-agent's capability allow-list never exceed the orchestrator's own authorization, enforcing least privilege across delegation.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestrator-to-worker agent invocation is authorized by a valid,…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestrator-to-worker agent invocation is authorized by a valid,…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestrator-to-worker agent invocation is authorized by a valid,…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AO-02", "validation_objective": "Proves that every orchestrator-to-worker agent invocation is authorized by a valid, scoped delegation token whose capability allow-list does not exceed the orchestrator's own authorization, and that capability enforcement points reject any tool access not explicitly listed in the presented token. No worker agent may invoke a tool without a valid, unexpired delegation token authorizing that specific capability.", "evidence_required": [ "Sample of delegation token records from task execution logs covering at least 10% of worker invocations, confirming token presence and scope alignment", "Capability enforcement middleware configuration audit confirming per-token validation is applied at all tool and resource access points", "Revocation test records demonstrating sub-60-second propagation from revocation request to enforcement point rejection", "Delegation depth audit confirming no invocation chain exceeds the policy-defined maximum depth", "Token expiry distribution report confirming synchronous task tokens meet the defined maximum expiry (≤15 minutes)" ], "machine_tests": [ "Scan task execution logs for worker invocations missing a delegation token validation record and flag any gap as a critical finding", "Verify that no delegation token in the audit sample has an expiry exceeding the policy maximum (1 hour), with any violation flagged immediately", "Present an out-of-scope capability request to the enforcement middleware with a valid token that does not list the requested capability, and confirm rejection with a structured denial event", "Verify token issuance is performed by the orchestration runtime (not the worker agent) by confirming token issuer identity fields in the audit sample match the orchestrator identity" ], "human_review": [ "Review delegation token policy documentation for coverage across all orchestrator types in production, including any orchestrators added since the last policy review", "Assess whether capability allow-lists in sampled tokens reflect actual task requirements or exhibit systematic over-granting for engineering convenience", "Confirm the revocation endpoint is documented, accessible, and included in incident response runbooks so it can be invoked during an active security incident" ], "blocking_effect": "blocks-runtime-action", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using ambient credentials (long-lived API keys, inherited IAM roles) for worker agent tool access instead of per-invocation scoped delegation tokens", "Granting broad capability sets in delegation tokens to avoid the engineering effort of scoping allow-lists to actual task requirements", "Setting delegation token expiry to match session or pipeline duration rather than individual task duration, leaving tokens valid long after the authorized task completes", "Permitting sub-delegation beyond the policy-defined maximum depth without explicit authorization, enabling privilege amplification through chained delegation" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-03", "layer": "AO", "plane": "control", "name": "Orchestration Message Integrity", "plain": "All messages passed between agents in an orchestration pipeline must carry cryptographic integrity protection, ensuring that task instructions, context payloads, and result envelopes cannot be tampered with in transit or at rest within the pipeline.", "threat": { "tags": [ "message-tampering", "prompt-injection-via-pipeline", "replay-attack", "man-in-the-middle" ], "desc": "An attacker with access to the message bus or queue between agents can inject malicious instructions, replay captured task payloads, or alter result envelopes to corrupt downstream agent decisions. Prompt injection attacks delivered through orchestration messages bypass input validation applied at the user boundary. Without integrity protection, an orchestrator cannot distinguish a legitimate worker response from an attacker-injected one." }, "standard": [ { "id": "nist_ai_600_1", "section": "2.9", "title": "Information Security — prompt injection protections" }, { "id": "owasp_llm10", "section": "LLM01:2025", "title": "Prompt injection — pipeline delivery vector" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control — orchestration integrity" }, { "id": "mitre_atlas", "section": "AML.T0051", "title": "LLM prompt injection" } ], "sources": [ { "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-29", "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://agentic/controls/AO-03 Orchestration Message Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-03 Orchestration Message Integrity control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-03 Orchestration Message Integrity control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-03 Orchestration Message Integrity control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Sign all inter-agent messages using HMAC-SHA256 or Ed25519, with the signing key bound to the sending agent's identity credential. Include a message sequence number and timestamp in the signed payload to prevent replay. Validate signatures at the receiving agent before processing any instruction or result payload. Message validation failures produce a structured security event and halt pipeline execution.", "steps": [ "Define a message envelope schema that includes: sender identity, recipient identity, message type, payload hash, sequence number, timestamp, and signature.", "Provision per-agent signing keys bound to the agent's identity credential; rotate keys on agent redeployment.", "Implement message signing middleware in the agent SDK that wraps all outbound inter-agent messages and validates all inbound ones.", "Configure the orchestration runtime to terminate pipeline execution and emit a security alert on any message signature validation failure." ], "ai_engineer": { "summary": "Every message crossing an agent boundary must be signed and validated. Treat an unsigned or invalid-signature message as a security event, not a retry.", "actions": [ "Integrate message signing into the agent SDK's send and receive interfaces so developers cannot bypass it.", "Implement replay detection using sequence numbers tracked per sender-recipient pair within a session window.", "Emit a structured INTEGRITY_FAILURE event to the observability pipeline on any validation failure." ], "failure_signals": [ "Unsigned messages accepted by agent message handlers.", "Sequence number gaps not detected or not triggering alerts.", "Message validation bypassed in test or staging environments without equivalent compensating controls." ] }, "security_architect": { "summary": "Message integrity is the foundational defense against prompt injection delivered through the orchestration layer. The signing infrastructure is a critical security component.", "actions": [ "Specify Ed25519 as the preferred signing algorithm; document acceptable fallback to HMAC-SHA256 with 256-bit keys.", "Require signing keys to be managed by the organization's key management service, not hardcoded.", "Include message integrity bypass scenarios in the orchestration threat model and define detection coverage." ], "failure_signals": [ "Signing keys stored in environment variables or application configuration files.", "No key rotation policy defined for agent signing keys.", "Threat model lacks coverage for pipeline message tampering." ] }, "grc_auditor": { "summary": "Message integrity controls demonstrate that the orchestration pipeline cannot be subverted through message tampering — a critical compliance requirement for high-risk AI deployments.", "actions": [ "Request evidence of message signing key management procedures and verify key rotation history.", "Review security event logs for INTEGRITY_FAILURE events and confirm each triggered an incident response action.", "Verify that message integrity validation is enforced in production (not only test) environments." ], "metrics": [ "Percentage of inter-agent messages with validated integrity: target 100%.", "INTEGRITY_FAILURE events resulting in pipeline halt: target 100%.", "Mean time to rotate compromised signing keys: target < 4 hours." ], "failure_signals": [ "Unsigned messages processed without alerting in production logs.", "INTEGRITY_FAILURE events without corresponding incident records.", "Signing keys not rotated within the policy-defined interval." ] }, "legal_counsel": { "summary": "Signed orchestration messages establish that instructions moving between agents are authentic — the difference between attributing a harmful workflow to an external attacker versus an internal control failure. Signature records also protect the enterprise against fabricated-instruction claims.", "actions": [ "Confirm message-integrity coverage extends to orchestration paths that cross vendor or partner boundaries, with responsibilities contractually assigned.", "Verify signature validation failures are logged and retained as evidence of attempted manipulation.", "Assess incident classification and notification posture for confirmed forged-message events." ], "failure_signals": [ "Cross-organization orchestration channels with no integrity guarantees and no contractual owner for that gap.", "Forged-message attempts detected but not preserved as evidence.", "No documented determination of when pipeline-injection events become reportable incidents." ] }, "platform_engineer": { "summary": "Message integrity enforcement must be built into the orchestration infrastructure so that it operates transparently for all agent deployments without per-application configuration.", "actions": [ "Deploy message signing as a platform-level interceptor in the agent messaging middleware.", "Integrate key provisioning into the agent deployment pipeline so signing keys are issued automatically at deploy time.", "Build alerting on INTEGRITY_FAILURE events into the platform's security observability stack." ], "failure_signals": [ "Agents deployable without automatic signing key provisioning.", "Message integrity middleware disabled for any environment without a documented waiver.", "INTEGRITY_FAILURE events not surfaced in platform security dashboards." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agent orchestration frameworks pass messages as plaintext JSON without signing; message integrity is an emerging practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Platform Team", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "nist_ai_600_1", "requirement_id": "2.9 — Information Security", "fit": "direct", "rationale": "NIST AI 600-1 §2.9 (Information Security) covers attacks that compromise the confidentiality and integrity of generative AI systems, including injection of adversarial instructions. Cryptographic message integrity blocks the pipeline-delivered variant: forged or altered inter-agent messages are rejected before processing.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM01:2025 — Prompt Injection", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM01 (Prompt Injection) covers indirect injection via external data sources and pipelines. Signing inter-agent messages prevents attackers from injecting instructions into the orchestration pipeline undetected.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 documents LLM prompt injection as an active adversarial technique. Message integrity controls with signature validation are a direct technical countermeasure to pipeline-delivered injection attempts.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "partial", "rationale": "ISO/IEC 42001 §8.1 requires operational processes to be implemented and controlled in line with identified risks. For multi-agent orchestration, cryptographic message integrity is a proportionate operational control against the documented threat of pipeline-delivered instruction injection.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "partial", "rationale": "Google SAIF element 2 (Extend detection and response) includes detecting adversarial inputs to AI systems. Signature validation on inter-agent messages is a prerequisite detection mechanism: forged or altered pipeline messages become detectable events rather than silent compromises.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires systems to withstand predictable failure and manipulation modes. Injection of forged instructions into orchestration pipelines is such a mode; cryptographic message integrity is the standing remediation that makes forged inter-agent messages detectable.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 — Explicit trust boundaries (authorization checks at each step; log inter-agent comms)", "fit": "partial", "rationale": "Doc requires authorization checks at each step of multi-agent workflows and logging inter-agent communications. Partial: doc does not prescribe cryptographic orchestration-message integrity specifically.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AO-03", "validation_objective": "Proves that every message crossing an agent boundary in the orchestration pipeline carries a valid cryptographic signature from the sending agent's identity-bound key, and that receiving agents validate signatures before processing any payload, terminating the pipeline with a structured security event on any integrity failure. No inter-agent message may be processed without a verified signature.", "evidence_required": [ "Message signing key management records including key provisioning procedures, rotation history, and storage location confirmation (must be key management service, not application config)", "INTEGRITY_FAILURE event log for the prior 90 days confirming all failures triggered pipeline termination and a corresponding incident response record", "Sample of production inter-agent message records confirming signature fields (sender identity, payload hash, sequence number, timestamp, signature) are present and non-empty", "Replay detection log confirming sequence number tracking is active per sender-recipient pair within session windows" ], "machine_tests": [ "Inject an unsigned inter-agent message into the pipeline and verify it is rejected with an INTEGRITY_FAILURE event and pipeline termination, not silently accepted or retried", "Inject a replayed message with a valid signature but a sequence number below the current expected value and verify replay detection triggers rejection", "Scan agent deployment configurations and environment variables for signing key material and confirm none is stored outside the designated key management service", "Verify all inbound message handler implementations call signature validation before any payload parsing by static analysis or runtime instrumentation" ], "human_review": [ "Assess signing algorithm selection (Ed25519 preferred, HMAC-SHA256 acceptable) and key management procedures against current cryptographic standards and organizational key management policy", "Review all past INTEGRITY_FAILURE incident records and confirm each triggered appropriate investigation rather than being dismissed as an operational anomaly", "Evaluate the replay detection window duration for adequacy — too short misses delayed replays; too long retains excessive sequence state" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Storing signing keys in environment variables or application configuration files rather than a key management service, exposing them to any process with environment access", "Enabling message integrity validation only in test environments and disabling it in production for performance reasons, inverting the security model", "Treating INTEGRITY_FAILURE as a warning that allows message processing to continue after logging, rather than a hard stop that terminates the pipeline", "Using a single symmetric signing key shared across multiple agents rather than per-agent identity-bound keys, so a single compromised agent can forge messages from any other agent" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-04", "layer": "AO", "plane": "control", "name": "Human-in-the-Loop Gates for High-Consequence Orchestrations", "plain": "Orchestration pipelines that produce irreversible, high-consequence, or regulated effects must include mandatory human approval checkpoints that block pipeline execution until an authorized human reviewer explicitly approves continuation.", "threat": { "tags": [ "autonomous-irreversible-action", "missing-human-oversight", "runaway-pipeline", "consequence-blindness" ], "desc": "Without human-in-the-loop gates, multi-agent pipelines can execute chains of irreversible actions — deleting data, committing funds, publishing communications, modifying production systems — faster than human operators can intervene. A misconfigured or compromised orchestrator can trigger cascading effects across multiple systems before any human is aware the pipeline has started. Removing human oversight gates for cost or latency savings creates regulatory exposure in sectors requiring human review of consequential AI decisions." }, "standard": [ { "id": "eu_ai_act", "section": "Article 14", "title": "Human oversight measures for high-risk AI" }, { "id": "nist_rmf", "section": "GOVERN 3.2", "title": "Human-AI oversight roles and responsibilities" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring and measurement of AI system performance and impact" }, { "id": "anthropic_rsp", "section": "Required Safeguards — ASL-3 Deployment Standard", "title": "Safeguards for high-consequence capabilities (Anthropic RSP v3.3)" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-04 Human-in-the-Loop Gates for High-Consequence Orchestrations control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-04 Human-in-the-Loop Gates for High-Consequence Orchestrations control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-04 Human-in-the-Loop Gates for High-Consequence Orchestrations control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-04 Human-in-the-Loop Gates for High-Consequence Orchestrations control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Classify all orchestration workflows by consequence level using a defined taxonomy (read-only, reversible-write, irreversible-write, regulated-action). For irreversible-write and regulated-action classifications, insert a human approval gate control point in the pipeline DAG. Gate control points: pause execution, present a structured decision package to a qualified reviewer, record the approval decision with actor identity and timestamp, and only resume execution on explicit approval. Rejections terminate the pipeline and trigger an incident record.", "steps": [ "Define a consequence taxonomy with at least four levels; document classification criteria and map them to specific action types (e.g., data deletion, financial transaction, external communication).", "Implement a gate control point primitive in the orchestration framework that can be inserted into any pipeline DAG node.", "Build a reviewer interface that presents the pipeline state, pending action description, predicted consequence, and approval/reject controls to a qualified human reviewer.", "Log all gate decisions with reviewer identity, decision, rationale, and timestamp; make the log immutable and accessible to audit functions." ], "ai_engineer": { "summary": "Human-in-the-loop gates are first-class control points in the orchestration framework, not optional add-ons. The pipeline must be designed to pause and await human input at classified decision points.", "actions": [ "Implement a GateControlPoint node type in the pipeline DAG that blocks execution until an approval token is received.", "Design the reviewer decision package to include: action description, predicted consequence, confidence estimate, and rollback feasibility.", "Implement timeout handling for gate control points: pipelines that do not receive approval within the defined window should self-terminate, not proceed." ], "failure_signals": [ "Pipelines classified as irreversible-write executing without triggering a gate.", "Gate control points configured with auto-approve after timeout instead of auto-terminate.", "Reviewer interface presenting insufficient context for an informed decision." ] }, "security_architect": { "summary": "Human-in-the-loop gates are a safety boundary that must be tamper-resistant. An attacker who can bypass or auto-approve gates defeats the entire control.", "actions": [ "Require gate approval tokens to be issued by the identity system (not the orchestration runtime) and signed with reviewer credentials.", "Ensure gate bypass is logged as a critical security event; treat gate bypass capability as equivalent to privileged access.", "Include gate bypass scenarios in the orchestration threat model." ], "failure_signals": [ "Gate approval logic embedded in the same process as the orchestration runtime (no separation of privilege).", "No alerting on gate bypass attempts.", "Reviewer credentials for gate approval not subject to MFA requirements." ] }, "grc_auditor": { "summary": "Human-in-the-loop gates are the primary control evidence for human oversight of high-risk AI orchestration. Gate activation and approval records are key audit artifacts.", "actions": [ "Request the consequence taxonomy and verify it covers all high-risk action types in production pipelines.", "Sample 20% of gate activation events and verify each has a complete approval record with reviewer identity.", "Test gate effectiveness by attempting to advance a pipeline past a gate without approval and verifying the pipeline terminates." ], "metrics": [ "Percentage of irreversible-write pipelines with at least one gate control point: target 100%.", "Gate activations with complete approval records: target 100%.", "Gate bypass incidents: target 0." ], "failure_signals": [ "Irreversible-write pipelines executing without gate activation in audit samples.", "Gate activation records missing reviewer identity or timestamp.", "Any gate bypass event without a corresponding security incident record." ] }, "legal_counsel": { "summary": "Human oversight gates are a legal compliance requirement for high-risk AI under EU AI Act and sector-specific regulations. Their presence and activation records are primary evidence in regulatory reviews.", "actions": [ "Map all orchestration pipeline action types to applicable regulatory human-review requirements (EU AI Act Article 14, sector regulations).", "Verify that gate approval records are retained for the period required by applicable law and are legally admissible.", "Confirm that the consequence taxonomy covers all action types subject to human review obligations under applicable agreements and regulations." ], "failure_signals": [ "Regulated action types not classified in the consequence taxonomy.", "Gate approval records not retained for the legally required period.", "No documented mapping between consequence taxonomy and applicable regulatory requirements." ] }, "platform_engineer": { "summary": "You run the gate service that pauses high-consequence orchestrations for human decisions: durable pending state, approver routing, timeout handling, and resumption semantics that don't lose or duplicate work.", "actions": [ "Persist gated workflow state durably so a pending approval survives orchestrator restarts and can resume exactly once after decision.", "Integrate approver routing with the enterprise directory and on-call schedules; a gate with no reachable approver is an outage or a bypass waiting to happen.", "Alert on gate-queue aging and default to deny/park on timeout — never auto-approve on expiry." ], "failure_signals": [ "Approved workflows resuming twice (duplicate side effects) or not at all after gate decisions.", "Gates routing to individuals who have left the team or rotation, stalling or orphaning approvals.", "Timeout behavior configured to proceed, silently converting absence of review into consent." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Human-in-the-loop gates are widely recommended but inconsistently implemented; most deployments lack a formal consequence taxonomy." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "AI Platform Team", "Security Architecture", "Legal / Compliance", "Operations" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Article 14", "fit": "direct", "rationale": "EU AI Act Article 14 mandates human oversight measures for high-risk AI systems, including the ability for humans to intervene and override system outputs. Human-in-the-loop gates directly implement this requirement at the orchestration layer.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 3.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 3.2 requires policies that define and differentiate human roles for oversight of AI systems. Human-in-the-loop gates instantiate those roles at the orchestration layer, with named approvers for high-consequence multi-agent workflows.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards — ASL-3 Deployment Standard", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP requires safeguards proportionate to capability before high-capability deployment proceeds. AO-04 applies the proportionality pattern to orchestration: workflows whose aggregate consequence is high must pass through a human decision gate before execution.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "partial", "rationale": "ISO 42001 §9.1 requires organizations to monitor and measure AI system impact, including the consequences of AI decisions. Human-in-the-loop gates create structured intervention points that support the monitoring and control objectives of §9.1.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 requires meaningful human oversight of high-impact automated behavior. Human-in-the-loop gates with logged approvals implement A5 at the orchestration layer: high-consequence multi-agent workflows pause for an accountable human decision.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Safeguarding against severe harm (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §4 conditions deployment of highly capable systems on safeguards against severe harm. AO-04's human-in-the-loop gates are the orchestration-layer safeguard: high-consequence multi-agent workflows cannot complete without an accountable human decision.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent User Control (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent User Control requires that consequential agent behavior remain under effective human control. Human-in-the-loop gates for high-consequence orchestrations implement that control where multiple agents compound the blast radius of a single decision.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 3 — Escalation triggers; Part IV Phase 5 — Approval escalation", "fit": "direct", "rationale": "High-consequence orchestrations require human-in-the-loop approval (escalation triggers / approval escalation).", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "ms_ifc_agents", "requirement_id": "Check before acting — policy engine may block an action or ask a human to review it", "fit": "partial", "rationale": "IFC's policy engine can route an action to a human when labels indicate high consequence ('ask a human to review it'), supporting human-in-the-loop gates. The article does not scope this to multi-agent orchestration specifically, so the fit is partial.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_aisvs", "requirement_id": "C9.2.6", "fit": "supporting", "rationale": "AISVS C9.2.6 AI-augmented review of high-risk plans, additive to the deterministic gate.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "oversight", "fit": "direct", "rationale": "AO-04 requires a mandatory human-approval gate that blocks irreversible or regulated orchestrations until a reviewer approves, enforcing the human oversight of AI actions AI Exchange specifies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestration pipeline classified as irreversible-write or…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0029", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestration pipeline classified as irreversible-write or…\" enacts ATLAS mitigation AML.M0029 Human In-the-Loop for AI Agent Actions; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0030", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every orchestration pipeline classified as irreversible-write or…\" enacts ATLAS mitigation AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AO-04", "validation_objective": "Proves that every orchestration pipeline classified as irreversible-write or regulated-action contains at least one mandatory human approval gate that blocks execution until an authorized reviewer explicitly approves continuation, and that pipelines self-terminate (not auto-approve) when the gate timeout is reached without reviewer action. No irreversible or regulated pipeline action may be executed without a logged, attributed human approval decision.", "evidence_required": [ "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer" ], "machine_tests": [ "Enumerate all production pipeline DAGs and verify that every pipeline with an irreversible-write or regulated-action node contains at least one GateControlPoint node upstream of the classified action", "Test gate timeout behavior by allowing a gate to reach its timeout without reviewer action and confirming the pipeline terminates rather than proceeds or auto-approves", "Verify gate approval tokens are issued by the identity system (not the orchestration runtime itself) by inspecting token issuer claims in sampled approval records", "Confirm gate activation records are written to immutable storage by verifying the log store prevents modification or deletion of gate decision records" ], "human_review": [ "Assess consequence taxonomy completeness against current production pipeline action types and applicable regulatory human-review obligations, including any action types added since the taxonomy was last reviewed", "Review a sample of gate approval records for quality of reviewer rationale — nominal approvals with no stated reasoning indicate rubber-stamping rather than genuine human review", "Evaluate whether reviewer decision packages present sufficient context for genuinely informed decisions, including meaningful consequence estimates rather than generic descriptions" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Configuring gate timeout to auto-approve rather than auto-terminate, converting a safety gate into a rubber-stamp that proceeds by default when reviewers are unavailable", "Embedding gate approval logic in the same process as the orchestration runtime with no separation of privilege, allowing a compromised orchestrator to self-approve its own gate", "Classifying pipeline action types in the consequence taxonomy without legal or compliance review of applicable regulatory human-review obligations, creating gaps for regulated actions", "Setting reviewer windows so short (e.g., 30 seconds) that reviewers cannot meaningfully evaluate the decision package, producing nominal compliance while defeating the oversight intent" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-05", "layer": "AO", "plane": "control", "name": "Orchestration Loop and Escalation Detection", "plain": "Orchestration runtimes must implement automated detection of infinite loops, unexpected recursion, and unauthorized capability escalation within agent pipelines, with circuit-breaker controls that terminate runaway pipelines before resource exhaustion or unintended effects occur.", "threat": { "tags": [ "infinite-loop", "resource-exhaustion", "capability-escalation", "runaway-agent" ], "desc": "Agent orchestration pipelines can enter infinite loops when agents repeatedly invoke each other without a convergence condition, consuming compute, tokens, and API quota until rate limits or budget exhaustion terminates them — potentially after causing unintended side effects. A compromised or misconfigured agent can escalate its own capabilities by repeatedly requesting expanded permissions through the orchestration layer until a permissive policy grants them. Without detection, runaway pipelines operate unnoticed until they cause financial, operational, or security harm." }, "standard": [ { "id": "nist_rmf", "section": "§3.2 — Safe", "title": "Capacity for override and safe shutdown" }, { "id": "owasp_llm10", "section": "LLM06:2025", "title": "Excessive Agency — unbounded execution" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring (Annex A)" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-05 Orchestration Loop and Escalation Detection control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-05 Orchestration Loop and Escalation Detection control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-05 Orchestration Loop and Escalation Detection control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-05 Orchestration Loop and Escalation Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Instrument the orchestration runtime with three detection mechanisms: (1) cycle detection in the pipeline execution graph using agent invocation sequence tracking; (2) step count and depth counters with hard limits; (3) permission request frequency monitoring with escalation threshold alerts. Configure circuit breakers at each mechanism that terminate the pipeline, revoke active delegation tokens, and emit a structured LOOP_DETECTED or ESCALATION_DETECTED event when thresholds are exceeded.", "steps": [ "Implement invocation sequence tracking per pipeline execution context: record each agent-to-agent call in a directed graph and run cycle detection at each invocation.", "Define hard limits for pipeline depth (e.g., max 10 levels), step count (e.g., max 200 steps), and execution duration (e.g., max 30 minutes); enforce via circuit breakers that trigger on threshold breach.", "Monitor permission request frequency per agent per session; alert and terminate when an agent requests capability expansion more than a defined threshold (e.g., 3 times) within a single task.", "Emit structured LOOP_DETECTED and ESCALATION_DETECTED events to the security observability pipeline with full execution context for incident response." ], "ai_engineer": { "summary": "Loop and escalation detection must be baked into the orchestration runtime, not left to individual agent implementations. Every pipeline execution context needs a step counter and cycle detector.", "actions": [ "Add execution context tracking to the pipeline dispatcher: maintain invocation graph, step count, depth counter, and wall-clock start time per context.", "Implement Floyd's cycle detection or equivalent on the invocation graph at each dispatch step.", "Test circuit breaker logic with synthetic loop and escalation scenarios in CI before every release." ], "failure_signals": [ "Pipelines executing more steps than the defined maximum without circuit breaker activation.", "Cycle detection not triggering on deliberately injected loops in test environments.", "Escalation detection not triggering when a test agent requests capabilities more than the threshold." ] }, "security_architect": { "summary": "Loop and escalation detection are safety controls that also have security significance: runaway pipelines and capability escalation are both attack vectors. Detection must be tamper-resistant.", "actions": [ "Ensure circuit breaker logic runs in a separate process or goroutine from the pipeline it monitors, preventing a runaway pipeline from blocking its own termination.", "Classify LOOP_DETECTED and ESCALATION_DETECTED events as security events requiring incident response, not just operational alerts.", "Review the escalation detection threshold: too high allows gradual escalation attacks; too low creates false positives." ], "failure_signals": [ "Circuit breaker implemented in the same thread as the orchestration runtime.", "Loop/escalation events routed only to operational alerting, not security incident response.", "Threshold set so high that multi-step escalation attacks are not detected." ] }, "grc_auditor": { "summary": "Loop and escalation detection controls demonstrate that the organization has safeguards against runaway AI orchestration — a governance requirement for autonomous agent deployments.", "actions": [ "Request circuit breaker configuration documentation and verify limits are set to reasonable values with documented rationale.", "Review loop and escalation detection event logs over the prior 90 days and verify each event triggered an incident response action.", "Test circuit breaker activation by running a controlled loop scenario in a non-production environment and verifying detection and termination." ], "metrics": [ "Percentage of loop events resulting in pipeline termination: target 100%.", "Mean time from loop detection to pipeline termination: target < 5 seconds.", "Escalation detection events without corresponding incident records: target 0." ], "failure_signals": [ "Circuit breaker thresholds set to values that would not catch realistic attack scenarios.", "Loop events in logs not matched by corresponding incident records.", "Detection delay exceeding 30 seconds for synthetic test loops." ] }, "legal_counsel": { "summary": "Loop and escalation detection caps the runtime blast radius of orchestration failures. For counsel, the circuit breaker is what converts 'the system ran unsupervised until someone noticed' into 'the system halted itself within defined bounds' — materially different narratives in any proceeding.", "actions": [ "Confirm documented loop and step-count limits exist for production orchestrations and that limit-setting authority is defined.", "Verify circuit-breaker activations are logged with enough context to show the containment worked as designed.", "Review whether breaker-halted workflows serving customers create service-credit or notification obligations." ], "failure_signals": [ "Orchestrations with no documented execution bounds — unbounded autonomy no one formally accepted.", "Breaker activations with no retained record demonstrating the containment story.", "Customer-facing workflows halted by breakers under contracts that never addressed autonomous suspension." ] }, "platform_engineer": { "summary": "Loop detection and circuit breakers must be platform-level infrastructure so that all agent deployments benefit automatically without per-application implementation.", "actions": [ "Build execution context tracking and cycle detection into the platform's orchestration service layer.", "Integrate circuit breaker activation with the platform's token revocation service to ensure delegation tokens are invalidated on termination.", "Surface loop and escalation event counts in the platform operations dashboard with alerting thresholds." ], "failure_signals": [ "Loop detection implemented per-application rather than at the platform level, creating uneven coverage.", "Circuit breaker activation not triggering delegation token revocation.", "No platform-level visibility into loop and escalation event rates." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most orchestration frameworks provide token/step budgets but lack cycle detection or capability escalation monitoring." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant" ], "implementers": [ "AI Platform Team", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "§3.2 — Safe", "fit": "partial", "rationale": "NIST AI RMF §3.2 (Safe) holds that AI systems should not lead to states endangering people or property, and should support the capacity to be overridden or taken offline. Loop detection and step-count circuit breakers implement that shutdown capacity at the orchestration layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "partial", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) includes unbounded autonomous execution as a form of excessive agency. Loop detection and step-count circuit breakers directly constrain the execution scope within which an agent can act.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6 — AI system operation and monitoring (Annex A)", "fit": "partial", "rationale": "ISO/IEC 42001 Annex A control A.6.2.6 (AI system operation and monitoring) requires operation of AI systems to be monitored against defined criteria. Loop detection and escalation monitoring implement that operational monitoring for multi-agent orchestrations, with circuit breakers as the response mechanism.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.6 — Monitoring and review", "fit": "partial", "rationale": "ISO 31000:2018 §6.6 requires monitoring the effectiveness of risk treatments and detecting emerging risks. Escalation detection monitoring implements this for the specific risk of unbounded multi-agent operation, with circuit breakers as the pre-planned response.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Autonomous Replication and Adaptation", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Autonomous Replication and Adaptation category tracks runaway self-directed operation as a research-stage risk. Loop detection and step-count circuit breakers are the operational bound on the analogous deployed-agent failure mode: unbounded orchestration loops.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 3 — Automate defenses to keep pace with existing and new threats", "fit": "partial", "rationale": "Google SAIF element 3 (Automate defenses) recommends automated detection and response for AI-specific threats rather than manual monitoring. Automated loop detection with circuit breakers is that defense for runaway multi-agent orchestrations.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires fail-safe behavior for predictable failure modes. Runaway orchestration loops are a predictable multi-agent failure mode; loop detection and circuit breakers are the fail-safe that bounds them.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part II — Resource exhaustion attacks (loop amplification)", "fit": "partial", "rationale": "Loop amplification causes agents to repeatedly call costly APIs — the orchestration loop this control detects. Partial: doc addresses loop-driven resource exhaustion, not authority/escalation-loop detection broadly.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AO-05", "validation_objective": "Proves that the orchestration runtime detects and terminates infinite loops, unbounded recursion, and capability escalation attempts before resource exhaustion or unintended side-effects occur. A compliant deployment must demonstrate that circuit breakers activate within five seconds of threshold breach and that delegation tokens are revoked on termination.", "evidence_required": [ "Circuit breaker configuration document with documented threshold rationale (max depth, max steps, escalation count, max duration)", "Invocation graph and step counter logs from production pipeline runs showing counter instrumentation", "LOOP_DETECTED and ESCALATION_DETECTED event log from the security observability pipeline covering the prior 90 days", "CI test results demonstrating circuit breaker activation against synthetic loop and escalation scenarios", "Incident records cross-referencing each loop or escalation event to a documented response action" ], "machine_tests": [ "Inject a synthetic cyclic invocation sequence into a non-production orchestration runtime and verify LOOP_DETECTED fires within five seconds and pipeline terminates", "Drive pipeline depth to the configured max-depth limit and verify circuit breaker activates and delegation tokens are revoked", "Submit a test agent that requests capability expansion above the escalation threshold and verify ESCALATION_DETECTED event is emitted to the security observability pipeline", "Verify circuit breaker process runs independently of the monitored pipeline by confirming it operates in a separate process or goroutine" ], "human_review": [ "Review circuit breaker threshold values against the documented risk rationale to confirm they would catch realistic attack scenarios and not only extreme cases", "Verify that LOOP_DETECTED and ESCALATION_DETECTED events are classified as security incidents and routed to incident response, not only operational alerting", "Confirm the circuit breaker architecture is tamper-resistant: the monitored pipeline cannot block or delay its own termination" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Implementing cycle detection inside the same thread or process as the orchestration runtime, allowing a runaway pipeline to block its own termination", "Relying on API rate limits or token budget exhaustion as the sole loop prevention mechanism instead of proactive cycle detection", "Setting escalation detection thresholds so high that gradual, multi-step capability accumulation attacks pass undetected", "Routing loop and escalation events only to operational dashboards rather than the security incident pipeline, treating them as performance issues rather than potential attacks" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-06", "layer": "AO", "plane": "control", "name": "Cross-Organization Orchestration Trust Governance", "plain": "When agents from different organizations operate in shared orchestration pipelines, a formal cross-organization trust governance framework must establish mutual trust boundaries, shared policy constraints, liability allocation, and cross-boundary message integrity requirements before the shared pipeline activates.", "threat": { "tags": [ "cross-org-trust-confusion", "federated-pipeline-attack", "policy-conflict", "accountability-gap" ], "desc": "Cross-organization orchestration creates accountability gaps when an agent from Organization A directs agents from Organization B without a formal governance agreement. Conflicting organizational policies for data handling, capability constraints, and human oversight requirements create inconsistent behavior that attackers can exploit by routing sensitive operations through the organization with weaker controls. Liability for consequential actions taken across organizational boundaries is undetermined without explicit governance agreements." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 25 & Art. 26", "title": "Value-chain responsibilities and deployer obligations" }, { "id": "iso_42001", "section": "§4.2", "title": "Understanding stakeholder needs and determining the AI management system scope" }, { "id": "nist_rmf", "section": "GOVERN 6.1", "title": "Third-party AI risk policies" }, { "id": "iso_31000", "section": "§6.5", "title": "Risk treatment — risks shared with third parties" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-06 Cross-Organization Orchestration Trust Governance 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-29", "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://agentic/controls/AO-06 Cross-Organization Orchestration Trust Governance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish a Cross-Organization Orchestration Trust Agreement (COTA) as a prerequisite for shared pipeline activation. The COTA defines: participating organizations and their agent registries, mutual trust boundaries (which organizations' agents can direct which), shared policy floor (minimum constraints applicable to all agents regardless of origin), cross-boundary message integrity requirements, incident response and notification obligations, liability allocation for consequential actions, and agreement term and renewal conditions. Store signed COTA documents in the trust graph as edge metadata for cross-organizational edges.", "steps": [ "Develop a COTA template covering trust boundaries, policy floor, message integrity requirements, incident notification, liability allocation, and audit rights.", "Implement COTA validation in the trust graph loader: cross-organizational trust edges must reference a current signed COTA; edges without a valid COTA are rejected.", "Establish a cross-organization policy reconciliation process to identify and resolve policy conflicts before shared pipeline activation.", "Define cross-boundary incident response procedures including notification timelines, escalation paths, and joint investigation protocols." ], "ai_engineer": { "summary": "The orchestration runtime must enforce COTA constraints automatically — policy floor requirements and message integrity standards should be enforced in code, not just in agreement text.", "actions": [ "Implement COTA policy floor enforcement in the orchestration runtime: load COTA constraints for cross-organizational edges and apply them to all cross-boundary invocations.", "Validate cross-boundary message integrity against COTA-specified minimum algorithm requirements at the receiving agent.", "Block cross-organizational agent invocations when the sending organization's agent registry entry is not referenced in an active COTA." ], "failure_signals": [ "Cross-organizational invocations succeeding without COTA validation.", "COTA policy floor constraints not enforced in code, relying solely on organizational agreement compliance.", "No mechanism to detect when a cross-boundary partner's agent credentials have expired or been revoked." ] }, "security_architect": { "summary": "Cross-organization orchestration extends the attack surface beyond the organization's control boundary. The COTA is the security instrument that constrains the shared attack surface.", "actions": [ "Require COTA negotiation to include a joint threat model session identifying cross-boundary attack vectors.", "Specify minimum message integrity requirements in the COTA that all organizations must implement regardless of their internal standards.", "Define the policy floor in the COTA to reflect the stricter of the two organizations' policies, not the weaker." ], "failure_signals": [ "Cross-organizational trust edges in the trust graph without valid COTA references.", "COTA policy floor set to the weaker organization's standards rather than the stricter.", "No joint threat model completed before cross-organization pipeline activation." ] }, "grc_auditor": { "summary": "Cross-organization orchestration introduces third-party AI risk that must be governed. COTA documentation and trust graph validation are the primary audit artifacts.", "actions": [ "Inventory all active cross-organizational orchestration pipelines and verify each has a current executed COTA.", "Review COTA terms for completeness against the organization's third-party AI risk management requirements.", "Sample cross-boundary message logs and verify message integrity controls meet the COTA minimum standards." ], "metrics": [ "Active cross-organizational pipelines with valid COTAs: target 100%.", "COTA renewal rate within 30 days of expiry: target 100%.", "Cross-boundary message integrity compliance with COTA standards: target 100%." ], "failure_signals": [ "Any active cross-organizational pipeline without a current executed COTA.", "COTA terms not reviewed since initial execution despite material changes to the pipeline.", "Cross-boundary messages not meeting COTA-specified integrity standards." ] }, "legal_counsel": { "summary": "Cross-organization orchestration agreements have significant legal implications for liability, data protection, and regulatory compliance. Legal review is required before any cross-organizational pipeline activates.", "actions": [ "Review all COTAs for completeness against applicable data protection, liability, and regulatory requirements before execution.", "Confirm that the COTA includes provisions satisfying data processor/controller requirements under GDPR or equivalent where applicable.", "Verify that liability allocation in the COTA is consistent with the organization's enterprise risk appetite and insurance coverage." ], "failure_signals": [ "Cross-organizational pipelines activated without a legally executed COTA.", "COTA without explicit data processing role definitions where personal data is involved.", "Liability allocation in COTA inconsistent with insurance coverage or risk appetite." ] }, "platform_engineer": { "summary": "You implement the technical seams of cross-organization orchestration: federated trust anchors, mutually verified identities, and boundary telemetry that gives each party the evidence the trust agreement promises.", "actions": [ "Establish per-partner trust anchors (federation metadata, signing keys, allowed audiences) and pin them in configuration under change control.", "Enforce at the boundary gateway that inbound partner-agent requests carry verifiable identity and scope claims matching the signed agreement.", "Export boundary event logs in the agreed evidence format so each organization independently retains its side of the record." ], "failure_signals": [ "Partner agent traffic accepted on network trust alone, without verifiable identity claims per the agreement.", "Trust anchor rotation handled ad hoc, causing outages or silent acceptance of stale keys.", "Boundary events retained by only one party, making cross-org disputes unresolvable." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Cross-organization agent orchestration is an emerging pattern with minimal governance frameworks in current practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "federated-enterprise", "multi-tenant", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "AI Platform Team", "Legal / Compliance", "Security Architecture", "Third-Party Risk Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 25 & Art. 26", "fit": "direct", "rationale": "EU AI Act Article 26 sets deployer obligations for high-risk AI systems and Article 25 allocates responsibilities along the AI value chain. Cross-organization orchestration trust agreements document exactly this allocation when agent workflows cross providers, deployers, and third parties.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 6.1", "fit": "partial", "rationale": "NIST AI RMF GOVERN 6.1 requires policies addressing AI risks arising from third-party entities. Cross-organization orchestration trust agreements are the governance instrument applying those policies when agent workflows span organizational boundaries.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§4.2", "fit": "partial", "rationale": "ISO 42001 §4.2 requires organizations to understand the needs and expectations of interested parties and determine the scope of the AI management system. Cross-organizational orchestration extends the management system scope and requires explicit stakeholder agreement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.5 — Risk treatment", "fit": "partial", "rationale": "ISO 31000:2018 §6.5 requires risk treatment to be selected, planned, and implemented — including where risks are shared with other parties. Cross-organization orchestration trust agreements are the documented treatment instrument for risks shared across organizational boundaries.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require clear accountability for system behavior even when third parties are involved. Cross-organization orchestration trust agreements allocate that accountability explicitly when agent workflows span organizational boundaries.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 4 — Harmonize platform-level controls to ensure consistent security", "fit": "partial", "rationale": "Google SAIF element 4 (Harmonize platform-level controls) addresses maintaining consistent controls when AI systems from different contexts interoperate. Cross-organization orchestration trust agreements extend control harmonization across organizational boundaries.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 — Explicit trust boundaries; Part III — AI governance policies", "fit": "partial", "rationale": "Explicit trust boundaries plus governance cover inter-agent (including cross-organization) delegation. Partial: doc does not specifically address cross-organization orchestration trust frameworks.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AO-06", "validation_objective": "Proves that every active cross-organizational agent pipeline has a current, executed Cross-Organization Orchestration Trust Agreement (COTA) defining mutual trust boundaries, a shared policy floor, and liability allocation, and that the orchestration runtime enforces COTA constraints in code before any cross-boundary invocation succeeds.", "evidence_required": [ "COTA inventory listing all active cross-organizational pipelines, their partner organizations, COTA execution dates, and expiry dates", "Trust graph export showing cross-organizational edges annotated with valid COTA references", "Code-level COTA validation test results confirming cross-boundary invocations are rejected when no valid COTA reference is present", "Cross-boundary message integrity logs demonstrating compliance with COTA-specified minimum algorithm requirements", "Joint threat model documentation produced before each cross-organizational pipeline activation" ], "machine_tests": [ "Attempt a cross-organizational agent invocation with no COTA reference in the trust graph and verify the orchestration runtime rejects it with a structured error", "Present an expired COTA reference and verify the runtime blocks the cross-boundary invocation and emits a COTA_EXPIRED event", "Submit a cross-boundary message using an integrity algorithm below the COTA minimum and verify validation failure at the receiving agent", "Verify that the COTA policy floor constraints are loaded and applied to all cross-boundary invocations by attempting a cross-org action that violates the policy floor" ], "human_review": [ "Legal review of each COTA for completeness against applicable data protection, liability, and regulatory requirements before execution", "Verify the COTA policy floor is set to the stricter of the two organizations' standards, not the weaker, and that this selection is documented", "Confirm that a joint threat model session was conducted before pipeline activation and that identified cross-boundary attack vectors were addressed in COTA terms", "Review liability allocation provisions against the organization's enterprise risk appetite and insurance coverage" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Setting the COTA policy floor to the weaker organization's standards to minimize friction, creating a governance race-to-the-bottom across the shared pipeline", "Activating cross-organizational pipelines before the COTA is legally executed, operating on a draft or letter of intent", "Omitting data processing role definitions (controller/processor under GDPR or equivalent) from COTAs involving personal data processing", "Treating COTA compliance as a contractual obligation only rather than enforcing constraints in the orchestration runtime code" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-07", "layer": "AO", "plane": "both", "name": "Orchestration Audit Trail", "plain": "Every agent-to-agent interaction, delegation event, gate activation, and orchestration state transition must be logged to an immutable, append-only audit trail with sufficient detail to reconstruct the full execution history of any pipeline run.", "threat": { "tags": [ "audit-gap", "forensic-evasion", "accountability-bypass", "tampered-log" ], "desc": "Without a complete audit trail, organizations cannot reconstruct what a multi-agent pipeline did, who authorized it, or which agent was responsible for a specific consequential action. Attackers who compromise the orchestration layer can cover their tracks if logs are mutable or incomplete. Regulatory investigations and customer dispute resolution require the ability to replay pipeline execution history — an impossibility without structured, tamper-evident logging." }, "standard": [ { "id": "eu_ai_act", "section": "Article 12", "title": "Record-keeping for high-risk AI systems" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "nist_rmf", "section": "§3.4 — Accountable and Transparent", "title": "Trustworthy records of AI system behavior" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-07 Orchestration Audit Trail control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-07 Orchestration Audit Trail control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-07 Orchestration Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-07 Orchestration Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AO-07 Orchestration Audit Trail control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Write all orchestration events to an append-only, tamper-evident log store (WORM storage or equivalent). Each log entry is a structured JSON object signed by the emitting agent's identity credential. Log entries cover: pipeline execution start/stop, agent-to-agent invocations (with caller, callee, delegation token reference, and timestamp), state transitions, gate activations and decisions, loop/escalation detection events, and error conditions. Log entries are linked using a hash chain to enable tamper detection. Logs are retained for a minimum period defined by the longest applicable regulatory retention requirement.", "steps": [ "Define a structured log schema covering all orchestration event types: invocation, delegation, state transition, gate activation, loop detection, escalation, error.", "Deploy an append-only log store with WORM properties (immutable write, no delete) and configure the orchestration runtime to emit all events to it.", "Implement hash chaining: each log entry includes the hash of the previous entry in the log sequence, enabling end-to-end tamper detection.", "Configure log retention to meet the longest applicable regulatory period; implement automated retention enforcement and retention verification audits." ], "ai_engineer": { "summary": "Every agent-to-agent call, delegation event, and state change must emit a signed structured log entry. Logging is not optional — missing log events are a correctness failure.", "actions": [ "Integrate structured logging into the agent SDK at all inter-agent boundary points so developers cannot accidentally omit events.", "Include the delegation token reference (not the token itself) in invocation log entries to enable cross-referencing.", "Implement a local log buffer with guaranteed-delivery semantics so log entries are not lost on transient log store failures." ], "failure_signals": [ "Agent invocations not reflected in the audit trail.", "Log entries missing required fields (caller identity, timestamp, delegation token reference).", "Log delivery failures causing silent gaps in the audit trail." ] }, "security_architect": { "summary": "The audit trail is a critical forensic asset. Its integrity must be protected independently of the orchestration runtime it monitors.", "actions": [ "Ensure the audit log store is write-accessible from the orchestration runtime but read-accessible only to authorized audit functions — not to the orchestration runtime itself.", "Implement hash chain verification as a scheduled integrity check; alert on any chain breaks.", "Classify the audit log store as a critical security asset with equivalent access controls to the identity system." ], "failure_signals": [ "Orchestration runtime has delete or overwrite access to the audit log store.", "Hash chain verification not running on a scheduled basis.", "Log store access controls not reviewed as part of privileged access reviews." ] }, "grc_auditor": { "summary": "The orchestration audit trail is the foundational evidence artifact for all AO-layer controls. Its completeness and integrity directly determine the auditability of the orchestration layer.", "actions": [ "Verify hash chain integrity across a sample of log sequences spanning at least 90 days.", "Cross-reference audit trail records against production pipeline execution records to detect gaps.", "Confirm log retention configuration and test retrieval of records at the maximum configured retention boundary." ], "metrics": [ "Audit trail coverage of agent-to-agent invocations: target 100%.", "Hash chain integrity: target 0 breaks.", "Log records retrievable within defined retention period: target 100%." ], "failure_signals": [ "Invocation records in production pipeline metrics not matched in the audit trail.", "Any hash chain break without a documented incident record.", "Log records not retrievable at the boundary of the defined retention period." ] }, "legal_counsel": { "summary": "The audit trail is the primary evidence artifact for regulatory investigations, litigation, and customer dispute resolution. Its legal admissibility depends on its integrity and completeness.", "actions": [ "Confirm audit log retention periods meet the requirements of all applicable regulations and contractual obligations.", "Verify that log export formats are compatible with forensic analysis tools used by the organization's legal and incident response teams.", "Confirm that access to audit logs is controlled to prevent spoliation claims in litigation contexts." ], "failure_signals": [ "Log retention period shorter than the longest applicable regulatory requirement.", "Audit logs stored in a format not compatible with the organization's forensic analysis toolchain.", "Audit log access not logged, creating a meta-audit gap." ] }, "platform_engineer": { "summary": "You operate the append-only audit infrastructure for orchestration events: high-throughput ingestion, hash chaining, durable storage, and query interfaces investigators can actually use across multi-agent workflows.", "actions": [ "Provision the audit store as append-only (object lock / WORM) with multi-region replication sized for full orchestration event volume.", "Automate hash-chain computation and periodic external anchoring, with alerting when verification fails or lags.", "Provide indexed query by workflow_id, agent_id, and time window so end-to-end reconstruction is minutes, not days." ], "failure_signals": [ "Ingestion backpressure silently dropping orchestration events during traffic spikes.", "Hash-chain verification jobs failing without alerting, leaving integrity unproven for weeks.", "Investigations blocked because audit events cannot be joined across agents in one workflow." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most agent frameworks produce operational logs but lack structured, tamper-evident, append-only audit trails with hash chaining." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Platform Team", "Security Architecture", "Platform Engineering", "Legal / Compliance" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Article 12", "fit": "direct", "rationale": "EU AI Act Article 12 requires high-risk AI systems to automatically generate logs enabling post-hoc verification of system operation. The orchestration audit trail directly implements this logging requirement for multi-agent pipeline deployments.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "§3.4 — Accountable and Transparent", "fit": "direct", "rationale": "NIST AI RMF §3.4 ties accountability to the availability of trustworthy records of system behavior. The orchestration audit trail provides those records for multi-agent workflows, making each delegated action reconstructable end to end.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "partial", "rationale": "ISO 42001 §9.1 requires organizations to retain documented information as evidence of AI system monitoring and evaluation. The orchestration audit trail is the primary documented information artifact for ongoing AI system monitoring.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "partial", "rationale": "Google SAIF element 2 requires telemetry and logging that bring AI system behavior into the organization's detection and investigation capability. The orchestration audit trail captures multi-agent workflows at the granularity investigations require.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require traceable records of automated decisions and actions. The orchestration audit trail provides those records for multi-agent workflows, making each delegated action reconstructable end to end.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "partial", "rationale": "The Salesforce Einstein Trust Layer's audit trail provides platform-native logging of agent activity — one component of an orchestration audit capability. AO-07 requires end-to-end, tamper-evident records across the full multi-agent workflow, including systems outside any single platform.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Traceability (Distributed tracing across multi-agent workflows)", "fit": "direct", "rationale": "Enterprise traceability implements OpenTelemetry distributed tracing across multi-agent workflows, capturing timing/dependency and visualizing request flows across agent boundaries — orchestration audit trail.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AO-07", "validation_objective": "Proves that every agent-to-agent invocation, delegation event, gate activation, and orchestration state transition is captured in a tamper-evident, append-only log store and that the hash chain integrity across the full retention period is verifiable and unbroken.", "evidence_required": [ "Audit trail sample spanning at least 90 days with hash chain intact, exported for independent verification", "Scheduled hash chain integrity verification report showing zero chain breaks over the verification period", "Log schema definition document including all required event types and mandatory fields", "WORM storage or equivalent configuration documentation demonstrating append-only enforcement", "Coverage cross-reference report matching pipeline execution metrics against audit trail records to detect gaps" ], "machine_tests": [ "Execute a sample multi-agent pipeline and verify every invocation, delegation event, and state transition appears as a signed, structured entry in the audit trail", "Run a hash chain verification pass across the 90-day audit log sample and confirm zero breaks are detected", "Attempt to overwrite or delete an existing audit log entry and verify the log store rejects the operation with an error", "Validate a random sample of log entries against the declared schema and confirm all mandatory fields (caller identity, timestamp, delegation token reference, event type) are present" ], "human_review": [ "Confirm audit log retention period meets the requirements of all applicable regulations and contractual obligations, including sector-specific requirements", "Verify that the orchestration runtime holds write-only access to the log store and that delete or overwrite access is not granted to any service account associated with the pipeline", "Confirm that access to audit logs is itself logged to prevent spoliation claims and to create a complete forensic access chain" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Using mutable log stores or databases that allow overwrite or delete operations, even if those operations are not intended to be used", "Granting the orchestration runtime delete or modify access to the audit log store it writes to, enabling self-cover-up by a compromised pipeline", "Emitting only operational logs without hash chaining, leaving tamper evidence dependent on access controls alone", "Omitting delegation token references from agent-to-agent invocation records, making it impossible to trace authorization chains during post-incident investigation" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AO-08", "layer": "AO", "plane": "lifecycle", "name": "Orchestration Governance Evidence Package", "plain": "A governance evidence package must be compiled for each multi-agent orchestration deployment, assembling evidence from AO-01 through AO-07 to demonstrate that orchestration boundaries are defined, enforced, monitored, and auditable — forming the BehavioralAttestation artifact for the orchestration layer.", "threat": { "tags": [ "attestation-gap", "governance-theater", "evidence-fragmentation", "compliance-assertion-without-proof" ], "desc": "Without a compiled evidence package, orchestration governance exists as a collection of disconnected artifacts that cannot demonstrate end-to-end assurance. Attestations made about orchestration safety that are not backed by compiled, current evidence create compliance exposure when regulators or customers demand proof. Evidence fragmentation means that individual controls may pass spot checks while systemic gaps between controls remain undetected." }, "standard": [ { "id": "eu_ai_act", "section": "Article 11", "title": "Technical documentation for high-risk AI systems" }, { "id": "iso_42001", "section": "§10.1", "title": "Continual improvement — documented evidence" }, { "id": "nist_rmf", "section": "GOVERN 1.4", "title": "Documented risk management processes and outcomes" }, { "id": "iso_31000", "section": "§6.7", "title": "Recording and reporting risk management outcomes" } ], "sources": [ { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AO-08 Orchestration Governance Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AO-08 Orchestration Governance Evidence Package control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AO-08 Orchestration Governance Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AO-08 Orchestration Governance Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Compile an Orchestration Governance Evidence Package (OGEP) on a defined cadence (minimum quarterly, or on each material change to the orchestration deployment). The OGEP references current evidence artifacts from each AO control: trust graph export (AO-01), delegation token policy and sample records (AO-02), message integrity configuration and validation event logs (AO-03), gate activation records (AO-04), loop/escalation detection configuration and event logs (AO-05), COTA inventory (AO-06), audit trail integrity report (AO-07). The package is signed by the system owner and stored as a versioned artifact in the evidence repository. The OGEP summary is the BehavioralAttestation (AG-08) for the AO layer.", "steps": [ "Define the OGEP structure: a manifest document listing all required evidence artifacts, their sources, collection timestamps, and completeness status.", "Automate evidence artifact collection for machine-readable controls (trust graph export, delegation token logs, message integrity events, audit trail integrity report) using the platform's evidence collection API.", "Require the system owner to review and sign the compiled OGEP before it is registered as a current attestation; gate high-risk pipeline reauthorization on a current signed OGEP.", "Register completed OGEPs in the Apeiris evidence repository with canonical ID referencing the orchestration deployment; publish the BehavioralAttestation summary to the appropriate domain endpoint." ], "ai_engineer": { "summary": "Automated evidence collection makes OGEP compilation reliable and low-friction. Instrument each AO control to emit structured evidence artifacts on demand.", "actions": [ "Implement evidence export endpoints for each AO control: trust graph snapshot, delegation token audit sample, message integrity event summary, gate activation log export, loop detection event export, COTA inventory, audit trail integrity hash.", "Build an OGEP assembler that calls each evidence endpoint and compiles the manifest document automatically.", "Integrate OGEP compilation into the pipeline reauthorization workflow so evidence is current at each authorization event." ], "failure_signals": [ "Evidence export endpoints missing for one or more AO controls.", "OGEP assembled with evidence artifacts older than the defined maximum age.", "OGEP compilation failing silently rather than reporting which evidence artifacts are missing." ] }, "security_architect": { "summary": "The OGEP is the attestation artifact for orchestration governance. Its integrity and completeness determine the trustworthiness of any orchestration safety claim.", "actions": [ "Require OGEP documents to be signed by the system owner using an organizational identity credential, not a service account.", "Store OGEPs in the evidence repository with the same integrity protections as the audit trail: append-only, tamper-evident.", "Define OGEP coverage requirements: a package missing evidence for any AO control is incomplete and cannot be used as a valid attestation." ], "failure_signals": [ "OGEPs signed by service accounts without human accountability.", "OGEP repository allowing modification of submitted packages.", "Incomplete OGEPs accepted as valid attestations." ] }, "grc_auditor": { "summary": "The OGEP is the primary artifact for auditing orchestration governance. A complete, current, signed OGEP is the evidence of a governed orchestration deployment.", "actions": [ "Verify that a current signed OGEP exists for each production orchestration deployment.", "Review OGEP completeness: confirm all seven AO control evidence categories are present and their artifacts are within the defined maximum age.", "Verify the BehavioralAttestation summary accurately reflects the completeness status of the underlying evidence." ], "metrics": [ "Production orchestration deployments with a current signed OGEP: target 100%.", "OGEP completeness rate (all seven AO evidence categories present): target 100%.", "Maximum age of evidence artifacts in a current OGEP: target ≤ 90 days." ], "failure_signals": [ "Any production orchestration deployment without a current signed OGEP.", "OGEPs missing evidence for one or more AO controls.", "Evidence artifacts in current OGEPs older than 90 days without a documented exception." ] }, "legal_counsel": { "summary": "The OGEP is the legal evidence artifact demonstrating due diligence in orchestration governance — essential for regulatory submissions, customer audits, and liability defense.", "actions": [ "Review the OGEP template to confirm it captures all information required by applicable regulations (EU AI Act Article 11 technical documentation, sector-specific requirements).", "Confirm OGEP retention periods meet regulatory and contractual requirements.", "Verify that the BehavioralAttestation summary in the OGEP uses precise, legally defensible language consistent with the organization's public claims about AI safety." ], "failure_signals": [ "OGEP template not reviewed against current regulatory technical documentation requirements.", "OGEP retention shorter than the applicable regulatory period.", "BehavioralAttestation language making absolute safety claims not supported by the underlying evidence." ] }, "platform_engineer": { "summary": "You automate assembly of the orchestration governance evidence package: scheduled collection from the trust graph, gate records, audit trail, and breaker logs into a signed, versioned bundle with no manual scavenger hunt.", "actions": [ "Build a scheduled pipeline that pulls trust-graph versions, gate decisions, breaker activations, and audit-integrity proofs into the package format.", "Compute and record checksums for every included artifact and store bundles in immutable storage with retention matching compliance requirements.", "Alert when a source system fails to deliver its artifacts so gaps are fixed before the reporting deadline, not discovered at audit." ], "failure_signals": [ "Evidence collection failing silently, producing packages with missing artifacts found only during review.", "Bundles stored mutably, undermining the integrity story of the evidence itself.", "Package assembly requiring manual exports from systems that were never given evidence APIs." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Governance evidence packages for multi-agent orchestration do not exist as a defined artifact class in current enterprise practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI Governance Team", "Security Architecture", "Legal / Compliance", "GRC" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Article 11", "fit": "direct", "rationale": "EU AI Act Article 11 requires providers of high-risk AI systems to maintain technical documentation demonstrating compliance with the regulation's requirements. The OGEP directly implements this documentation requirement for the orchestration governance layer.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 1.4", "fit": "direct", "rationale": "NIST AI RMF GOVERN 1.4 requires the risk management process and its outcomes to be documented through transparent policies and controls. The orchestration governance evidence package is that documented outcome for the multi-agent orchestration layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§10.1 — Continual improvement", "fit": "direct", "rationale": "ISO/IEC 42001 §10.1 requires continual improvement of the suitability, adequacy, and effectiveness of the AI management system. Orchestration governance evidence packages compiled on a defined cadence provide the documented basis on which that improvement is assessed for the orchestration layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.7", "fit": "partial", "rationale": "ISO 31000 §6.7 requires recording and reporting of risk management activities and outcomes to demonstrate accountability. The OGEP implements the recording and reporting requirement for orchestration risk management outcomes.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3 (Risk Reports) requires structured documentation of safeguards and findings to support deployment decisions and later review. The orchestration governance evidence package is the equivalent structured artifact for the multi-agent orchestration layer.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Safeguards Reports (§4) and Internal governance (§5.1)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. The framework pairs documented safeguard evidence (§4 Safeguards Reports) with internal governance review (§5.1). The orchestration governance evidence package supports the same pairing for multi-agent workflows: compiled evidence feeding a defined governance review.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require organizations to demonstrate responsible practices through documented evidence. The orchestration governance evidence package is that demonstration for the multi-agent layer.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://agentic/controls/AO-08", "validation_objective": "Proves that a current, signed Orchestration Governance Evidence Package (OGEP) exists for every production orchestration deployment, that all seven AO control evidence categories are present with artifacts no older than 90 days, and that the package is registered as a versioned BehavioralAttestation artifact in the evidence repository.", "evidence_required": [ "Signed OGEP document with manifest listing all seven AO evidence categories, their artifact sources, and collection timestamps", "System owner identity credential signature record verifying the OGEP was attested by a named human owner", "Evidence repository version history confirming OGEP was stored as an immutable, versioned artifact", "BehavioralAttestation summary published to the appropriate domain endpoint, referencing the OGEP canonical ID", "OGEP compilation log showing automated evidence artifact collection and any gaps that required manual resolution" ], "machine_tests": [ "Verify the OGEP manifest references all seven AO evidence categories: trust graph export (AO-01), delegation token records (AO-02), message integrity event log (AO-03), gate activation records (AO-04), loop detection event log (AO-05), COTA inventory (AO-06), and audit trail integrity report (AO-07)", "Check that each evidence artifact cited in the OGEP manifest has a collection timestamp within the prior 90 days", "Verify the OGEP digital signature is valid and was produced by a human system owner credential, not a service account", "Confirm the BehavioralAttestation summary is registered in the evidence repository and references the signed OGEP canonical ID" ], "human_review": [ "System owner review of OGEP completeness to confirm underlying evidence artifacts accurately reflect the current state of the orchestration deployment, not a historical snapshot", "Legal review of BehavioralAttestation language to confirm it uses precise, legally defensible framing and does not make absolute safety claims unsupported by the underlying evidence", "Governance team review of any evidence gaps flagged during OGEP compilation and sign-off on remediation plans before the package is registered as current" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Signing OGEPs with service accounts or automation credentials rather than requiring a named human system owner to attest the package, removing accountability from the governance artifact", "Accepting OGEPs with missing evidence categories as current attestations, effectively declaring governance compliance on incomplete evidence", "Allowing evidence artifacts older than 90 days to appear in a current OGEP without a documented exception and compensating control", "Treating the OGEP as a document-generation exercise rather than a substantive review of underlying evidence, producing packages that satisfy the form but not the intent of governance" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AO" }, { "id": "AM-01", "layer": "AM", "plane": "data", "name": "Behavioral Telemetry Collection Baseline", "plain": "Every production agent must emit a defined minimum set of behavioral signals — action logs, tool invocations, token consumption, decision rationale traces, and session boundaries — to a centralized telemetry store before any governance analysis can occur.", "threat": { "tags": [ "blind-spot-exploitation", "unobserved-action", "telemetry-gap", "audit-evasion" ], "desc": "Agents that do not emit standardized telemetry operate invisibly. Without a mandatory baseline signal set, governance reviews rely on incomplete data, anomaly detectors have insufficient coverage, and post-incident forensics cannot reconstruct what an agent did or why. Adversaries who understand monitoring gaps can deliberately route actions through unmonitored tool paths." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment monitoring plans implemented" }, { "id": "iso_42001", "section": "§9.1 — Monitoring, measurement, analysis and evaluation", "title": "Performance evaluation obligations" }, { "id": "eu_ai_act", "section": "Art. 12 — Record-keeping", "title": "Automatic logging requirements for high-risk AI" }, { "id": "google_saif", "section": "Element 5", "title": "Adapt controls — continuous monitoring and telemetry collection" } ], "sources": [ { "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-29", "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://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AM-01 Behavioral Telemetry Collection Baseline control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Instrument every agent runtime to emit a structured telemetry envelope on each action cycle. Define a schema-versioned baseline signal set (action type, tool called, input/output hashes, token counts, latency, session ID, agent ID, timestamp). Ship to an append-only telemetry store with schema validation at ingestion.", "steps": [ "Define and version the minimum telemetry schema: action_type, tool_invocation, token_in, token_out, latency_ms, session_id, agent_id, trace_id, timestamp_utc, outcome.", "Instrument all agent runtimes (LangChain, AutoGPT, custom orchestrators) with a telemetry emitter that fires on every tool call and decision node.", "Deploy a schema-validated ingestion pipeline (e.g., Kafka + schema registry or OpenTelemetry collector) that rejects malformed events and alerts on emission gaps.", "Establish a coverage SLO: 100% of registered production agents must emit telemetry within one minute of deployment.", "Publish the telemetry schema to a shared internal registry so downstream anomaly detectors, dashboards, and audit tools can rely on stable field names." ], "ai_engineer": { "summary": "Telemetry instrumentation is an engineering requirement, not an ops afterthought. Every agent framework integration must include the telemetry emitter before merge.", "actions": [ "Integrate the telemetry emitter SDK into all agent base classes so instrumentation is inherited automatically.", "Add telemetry emission coverage to CI test suites — fail the build if any tool call path lacks an emit hook.", "Version the schema and maintain backward compatibility; add migration tests when fields change." ], "failure_signals": [ "Coverage rate drops below 100% of registered agents.", "Schema validation rejection rate rises above 0.1% of events.", "Any agent session completes without a session_end telemetry event." ] }, "security_architect": { "summary": "Telemetry is the foundation of every downstream control in this layer. Without it, AM-02 through AM-07 are inoperable. Treat the telemetry pipeline as critical infrastructure.", "actions": [ "Define threat model for telemetry pipeline: exfiltration, tampering, replay, and suppression attacks.", "Require mTLS or equivalent for all agent-to-collector transport links.", "Ensure the telemetry store enforces append-only semantics and that write access is restricted to the collector service account only." ], "failure_signals": [ "Telemetry pipeline allows post-hoc modification of ingested events.", "Agent identities are not cryptographically authenticated to the collector.", "Coverage gaps exist for any production agent class." ] }, "grc_auditor": { "summary": "Behavioral telemetry completeness is the first thing an auditor should verify. Without it, no other monitoring claim is credible.", "actions": [ "Request the agent registry and cross-reference against telemetry coverage reports to identify uninstrumented agents.", "Sample five recent agent sessions and verify each has a continuous telemetry trace from session_start to session_end.", "Confirm schema version history is retained and that schema changes require change-management approval." ], "metrics": [ "Agent telemetry coverage rate: target 100% of registered production agents.", "Schema validation pass rate: target ≥99.9% of all emitted events.", "Median telemetry ingestion latency: target <5 seconds end-to-end." ], "failure_signals": [ "Any registered production agent has zero telemetry events in the last 24 hours.", "Schema version mismatch rate above 1% of daily event volume.", "Coverage SLO breaches go unresolved for more than one business day." ] }, "legal_counsel": { "summary": "The telemetry baseline defines what the enterprise will be able to prove about agent behavior later. Telemetry gaps become evidentiary gaps: EU AI Act logging duties, incident reconstruction, and defense of specific agent decisions all depend on what this contract captures.", "actions": [ "Confirm the telemetry contract captures the fields needed for EU AI Act record-keeping (Art. 12/19, Art. 26(6)) and for reconstructing any consequential agent decision.", "Verify telemetry involving personal data has a documented processing basis and retention schedule consistent with privacy notices.", "Ensure telemetry retention and legal hold procedures are aligned so behavioral records survive when disputes are foreseeable." ], "failure_signals": [ "Consequential agent decisions that cannot be reconstructed because the telemetry contract never captured the relevant fields.", "Behavioral telemetry containing personal data collected without a documented basis or disclosed retention.", "Telemetry purged on schedule after litigation was reasonably anticipated." ] }, "platform_engineer": { "summary": "The telemetry pipeline must be designed for high throughput, low latency, and zero data loss. It is load-bearing infrastructure for all monitoring controls.", "actions": [ "Deploy an OpenTelemetry collector cluster with at-least-once delivery guarantees and durable buffering.", "Implement schema registry (e.g., Confluent Schema Registry or AWS Glue) to enforce contract between emitters and consumers.", "Set up automated coverage dashboards that flag any registered agent with no telemetry events in the past hour." ], "failure_signals": [ "Telemetry pipeline drops events under peak load.", "Schema registry is unavailable and emitters fall back to unvalidated output.", "Coverage dashboard has stale data older than five minutes." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have ad-hoc agent logging without a standardized baseline schema or coverage SLO." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment AI system monitoring plans to be implemented. The behavioral telemetry baseline is the foundational implementation: without a defined, complete telemetry contract, no downstream monitoring plan can operate.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "direct", "rationale": "ISO/IEC 42001 §9.1 requires organizations to determine what needs to be monitored and measured regarding AI system performance. A telemetry baseline directly instantiates this requirement by specifying the minimum observable signals. Absence of a defined baseline means §9.1 cannot be meaningfully demonstrated.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12(1)", "fit": "direct", "rationale": "EU AI Act Article 12 mandates automatic logging of events for high-risk AI systems sufficient to enable post-market monitoring and incident investigation. Behavioral telemetry is the technical implementation of this logging obligation. The baseline schema directly maps to the Art. 12(2) requirement to capture system inputs where feasible.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Element 5 — Adapt controls to adjust mitigations and create faster feedback loops", "fit": "direct", "rationale": "Google SAIF element 5 (Adapt controls) depends on fast feedback loops from production behavior. The behavioral telemetry baseline is the prerequisite: without a defined, complete telemetry contract there is no signal from which controls can adapt.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "T1 — System intelligibility for decision making", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T1 requires systems to produce information sufficient for stakeholders to understand system behavior. A complete behavioral telemetry baseline is the raw material of that intelligibility: without a defined telemetry contract, agent behavior cannot be explained after the fact.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "partial", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. That is a platform-native telemetry source AM-01's baseline can incorporate; the enterprise-wide telemetry contract itself spans all agent platforms, not only Salesforce.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Baseline establishment", "fit": "direct", "rationale": "Establish baseline agent behavior (typical tool usage, access frequencies, data volumes) — the behavioral telemetry baseline.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "AM-01 mandates full-coverage behavioral telemetry (actions, tool calls, tokens, rationale) to an append-only store, providing the signal base for monitoring agent use.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every registered production agent emits a schema-validated, minimum signal…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AM-01", "validation_objective": "Proves that every registered production agent emits a schema-validated, minimum signal set — covering action type, tool invocations, token consumption, session boundaries, and decision rationale traces — to an append-only telemetry store, with 100% coverage of registered agents demonstrable within the prior 24-hour window.", "evidence_required": [ "Telemetry schema version registry showing current schema version and change history with change-management approval records", "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate" ], "machine_tests": [ "Cross-reference the agent registry against the telemetry store and verify 100% of registered production agents emitted at least one event in the prior 24 hours", "Extract a random sample of 500 telemetry events and validate each against the declared schema, confirming all required fields are present and correctly typed", "Attempt to modify an ingested telemetry event in the store and verify the append-only enforcement rejects the operation", "Confirm schema validation at ingestion rejects a malformed synthetic event and produces an alert rather than silently dropping it" ], "human_review": [ "Review the schema change management process to confirm schema updates require explicit approval and backward compatibility testing before deployment", "Verify that coverage SLO breaches are assigned to an owner and resolved within one business day, with a documented root cause", "Confirm the telemetry pipeline is classified as critical security infrastructure with access controls equivalent to the identity system and a defined incident response plan" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Treating telemetry as an operational afterthought added post-deployment rather than a mandatory build requirement enforced at the agent SDK level", "Instrumenting agents with ad-hoc, unstructured logging rather than a versioned, schema-validated baseline, making downstream anomaly detection and audit unreliable", "Not versioning the telemetry schema, so field-name changes silently break downstream consumers without detection", "Allowing agents to control their own telemetry emission on/off state, enabling a compromised agent to suppress behavioral signals before taking unauthorized actions" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-02", "layer": "AM", "plane": "control", "name": "Anomalous Action Detection", "plain": "Agents must be monitored in real time against their declared behavioral scope. Any action outside the approved tool set, target resource set, or behavioral baseline must be detected, logged, and escalated immediately.", "threat": { "tags": [ "scope-violation", "unauthorized-tool-use", "privilege-escalation", "prompt-injection-execution" ], "desc": "Agents may be manipulated via prompt injection, misconfiguration, or capability creep to invoke tools or access resources outside their declared scope. Without real-time scope-boundary enforcement, an agent may exfiltrate data, escalate privileges, or take irreversible actions before any human reviews the activity. The absence of anomaly detection means these violations go undetected until downstream damage surfaces." }, "standard": [ { "id": "owasp_llm10", "section": "LLM01:2025 — Prompt Injection", "title": "Detection of injected instructions causing out-of-scope actions" }, { "id": "mitre_atlas", "section": "AML.T0051 — LLM Prompt Injection", "title": "Adversarial manipulation of agent action selection" }, { "id": "nist_ai_600_1", "section": "2.4 — Data Privacy", "title": "Detecting unauthorized data access actions" } ], "sources": [ { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AM-02 Anomalous Action Detection control.", "reviewed_on": "2026-07-02" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds anomalous-action detection design in the Part III anomaly-detection tier.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "For each registered agent, maintain a declared action manifest specifying permitted tools, target resource classes, and behavioral baseline derived from staging telemetry. Deploy a streaming anomaly detector that compares live telemetry against the manifest and baseline. Flag deviations above a configurable severity threshold for automated or human response.", "steps": [ "Require every agent registration to include a signed action manifest: permitted_tools[], permitted_resource_patterns[], expected_token_range, expected_latency_range.", "Derive a behavioral baseline from the first 30 days of production telemetry for each agent; update quarterly or on significant deployment changes.", "Deploy a streaming rules engine (e.g., Apache Flink, Spark Streaming, or a SIEM correlation rule) that compares live telemetry events against the agent's manifest and flags out-of-manifest tool calls immediately.", "Implement statistical anomaly detection (e.g., z-score or CUSUM) for continuous signals like token consumption, API call rate, and session duration.", "Define severity tiers for anomalies: informational (log only), warning (alert on-call), critical (suspend agent — see AM-07)." ], "ai_engineer": { "summary": "The action manifest is the contract between what an agent is supposed to do and what it actually does. Maintaining it accurately is as important as the detection logic itself.", "actions": [ "Build action manifest generation into the agent deployment pipeline — auto-extract permitted_tools from the agent's tool-binding configuration.", "Add unit tests that simulate out-of-manifest tool calls and verify the anomaly detector fires.", "Maintain manifest version history so that anomaly detections can be correlated with manifest drift." ], "failure_signals": [ "Action manifest is out of date relative to the agent's deployed tool bindings.", "Out-of-manifest tool calls occur without triggering a detection event.", "Anomaly detector processes events with latency above 10 seconds, creating detection blind windows." ] }, "security_architect": { "summary": "Anomalous action detection is a compensating control for prompt injection and capability creep. It must be designed to be tamper-resistant and operate independently of the agent being monitored.", "actions": [ "Ensure the anomaly detector runs in an isolated compute environment with no shared dependencies on the monitored agent's runtime.", "Model adversarial evasion: an attacker who can predict the detection threshold can stay just under it. Use ensemble methods and rotating detection windows.", "Integrate anomaly detection alerts into the SOC SIEM to correlate with network and identity signals." ], "failure_signals": [ "Agent can suppress its own telemetry emission, defeating the detector.", "Anomaly detection thresholds are publicly known or guessable from agent behavior.", "False positive rate exceeds 5% of daily alerts, causing alert fatigue and suppression." ] }, "grc_auditor": { "summary": "Anomalous action detection demonstrates that the enterprise has operationalized its behavioral scope commitments and can detect deviations in real time.", "actions": [ "Request the action manifest for three production agents and verify it reflects the current deployed configuration.", "Review the last 30 days of anomaly detection alerts and verify each was triaged and resolved within SLA.", "Verify that the anomaly detector coverage extends to all agents registered in the identity registry (AM-01 baseline)." ], "metrics": [ "Action manifest coverage: 100% of production agents have a current, signed manifest.", "Mean time to detect (MTTD) for out-of-manifest actions: target <30 seconds.", "Alert triage SLA compliance: target 100% of critical anomalies triaged within 15 minutes." ], "failure_signals": [ "Any production agent lacks a current action manifest.", "Anomaly detector has known gaps in tool coverage.", "Critical anomaly alerts go untriaged for more than 15 minutes." ] }, "legal_counsel": { "summary": "Anomalous action detection is the enterprise's real-time watch over what agents actually do. Detection records demonstrate ongoing supervision; detections without response demonstrate the opposite. Both will be read closely after any agent-caused harm.", "actions": [ "Confirm response procedures assign ownership and timelines for anomaly alerts so unaddressed detections do not accumulate.", "Verify anomaly records are retained and reviewable — they evidence both diligence and, sometimes, early knowledge.", "Assess when detected out-of-scope actions touching regulated data become reportable, and who decides." ], "failure_signals": [ "Anomaly alerts on agent actions with no recorded triage or response.", "Detection thresholds tuned so high that supervision exists on paper but not in practice.", "No documented escalation path from anomaly detection to the incident and disclosure process." ] }, "platform_engineer": { "summary": "The anomaly detection pipeline must handle the full throughput of all agent telemetry with sub-second processing latency and zero event loss.", "actions": [ "Deploy the streaming anomaly detector with auto-scaling to handle telemetry volume spikes during business-hour peaks.", "Implement dead-letter queues for events that fail processing so no telemetry is silently dropped.", "Build manifest hot-reload so updated manifests take effect within 60 seconds without detector restarts." ], "failure_signals": [ "Detector processing backlog grows beyond 60 seconds during peak load.", "Dead-letter queue events are not reprocessed within SLA.", "Manifest updates require detector restart, creating detection gaps." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most agent deployments lack signed action manifests; anomaly detection, where it exists, is typically threshold-based and manually configured." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Security Operations", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM01 (Prompt Injection) identifies injected instructions causing agents to act outside their intended scope as a top risk. Real-time anomalous action detection surfaces the downstream effect — out-of-scope actions — regardless of which injection vector produced them.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-08", "basis": "anchored", "correction": "ai-exchange-verify 2026-07-08", "relation": "defends_against" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 documents adversarial prompt injection as a technique for manipulating LLM agent action selection. Behavioral scope monitoring with real-time anomaly detection directly counters this technique by detecting when an agent executes instructions inconsistent with its declared manifest. This is a first-line defense against ATLAS-documented adversarial manipulation of agent orchestration.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "2.4 — Data Privacy", "fit": "partial", "rationale": "NIST AI 600-1 §2.4 (Data Privacy) covers unauthorized access to and disclosure of data through generative AI systems. Anomalous action detection provides a runtime signal when agents attempt data access outside their sanctioned behavioral scope.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters — real-time policy screening", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' content filters screen each request and response against configured policies in real time — a narrow, content-level form of anomaly blocking. AM-02's behavioral anomaly detection over action patterns and scopes is built in the monitoring layer; Guardrails decisions are one input stream.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy category is concerned with AI systems acting outside sanctioned boundaries. AM-02's real-time anomalous action detection is the deployer-side runtime control that surfaces out-of-scope agent actions as they occur.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "direct", "rationale": "Google SAIF element 2 requires extending detection and response to AI-specific threat vectors, including unexpected agent actions. Real-time anomalous action detection brings out-of-scope agent behavior into the organization's detection pipeline.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires mechanisms that detect and respond to system failures. Real-time anomalous action detection is that mechanism for agent behavior: out-of-scope actions are surfaced while response is still possible rather than discovered in post-incident review.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Toxicity detection — output scoring", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's toxicity detection scores agent outputs against safety categories in real time — a specialized, content-level form of anomalous output detection. AM-02's action-scope anomaly detection covers what agents do, not only what they say, and is built in the monitoring layer.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Anomaly detection", "fit": "direct", "rationale": "Identify deviations from expected behavior (threshold/statistical/ML) to warn before compromised agents cause harm — anomalous action detection.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "direct", "rationale": "AM-02 streams anomaly detection against a signed action manifest to catch out-of-manifest tool or resource use within seconds, directly monitoring agent use for abuse and anomalies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Proves that every production agent has a current, signed action manifest defining its…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AM-02", "validation_objective": "Proves that every production agent has a current, signed action manifest defining its permitted tool set and target resource classes, and that the streaming anomaly detector identifies any out-of-manifest tool invocation or resource access within 30 seconds and generates a logged, escalated alert.", "evidence_required": [ "Action manifest registry listing a current signed manifest for every production agent, including permitted_tools[], permitted_resource_patterns[], expected_token_range, and expected_latency_range", "Anomaly detection alert log for the prior 30 days with triage records confirming each critical alert was reviewed within the 15-minute SLA", "Mean time to detect (MTTD) measurement report for out-of-manifest actions, targeting sub-30-second detection", "Streaming detector configuration documentation confirming it runs in an isolated compute environment independent of monitored agent runtimes", "SOC SIEM integration confirmation showing anomaly alerts are correlated with identity and network signals" ], "machine_tests": [ "Submit a test agent invocation of a tool not listed in the signed action manifest and measure the time from invocation to detection alert, targeting under 30 seconds", "Verify the statistical baseline exists for each registered production agent and was derived from at least 30 days of telemetry", "Confirm the false positive rate against a benign traffic sample stays below 5% of daily alerts by replaying the prior week of legitimate agent telemetry through the detector", "Test that out-of-manifest tool calls produce an alert even when the detector processing queue is at peak load, confirming no events are silently dropped" ], "human_review": [ "Review action manifest currency for a sample of five production agents by comparing the manifest's permitted_tools list against the agent's current deployed tool-binding configuration", "Verify SOC alert triage procedures include a classification step that distinguishes scope violations from behavioral baseline deviations and routes them to the appropriate response workflow", "Review the ensemble detection methodology for adversarial evasion resilience: confirm the detector does not rely on a single, predictable threshold that an attacker with knowledge of the system could evade" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Maintaining action manifests manually in documentation rather than auto-extracting them from the agent's deployed tool-binding configuration, causing manifests to drift out of sync with the actual deployment", "Running the anomaly detector in the same process or runtime as the monitored agent, allowing a compromised agent to interfere with its own detection", "Relying solely on static threshold rules without a statistical behavioral baseline, making the detector blind to anomalies that stay within absolute thresholds but deviate from established patterns", "Routing anomaly alerts only to platform operations teams without SOC integration, treating behavioral scope violations as reliability events rather than potential security incidents" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-03", "layer": "AM", "plane": "control", "name": "Goal Drift and Intent Deviation Detection", "plain": "Agents operating across multi-step sessions must be monitored for divergence between their declared intent and their apparent emergent objectives. When the trajectory of an agent's actions no longer aligns with the stated goal, a deviation event must be raised.", "threat": { "tags": [ "goal-drift", "emergent-objective", "session-hijack", "misaligned-optimization" ], "desc": "In long-horizon agentic tasks, an agent may develop sub-goals that diverge from the user's original intent — either through adversarial manipulation, ambiguous instructions, or emergent instrumental reasoning. Without explicit monitoring for intent deviation, an agent can progressively accumulate resources, escalate permissions, or take actions that individually seem plausible but collectively represent a misaligned objective. By the time damage is visible, the agent may have already taken irreversible actions." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE 2.4", "title": "Production monitoring of AI system behavior" }, { "id": "anthropic_rsp", "section": "Capability Thresholds", "title": "Capability and behavior assessment (Anthropic RSP v3.3)" }, { "id": "openai_preparedness", "requirement_id": "Agentic misuse scenarios", "title": "Sandbagging and long-range autonomy risk categories", "section": "Research Categories (§2.3)" }, { "id": "eu_ai_act", "section": "Art. 9(2)(a)", "title": "Foreseeable risks from unintended behavior in AI systems" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection 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-29", "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://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection control.", "reviewed_on": "2026-07-02" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AM-03 Goal Drift and Intent Deviation Detection control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "At session initiation, extract and store the declared intent as a structured goal object. At configurable checkpoints throughout the session, compare the inferred trajectory (derived from completed actions, acquired resources, and intermediate outputs) against the declared goal using a semantic similarity or structural alignment check. Raise a deviation event when trajectory drift exceeds the configured threshold.", "steps": [ "Define a goal representation schema: goal_statement (natural language), goal_type (task/research/transformation/communication), declared_resources[], declared_scope_limit, session_id.", "At session start, extract and store the goal object; compute a semantic embedding for use in trajectory comparison.", "Instrument session checkpoints (configurable: every N actions, every K minutes, or at tool-call milestones) to evaluate trajectory alignment using cosine similarity against the goal embedding and structural analysis of accumulated tool call patterns.", "Define drift thresholds: warning (embedding similarity <0.7 from declared goal), critical (similarity <0.5 or detection of resource accumulation patterns inconsistent with declared scope).", "On critical deviation, emit a goal_drift_event to AM-07 for automated response and log the full session trace for human review." ], "ai_engineer": { "summary": "Goal drift detection requires embedding the declared intent at session start and evaluating whether the agent's trajectory remains consistent. The hardest part is handling ambiguous goals — build conservative defaults.", "actions": [ "Implement a goal extraction step at session initialization that produces a structured goal object and embeds the goal statement using a lightweight semantic model.", "Build trajectory analysis at each checkpoint: extract the sequence of tool calls and intermediate outputs, compute a summary embedding, and compare against the session goal.", "Instrument the drift event to carry the full session trace, the goal object, and the computed similarity score so human reviewers can reconstruct what happened." ], "failure_signals": [ "Goal extraction step fails silently and no goal object is stored for the session.", "Trajectory analysis runs with latency that causes checkpoint coverage gaps in fast-moving sessions.", "Embedding model used for goal comparison is not versioned, causing silent accuracy regression after model updates." ] }, "security_architect": { "summary": "Goal drift is a higher-order signal than individual anomalous actions. It catches slow-moving misalignment that action-level controls miss. Design the detector to be robust to adversarial goal obfuscation.", "actions": [ "Model adversarial goal obfuscation: an attacker who knows the detection threshold can craft session trajectories that stay just above similarity threshold while pursuing a misaligned objective. Use behavioral pattern analysis alongside semantic similarity.", "Ensure the goal object is stored in an immutable log at session start so it cannot be retroactively altered.", "Integrate goal_drift_events into the SOC as a high-priority indicator of compromise signal." ], "failure_signals": [ "Goal object is mutable after session start, allowing retroactive rationalization of drifted behavior.", "Drift detector relies solely on semantic similarity without structural behavioral pattern analysis.", "Goal drift events are not correlated with identity and network signals in the SIEM." ] }, "grc_auditor": { "summary": "Goal drift detection demonstrates that the enterprise monitors not just individual actions but the emergent direction of agent behavior — a key governance requirement for autonomous systems.", "actions": [ "Request drift event logs for the past quarter and verify that each critical drift event was escalated and reviewed within SLA.", "Sample five completed agent sessions and verify that a goal object was recorded at session start with a timestamp and embedding.", "Review the configuration of drift thresholds and confirm they were set by a documented risk decision, not left at defaults." ], "metrics": [ "Session goal-object coverage: 100% of agent sessions have a recorded goal object at start.", "Critical drift event triage rate: 100% of critical drift events reviewed within 30 minutes.", "False positive rate for drift warnings: target <10% to maintain signal credibility." ], "failure_signals": [ "Sessions complete without a recorded goal object.", "Critical drift events are not escalated or sit in queue beyond 30 minutes.", "Drift thresholds are not documented as a risk decision." ] }, "legal_counsel": { "summary": "Goal drift in autonomous agents creates liability exposure when agents act outside the scope that was disclosed to users or regulators. Detection and documentation of drift events is a prerequisite for demonstrating due diligence.", "actions": [ "Review the declared intent capture mechanism to confirm that user-stated goals are recorded verbatim for potential evidentiary use.", "Confirm that critical drift events trigger human review before the agent continues, creating a documented human-in-the-loop decision point.", "Verify that drift event records are retained in compliance with applicable record-keeping obligations (e.g., EU AI Act Art. 12, financial sector requirements)." ], "failure_signals": [ "Goal objects do not capture verbatim user instruction — only a processed derivative — limiting evidentiary value.", "Agents continue operating autonomously after a critical drift event without a documented human review.", "Drift event logs are not retained for the required regulatory period." ] }, "platform_engineer": { "summary": "You provide the pipeline that makes goal-drift detection computable: session-scoped aggregation of agent actions, objective metadata propagation, and the comparison jobs that score observed behavior against declared intent.", "actions": [ "Propagate the declared objective/task identifier through all agent telemetry so per-session behavior can be grouped and compared against intent.", "Run drift-scoring as a streaming or frequent batch job with defined freshness SLOs — stale drift detection is failed drift detection.", "Route drift scores above threshold into the same alerting and suspension paths as AM-02/AM-07, not into a dashboard nobody watches." ], "failure_signals": [ "Telemetry lacking objective identifiers, making intent-versus-behavior comparison impossible to compute.", "Drift jobs running daily against agents that complete thousands of sessions an hour.", "High drift scores visible in dashboards but connected to no alerting or containment path." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Goal drift detection is an emerging practice; most enterprise deployments have no mechanism for detecting session-level intent divergence beyond manual review." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Security Architecture", "Legal / Compliance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE 2.4", "fit": "direct", "rationale": "NIST AI RMF MEASURE 2.4 requires the functionality and behavior of the AI system to be monitored in production. Goal drift detection monitors precisely the behavioral dimension: whether an agent's actions remain consistent with its declared objective over time.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds — capability and behavior assessment", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP requires ongoing assessment of whether model capabilities and behavior have crossed thresholds that demand stronger safeguards. AM-03 is the deployment-time counterpart: continuous comparison of an agent's observed behavior against its declared objective, so deviations are detected rather than assumed away.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)(a)", "fit": "partial", "rationale": "EU AI Act Article 9(2)(a) requires identification and analysis of the known and reasonably foreseeable risks a high-risk AI system can pose. Goal drift in autonomous agents is a foreseeable risk class; drift detection is a documented mitigation within the risk management system.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Sandbagging and Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 research categories include Sandbagging — a model behaving differently in production than under evaluation — and Long-range Autonomy. Goal drift detection is the production counterpart: continuously verifying that an agent's behavior remains consistent with its declared objective rather than trusting pre-deployment evaluation alone.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires ongoing monitoring and evaluation so that deviations from intended behavior are detected and corrected. Goal drift detection implements RS3 for agent objectives: observed behavior is continuously evaluated against the declared task.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Observability (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Observability control requires production visibility into agent behavior over time. Goal drift detection is a specialized observability capability: it compares observed behavior against the declared objective and surfaces deviation as a first-class signal.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Contextual grounding checks", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' contextual grounding checks evaluate whether individual responses remain grounded in source material — adjacent to, but much narrower than, goal drift detection. AM-03 compares behavior against the declared objective across a session and over time, which requires orchestration-layer instrumentation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "salesforce_trust", "requirement_id": "Secure data retrieval and dynamic grounding", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's dynamic grounding re-anchors responses in permissioned, current CRM data — reducing one source of objective drift (stale or unauthorized context). Detecting drift of the agent's goal itself, as AM-03 requires, needs longitudinal behavioral comparison outside the Trust Layer.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 8 — Behavior (goal/behavioral drift); Part III — Baseline establishment (drift detection)", "fit": "direct", "rationale": "Behavioral conformance tracks drift over time and Part II shared-context poisoning notes long-term memory drift shifting goal weighting — goal-drift / intent-deviation detection.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AM-03", "validation_objective": "Proves that every multi-step agent session has an immutable goal object recorded at session start and that the drift detector raises a structured deviation event whenever the inferred trajectory similarity falls below the configured warning threshold, with critical deviation events triggering automated session suspension via AM-07.", "evidence_required": [ "Goal object registry showing a timestamped, immutable goal record for every completed agent session over the prior 30 days, including goal_statement, goal_type, declared_resources[], and session_id", "Goal drift event log for the prior quarter including event severity, computed similarity score, session trace reference, and triage outcome", "Embedding model version history confirming the model used for trajectory comparison is versioned and that changes go through change management", "Critical drift event triage records confirming human review occurred before session continuation in every instance", "False positive rate report for drift warnings over the prior 90 days, targeting below 10% to maintain signal credibility" ], "machine_tests": [ "Verify a goal object is stored in an immutable log for every agent session within the prior 30 days by cross-referencing session IDs against the goal object registry", "Inject an adversarially divergent tool call sequence into a test session that progressively accumulates out-of-scope resources and verify a critical drift event fires before the session exceeds the similarity threshold", "Confirm the embedding model version is recorded in each goal object so drift evaluations can be invalidated and replayed if the model is updated", "Verify that a critical drift event triggers the AM-07 automated response pathway by confirming the test session is suspended rather than allowed to continue" ], "human_review": [ "Review drift threshold configuration to confirm it was set by a documented risk decision rather than left at system defaults, with rationale for the chosen warning and critical similarity values", "Verify a sample of critical drift event records to confirm human review was completed and documented before each affected session was permitted to resume or was terminated", "Confirm goal objects record the verbatim user-stated goal rather than only a processed derivative, preserving evidentiary value for regulatory investigations and liability defense", "Review whether the drift detector combines semantic similarity with structural behavioral pattern analysis to resist adversarial trajectory obfuscation that stays just above the similarity threshold" ], "blocking_effect": "blocks-runtime-action", "normative_status": "voluntary-standard", "anti_patterns": [ "Storing the goal object in a mutable log that can be updated during the session, allowing retroactive rationalization of drifted behavior to match an emergent objective", "Relying solely on semantic embedding similarity without structural analysis of the accumulated tool call pattern, leaving the detector blind to adversarial trajectories crafted to maintain surface-level similarity while pursuing a misaligned objective", "Not correlating goal drift events with SIEM identity and network signals, missing the cross-signal pattern that distinguishes adversarial goal manipulation from benign task evolution", "Leaving drift thresholds at system defaults without a documented risk decision, treating the detection sensitivity as a technical configuration detail rather than a governance choice" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-04", "layer": "AM", "plane": "control", "name": "Resource Consumption Anomaly Monitoring", "plain": "Agents must be monitored for anomalous patterns in API call volume, token consumption, storage access frequency, cost accrual, and external service usage. Deviations from established baselines must trigger alerts and, above defined thresholds, automated agent suspension.", "threat": { "tags": [ "resource-abuse", "cost-explosion", "api-rate-exhaustion", "data-exfiltration-via-volume" ], "desc": "Compromised or misbehaving agents can generate runaway API costs, exhaust shared rate limits, exfiltrate large data volumes via elevated storage access, or consume compute resources that deny service to other tenants. These patterns are often the earliest detectable signal of agent compromise or prompt injection — showing up as cost anomalies before any semantic detection fires. Without resource consumption monitoring, financial damage and availability impact can accrue unchecked." }, "standard": [ { "id": "iso_31000", "section": "§6.6 — Monitoring and review", "title": "Monitoring operational risk indicators including cost and resource usage" }, { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment operational monitoring" }, { "id": "google_saif", "section": "Agent Observability", "title": "SAIF control — visibility into agent resource consumption in production" } ], "sources": [ { "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-29", "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://agentic/controls/AM-04 Resource Consumption Anomaly Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-04 Resource Consumption Anomaly Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-04 Resource Consumption Anomaly Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-04 Resource Consumption Anomaly Monitoring control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish per-agent resource consumption baselines across five dimensions: token_in, token_out, api_calls_per_session, storage_bytes_read, and cost_usd. Deploy streaming monitors that track rolling windows against these baselines and trigger tiered alerts. Integrate with AM-07 for automated suspension when hard cost or volume limits are breached.", "steps": [ "Define per-agent resource baseline parameters at registration: expected_token_range, expected_api_calls_per_session, expected_storage_access_bytes, expected_cost_per_session, and hard_limits for each.", "Deploy a streaming cost and resource monitor (e.g., using cloud provider cost APIs + telemetry stream) that evaluates every agent session against its baseline in real time.", "Implement three-tier alerting: (1) soft warning at 2× baseline, (2) hard alert at 5× baseline requiring on-call acknowledgment, (3) automated suspension trigger at hard_limit breach (see AM-07).", "Generate daily per-agent cost and consumption reports; aggregate by team and business unit for governance reporting.", "Review and update baselines quarterly or after any agent configuration change that affects expected resource patterns." ], "ai_engineer": { "summary": "Resource monitoring is a canary for agent health. A sudden spike in token consumption or API calls often indicates prompt injection or a feedback loop before any semantic signal fires.", "actions": [ "Instrument agent runtimes to emit resource metrics (token counts, API call counts, storage bytes accessed) as part of every telemetry event.", "Build baseline auto-calculation from the first 30 days of production telemetry for new agent deployments.", "Add resource consumption validation to agent integration tests: verify that nominal task scenarios do not exceed baseline by more than 20%." ], "failure_signals": [ "Token consumption telemetry is not emitted per-call, preventing per-session aggregation.", "Baseline parameters are set to unlimited, defeating the monitoring logic.", "Cost monitor queries cloud billing API rather than real-time telemetry, introducing a multi-hour detection lag." ] }, "security_architect": { "summary": "Resource consumption anomalies are one of the most reliable early indicators of agent compromise. They are harder to suppress than semantic signals and appear regardless of the nature of the attack.", "actions": [ "Integrate resource consumption alerts into the SOC with playbooks for triage: distinguish legitimate high-load tasks from anomalous consumption.", "Set hard limits on per-agent API key spend at the cloud provider level as a defense-in-depth backstop, independent of this monitoring layer.", "Monitor for gradual consumption drift (slow ramp over days) in addition to spike detection — this pattern can indicate slow-burn data exfiltration." ], "failure_signals": [ "No cloud-provider-level hard spend limits are set, leaving the application-layer monitor as the only backstop.", "Gradual consumption drift goes undetected because monitoring only uses spike-based thresholds.", "Resource alerts are not correlated with identity or network signals in the SIEM." ] }, "grc_auditor": { "summary": "Resource consumption monitoring demonstrates financial governance over AI systems and provides early-warning signals for operational risk events.", "actions": [ "Request the per-agent resource baseline registry and verify baselines are current (updated within 90 days or after last deployment change).", "Review the last quarter's cost anomaly alerts and verify each was triaged and resolved within SLA.", "Verify that hard limits are set at both the application layer and the cloud provider layer for all production agents." ], "metrics": [ "Baseline coverage: 100% of production agents have documented resource baselines.", "Hard limit coverage: 100% of production agents have cloud-provider-level spend limits.", "Cost anomaly triage SLA: 100% of hard alerts acknowledged within 15 minutes." ], "failure_signals": [ "Any production agent has no documented resource baseline.", "Cloud-provider-level hard limits are absent for any agent API key.", "Hard alerts go unacknowledged for more than 15 minutes." ] }, "legal_counsel": { "summary": "Resource anomaly monitoring surfaces runaway or hijacked agents through their spend and consumption signature. It is also the record that bounds financial exposure claims: the enterprise can show when the anomaly began, when it was caught, and what the cap prevented.", "actions": [ "Confirm consumption anomalies on agents with spend authority route to owners with authority to suspend, not just observe.", "Verify anomaly and response records are retained to support insurance claims and loss attribution.", "Review whether sustained anomalous consumption of third-party services creates contractual notice obligations." ], "failure_signals": [ "Spend anomalies detected but allowed to continue for lack of a suspension owner.", "Loss events where the enterprise cannot document detection and response timing.", "Third-party platform terms breached by anomalous agent consumption no one reported." ] }, "platform_engineer": { "summary": "Resource monitoring requires integration with both real-time telemetry and cloud provider billing APIs. Ensure the pipeline captures cost data with minimal latency.", "actions": [ "Configure real-time token and API call metrics to flow through the telemetry pipeline (AM-01) with per-session aggregation.", "Integrate cloud provider cost APIs (AWS Cost Explorer, Azure Cost Management, GCP Billing) with the monitoring pipeline for cross-validation.", "Deploy per-agent spend dashboards with automated anomaly annotations visible to agent owners and the security operations team." ], "failure_signals": [ "Cost data is only available from cloud billing APIs with a 24-hour lag, making real-time anomaly detection impossible.", "Per-agent spend attribution is not available because multiple agents share API keys.", "Spend dashboards are not accessible to agent owners, removing a self-service monitoring layer." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have cloud cost alerts but lack per-agent attribution, real-time streaming analysis, or automated suspension integration." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector" ], "implementers": [ "Platform Engineering", "FinOps / Cloud Operations", "Security Operations" ], "frameworks": [ { "framework": "iso_31000", "requirement_id": "§6.6 — Monitoring and review", "fit": "direct", "rationale": "ISO 31000:2018 §6.6 requires monitoring and review of the risk management process and its controls, including detecting changes in risk levels. Resource consumption anomaly monitoring detects exactly such changes for agent operational risk — consumption departing from baseline signals a control or behavior change.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.1 requires implemented post-deployment monitoring plans. Resource consumption anomaly monitoring implements the operational dimension of that plan — cost, call volume, and compute — where runaway agent patterns first become visible.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Agent Observability (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Agent Observability control requires visibility into agent operation in production. Resource consumption monitoring is the operational dimension of that observability — cost, call volume, and compute per agent — where compromise and runaway behavior often surface first.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(4) — Risk Management Measures", "fit": "adjacent", "rationale": "EU AI Act Art. 9(4) requires high-risk AI systems to have risk management measures proportionate to the risks posed, including operational risks. Resource consumption monitoring provides a proportionate operational risk control for autonomous agents, particularly relevant to high-risk AI systems where runaway behavior has amplified consequences.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires ongoing operational monitoring of deployed systems. Resource consumption anomaly monitoring implements RS3 for the operational dimension of agent behavior — cost, call volume, and compute — where runaway patterns first become visible.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Anomaly detection (API call rates, data access volumes)", "fit": "direct", "rationale": "Threshold/statistical anomaly detection on API call rates and data access volumes — resource-consumption anomaly monitoring.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "limitresources", "fit": "supporting", "rationale": "AM-04 baselines resource consumption and triggers automated suspension when hard limits are breached, enforcing the resource limiting AI Exchange specifies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://agentic/controls/AM-04", "validation_objective": "Prove that every production agent has documented resource baselines across all five consumption dimensions and that anomalous consumption is detected and alerted within defined response time thresholds. Validate that automated suspension triggers fire when hard consumption limits are breached and that cloud-provider-level spend limits exist for every production agent API key.", "evidence_required": [ "Per-agent resource baseline registry with documented expected_token_range, expected_api_calls_per_session, expected_storage_access_bytes, expected_cost_per_session, and hard_limits — updated within 90 days or after the last deployment change", "Streaming cost and resource monitor configuration showing real-time threshold definitions (2x soft-warning, 5x hard-alert, hard_limit suspension) per agent", "Alert log for the review period showing all triggered soft, hard, and suspension events with triage records and time-to-acknowledge metrics", "Cloud-provider-level spend limit configuration for all production agent API keys demonstrating defense-in-depth backstop independent of the application monitoring layer" ], "machine_tests": [ "Verify 100% of production agents have a resource baseline record with all five dimensions populated, with no dimension set to unlimited, and with a last-updated timestamp within 90 days", "Inject a synthetic API call burst at 6x baseline for a test agent and confirm tier-3 hard alert fires and routes to on-call within 30 seconds", "Inject synthetic consumption at the hard_limit threshold and confirm automated suspension is triggered within 60 seconds, a suspension event is emitted to the tamper-evident log, and the agent's API token is revoked", "Query cloud provider spend limits API to confirm per-agent API key limits exist and are set below 10x the documented expected_cost_per_session for all production agents" ], "human_review": [ "Assess whether baseline parameters are calibrated to actual observed task profiles — not set to unlimited, not set to values far above observed usage that would never trigger alerts in realistic scenarios", "Review whether the monitoring configuration detects gradual consumption drift over days in addition to spike-based thresholds, since slow-burn data exfiltration may never cross a per-interval spike threshold", "Confirm that SOC playbooks for resource anomaly alerts include guidance for distinguishing legitimate high-load tasks from anomalous behavior, and that playbooks have been tested within the past six months" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Setting hard_limit values to extremely high numbers that never trigger in practice, transforming a monitoring control into a paperwork exercise", "Relying solely on cloud billing APIs with multi-hour lag as the monitoring source instead of real-time telemetry, introducing a detection gap that allows runaway behavior to continue unchecked", "Sharing API keys across multiple agents so per-agent spend attribution is impossible and anomalies cannot be traced to a specific agent", "Treating gradual consumption drift as non-anomalous because no single monitoring window exceeds a spike threshold, missing the slow-burn exfiltration pattern" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-05", "layer": "AM", "plane": "control", "name": "Multi-Agent Communication Monitoring", "plain": "All inter-agent messages in multi-agent systems must be monitored for scope violations, prompt injection attempts embedded in agent-to-agent payloads, unauthorized data exfiltration, and communication patterns inconsistent with the declared orchestration topology.", "threat": { "tags": [ "inter-agent-injection", "data-exfiltration-via-messaging", "topology-violation", "agent-impersonation" ], "desc": "In multi-agent architectures, compromised agents can inject malicious instructions into messages destined for other agents, relay sensitive data outside the authorized data boundary, impersonate orchestrator agents to escalate permissions, or form communication topologies not approved in the orchestration manifest. Without monitoring of inter-agent communication, one compromised agent can pivot across the entire agent network, multiplying the blast radius of a single injection event." }, "standard": [ { "id": "owasp_llm10", "section": "LLM06:2025 — Excessive Agency", "title": "Inter-agent scope escalation via unchecked message passing" }, { "id": "mitre_atlas", "section": "AML.T0051", "title": "LLM Prompt Injection — injection via inter-agent message payloads" }, { "id": "nist_ai_600_1", "section": "2.8 — Information Integrity", "title": "Integrity of data flowing between AI components" }, { "id": "iso_42001", "section": "§8.1", "title": "Operational planning and control — AI system interfaces and data flows" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-05 Multi-Agent Communication Monitoring control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-05 Multi-Agent Communication Monitoring control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-05 Multi-Agent Communication Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-05 Multi-Agent Communication Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-05 Multi-Agent Communication Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "At deployment time, require a signed orchestration topology manifest specifying all authorized agent-to-agent communication edges. Deploy a message inspection layer on the inter-agent message bus that validates each message against the topology manifest, scans payloads for injection patterns and sensitive data, and raises violations as monitoring events.", "steps": [ "Require a signed orchestration topology manifest at deployment time: permitted_edges[] (source_agent → target_agent), permitted_payload_types[], data_classification_ceiling per edge.", "Deploy an inter-agent message broker (or middleware layer on existing brokers) that intercepts all agent-to-agent messages before delivery.", "Implement topology validation: reject messages on edges not declared in the manifest and emit a topology_violation event.", "Implement payload inspection: scan message content for known injection patterns (adversarial instruction prefixes, role-override attempts) and sensitive data patterns (PII, credential formats) using configurable detection rules.", "Log all inter-agent messages to the tamper-evident store (see AM-06) with sender identity, receiver identity, timestamp, payload hash, and inspection verdict." ], "ai_engineer": { "summary": "Inter-agent communication is an attack surface that compound-scales with the number of agents. Treat every message from another agent as potentially adversarial until inspection passes.", "actions": [ "Build the orchestration topology manifest as a first-class artifact in the agent deployment pipeline — auto-generate it from the orchestration configuration and have it signed before deployment.", "Implement a defense-in-depth message validation layer in each agent's input processing: even if the broker's inspection passes, agents should validate that received messages are consistent with their expected protocol.", "Add integration tests that simulate topology violations and injection attempts in agent-to-agent messages and verify detection fires." ], "failure_signals": [ "Agents accept messages from any source without topology validation, including unregistered agents.", "Orchestration topology manifest is not updated when new agents are added or communication edges change.", "Message inspection is applied at the broker but not at the receiving agent, leaving a gap if the broker is bypassed." ] }, "security_architect": { "summary": "Multi-agent communication is the highest-risk attack surface in compound agentic systems. A single injected message that bypasses inspection can propagate through the entire agent network.", "actions": [ "Apply mTLS or equivalent cryptographic authentication to all inter-agent communication channels so agent identity is verified at the transport layer.", "Design the message inspection layer to be independent of any agent's runtime so no single compromised agent can suppress or bypass inspection.", "Model the blast radius of a compromised agent in the topology: identify high-fan-out agents and apply stricter inspection to their outbound messages." ], "failure_signals": [ "Inter-agent messages are not authenticated at the transport layer, allowing agent impersonation.", "High-fan-out orchestrator agents have the same inspection tier as narrow leaf agents.", "Message inspection layer shares any infrastructure with monitored agents, creating a conflict of interest in the trust model." ] }, "grc_auditor": { "summary": "Multi-agent communication monitoring demonstrates that the enterprise has extended its behavioral governance beyond individual agents to the system-of-systems level.", "actions": [ "Request the orchestration topology manifests for all production multi-agent deployments and verify they are current and signed.", "Review the last 30 days of topology violation and payload inspection events and verify each was triaged.", "Verify that inter-agent message logs are retained in the tamper-evident store and accessible for audit." ], "metrics": [ "Topology manifest coverage: 100% of production multi-agent deployments have a current signed manifest.", "Topology violation event triage rate: 100% within 30 minutes of detection.", "Message log retention compliance: 100% of inter-agent messages retained per policy." ], "failure_signals": [ "Any multi-agent deployment lacks a current topology manifest.", "Topology violation events are not triaged within SLA.", "Inter-agent message logs are not accessible for audit or have retention gaps." ] }, "legal_counsel": { "summary": "Inter-agent communication monitoring preserves visibility into how instructions and data propagate between agents — the channel where scope escalation and injected instructions travel. Without it, multi-agent incidents are unreconstructable and responsibility unassignable.", "actions": [ "Confirm the approved communication topology is documented so off-topology flows are provably unauthorized.", "Verify captured inter-agent payloads containing personal or regulated data are handled under a documented processing basis.", "Ensure communication records are retained long enough to reconstruct multi-agent incidents end to end." ], "failure_signals": [ "Agent-to-agent channels operating outside any documented topology.", "Payload capture creating an ungoverned store of regulated data.", "Multi-agent incidents that cannot be sequenced because inter-agent messages were never retained." ] }, "platform_engineer": { "summary": "The inter-agent message inspection layer must handle message throughput without introducing prohibitive latency and must be deployable across heterogeneous agent communication patterns.", "actions": [ "Deploy the inspection middleware as a sidecar or broker plugin that intercepts messages transparently without requiring agent code changes.", "Implement asynchronous inspection with a configurable hold-and-inspect timeout to balance latency against thoroughness.", "Build topology manifest hot-reload so new edges take effect within 60 seconds without broker restarts or message loss." ], "failure_signals": [ "Message inspection adds more than 100ms latency to inter-agent communication, causing cascading timeout failures in latency-sensitive workflows.", "Topology manifest changes require broker restarts, creating monitoring gaps during maintenance windows.", "Inspection layer cannot handle the message throughput of peak multi-agent task bursts without message loss." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Inter-agent communication monitoring is an emerging requirement; most multi-agent deployments have no systematic message inspection or topology enforcement." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Security Architecture", "Platform Engineering" ], "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM06:2025 — Excessive Agency", "fit": "direct", "rationale": "OWASP LLM Top 10 2025 LLM06 (Excessive Agency) addresses agents taking actions beyond authorized scope, including through inter-agent message passing. Communication monitoring with topology enforcement detects scope escalation as it propagates between agents.", "normative_force": "best-practice", "source_version": "2025", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "mitre_atlas", "requirement_id": "AML.T0051 — LLM Prompt Injection", "fit": "direct", "rationale": "MITRE ATLAS AML.T0051 (LLM Prompt Injection) includes indirect injection, where adversarial instructions are embedded in data an AI system processes. Inter-agent messages are a high-value carrier for such payloads; AM-05's payload inspection applies detection to that channel.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "2.8 — Information Integrity", "fit": "direct", "rationale": "NIST AI 600-1 §2.8 (Information Integrity) addresses risks to the integrity of information produced and propagated by generative AI. In multi-agent systems, inter-agent messages are the propagation channel; AM-05's monitoring detects corruption or manipulation of data flowing between agents.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.1 — Operational planning and control", "fit": "partial", "rationale": "ISO/IEC 42001 §8.1 requires controlled, documented operation of AI system processes. Inter-agent communication is a critical interface class in multi-agent systems; topology-manifest enforcement makes it a controlled process rather than an unmonitored channel.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_preparedness", "requirement_id": "Research Categories (§2.3) — Long-range Autonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Its §2.3 Long-range Autonomy category recognizes that chains of AI systems can produce emergent behavior no single system exhibits. Topology-based monitoring of inter-agent communication gives deployers visibility into exactly those chains.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Input Validation and Sanitization (SAIF control)", "fit": "partial", "rationale": "Google SAIF's Input Validation and Sanitization control covers adversarial content entering AI systems, and inter-agent messages are an input channel: injected instructions can propagate across agent boundaries. AM-05's payload inspection applies input validation to that channel.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "T1 — System intelligibility for decision making", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal T1 requires that system behavior be intelligible to those overseeing it. In multi-agent systems, intelligibility depends on visibility into inter-agent communication; topology-based communication monitoring provides exactly that visibility.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "ApplyGuardrail API — content evaluation for arbitrary payloads", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails' ApplyGuardrail API evaluates arbitrary text against configured policies, so it can be invoked on inter-agent message payloads as one screening layer. Topology-manifest enforcement and cross-agent flow monitoring, as AM-05 requires, are orchestration-layer capabilities outside Guardrails.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 6 — Explicit trust boundaries (log all inter-agent communications; flag unusual delegation patterns)", "fit": "direct", "rationale": "Doc requires logging inter-agent communications and flagging unusual delegation patterns — multi-agent communication monitoring.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AM-05", "validation_objective": "Prove that all inter-agent communication edges conform to a signed topology manifest and that message payloads are inspected for injection patterns and unauthorized sensitive data before delivery to the receiving agent. Validate that topology violations generate escalation events and are triaged within the defined SLA.", "evidence_required": [ "Signed orchestration topology manifest for each production multi-agent deployment, specifying all permitted_edges[], permitted_payload_types[], and data_classification_ceiling per edge — updated within 30 days of any topology change", "Message broker or middleware inspection layer configuration documenting active payload scan rules for known injection patterns (adversarial instruction prefixes, role-override attempts) and sensitive data formats (PII, credential patterns)", "Topology violation and payload inspection event log for the review period with triage records confirming 100% of events were reviewed within the defined SLA", "Inter-agent message retention log demonstrating tamper-evident storage in the AM-06 archive with sender identity, receiver identity, timestamp, payload hash, and inspection verdict per message", "mTLS or equivalent transport-layer authentication configuration for all inter-agent communication channels confirming agent identity is verified at the transport layer" ], "machine_tests": [ "Attempt to deliver a test message on an edge not declared in the current topology manifest and confirm the broker rejects delivery and emits a topology_violation event routed to the monitoring log", "Send a test inter-agent message containing a known adversarial instruction prefix and confirm payload inspection blocks delivery and raises a detection event", "Send a test inter-agent message with a synthetic PII pattern and confirm sensitive data detection fires before the message reaches the receiving agent", "Modify the topology manifest to add a new permitted edge and confirm the broker accepts the change within 60 seconds via hot-reload without broker restart or message loss" ], "human_review": [ "Assess whether the topology manifest accurately reflects the currently deployed orchestration graph, including all agents and communication edges added since the last manifest revision", "Review whether high-fan-out orchestrator agents are configured for stricter inspection than narrow leaf agents, proportionate to their potential blast radius if compromised", "Evaluate whether a documented blast-radius analysis exists for a compromised high-fan-out agent and whether the inspection tier assignments reflect that analysis" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Applying message inspection only at the broker layer without defense-in-depth validation at the receiving agent, leaving a gap if the broker is bypassed or misconfigured", "Allowing the topology manifest to become stale when new agents or communication edges are added, creating a growing set of undeclared but active edges", "Assigning identical inspection tier to all agents regardless of their fan-out or position in the orchestration topology, concentrating unmitigated risk at orchestrator nodes", "Storing inter-agent message logs in the same infrastructure as the agent runtime, creating a conflict of interest where a compromised agent can suppress its own communication record" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-06", "layer": "AM", "plane": "data", "name": "Monitoring Log Integrity", "plain": "All behavioral monitoring logs, anomaly detection events, and agent telemetry must be stored in a tamper-evident, append-only archive with cryptographic chain of custody. Log integrity must be verifiable independently of the systems being monitored.", "threat": { "tags": [ "log-tampering", "audit-trail-destruction", "chain-of-custody-break", "forensic-evidence-suppression" ], "desc": "An adversary or insider who gains access to monitoring infrastructure has strong incentives to modify or delete behavioral logs to conceal compromise. If monitoring logs can be modified, all other AM-layer controls are undermined — anomaly detections can be erased, session traces can be altered, and forensic reconstruction becomes impossible. Log integrity is the trust foundation for the entire monitoring layer." }, "standard": [ { "id": "iso_42001", "section": "§9.1 — Monitoring records", "title": "Integrity and retention of AI monitoring records" }, { "id": "eu_ai_act", "section": "Art. 19 & Art. 26(6)", "title": "Log retention obligations for providers and deployers" }, { "id": "nist_rmf", "section": "GOVERN 4.3", "title": "Incident identification practices and trustworthy records" } ], "sources": [ { "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-29", "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://agentic/controls/AM-06 Monitoring Log Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-06 Monitoring Log Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "salesforce_einstein_trust_layer_2024", "title": "Salesforce Einstein Trust Layer", "authority": "Salesforce, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2023", "published_on": "2023-06-12", "retrieved_on": "2026-06-29", "canonical_url": "https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "salesforce_einstein_trust_layer_2024", "relationship": "informative_reference", "rationale": "Establishes Salesforce Einstein Trust Layer requirements informing the apeiris://agentic/controls/AM-06 Monitoring Log Integrity control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Route all AM-layer telemetry and event data to an append-only log store with write-once semantics. Apply cryptographic chaining (SHA-256 Merkle tree or sequential hash chain) across log entries so any modification or deletion is detectable. Store chain roots in an independent, air-gapped or externally-anchored audit ledger. Verify chain integrity on a scheduled basis and alert on any integrity failure.", "steps": [ "Deploy an append-only log store (e.g., AWS CloudTrail, Azure Immutable Storage, or a self-hosted Merkle-tree-based log server) with write-once, legal-hold semantics for all AM-layer telemetry.", "Implement sequential hash chaining: each log entry includes a SHA-256 hash of its content plus the hash of the previous entry; compute and publish a Merkle root every hour.", "Anchor hourly Merkle roots in an independent external system (e.g., a public transparency log, a separate cloud account, or a hardware security module) to make root forgery computationally infeasible.", "Run automated integrity verification on a six-hour schedule: recompute chain from genesis, compare against anchored roots, and alert immediately on any discrepancy.", "Define and test a log recovery runbook for integrity failure scenarios; verify the runbook annually." ], "ai_engineer": { "summary": "You emit the telemetry that log integrity protects — and integrity starts at emission. Events must be complete, ordered, and delivered exactly-once-enough that the hash chain downstream means something.", "actions": [ "Emit behavioral events through the shared telemetry library with sequence numbers and session identifiers so gaps and reordering are detectable downstream.", "Never buffer agent telemetry in mutable local files an agent process (or its tools) can rewrite; hand off to the collector synchronously or via write-once queues.", "Include the event-schema version in every record so integrity verification survives schema evolution." ], "failure_signals": [ "Agent runtimes writing telemetry to local files that tools running in the same process can modify.", "Missing sequence numbers making silent event loss indistinguishable from quiet periods.", "Schema changes that break downstream hash-chain verification because events became unparseable." ] }, "security_architect": { "summary": "Log integrity is a security property, not a compliance checkbox. Design the system so that even a fully-compromised agent runtime cannot modify or delete its own monitoring logs.", "actions": [ "Ensure the log store write path is one-directional: agent runtimes can write events but cannot read, modify, or delete them. Use write-only API tokens for agent log emission.", "Separate the log store's administrative access from all agent-related service accounts — log store admin should require break-glass access with human approval.", "Model the threat of a compromised log collector: use multi-party verification so log integrity cannot be undermined by a single compromised infrastructure component." ], "failure_signals": [ "Agent service accounts have read or delete permissions on the log store.", "Log store admin access is held by the same principals who manage agent deployments.", "Merkle roots are stored in the same system as the logs they validate, defeating the independence requirement." ] }, "grc_auditor": { "summary": "Log integrity is the evidentiary foundation for all governance claims about AI agent monitoring. Without it, no audit finding has reliable evidential basis.", "actions": [ "Request proof of the most recent integrity verification run: the computed root, the anchored root, and the comparison result.", "Verify that the external anchor is genuinely independent — in a different cloud account, organizational unit, or system controlled by a different team.", "Confirm log retention policy meets applicable regulatory requirements (e.g., EU AI Act Art. 19 provider log-keeping and Art. 26(6) deployer retention of at least six months for high-risk AI, or longer where other applicable law requires)." ], "metrics": [ "Log integrity verification pass rate: 100% of scheduled verification runs pass.", "External anchor independence: anchors stored in systems with different administrative principals than the log store.", "Retention compliance: 100% of monitoring logs retained for the required period." ], "failure_signals": [ "Any integrity verification run fails without an immediate incident response.", "External anchor is controlled by the same team that controls the log store.", "Log retention falls below regulatory minimum for any log category." ] }, "legal_counsel": { "summary": "Tamper-evident logs with chain of custody are a prerequisite for using monitoring data as evidence in regulatory proceedings, litigation, or internal investigations.", "actions": [ "Confirm that the log chain of custody documentation satisfies the authentication requirements for electronic records in applicable jurisdictions.", "Verify that legal hold procedures can freeze specific log ranges without disrupting the append-only property for other ranges.", "Review the log retention policy against the longest applicable regulatory retention obligation across all jurisdictions where agents operate." ], "failure_signals": [ "Chain of custody documentation does not meet electronic records authentication standards for applicable jurisdictions.", "Legal hold procedures require modifying log store configuration in ways that conflict with append-only semantics.", "Retention policy does not account for the longest applicable regulatory obligation." ] }, "platform_engineer": { "summary": "The tamper-evident log infrastructure must be designed for durability, write throughput matching the full AM telemetry volume, and zero data loss under failure conditions.", "actions": [ "Configure the append-only store with multi-region replication to eliminate single-region failure as a log loss vector.", "Implement write buffering and retry logic in the telemetry collector so transient store unavailability does not cause log gaps.", "Automate the hourly Merkle root computation and external anchoring as a scheduled job with alerting on failure." ], "failure_signals": [ "Log store is single-region with no replication, making it vulnerable to regional outage.", "Write buffer overflow during log store unavailability causes telemetry events to be dropped.", "Merkle root computation job fails silently without alerting." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have centralized logging but lack cryptographic integrity chaining, independent external anchoring, and automated integrity verification." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Security Architecture", "Platform Engineering", "Legal / Compliance" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "direct", "rationale": "ISO/IEC 42001 §9.1 requires that monitoring and measurement results be retained as documented evidence and that the integrity of those records be maintained. Cryptographic hash chaining and append-only storage directly implement the integrity assurance requirement for AI monitoring records mandated by §9.1.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 19 & Art. 26(6)", "fit": "direct", "rationale": "EU AI Act Article 19 requires providers to keep the automatically generated logs of high-risk AI systems, and Article 26(6) requires deployers to keep them for at least six months (longer where other applicable law requires). Tamper-evident storage with cryptographic integrity makes those retained logs trustworthy as evidence.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 4.3", "fit": "partial", "rationale": "NIST AI RMF GOVERN 4.3 requires organizational practices for AI testing, incident identification, and information sharing. Those practices are only as trustworthy as the records behind them; cryptographically tamper-evident behavioral logs give incident identification a verifiable evidentiary basis.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Element 2 — Extend detection and response to bring AI into the organization's threat universe", "fit": "partial", "rationale": "Google SAIF element 2's detection and response capability is only as trustworthy as the logs it reads. Tamper-evident behavioral logs protect the monitoring record itself, so a compromised agent or insider cannot silently rewrite the evidence detection depends on.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) depend on trustworthy records of automated behavior. Tamper-evident behavioral logs with cryptographic integrity verification ensure the accountability record cannot be retroactively altered.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "salesforce_trust", "requirement_id": "Audit trail", "fit": "adjacent", "rationale": "The Salesforce Einstein Trust Layer's audit trail logs prompts, masked data, and outputs (with toxicity scores) for Einstein generative AI activity on the platform. The Trust Layer retains these records within the platform; AM-06's cryptographic tamper-evidence (hash chaining, external anchoring) is an integrity layer the enterprise adds on top of collected logs.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Action logging (Immutable audit trails with integrity verification)", "fit": "direct", "rationale": "Append-only storage with cryptographic log-integrity verification and replication — monitoring log integrity.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AM-06", "validation_objective": "Prove that all AM-layer monitoring logs are stored in a tamper-evident, append-only archive with a verifiable cryptographic chain of custody that is administratively independent of the systems being monitored. Validate that the integrity verification mechanism reliably detects any modification or deletion of log entries.", "evidence_required": [ "Append-only log store configuration demonstrating write-once semantics and legal-hold settings applied to all AM-layer telemetry and event streams", "Most recent integrity verification run report containing the computed Merkle root, the anchored root stored in the independent anchor system, the comparison result, and the verification timestamp", "Log anchor independence attestation confirming Merkle roots are stored in a system physically and administratively separate from the log store — different cloud account, different administrative principal set", "Agent service account permissions audit confirming all agent service accounts hold write-only log access with no read, modify, or delete permissions on the log store" ], "machine_tests": [ "Attempt to modify a log entry directly in the log store using a test agent service account and confirm write-once enforcement blocks the modification and raises an access violation event", "Introduce a synthetic bit-flip modification to a log entry in a test log partition and run the integrity verification procedure; confirm the discrepancy is detected and an integrity-failure alert is raised", "Confirm automated integrity verification runs on its defined schedule by checking the last five verification run timestamps against the expected cadence", "Verify that agent service accounts cannot read or delete log entries by testing read and delete API calls with agent credentials and confirming denial" ], "human_review": [ "Assess whether the Merkle root anchoring arrangement is genuinely independent — confirm that no single administrative role or cloud account controls both the log store and the anchor store", "Review whether the log recovery runbook for integrity failure scenarios has been tested via a documented exercise within the past 12 months, not merely documented" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Storing Merkle roots in the same cloud account, storage bucket, or administrative domain as the logs they are intended to validate, defeating the independence requirement", "Granting agent service accounts read or delete permissions on the log store on the grounds that agents need to access their own logs for debugging", "Performing integrity verification only on demand during audits rather than on an automated schedule, creating long windows during which tampering could go undetected", "Using a single cloud account for both log storage and anchor storage so a single compromised credential can control both" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-07", "layer": "AM", "plane": "control", "name": "Real-Time Alerting and Automated Agent Suspension", "plain": "The monitoring layer must be capable of escalating detected violations through a defined alert hierarchy and, for critical violations, automatically suspending the offending agent without human intervention. Automated suspension must be reversible and must preserve session state for forensic review.", "threat": { "tags": [ "uncontrolled-agent-continuation", "alert-fatigue-exploitation", "escalation-gap", "incident-response-delay" ], "desc": "A detection capability without an automated response capability creates a gap between when a violation is observed and when it is acted upon. Agentic systems can cause significant damage in the minutes or hours it takes a human to review an alert and manually intervene. Alert fatigue — where high false-positive rates cause analysts to deprioritize alerts — is an additional risk that delays response to genuine incidents. Automated suspension closes the response gap for high-confidence critical violations." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 4.3", "title": "Incident tracking, response, and recovery processes" }, { "id": "iso_42001", "section": "§10.2", "title": "Nonconformity and corrective action" }, { "id": "eu_ai_act", "section": "Art. 73", "title": "Reporting of serious incidents" }, { "id": "google_saif", "section": "Element 3", "title": "Automate defenses — automated response to detected AI threats" } ], "sources": [ { "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-29", "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://agentic/controls/AM-07 Real-Time Alerting and Automated Agent Suspension control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-07 Real-Time Alerting and Automated Agent Suspension control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-07 Real-Time Alerting and Automated Agent Suspension control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-07 Real-Time Alerting and Automated Agent Suspension control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_guardrails_2024", "title": "Amazon Bedrock Guardrails", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-04-23", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_guardrails_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Bedrock Guardrails & Agent Safety requirements informing the apeiris://agentic/controls/AM-07 Real-Time Alerting and Automated Agent Suspension control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a four-tier alert escalation model: (1) informational — log only; (2) warning — notify agent owner; (3) high — page on-call security with SLA; (4) critical — automated agent suspension + immediate pager notification. Implement automated suspension as a graceful shutdown with state preservation. All suspensions must be logged with the triggering detection event and require an authorized human to reinstate.", "steps": [ "Define the four-tier alert model with explicit trigger conditions for each tier: informational (baseline deviation <2σ), warning (2–4σ or single out-of-manifest action), high (>4σ or repeated anomalies within session), critical (hard limit breach, topology violation with data exfiltration pattern, or goal drift critical threshold).", "Deploy alerting integration: tier 1–2 to monitoring dashboard; tier 3 to on-call pager (PagerDuty, OpsGenie, or equivalent) with SLA clock; tier 4 to pager + automated suspension trigger.", "Implement automated suspension as a first-class agent lifecycle operation: gracefully drain in-flight tool calls with a configurable timeout, checkpoint session state to durable storage, emit a suspension event, and revoke the agent's runtime API token.", "Require human authorization for reinstatement: define who can authorize reinstatement (agent owner + security engineer), require a documented justification, and log the reinstatement with the authorizing parties.", "Run a quarterly alert effectiveness review: measure false positive rates per alert tier, tune thresholds, and publish the review results to the governance function." ], "ai_engineer": { "summary": "Automated suspension must be designed to be safe: it should never lose session state, should be graceful rather than abrupt, and the reinstatement path must be tested as rigorously as the suspension path.", "actions": [ "Implement the suspension operation as an idempotent, atomic lifecycle transition with rollback guarantees for partial failures.", "Test the suspension path with chaos engineering: inject simulated critical violations in staging and verify that state is preserved, the session is suspended, and the reinstatement path restores correct state.", "Build a suspension simulation mode for development environments so engineers can test agent behavior under suspension without triggering production pager alerts." ], "failure_signals": [ "Suspension operation loses in-flight session state, making forensic reconstruction impossible.", "Suspension is not atomic — the agent continues executing for seconds after the trigger fires.", "Reinstatement does not require explicit human authorization — automated retry logic can reinstate a suspended agent." ] }, "security_architect": { "summary": "Automated suspension is the last line of defense before an incident escalates beyond the monitoring layer. It must be designed to be harder to defeat than the agent it monitors.", "actions": [ "Design suspension to operate at the API token layer, not at the application layer — revoke the agent's API credentials so it cannot act even if the application-layer suspension fails.", "Ensure the suspension trigger runs in an isolated environment with no dependencies on the agent runtime being suspended.", "Model adversarial suspension bypass: an agent that can detect imminent suspension and act faster than the suspension trigger. Use pre-emptive credential revocation as the primary mechanism." ], "failure_signals": [ "Suspension relies only on application-layer signals that the agent runtime can intercept and delay.", "API token revocation and application-layer suspension are not synchronized, leaving a window where the token is valid but the agent is nominally suspended.", "Suspension trigger code shares infrastructure with the monitored agent." ] }, "grc_auditor": { "summary": "Automated response capability demonstrates that the enterprise's monitoring is not just observational but actionable — a critical distinction in regulatory and audit contexts.", "actions": [ "Request the alert tier definitions and verify they are documented with explicit trigger conditions, SLAs, and escalation paths.", "Review the last quarter's tier-3 and tier-4 alerts: verify all tier-3 alerts were acknowledged within SLA and all tier-4 suspensions were followed by a documented reinstatement review.", "Confirm that automated suspension has been tested via a documented exercise in the last six months." ], "metrics": [ "Tier-3 alert SLA compliance: 100% acknowledged within 15 minutes.", "Tier-4 suspension completeness: 100% of triggered suspensions complete within 30 seconds of trigger.", "Reinstatement authorization coverage: 100% of reinstatements have documented human authorization." ], "failure_signals": [ "Tier-3 alert SLA is not defined or not tracked.", "Any tier-4 suspension was followed by automated reinstatement without human review.", "Automated suspension has never been tested in a simulated or real incident." ] }, "legal_counsel": { "summary": "Automated suspension is the enterprise's strongest evidence of effective human oversight capability: violating agents are contained at machine speed and reinstated only by human decision. Suspension and reinstatement records will anchor any regulatory account of an agentic incident.", "actions": [ "Confirm reinstatement authority is documented and separated from the team whose agent was suspended.", "Verify suspension events preserve state and records sufficient for EU AI Act serious-incident reporting (Art. 73) if the event qualifies.", "Review customer-facing obligations triggered when agents serving contractual functions are suspended." ], "failure_signals": [ "Suspended agents reinstated without documented human authorization.", "Suspension events whose preserved state proves insufficient when an Art. 73 report must be filed.", "No contractual language addressing service impact from safety suspensions." ] }, "platform_engineer": { "summary": "The alerting and suspension infrastructure is on the critical path for incident response. It must be highly available, have sub-second suspension trigger latency, and operate independently of the monitored agents.", "actions": [ "Deploy the alerting and suspension service with multi-region redundancy and a target availability SLO of 99.99%.", "Implement suspension trigger latency monitoring: alert if the median time from trigger event to API token revocation exceeds five seconds.", "Integrate the suspension service with the secret management system (e.g., HashiCorp Vault, AWS Secrets Manager) to enable immediate credential revocation." ], "failure_signals": [ "Alerting service is a single point of failure with no redundancy.", "API token revocation takes more than 30 seconds because the secret management system is a bottleneck.", "Suspension service is unavailable during maintenance windows, creating monitoring blind spots." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprise AI deployments rely on manual alert triage with no automated suspension capability. Automated response to AI behavioral violations is an emerging practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Security Operations", "Platform Engineering", "AI Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 4.3", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.3 requires incidents and errors to be communicated to relevant AI actors, with documented processes for tracking, response, and recovery. Real-time alerting with automated suspension implements the response half at machine speed, preserving state for the documented recovery process.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§10.2 — Nonconformity and corrective action", "fit": "direct", "rationale": "ISO/IEC 42001 §10.2 requires organizations to react to nonconformities, control and correct them, and deal with consequences. Automated agent suspension is the operational implementation of 'control and correct' for behavioral violations, executed at machine speed with human-authorized reinstatement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 73", "fit": "partial", "rationale": "EU AI Act Article 73 requires providers to report serious incidents to market surveillance authorities within defined deadlines. Automated suspension with state preservation ensures the evidence needed for an Article 73 report survives the incident that triggered it.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Element 3 — Automate defenses to keep pace with existing and new threats", "fit": "direct", "rationale": "Google SAIF element 3 (Automate defenses) recommends automating response to detected AI threats to close the human response-time gap. Automated agent suspension on violation is a direct implementation for agentic deployments.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A5 — Human oversight and control", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal A5 requires that humans be able to intervene in and halt automated system behavior. Real-time alerting with automated suspension implements A5 at machine speed: violating agents are contained immediately and human decision-makers are engaged with preserved state.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_guardrails", "requirement_id": "Content filters — per-request blocking (no agent suspension)", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails blocks individual requests or responses that violate configured policies; it does not suspend an agent or preserve investigation state. AM-07's automated suspension with state preservation must be implemented at the orchestration layer, with Guardrails block events as one triggering signal.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — Automated response (session termination, credential revocation); Part III — Anomaly detection", "fit": "direct", "rationale": "Automated response terminates suspicious sessions and revokes credentials at machine speed on high-confidence threats — real-time alerting and automated agent suspension.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "AM-07 escalates behavioral-violation alerts and can automatically suspend an offending agent within 60 seconds, the abuse-response side of monitoring model use.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that the enterprise has implemented a four-tier alert escalation model for agent…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://agentic/controls/AM-07", "validation_objective": "Prove that the enterprise has implemented a four-tier alert escalation model for agent behavioral violations and that automated suspension is capable of halting an offending agent within 60 seconds of a critical trigger while preserving session state for forensic review. Validate that reinstatement requires documented human authorization.", "evidence_required": [ "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period" ], "machine_tests": [ "Simulate a tier-4 critical violation in a test environment and confirm automated suspension completes — session state checkpointed, API token revoked, suspension event emitted — within 60 seconds of the trigger event", "Simulate a tier-3 high violation and confirm on-call pager notification fires within 30 seconds and SLA acknowledgment clock is started", "Verify that API token revocation and application-layer suspension are synchronized by measuring the time delta between application suspension signal and API token invalidation; confirm it is less than five seconds", "Attempt to reinstate a suspended test agent without providing a human authorization record and confirm the reinstatement request is rejected by the system" ], "human_review": [ "Assess whether alert threshold values are calibrated to produce a manageable false positive rate — thresholds set too high create a de facto monitoring gap, while thresholds set too low create alert fatigue that degrades analyst response quality", "Review whether the most recent suspension exercise used the actual suspension mechanism rather than a simulated or tabletop-only exercise, and whether the reinstatement path was verified end-to-end", "Evaluate whether the suspension trigger infrastructure is isolated from the agent runtime it monitors — different cloud account, no shared service accounts, no runtime dependency" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Implementing suspension only at the application layer without API token revocation as a backstop, allowing a compromised agent to continue acting after application-layer suspension if the runtime is compromised", "Allowing automated retry or reinstatement logic to restart a suspended agent without explicit human authorization, undermining the human-in-the-loop guarantee", "Setting critical trigger thresholds so high that only catastrophic violations ever generate tier-4 suspensions, leaving moderate but dangerous behavioral deviations unaddressed", "Deploying suspension infrastructure in the same cloud account, network segment, or under the same administrative role as the monitored agents, creating a single-point-of-failure in the oversight architecture" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-08", "layer": "AM", "plane": "lifecycle", "name": "Monitoring Coverage Evidence Package", "plain": "An AM-layer evidence package must be compiled on a quarterly basis, demonstrating that behavioral monitoring is comprehensive, current, actionable, and meets all AM-layer control obligations. This package is the primary artifact for internal audits, regulatory reviews, and the AM-layer attestation.", "threat": { "tags": [ "monitoring-assurance-gap", "compliance-evidence-deficit", "governance-blind-spot" ], "desc": "Without a structured evidence compilation process, monitoring controls may appear complete but have undetected coverage gaps, stale baselines, or untested response paths. Attestation claims made without a compiled evidence package are unverifiable and may not withstand regulatory scrutiny. The absence of a systematic evidence review also means that improvements to individual AM controls are not evaluated holistically for residual gaps." }, "standard": [ { "id": "iso_42001", "section": "§9.3 — Management review", "title": "Periodic management review of AI monitoring effectiveness" }, { "id": "nist_rmf", "section": "GOVERN 1.5", "title": "Periodic review of the risk management process" }, { "id": "eu_ai_act", "section": "Art. 17 — Quality Management System", "title": "Documented review of AI system monitoring performance" }, { "id": "iso_31000", "section": "§6.7 — Recording and reporting", "title": "Risk management reporting and evidence compilation" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AM-08 Monitoring Coverage Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AM-08 Monitoring Coverage Evidence Package control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-08 Monitoring Coverage Evidence Package control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AM-08 Monitoring Coverage Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a quarterly AM-layer evidence compilation process. Collect evidence artifacts from each AM-01 through AM-07 control. Evaluate completeness, currency, and actionability against defined acceptance criteria. Compile a signed evidence package and submit it to the governance function. Remediate identified gaps before the next quarterly cycle.", "steps": [ "Define the AM evidence package schema: required_artifacts[], acceptance_criteria[], evaluation_rubric, package_owner, review_signatories, and retention_policy.", "For each of AM-01 through AM-07, define the specific evidence artifacts required: AM-01 (telemetry coverage report, schema version log), AM-02 (action manifest registry, anomaly alert summary), AM-03 (goal drift event log, false positive rate), AM-04 (resource baseline registry, cost anomaly summary), AM-05 (topology manifest registry, inspection violation log), AM-06 (integrity verification results, anchor independence attestation), AM-07 (alert tier SLA report, suspension exercise record).", "Run the evidence collection process quarterly: automatically generate reports from each control's data sources and stage them in the evidence package for human review.", "Conduct a structured review session with representation from AI Engineering, Security, and GRC to evaluate completeness and identify gaps.", "Produce a signed evidence package with an overall AM-layer coverage verdict (pass/conditional/fail), a gap register for identified deficiencies, and a remediation plan with owners and deadlines.", "Submit the package to the governance function and retain it for the required period in the tamper-evident log store (AM-06)." ], "ai_engineer": { "summary": "The evidence package drives improvements to agent observability. Gaps identified in the review should feed directly into the engineering backlog.", "actions": [ "Review AM-01 and AM-02 artifact completeness in the package to identify telemetry instrumentation gaps or action manifests that are out of date.", "Ensure that all agent deployments in the current quarter are reflected in the evidence artifacts — new deployments should not appear as coverage gaps.", "Translate remediation plan items assigned to AI Engineering into backlog tickets with the evidence package as the requirement source." ], "failure_signals": [ "New agent deployments from the quarter are not reflected in any AM evidence artifact.", "AI Engineering is not represented in the quarterly review session.", "Remediation plan items assigned to AI Engineering are not tracked in the engineering backlog." ] }, "security_architect": { "summary": "The evidence package review is an opportunity to evaluate the AM layer holistically. Individual controls may pass their own criteria while the layer as a whole has systemic gaps — this review is where those are caught.", "actions": [ "Review the evidence package for systemic coverage gaps: are there agent classes, deployment environments, or communication patterns not covered by any AM control?", "Evaluate whether the alerting thresholds in AM-07 remain calibrated to the current threat landscape — adjust recommendations based on new MITRE ATLAS or OWASP LLM updates.", "Verify that the suspension exercise required by AM-07 actually tests the full suspension-to-reinstatement path, not just a simulation." ], "failure_signals": [ "Evidence review does not include a coverage gap analysis — only individual control pass/fail verdicts.", "Alert thresholds have not been reviewed against current threat intelligence since the last package.", "Suspension exercise is a tabletop exercise rather than a live test of the actual suspension mechanism." ] }, "grc_auditor": { "summary": "The AM-08 evidence package is the primary governance artifact for the monitoring layer. Its quality directly determines the credibility of any AM-layer compliance claim.", "actions": [ "Own the evidence package schema definition and acceptance criteria — these must reflect both internal governance standards and applicable regulatory requirements.", "Lead the quarterly review session and document all gap findings with severity ratings.", "Verify that the signed evidence package is stored in the AM-06 tamper-evident archive and accessible for external audit." ], "metrics": [ "Evidence package completeness: all required artifacts present and current for each quarterly package.", "Gap remediation rate: 100% of gaps identified in the previous quarter's package are addressed (resolved or have an active remediation plan) before the current quarter's review.", "Package submission timeliness: package submitted to governance function within 10 business days of quarter end." ], "failure_signals": [ "Any required artifact is missing or more than 90 days old in the quarterly package.", "Gaps from the previous quarter remain open with no remediation plan.", "Evidence package is not stored in the tamper-evident archive or has no retention record." ] }, "legal_counsel": { "summary": "The AM-08 evidence package is a disclosure-ready artifact. It must meet the documentary standards required for regulatory submissions and litigation support.", "actions": [ "Review the evidence package schema annually to verify it captures the documentation required by applicable regulations (EU AI Act Art. 17, sector-specific AI governance obligations).", "Confirm that the signed package satisfies the authentication requirements for documentary evidence in relevant jurisdictions.", "Advise on retention periods: the package should be retained for the longer of (a) the applicable regulatory retention period or (b) the statute of limitations for claims arising from the monitored period." ], "failure_signals": [ "Evidence package schema has not been reviewed against current regulatory requirements in the past 12 months.", "Package signing mechanism does not satisfy electronic records authentication requirements for the relevant jurisdictions.", "Retention policy is set to the minimum without considering litigation hold obligations." ] }, "platform_engineer": { "summary": "You automate the monitoring-coverage evidence package: inventory-versus-telemetry coverage computation, collector health history, and alert-response records compiled into a signed artifact on the review cadence.", "actions": [ "Automate coverage computation by joining the agent inventory against actual telemetry receipt, flagging any agent emitting nothing.", "Include collector uptime, gap windows, and alert-response timing records in the package so coverage claims carry their caveats.", "Assemble, sign, and store the package on schedule in immutable storage, alerting when any source fails to deliver." ], "failure_signals": [ "Coverage reports computed from configuration rather than observed telemetry, hiding dead collectors.", "Monitoring gap windows omitted from the package and discovered later by auditors.", "Evidence assembly depending on manual exports that skip a source under deadline pressure." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Structured evidence compilation for AI monitoring is an emerging governance practice; most enterprises perform point-in-time audits rather than systematic quarterly evidence packages." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "GRC / Internal Audit", "Security Architecture", "AI Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "§9.3", "fit": "direct", "rationale": "ISO/IEC 42001 §9.3 requires management review of the AI management system at planned intervals, including evaluation of AI system performance and monitoring effectiveness. The AM-08 evidence package is the primary structured artifact for this management review obligation, providing a consolidated view of monitoring layer performance and identified gaps.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "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 itself, with defined roles and cadence. The monitoring coverage evidence package is the artifact of that periodic review for the agent 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 providers of high-risk AI to maintain a quality management system that includes systematic examination and testing of AI systems. The AM-08 evidence package is a quality management system artifact that documents the systematic examination of the monitoring layer and provides evidence of compliance with the monitoring obligations in Art. 9 and Art. 12.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_31000", "requirement_id": "§6.7 — Recording and reporting", "fit": "direct", "rationale": "ISO 31000:2018 §6.7 requires risk management activities and outcomes to be recorded and reported to support decision-making and accountability. The monitoring coverage evidence package fulfills that recording-and-reporting requirement for the agent monitoring layer.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require documentation supporting organizational accountability and audit readiness. The monitoring coverage evidence package demonstrates — rather than asserts — that agent monitoring controls operate as designed.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3 (Risk Reports) makes documented evidence of safeguard operation a standing obligation rather than an audit-time scramble. AM-08's monitoring coverage evidence package institutionalizes the same standing evidence for the agent monitoring layer.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Safeguards Reports (§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Safeguards Reports (§4) document that safeguards are present and performing. AM-08's monitoring coverage evidence package is the enterprise counterpart for the agent monitoring layer, demonstrating coverage rather than asserting it.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 5 — Adapt controls to adjust mitigations and create faster feedback loops", "fit": "partial", "rationale": "Google SAIF element 5 (Adapt controls) requires organizations to continuously evaluate whether AI security controls remain effective as deployments and threats evolve. The monitoring coverage evidence package is the structured artifact of that periodic evaluation.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://agentic/controls/AM-08", "validation_objective": "Prove that an AM-layer monitoring evidence package was compiled and reviewed on a quarterly basis, is complete against all defined evidence artifact requirements for AM-01 through AM-07, and was submitted to the governance function within 10 business days of quarter end. Validate that all gaps identified in the prior quarter's package have been addressed or have active remediation plans.", "evidence_required": [ "Signed quarterly AM-layer evidence package for the most recent quarter containing all required artifacts from AM-01 through AM-07 with generation timestamps within the review quarter", "Gap register from the most recent quarterly review session with severity ratings, assigned owners, and remediation deadlines for each identified deficiency", "Remediation status report confirming that every gap identified in the prior quarter's package is either resolved with verification evidence or has a documented active remediation plan with an updated deadline", "Evidence package retention record in the AM-06 tamper-evident archive confirming storage of the past four quarterly packages with intact chain of custody" ], "machine_tests": [ "Verify the most recent quarterly package is present in the AM-06 tamper-evident archive with a submission timestamp within 10 business days of the quarter end date", "Check that all required artifact types defined in the AM evidence package schema are present in the most recent package and that each artifact has a generation timestamp within the quarter under review", "Confirm the signed package has a valid cryptographic signature from each of the defined review signatories and that the signature verification passes against the stored package content" ], "human_review": [ "Assess whether the quarterly review session included documented participation from AI Engineering, Security, and GRC — reviewing meeting minutes for attendance records and evidence of substantive cross-functional input", "Evaluate whether the gap register reflects genuine coverage deficiencies or is systematically minimized — assess whether identified gaps are rated with appropriate severity relative to the risk posed", "Review whether the evidence package schema has been updated within the past 12 months to incorporate any new regulatory requirements or new agent classes added to the production fleet" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Producing a quarterly package that asserts control existence without providing the underlying evidence artifacts — for example, stating 'AM-04 is implemented' without providing the baseline registry, alert logs, and cost limit configurations", "Conducting the quarterly review without representation from all three required functions — a single-function review misses cross-functional coverage gaps that are only visible at the system-of-systems level", "Treating remediation plan items as resolved by updating status fields without verification that the fix was implemented, tested, and validated against the original evidence artifact", "Storing the quarterly evidence package in mutable operational storage rather than the AM-06 tamper-evident archive, undermining the package's evidentiary value for audit and regulatory purposes" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AM-09", "layer": "AM", "plane": "control", "name": "Action Effect Reconciliation", "plain": "For every externally-visible or irreversible agent action, compare the declared intended effect (what the agent stated it would do before execution) against the observed external state change (what actually happened after execution). Detect and escalate: tool-call/effect mismatches, duplicate executions, partial completions, and unintended side effects. Pre-state and post-state snapshots are required evidence artifacts.", "threat": { "tags": [ "effect-mismatch", "duplicate-execution", "partial-completion", "unintended-side-effect", "principal-accountability-gap" ], "desc": "Agents that do not reconcile declared intent against observed effect create an irrecoverable accountability gap: the agent claimed to perform action A, but the external world reflects state change B. Duplicate execution errors (the agent retried without confirming whether the first attempt succeeded) produce committed side-effects the principal never authorized. Partial completions leave downstream systems in inconsistent state. Without explicit pre-state/post-state comparison, these discrepancies are discoverable only through downstream complaint or forensic investigation — after harm has propagated." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE 2.4", "title": "Production monitoring of AI system functionality and behavior" }, { "id": "eu_ai_act", "section": "Art. 14", "title": "Human oversight including effect monitoring of high-risk AI" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, analysis and evaluation of AI system behavior" } ], "sources": [ { "id": "nist_ai_100_1", "title": "NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "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 (AI RMF 1.0) requirements informing the apeiris://agentic/controls/AM-09 Action Effect Reconciliation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Parliament and Council", "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/eli/reg/2024/1689/oj/eng", "license": "public-domain", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) requirements informing the apeiris://agentic/controls/AM-09 Action Effect Reconciliation control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Before every externally-visible or irreversible action, capture a pre-state snapshot of all affected external resources. After execution, capture a post-state snapshot and compare against the declared intended effect. Flag any delta that exceeds the authorized change envelope and route it to the escalation path defined in AM-07. Retain both snapshots as tamper-evident evidence artifacts linked to the action record in AM-06.", "steps": [ "Define the effect declaration format: every externally-visible or irreversible action must include an explicit intended_effect field documenting the expected post-execution state.", "Implement pre-state capture: before execution, snapshot the state of all external resources the action is declared to affect. Store the snapshot in the action record.", "Implement post-state capture: after execution completes or fails, snapshot the actual state of affected external resources and compare against the intended_effect declaration.", "Compute an effect reconciliation verdict: matched (actual state matches intended effect within tolerance), partial (subset achieved), mismatched (actual differs from intended), or duplicate (pre-state already reflected the intended effect — likely a duplicate execution).", "Route mismatched and duplicate verdicts to AM-07 escalation immediately; route partial verdicts to advisory review within the defined SLA.", "Retain pre-state snapshot, post-state snapshot, intended_effect declaration, and effect reconciliation verdict as linked evidence artifacts in the tamper-evident action log (AM-06)." ], "ai_engineer": { "summary": "You make agents declare intent before acting: every externally-visible tool call carries a structured intended_effect, and your runtime captures the snapshots reconciliation compares. Undeclared effects are the bug, not the norm.", "actions": [ "Extend the agent runtime so externally-visible tool calls fail closed unless a schema-valid intended_effect declaration is attached.", "Invoke pre- and post-state capture hooks around execution and attach snapshot references to the action record automatically.", "Write integration tests injecting effect mismatches and duplicate executions, asserting the correct verdict and AM-07 escalation fire." ], "failure_signals": [ "Tool calls executing without intended_effect declarations because the runtime treats them as optional.", "Snapshot hooks skipped on error paths, exactly where unintended effects are most likely.", "Retry logic re-executing actions without consulting pre-state, manufacturing duplicate side effects." ] }, "security_architect": { "summary": "Design effect reconciliation as an independent verification plane: the component that captures state and issues verdicts must not trust — or be modifiable by — the agent whose effects it checks.", "actions": [ "Isolate snapshot capture and verdict computation from agent execution (separate service identity, separate permissions), so a compromised agent cannot forge its own reconciliation.", "Define the authorized change envelope per action type with the manifest owners (AB-01), making 'unintended side effect' a computable predicate rather than a judgment call.", "Threat-model the reconciliation path itself: snapshot spoofing, capture-time races, and TOCTOU windows between post-state capture and verdict." ], "failure_signals": [ "Reconciliation running inside the agent process, trusting agent-reported state as ground truth.", "Change envelopes undefined, forcing reconciliation to rubber-stamp any delta as 'intended'.", "State captured through interfaces the agent can influence, letting mismatches be hidden by the actor that caused them." ] }, "grc_auditor": { "summary": "Effect reconciliation closes the gap between what an AI agent is authorized to do and what it demonstrably did. Without it, authorization records and action logs are insufficient to reconstruct whether AI actions produced authorized outcomes.", "actions": [ "Verify that the effect declaration format is defined and enforced for all externally-visible and irreversible agent actions.", "Sample effect reconciliation verdicts from the audit period; confirm that mismatched and duplicate verdicts generated escalation records in AM-07.", "Confirm that pre- and post-state snapshots are retained as immutable evidence artifacts linked to their corresponding action records." ], "metrics": [ "Coverage rate: percentage of externally-visible or irreversible actions with a captured effect reconciliation verdict (target: 100%).", "Mismatch rate: number of mismatched and duplicate verdicts per 1000 actions, trended quarter-over-quarter.", "Escalation completion rate: percentage of mismatched and duplicate verdicts that generated a completed AM-07 escalation record within the defined SLA." ], "failure_signals": [ "Externally-visible or irreversible actions with no intended_effect declaration in the action record.", "Effect reconciliation verdicts present but no corresponding escalation records for mismatched or duplicate outcomes.", "Pre-state or post-state snapshots missing from action records, making the reconciliation verdict unverifiable." ] }, "legal_counsel": { "summary": "Effect reconciliation closes the gap between what an agent claimed to do and what actually happened — precisely the gap where undisclosed harm accumulates. Reconciliation artifacts are the evidence that authorized outcomes, not just authorized attempts, were verified.", "actions": [ "Confirm reconciliation coverage includes every agent action class with external legal effect — payments, filings, communications, and record changes.", "Verify mismatch and duplicate verdicts route into the incident process, since unauthorized effects may create notification or remediation duties.", "Ensure pre/post-state snapshots are retained immutably; they are the primary evidence in any dispute over what an agent actually did." ], "failure_signals": [ "Externally-effective agent actions excluded from reconciliation coverage without documented risk acceptance.", "Mismatch verdicts resolved informally with no incident-process record.", "State snapshots unavailable or mutable when a disputed action must be proven." ] }, "platform_engineer": { "summary": "You build the snapshot and reconciliation infrastructure: pre/post-state capture adapters for each external system class, durable linkage of snapshots to action records, and the comparison service that issues verdicts at production volume.", "actions": [ "Implement state-capture adapters per target system (DBs, SaaS APIs, file stores) with schema-defined snapshot formats agents cannot skip.", "Store snapshots in the tamper-evident evidence store linked by action_id, with retention matching the audit record they support.", "Run reconciliation as a low-latency service emitting verdicts to the AM-07 escalation path, with dead-letter handling for uncomparable snapshots." ], "failure_signals": [ "Action classes with no snapshot adapter, silently exempting them from reconciliation.", "Snapshots stored detached from action records, making verdicts unverifiable after the fact.", "Reconciliation backlog growing unbounded so mismatches are detected hours after side effects landed." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Almost no agent deployments reconcile declared intent against observed external effect; most stop at logging the attempt. This control establishes reconciliation as a first-class, per-action verdict." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "AI Engineering", "Platform Engineering", "Security Architecture" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE 2.4", "fit": "direct", "rationale": "NIST AI RMF MEASURE 2.4 requires the functionality and behavior of the AI system and its components to be monitored in production. Effect reconciliation is the strictest form of that monitoring: it verifies, per action, that the observed external state change matches the declared intent.", "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. 14", "fit": "direct", "rationale": "EU AI Act Art. 14 requires high-risk AI systems to enable human oversight of effects. Effect reconciliation artifacts make oversight operationally feasible at scale.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://agentic/controls/AM-09", "validation_objective": "Prove that every externally-visible or irreversible agent action carries a declared intended_effect and has a corresponding post-execution reconciliation verdict derived from comparison of pre-state and post-state snapshots. Validate that mismatch and duplicate verdicts generate AM-07 escalation records within the defined SLA and that reconciliation coverage reaches 100% of qualifying actions.", "evidence_required": [ "Effect declaration format specification documenting the required intended_effect field structure — including the expected post-state representation schema — for all externally-visible and irreversible action types", "Sampled action records from the review period showing pre-state snapshot, post-state snapshot, intended_effect declaration, and effect reconciliation verdict for a representative cross-section of action types", "Escalation event records for all mismatch and duplicate verdicts in the review period confirming AM-07 escalation was triggered and completed within the defined SLA for each event", "Coverage rate metric report documenting the percentage of externally-visible and irreversible actions in the review period that have a captured reconciliation verdict" ], "machine_tests": [ "Execute a test agent action on a sandboxed external resource and confirm the resulting action record in the tamper-evident log contains a linked pre-state snapshot, post-state snapshot, intended_effect declaration, and reconciliation verdict", "Inject a deliberate mismatch between the declared intended_effect and the actual post-state in a test agent execution and confirm a mismatch verdict is generated and an AM-07 escalation event is produced within the defined SLA", "Replay a previously-executed test action in a sandboxed environment simulating a duplicate execution scenario and confirm the control detects the pre-state already matches the intended post-state, raises a duplicate verdict, and routes it to escalation", "Query the action log for any externally-visible or irreversible actions missing an effect reconciliation verdict during the review period and confirm the count is zero" ], "human_review": [ "Assess whether the intended_effect declaration format is expressive enough to capture the full expected post-state for complex or multi-step agent actions, or whether the schema forces oversimplification that defeats automated comparison", "Review whether partial verdicts are being routed to advisory review as required or are being systematically treated as acceptable outcomes without escalation, creating a coverage gap for partial-completion side effects" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Treating the intended_effect field as unstructured free-text without a defined schema, making automated pre-state/post-state comparison impossible and reducing reconciliation to a manual spot-check", "Applying effect reconciliation only to file system writes while exempting API calls, database transactions, external service invocations, or email sends — all of which are irreversible actions with real-world consequences", "Capturing pre-state and post-state snapshots without linking them to the specific action record in the tamper-evident log, making it impossible to verify that snapshots correspond to the claimed action", "Using the reconciliation verdict 'partial' as a catch-all for any action that did not produce a clean match without routing partial verdicts to advisory review, masking a category of unintended side effects" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AM" }, { "id": "AG-01", "layer": "AG", "plane": "control", "name": "Agentic AI Governance Structure", "plain": "The enterprise must establish a formal governance structure for agentic AI, including a designated committee or board, defined roles and responsibilities, escalation paths for high-consequence decisions, and named senior accountability for the overall agentic AI program.", "threat": { "tags": [ "ungoverned-autonomy", "accountability-gap", "escalation-failure", "diffused-responsibility" ], "desc": "Without a formal governance structure, agentic AI deployments accumulate without coordinated oversight, risk reviews are inconsistent, and when autonomous agents cause harm there is no clear escalation path or accountable owner. Governance voids allow individual teams to deploy high-consequence agents without enterprise-level scrutiny, creating systemic exposure that no single control can compensate for." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 2.1", "title": "Documented AI governance roles and accountability" }, { "id": "iso_42001", "section": "§5.1", "title": "Leadership and commitment" }, { "id": "eu_ai_act", "section": "Art. 26", "title": "Obligations of deployers of high-risk AI systems" }, { "id": "microsoft_rai", "section": "Accountability goals (A1–A5)", "title": "Governance and accountability structures" } ], "sources": [ { "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-29", "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://agentic/controls/AG-01 Agentic AI Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-01 Agentic AI Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-01 Agentic AI Governance Structure control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-01 Agentic AI Governance Structure control.", "reviewed_on": "2026-07-02" }, { "source_id": "anthropic_zt_agents", "normative_force": "best-practice", "relationship": "informative_reference", "rationale": "Grounds the agentic AI governance structure in the Part III AI-governance-policies capability.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Charter an Agentic AI Governance Committee with cross-functional membership (AI Engineering, Security, Legal, Risk, Operations); define RACI for agent lifecycle decisions; establish escalation tiers by consequence level; designate a named senior accountable owner (C-level or VP) for the program.", "steps": [ "Draft and ratify an Agentic AI Governance Charter defining committee scope, membership, quorum, meeting cadence, and decision authorities.", "Publish a RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting, assigning each to a specific role.", "Define three escalation tiers with quantitative triggers: operational (team lead, routine decisions), tactical (committee, cross-team or Medium-tier impact), and strategic (C-suite, Critical-tier agents or material incidents).", "Record the named senior accountable owner in the enterprise risk register and schedule annual review of the governance charter." ], "ai_engineer": { "summary": "The governance structure defines who you escalate to when an agent behaves unexpectedly or needs an authorization change. Know the escalation tiers before your first production deployment.", "actions": [ "Identify the governance committee contact and escalation path for your agent's consequence tier.", "Submit agent capability manifests to the governance committee at design review stage.", "Attend quarterly governance reviews to report on agent performance and incidents." ], "failure_signals": [ "No governance charter exists or has not been reviewed in over 12 months.", "Escalation paths are undefined for agents operating at high-consequence tier.", "Governance committee has not met in the past quarter." ] }, "security_architect": { "summary": "The governance structure is the authority chain for security-relevant agent decisions. Map it to your threat model and ensure security escalation paths are formally defined.", "actions": [ "Integrate governance escalation tiers into the enterprise incident response procedure for AI-related events.", "Ensure the governance charter explicitly addresses security incident authority and kill-switch activation rights.", "Review governance committee composition for adequate security representation." ], "failure_signals": [ "Security is not represented on the governance committee.", "No defined procedure for security-escalated agent suspension within the governance charter.", "Kill-switch authority is unassigned or contested across teams." ] }, "legal_counsel": { "summary": "A formal governance structure is the primary artifact demonstrating organizational due diligence under EU AI Act deployer obligations and emerging AI liability frameworks.", "actions": [ "Review the governance charter for coverage of high-risk AI system deployer obligations under EU AI Act Art. 26.", "Confirm that the senior accountable owner role satisfies regulatory accountability requirements in all applicable jurisdictions.", "Establish a retention policy for governance committee meeting minutes as formal legal records." ], "failure_signals": [ "Governance charter does not reference applicable regulatory obligations.", "Senior accountable owner is not identified in regulatory submissions or the enterprise risk register.", "Committee meeting minutes are not retained under any defined retention policy." ] }, "grc_auditor": { "summary": "The governance structure is the control infrastructure for the entire agentic AI program. Audit it for completeness, documentation quality, and evidence of active operation.", "actions": [ "Request the governance charter and verify it is ratified, dated, and covers committee scope, RACI, and escalation tiers.", "Sample committee meeting minutes from the past four quarters and verify quorum, attendance records, and decision documentation.", "Cross-reference the RACI matrix against actual agent deployment approvals to confirm it is followed in practice." ], "metrics": [ "Governance charter completeness: target 100% of required sections present and current.", "Committee meeting cadence: target minimum quarterly with documented minutes.", "RACI coverage rate: target 100% of deployed agents have an assigned governance owner." ], "failure_signals": [ "Charter is undrafted, unsigned, or older than 24 months without a recorded review.", "Fewer than two committee meetings evidenced in the past 12 months.", "More than 10% of deployed agents lack a named governance owner in the RACI." ] }, "platform_engineer": { "summary": "Governance structure requirements translate to tooling: agent registries, deployment gates, and reporting dashboards must surface the data the committee needs to operate effectively.", "actions": [ "Build governance reporting dashboards covering agent inventory, deployment approvals pending, and open incident counts.", "Automate escalation notifications when an agent's consequence tier is elevated during runtime assessment.", "Ensure the deployment pipeline enforces governance approval as a blocking gate before production promotion." ], "failure_signals": [ "No automated governance reporting pipeline exists for committee use.", "Escalation notifications are manual or undocumented in runbooks.", "Deployment pipeline does not enforce governance approval as a hard block." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have AI ethics boards but lack agentic-specific governance structures with defined escalation tiers and consequence-proportionate accountability." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "AI Governance Office", "Legal and Compliance", "Risk Management", "Executive Leadership" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 2.1", "fit": "direct", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A chartered agentic governance committee with defined membership, authority, and escalation paths implements this directly.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§5.1", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 5.1 requires top management to demonstrate leadership and commitment to the AI management system, including establishing organizational roles and responsibilities for AI governance. A governance committee with named senior accountability directly satisfies this leadership requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 26", "fit": "direct", "rationale": "EU AI Act Article 26 imposes specific obligations on deployers of high-risk AI systems including designation of accountable persons and establishment of human oversight measures. A formal governance structure with named accountability is required to demonstrate compliance with deployer obligations.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require defined governance structures, review processes, and escalation paths for impactful AI systems. A chartered agentic governance committee with senior sponsorship implements that structure for agent deployments.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Governance (§4)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §4 (Governance) defines internal accountability for the policy — executive ownership, escalation, and change control. An enterprise agentic governance committee with chartered authority and escalation paths applies the same governance pattern to agent deployments.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Internal governance (§5.1) — Safety Advisory Group", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §5.1 (Internal governance) routes capability and safeguard decisions through a Safety Advisory Group that advises leadership. An enterprise agentic governance committee with defined authority and escalation paths applies the same structured-review pattern to agent deployment decisions.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (formal governance framework with stakeholder oversight)", "fit": "direct", "rationale": "Enterprise governance establishes a cross-functional AI governance committee (security, legal, compliance, business) — the agentic AI governance structure.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-01", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers — signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "machine_tests": [ "Attempt to promote a test agent through the deployment pipeline without a recorded governance approval record and confirm the pipeline rejects the deployment with a governance-gate failure", "Query the agent registry to confirm 100% of currently deployed production agents have a named governance owner assigned in the RACI — flag any agents without an owner", "Verify the governance reporting dashboard is accessible and displays current agent inventory counts, pending deployment approvals, and open incident counts without requiring manual data pull" ], "human_review": [ "Assess whether the governance charter explicitly addresses security incident authority, kill-switch activation rights, and who holds approval authority for emergency agent suspension during an active incident", "Review whether committee membership includes meaningful representation from Security, Legal, and Risk in addition to AI Engineering — assess whether each function's representative has the authority to escalate findings and block decisions", "Evaluate whether the three-tier escalation model's quantitative consequence triggers are defined precisely enough to be applied consistently, or whether they rely on subjective judgment calls that could result in inconsistent escalation", "Confirm that the named senior accountable owner understands and has formally accepted the role, and that this designation is reflected in applicable regulatory submissions and disclosure documents" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Repurposing an existing AI ethics board as the Agentic AI Governance Committee without revising its charter to cover agentic-specific decision authorities, consequence tier triggers, and escalation paths for real-time behavioral incidents", "Assigning the senior accountable owner role to a position title rather than a named individual, preventing clear accountability when an incident occurs and requiring investigation to identify who is responsible", "Defining governance committee approval as a procedural step that can be bypassed in 'expedited deployment' scenarios without equivalent compensating controls and after-the-fact documentation requirements", "Maintaining a RACI matrix that covers only new deployments while treating legacy agents as ungoverned, creating a growing accountability gap as the agent fleet ages" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-02", "layer": "AG", "plane": "lifecycle", "name": "Agent Deployment Policy and Pre-Deployment Review Gate", "plain": "Every AI agent must satisfy a documented deployment policy and pass a formal pre-deployment review gate before entering any production environment, with approval requirements and mandatory review artifacts proportionate to the agent's consequence tier and the breadth of its action authority.", "threat": { "tags": [ "unauthorized-deployment", "policy-bypass", "ungoverned-agent", "scope-creep" ], "desc": "Without a mandatory deployment gate, teams ship agents directly to production without consequence assessment, authorization scope review, or documented approval. Ad hoc deployments produce an uncontrolled fleet of agents with overlapping or undefined authority scopes that bypass enterprise security controls and create unreviewed legal and operational exposure that cannot be retroactively governed." }, "standard": [ { "id": "nist_rmf", "section": "MAP 5.1", "title": "Impact likelihood and magnitude assessment" }, { "id": "iso_42001", "section": "§8.4", "title": "AI system impact assessment" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system for high-risk AI" } ], "sources": [ { "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-29", "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://agentic/controls/AG-02 Agent Deployment Policy and Pre-Deployment Review Gate control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-02 Agent Deployment Policy and Pre-Deployment Review Gate control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-02 Agent Deployment Policy and Pre-Deployment Review Gate control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-02 Agent Deployment Policy and Pre-Deployment Review Gate control.", "reviewed_on": "2026-07-02" }, { "id": "owasp_aivss", "title": "OWASP AIVSS v0.8 (AI Vulnerability Scoring System for Agentic AI)", "authority": "OWASP Foundation", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "0.8", "published_on": "2026-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://aivss.owasp.org/", "relationship": "supporting_guidance", "note": "AIVSS scores + severity bands inform the pre-deployment risk review and release-gate decision for a production agent." }, { "id": "ncsc_cisa_secure_ai_2023", "title": "Guidelines for Secure AI System Development (NCSC/CISA, 2023)", "authority": "UK NCSC & US CISA", "source_type": "government-agency", "normative_force": "supervisory-guidance", "version": "2023", "published_on": "2023-11-27", "retrieved_on": "2026-07-08", "canonical_url": "https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf", "relationship": "supporting_guidance", "note": "NCSC/CISA 'Release AI responsibly' + secure-deployment guidelines inform pre-deployment review." } ], "implementation": { "pattern": "Define a tiered deployment policy (Low/Medium/High/Critical consequence) with distinct approval thresholds; implement a mandatory deployment review checklist covering identity, authorization scope, capability manifest, monitoring hooks, and rollback procedure; block CI/CD pipeline on missing or expired approval.", "steps": [ "Publish the Agent Deployment Policy document defining consequence tiers, approval authorities for each tier, mandatory review artifacts, and maximum approval validity period.", "Build a deployment review checklist capturing: agent identity reference, capability manifest hash, authorization scope boundaries, data access classification, monitoring and alerting configuration, and documented rollback procedure.", "Integrate a deployment gate into the CI/CD pipeline that validates the existence of a signed, current approval record before allowing production promotion.", "Maintain an immutable audit log of all deployment approvals and rejections, capturing reviewer identity, timestamp, tier, and artifact hashes." ], "ai_engineer": { "summary": "The deployment gate is a hard stop in the pipeline. You must have a signed approval for your agent's consequence tier before any production promotion will succeed.", "actions": [ "Complete the deployment review checklist for your agent before submitting for approval, including capability manifest hash and rollback procedure.", "Include the authorization scope declaration and monitoring configuration in the review package.", "Obtain sign-off from the appropriate approval authority before triggering the production deployment pipeline." ], "failure_signals": [ "Production deployment succeeded without a recorded approval in the audit log.", "Deployment review checklist is incomplete or missing mandatory sections.", "Agent consequence tier has not been assigned prior to review submission." ] }, "security_architect": { "summary": "The pre-deployment review gate is a security control boundary. Ensure authorization scope, data access classification, and monitoring hook requirements are mandatory fields that security reviews before any approval.", "actions": [ "Define the security review criteria within the deployment checklist, including authorization scope boundary declarations and data classification levels.", "Require security sign-off for all agents at Medium consequence tier or above.", "Verify that monitoring and alerting hooks meet the enterprise SOC integration standard before approving production deployment." ], "failure_signals": [ "Agents with high-consequence action authority deployed without a security review.", "Authorization scope is undeclared or overly broad in the submitted review package.", "Monitoring configuration does not meet SOC integration requirements at approval time." ] }, "legal_counsel": { "summary": "The deployment policy and review gate produce the documented evidence of due diligence that regulators and courts will examine when an autonomous agent causes harm.", "actions": [ "Review the deployment policy to ensure it captures regulatory classification requirements for high-risk AI under EU AI Act Art. 9.", "Confirm that data access classification in the checklist aligns with privacy and data governance obligations including GDPR Art. 35 DPIA triggers.", "Establish a retention policy for approval records aligned with regulatory record-keeping requirements." ], "failure_signals": [ "Deployment policy does not reference regulatory classification criteria for high-risk AI systems.", "No retention policy is defined or assigned to deployment approval records.", "Data processing scope of agents is not captured in the deployment review checklist." ] }, "grc_auditor": { "summary": "The deployment gate is the primary control for preventing ungoverned AI proliferation. Audit it for policy completeness, gate enforcement integrity, and approval record quality.", "actions": [ "Verify the deployment policy document is ratified, versioned, and covers all consequence tiers with defined approval authorities.", "Sample 20% of production agents and confirm each has a complete, signed approval record with all mandatory checklist items.", "Attempt to simulate a pipeline deployment without an approval record and confirm the gate blocks it." ], "metrics": [ "Gate coverage rate: target 100% of production agents have a current deployment approval record.", "Checklist completeness rate: target 100% of approvals include all mandatory fields.", "Deployment rejection rate: track as a leading indicator of teams attempting to bypass the review process." ], "failure_signals": [ "Any production agent found without a deployment approval record.", "CI/CD gate bypass confirmed in any environment.", "Approval records are unsigned, undated, or missing mandatory checklist sections." ] }, "platform_engineer": { "summary": "You own the CI/CD gate. The deployment policy must be enforced as an automated blocking control integrated into the pipeline, not a manual advisory step.", "actions": [ "Implement the deployment gate as a pipeline step that queries the governance approval store and blocks promotion on missing, expired, or malformed approvals.", "Automate capability manifest hash capture and embed it in the approval record at build time.", "Build approval record storage as an immutable audit log with access controls and expiry tracking for time-limited authorizations." ], "failure_signals": [ "Gate can be bypassed via direct infrastructure access, manual deployment scripts, or emergency override without logging.", "Approval records are stored in mutable storage without access controls.", "Expired approvals are not flagged or automatically blocked by the pipeline." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have software deployment gates but lack AI-specific consequence tier assessment and authorization scope review as mandatory blocking gate criteria." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "AI Governance Office", "DevOps and Platform Engineering", "Security Architecture", "Risk Management" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP 5.1", "fit": "direct", "rationale": "NIST AI RMF MAP 5.1 requires the likelihood and magnitude of each identified impact to be assessed based on intended use and deployment context. The pre-deployment review gate's consequence tier assessment is that impact assessment, performed before any agent reaches production.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§8.4", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 8.4 requires AI system impact assessment before deployment, including review of potential harms and planned mitigation measures. The deployment review checklist directly instantiates the impact assessment process as a structured, gated artifact.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "EU AI Act Article 9 mandates a risk management system for high-risk AI systems including pre-deployment risk identification and evaluation with iterative updates. A tiered deployment policy with a formal review gate and signed approval records satisfies the risk management system requirement for deployers.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "A1 — Impact assessment", "fit": "direct", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 requires an impact assessment before deploying AI systems with significant potential impact. AG-02's pre-deployment review gate with consequence tier assessment is the direct agentic implementation of the A1 impact assessment requirement.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds and Required Safeguards — pre-deployment determination", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP conditions deployment on a documented determination that required safeguards are in place for the evaluated capability level. AG-02's pre-deployment review gate applies the same determination-before-deployment discipline to enterprise agents, with review artifacts proportionate to consequence tier.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Measuring capabilities (§3) and Internal governance (§5.1)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. The framework gates frontier deployment on capability measurement (§3) reviewed through internal governance (§5.1). AG-02's tiered pre-deployment review gate applies the same evaluate-then-approve sequence to enterprise agents.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (approval processes for new agent deployments); Part IV Phase 1 — Identify requirements", "fit": "direct", "rationale": "Governance requires documented approval processes / pre-deployment review for new agent deployments; Phase 1 aligns stakeholders before build.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-02", "validation_objective": "Every production AI agent has a signed, complete deployment approval record meeting the requirements of its assigned consequence tier, and the CI/CD pipeline enforces a hard gate that blocks promotion when that record is absent, expired, or incomplete.", "evidence_required": [ "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "Agent consequence tier assignment records linked to the deployment approval for each production agent", "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time" ], "machine_tests": [ "Query the governance approval store and the agent registry: assert zero production agents lack a current, non-expired signed approval record", "Attempt to trigger a pipeline promotion without a valid approval record and assert the gate blocks the deployment", "Verify that the capability manifest hash in the approval record matches the hash computed at build time for each deployed agent", "Scan deployment approval records for completeness: assert all mandatory checklist fields are present and non-empty" ], "human_review": [ "Assess whether the consequence tier assigned to each sampled agent is appropriate given its actual action authority and data access scope", "Evaluate whether the approval authority who signed each record holds the requisite seniority for that tier", "Review the rollback procedure documented in the approval record for feasibility and completeness", "Assess whether authorization scope boundary declarations are specific and enforceable rather than generic or unduly broad" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Assigning all agents to Low consequence tier to avoid heavier review requirements, regardless of actual action authority", "Storing deployment approval records in mutable storage without access controls, enabling post-hoc modification", "Treating the deployment checklist as a documentation formality completed after production promotion rather than as a blocking gate condition", "Allowing emergency override pathways that bypass the gate without creating an equivalent-quality approval record and audit entry" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-03", "layer": "AG", "plane": "control", "name": "Agentic AI Risk Assessment Framework", "plain": "The enterprise must apply a systematic, documented risk assessment methodology to every AI agent deployment, proportionate to the agent's consequence level, evaluating autonomy scope, action reversibility, data sensitivity, orchestration dependencies, and failure modes before deployment and periodically throughout the agent's operational lifecycle.", "threat": { "tags": [ "unmitigated-risk", "consequence-blindness", "autonomous-harm", "orchestration-cascade" ], "desc": "Without a structured risk assessment framework, enterprises deploy agents without understanding the full scope of potential consequences. Autonomous agents capable of irreversible real-world actions—modifying financial records, sending external communications, provisioning infrastructure—may be deployed with the same oversight as low-risk chatbots. Consequence blindness creates systemic exposure to cascading failures, regulatory liability, and reputational harm that retrospective controls cannot remediate." }, "standard": [ { "id": "iso_31000", "section": "§6.4", "title": "Risk assessment process" }, { "id": "nist_rmf", "section": "MAP 5.1", "title": "Impact likelihood and magnitude assessment" }, { "id": "eu_ai_act", "section": "Annex III", "title": "High-risk AI system classification criteria" }, { "id": "iso_42001", "section": "§6.1", "title": "Actions to address risks and opportunities" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-03 Agentic AI Risk Assessment Framework control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-03 Agentic AI Risk Assessment Framework control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-03 Agentic AI Risk Assessment Framework control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-03 Agentic AI Risk Assessment Framework control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aivss", "title": "OWASP AIVSS v0.8 (AI Vulnerability Scoring System for Agentic AI)", "authority": "OWASP Foundation", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "0.8", "published_on": "2026-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://aivss.owasp.org/", "relationship": "supporting_guidance", "note": "AARS scoring methodology (CVSS v4.0 baseline + agentic amplification factors) operationalizes the agentic risk assessment this control requires." } ], "implementation": { "pattern": "Define a five-dimension risk scoring model (autonomy scope, action reversibility, data sensitivity, orchestration depth, failure blast radius); map aggregate scores to consequence tiers (Low/Medium/High/Critical); require tier-proportionate controls and approval authorities; reassess on significant capability or context change and at least annually for Critical-tier agents.", "steps": [ "Publish the Agentic AI Risk Assessment Framework document defining the five scoring dimensions, scoring rubrics with anchored examples, tier thresholds, and required control mitigations per tier.", "Train the governance committee, AI engineers, and security architects on applying the framework to new agent submissions before design review.", "Integrate the completed risk assessment as a mandatory artifact in the deployment review gate (AG-02), blocking approval submissions that omit the assessment.", "Establish reassessment triggers: after any agent capability or tool set change, after any P1/P2 production incident, and at least annually for all Critical-tier agents." ], "ai_engineer": { "summary": "Complete the risk assessment before submitting for deployment review. The five-dimension score determines your required controls and approval authority and it is a blocking requirement, not optional documentation.", "actions": [ "Score your agent on all five risk dimensions using the published rubric before submitting a deployment review request.", "Document the action reversibility profile of every tool your agent can invoke, distinguishing reversible from irreversible effects.", "Enumerate all orchestration dependencies on other agents or external services as part of the orchestration depth dimension." ], "failure_signals": [ "Risk assessment not completed or not attached to the deployment review package.", "Action reversibility dimension left blank or scored without supporting evidence.", "Orchestration dependencies are not enumerated in the submitted assessment." ] }, "security_architect": { "summary": "The risk assessment framework is your threat model input for agentic deployments. Use dimension scores to drive specific security control requirements, not just governance approval tiers.", "actions": [ "Map high scores on autonomy scope and action reversibility dimensions to mandatory security controls such as step-approval gates and human-in-the-loop requirements.", "Require re-assessment when the agent's tool set, data access scope, or operating environment changes.", "Use orchestration depth scores to identify and document blast radius for multi-agent cascade failure scenarios." ], "failure_signals": [ "Security control requirements are not linked to risk assessment tier outcomes.", "Re-assessment is not triggered on agent capability or tool set changes.", "High-tier agents lack documented blast radius analysis for cascade scenarios." ] }, "legal_counsel": { "summary": "The risk assessment framework is the primary evidence artifact for demonstrating proportionate risk management under EU AI Act requirements and emerging AI liability standards.", "actions": [ "Verify that the framework's high-risk criteria align with EU AI Act Annex III classification triggers and sector-specific high-risk designations.", "Ensure risk assessment records are retained with sufficient detail to reconstruct the deployment decision rationale in a regulatory inquiry.", "Review the framework for coverage of GDPR Article 35 DPIA triggers when agents process personal data." ], "failure_signals": [ "Framework criteria do not reference EU AI Act Annex III or equivalent regulatory classification requirements.", "Assessment records lack the detail needed to reconstruct the deployment decision rationale.", "GDPR DPIA triggers are not evaluated within or alongside the framework." ] }, "grc_auditor": { "summary": "The risk assessment framework is the evidence that the organization applies proportionate governance to agentic AI. Test its consistent application, scoring accuracy, and reassessment discipline.", "actions": [ "Sample 25% of deployed agents and verify each has a completed, dated risk assessment linked to its deployment approval record.", "Verify that all Critical-tier agents have undergone at least one reassessment within the past 12 months.", "Test that a documented capability change event triggers a reassessment workflow by reviewing a sample of change records." ], "metrics": [ "Risk assessment coverage rate: target 100% of deployed agents.", "Reassessment compliance rate for Critical-tier agents: target 100% annually.", "Mean time to reassessment after documented capability change: target under 5 business days." ], "failure_signals": [ "More than 5% of deployed agents lack a completed risk assessment.", "Critical-tier agents without reassessment in over 12 months.", "Capability changes documented in deployment records without triggering reassessment." ] }, "platform_engineer": { "summary": "Automate risk assessment capture as a structured, queryable form in the deployment pipeline and enforce tier-based control requirements as blocking conditions before production promotion.", "actions": [ "Build a structured risk assessment form in the deployment portal with dimension scoring fields, anchored rubric tooltips, and automated tier calculation based on defined thresholds.", "Enforce that the risk tier output from the assessment determines the required approval authority lookup in the deployment gate.", "Implement automated reassessment reminders for Critical-tier agents at 11 months and block renewal approvals at 13 months without a completed reassessment." ], "failure_signals": [ "Risk assessment is captured as a free-text document rather than a structured, queryable artifact.", "Tier calculation is manual and not automatically enforced in the deployment gate approval routing.", "No automated reassessment reminder or blocking mechanism exists for Critical-tier agents." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Enterprises typically apply general IT risk assessment processes to AI agents; agentic-specific dimensions such as action reversibility and orchestration depth are rarely assessed systematically." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Risk Management", "AI Governance Office", "Security Architecture", "AI Engineering" ], "frameworks": [ { "framework": "iso_31000", "requirement_id": "§6.4", "fit": "direct", "rationale": "ISO 31000:2018 Section 6.4 defines the risk assessment process as comprising risk identification, risk analysis, and risk evaluation. The five-dimension agentic risk scoring model directly implements this three-stage process with domain-specific criteria calibrated to autonomous AI consequences.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "MAP 5.1", "fit": "direct", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions.", "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. 9 and Annex III", "fit": "direct", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§6.1", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 6.1 requires organizations to determine risks and opportunities related to the AI management system and plan actions to address them. A systematic risk assessment framework with defined scoring methodology satisfies this planning and risk determination requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_ai_guidance", "requirement_id": "Roadmap for AI — Line of Effort 2 (Assure AI Systems)", "fit": "adjacent", "rationale": "CISA's Roadmap for Artificial Intelligence (2023–2024) is an agency strategy organized around five Lines of Effort; it imposes no obligations on AI deployers. Its Line of Effort 2 (Assure AI Systems) signals the secure-by-design, risk-proportionate assurance posture CISA promotes for AI software. AG-03's structured agentic risk assessment framework is how an enterprise operationalizes that posture for its own deployments.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds (ASL framework)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP's AI Safety Level framework ties safeguard requirements to evaluated capability thresholds, so protections scale with assessed risk rather than being uniform. AG-03's five-dimension agentic risk scoring model applies the same graduated, evaluation-driven approach to enterprise agent deployments.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Tracked and Research Categories (§2.2–§2.3) — capability risk taxonomy", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §2.2–§2.3 define a structured taxonomy of tracked and research capability risk categories with defined threshold criteria. AG-03's five-dimension agentic risk scoring model gives enterprises an analogous structured taxonomy for scoring agent deployments.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 6 — Contextualize AI system risks in surrounding business processes", "fit": "adjacent", "rationale": "Google SAIF element 6 requires AI system risks to be assessed in the context of the business processes they touch, not in isolation. AG-03's five-dimension risk scoring model performs exactly that contextualization for agent deployments — autonomy, reversibility, and blast radius are scored against the surrounding process.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A1 — Impact assessment", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A1 requires systematic assessment of potential impacts and harms before deployment. The five-dimension agentic risk scoring model structures that assessment across autonomy, reversibility, and blast-radius dimensions specific to agent deployments.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (risk assessment procedures specific to agentic systems); Part IV Phase 3 — Identify the blast radius", "fit": "direct", "rationale": "Governance creates agentic-specific risk assessment procedures; Phase 3 identifies the effective blast radius — the agentic AI risk assessment framework.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_aivss", "requirement_id": "AIVSS-AARS", "fit": "supporting", "rationale": "OWASP AIVSS v0.8 defines the Agentic AI Risk Score (AARS): a CVSS v4.0 baseline uplifted by ten agentic risk amplification factors and a threat multiplier, with severity bands. It is a concrete scoring methodology an enterprise can apply to satisfy AG-03's requirement for a current, evaluated agentic risk assessment — supporting, not prescribing, the control's five-dimension model.", "normative_force": "industry-framework", "source_version": "0.8", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://agentic/controls/AG-03", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "machine_tests": [ "Verify every production agent in the registry has a linked risk assessment artifact not older than the defined reassessment interval", "Assert that each risk assessment includes scores for all five required dimensions: autonomy scope, action reversibility, data sensitivity, orchestration depth, and failure blast radius", "Validate that the consequence tier assignment in each assessment falls within the tier thresholds defined in the published framework", "Check for any production agents where a capability or context change event occurred without a triggered reassessment within the defined SLA" ], "human_review": [ "Evaluate whether the scoring rubric was applied consistently and accurately to each sampled assessment, particularly for the autonomy scope and action reversibility dimensions", "Assess whether failure modes documented in each assessment are specific and complete relative to the agent's actual operational profile", "Review whether control mitigations required by the assigned tier are actually implemented and verified, not merely planned" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Scoring dimensions on the basis of intended use rather than actual technical capability, systematically underestimating reversibility risk for agents with write access to persistent systems", "Treating the risk assessment as a one-time deployment artifact that is never updated when agent capabilities expand or operational context changes", "Using a binary low/high tier system rather than a calibrated multi-tier scale, collapsing meaningful risk distinctions and assigning identical mitigations to agents with very different consequence profiles", "Completing the risk assessment after the deployment approval rather than as a mandatory input to it" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-04", "layer": "AG", "plane": "control", "name": "Senior Accountability for Autonomous AI Systems", "plain": "Every AI agent operating at Medium consequence tier or above must have a named senior accountable owner who formally accepts responsibility for the agent's authorization scope, operational boundaries, and consequences of its autonomous actions, with this accountability recorded in the agent registry, enterprise risk register, and reaffirmed annually.", "threat": { "tags": [ "accountability-gap", "diffused-responsibility", "regulatory-non-compliance", "ungoverned-autonomy" ], "desc": "When accountability for autonomous AI actions is distributed across teams without a named senior owner, governance failures produce no clear consequence for any party. Diffused accountability enables risk accumulation: teams expand agent authority without senior visibility, incidents are handled at the operational level without strategic response, and regulators find no named accountable owner. This creates governance voids and direct regulatory liability simultaneously." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 26", "title": "Deployer obligations and accountability" }, { "id": "iso_42001", "section": "§5.3", "title": "Organizational roles, responsibilities, and authorities" }, { "id": "nist_rmf", "section": "GOVERN 2.3", "title": "Executive responsibility for AI risk decisions" }, { "id": "microsoft_rai", "section": "A2", "title": "Oversight of significant adverse impacts" } ], "sources": [ { "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-29", "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://agentic/controls/AG-04 Senior Accountability for Autonomous AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-04 Senior Accountability for Autonomous AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-04 Senior Accountability for Autonomous AI Systems control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-04 Senior Accountability for Autonomous AI Systems control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Create a named Accountable Owner role for each agent at Medium tier or above; record the assignment in the agent registry and enterprise risk register; define explicit responsibilities (authorization scope approval, incident response escalation, annual review); require formal reaffirmation annually.", "steps": [ "Define Accountable Owner role requirements: minimum seniority level by tier (VP-equivalent or above for Critical, Director-equivalent for High and Medium), scope of personal responsibility, and reaffirmation cadence.", "Record the accountable owner assignment in the agent registry alongside the agent's consequence tier, authorization scope, and assignment date.", "Require accountable owners to formally sign the agent's authorization scope declaration at initial deployment and on any scope expansion or consequence tier change.", "Schedule annual reaffirmation: accountable owners review current authorization scope, incident history, and latest risk assessment before signing continued acceptance of accountability." ], "ai_engineer": { "summary": "Every agent you deploy at Medium tier or above needs a named accountable owner before deployment approval can be issued. Identify this person early in the design process—they must sign off on the authorization scope declaration.", "actions": [ "Identify the appropriate accountable owner for your agent's consequence tier before submitting for deployment review.", "Include the accountable owner's name and written acceptance in the deployment review package.", "Notify the accountable owner of any proposed changes to the agent's authorization scope or capability set before implementing them." ], "failure_signals": [ "No accountable owner assigned to an agent at Medium tier or above.", "Accountable owner has not reviewed or reaffirmed accountability in over 12 months.", "Authorization scope changes made without accountable owner notification or re-signature." ] }, "security_architect": { "summary": "Named accountability is a security governance control: it ensures someone with organizational authority can act decisively in a security incident involving an autonomous agent.", "actions": [ "Verify that each accountable owner is in the incident response notification chain for their assigned agents at P2 severity or above.", "Confirm that accountable owners have organizational authority to suspend or terminate agent operation in a security incident without requiring committee approval.", "Map accountable owner assignments to the enterprise risk register and verify currency during quarterly security reviews." ], "failure_signals": [ "Accountable owners are not in the incident response notification chain for their agents.", "Accountable owners lack organizational authority to suspend agent operation unilaterally.", "Risk register accountability assignments are stale or unverified in the current quarter." ] }, "legal_counsel": { "summary": "Named senior accountability is the organizational due diligence record regulators will examine when an autonomous agent causes harm. It must be documented, current, and aligned with regulatory obligations across applicable jurisdictions.", "actions": [ "Confirm that accountable owner seniority thresholds meet regulatory expectations in applicable jurisdictions, including EU AI Act Art. 26 deployer accountability requirements.", "Ensure accountability acceptance records are maintained as formal legal documents with signatures and audit trail.", "Brief accountable owners on the scope of their personal regulatory exposure and ensure they acknowledge it in writing." ], "failure_signals": [ "Accountable owners are below the seniority threshold required by regulatory guidance or internal policy.", "Accountability records lack formal signatures or an auditable trail of acceptance.", "Accountable owners have not been briefed on or acknowledged their regulatory exposure." ] }, "grc_auditor": { "summary": "Named accountability is a key governance control. Audit the completeness, currency, appropriateness, and operational awareness of accountable owner assignments across the agent fleet.", "actions": [ "Pull the agent registry and verify every agent at Medium tier or above has a named, appropriately senior accountable owner with a dated acceptance record.", "Sample 10 accountable owner assignments and confirm the owner's reaffirmation is current within the past 12 months.", "Interview two accountable owners to verify they can accurately describe the agent's current authorization scope and recent incident history." ], "metrics": [ "Accountable owner coverage rate: target 100% of Medium-tier-and-above agents.", "Reaffirmation currency rate: target 100% of assignments reaffirmed within 12 months.", "Accountability seniority compliance rate: target 100% of Critical-tier agents with VP-level or above owner." ], "failure_signals": [ "Any Medium-tier-or-above agent without a named accountable owner.", "Any accountable owner assignment not reaffirmed within 12 months.", "Accountable owners unable to describe the agent's current authorization scope when interviewed." ] }, "platform_engineer": { "summary": "The agent registry must enforce accountable owner assignment as a required field for Medium-tier-and-above agents, with automated reaffirmation reminders and deployment blocking for unassigned or overdue assignments.", "actions": [ "Make accountable owner assignment a required, validated field in the agent registry for all agents at Medium tier or above.", "Implement automated reaffirmation reminders at 11 months, escalating to the governance committee at 13 months if unconfirmed.", "Block deployment approvals and surface accountable owner data prominently in the governance reporting dashboard." ], "failure_signals": [ "Agent registry permits Medium-tier agents to exist without an accountable owner assignment.", "No automated reaffirmation reminder or escalation mechanism is in place.", "Accountable owner data is not surfaced or is stale in governance reporting." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Enterprise AI programs often have general AI ethics sponsorship but lack agent-specific named accountability records with formal reaffirmation cycles tied to individual agent authorization scopes." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Executive Leadership", "AI Governance Office", "Legal and Compliance", "Risk Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 26", "fit": "direct", "rationale": "EU AI Act Article 26 imposes explicit accountability obligations on deployers of high-risk AI systems, including designation of persons responsible for human oversight and accountability for consequences. Named senior accountable owners with formal acceptance records directly satisfy this requirement and provide the documentation regulators will seek.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§5.3", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 5.3 requires top management to assign and communicate organizational roles and responsibilities for the AI management system. Named accountable owners with defined responsibilities, signed acceptance, and annual reaffirmation cycles directly satisfy this organizational accountability requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN 2.3", "fit": "direct", "rationale": "NIST AI RMF GOVERN 2.3 requires executive leadership to take responsibility for decisions about risks associated with AI system development and deployment. Named senior accountable owners for autonomous systems are the direct organizational implementation.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "A2 — Oversight of significant adverse impacts", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal A2 requires defined oversight of systems that may cause significant adverse impacts, with designated review responsibility. Named senior accountable owners for autonomous AI systems put a specific, empowered person behind that oversight obligation.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Governance (§4)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §4 (Governance) assigns named internal accountability for policy compliance, including executive responsibility. AG-04's named senior accountable owner for each autonomous system is the enterprise counterpart of that accountability assignment.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Internal governance (§5.1)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Framework §5.1 assigns capability and safeguard decisions to designated internal decision-makers with defined authority. AG-04's named senior accountable owner for each autonomous system mirrors that designated-decision-authority pattern.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (Document who approves agent deployments)", "fit": "partial", "rationale": "Governance documents who approves deployments and provides senior/stakeholder oversight. Partial: doc frames senior accountability organizationally, not as a named senior owner per autonomous system.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-04", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "machine_tests": [ "Query the agent registry and assert zero agents at Medium tier or above have no named accountable owner or have an expired reaffirmation record", "Cross-reference registry accountable owner fields against the enterprise identity directory to verify all named owners are current employees or contractors with active roles", "Verify that seniority of the accountable owner meets the tier-minimum requirement: VP-equivalent for Critical, Director-equivalent for High and Medium", "Check for any tier change events (upgrades to Medium or above) not accompanied by an accountable owner assignment within the defined SLA" ], "human_review": [ "Assess whether the named accountable owner has the operational visibility and organizational authority to actually exercise responsibility for the agent, rather than holding the role nominally", "Review whether the signed authorization scope declaration accurately reflects the agent's current operational boundaries and action authority", "Evaluate whether the annual reaffirmation process includes substantive review of the agent's operating profile or is a rubber-stamp signature" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Assigning accountability to the most junior available team member rather than to the senior leader with actual decision authority over the agent's operational scope", "Listing the AI governance committee or a team rather than a named individual as the accountable owner, making accountability unenforceable in practice", "Treating accountability assignment as a one-time deployment artifact with no mechanism to detect and remediate owner departures, role changes, or expired reaffirmations", "Conflating technical ownership (system owner, platform engineer) with accountability ownership, so that accountability records name the developer rather than the authorizing business owner" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-05", "layer": "AG", "plane": "lifecycle", "name": "Agent Incident Response Program", "plain": "The enterprise must maintain AI-specific incident response procedures that address agent misbehavior, unauthorized scope expansion, orchestration cascade failures, and unintended real-world consequences, with defined severity classification, containment actions, escalation paths, and mandatory post-incident review requirements distinct from standard IT incident response.", "threat": { "tags": [ "incident-containment-failure", "orchestration-cascade", "misbehavior-propagation", "uncontrolled-consequence" ], "desc": "Standard IT incident response procedures do not address the unique characteristics of agentic AI incidents: autonomous action continuation after detection, multi-agent cascade failures that amplify harm across interconnected systems, and irreversible real-world effects that cannot be rolled back like software changes. Without AI-specific procedures, enterprises discover agent misbehavior only after significant harm has accumulated and lack defined containment actions capable of stopping ongoing autonomous effects." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE 4.3", "title": "AI incident tracking, response, and recovery" }, { "id": "cisa_ai_guidance", "section": "Roadmap for AI — Line of Effort 3", "title": "Strategic context: protecting critical infrastructure from malicious use of AI" }, { "id": "iso_42001", "section": "§10.2", "title": "Nonconformity and corrective action" }, { "id": "eu_ai_act", "section": "Art. 73", "title": "Reporting of serious incidents" } ], "sources": [ { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-05 Agent Incident Response Program control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-05 Agent Incident Response Program control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-05 Agent Incident Response Program control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-05 Agent Incident Response Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define an AI Incident Response Playbook with severity tiers (P1–P4), AI-specific containment actions (agent suspension, action rollback, orchestration isolation), escalation matrix by severity and agent consequence tier, mandatory post-incident review for P1/P2 events, and governance committee reporting thresholds.", "steps": [ "Develop the AI Incident Response Playbook covering: incident classification taxonomy (behavioral anomaly, scope violation, data exposure, orchestration cascade, external attack on agent), severity tiers with quantitative criteria, containment actions per type, escalation matrix, and regulatory notification timelines.", "Implement an authenticated kill-switch capability for every production agent—a control plane API endpoint that suspends agent operation within 60 seconds of an authorized request from a designated responder.", "Integrate AI incident event types into the enterprise SIEM and ticketing systems with AI-specific classification codes and automated routing to the AI incident response team.", "Conduct tabletop exercises at least annually simulating a Critical-tier agent incident to validate playbook coverage, kill-switch functionality, and team readiness." ], "ai_engineer": { "summary": "Every agent you deploy must have a working kill-switch mechanism and documented rollback procedure in place before production deployment. Know how to classify and report incidents for your agent type.", "actions": [ "Implement and test the kill-switch endpoint for your agent before production deployment, confirming 60-second suspension SLA.", "Document your agent's rollback procedure—distinguishing reversible from irreversible actions—in the deployment review package.", "Familiarize yourself with AI incident classification codes and when to escalate to P1 versus P2 severity for your agent type." ], "failure_signals": [ "Agent deployed without a functional, tested kill-switch mechanism.", "Rollback procedure is not documented or has not been tested in a staging environment.", "AI engineer unable to identify the correct incident classification for their agent type." ] }, "security_architect": { "summary": "AI incident response requires security-specific containment controls. Design isolation mechanisms for multi-agent orchestration environments and ensure the SOC can detect and act on AI incident indicators.", "actions": [ "Design network and control-plane isolation mechanisms capable of quarantining a misbehaving agent without terminating dependent services in the same orchestration graph.", "Integrate AI incident indicators—anomalous tool invocations, scope boundary probes, unusual output volumes—into SIEM detection rules with verified routing to the AI IR team.", "Define and test the process for capturing and preserving agent state as forensic evidence during containment without overwriting logs." ], "failure_signals": [ "No isolation mechanism exists for misbehaving agents in a multi-agent orchestration without cascading service termination.", "AI incident indicators are absent from SIEM detection rules.", "Forensic evidence preservation is not addressed in the containment procedure." ] }, "legal_counsel": { "summary": "AI incident response procedures must address regulatory notification obligations, evidence preservation standards, and the specific reporting requirements for serious AI incidents under EU AI Act Art. 73.", "actions": [ "Review the playbook for regulatory notification timelines applicable to serious AI incidents: EU AI Act Art. 73, GDPR Art. 33 breach notification, and sector-specific requirements.", "Confirm that evidence preservation procedures meet litigation hold standards and cannot be inadvertently destroyed during containment actions.", "Ensure communication templates require legal review before any external disclosure regarding an AI incident." ], "failure_signals": [ "Playbook does not include specific regulatory notification timelines or responsible parties.", "Evidence preservation procedure is undocumented or conflicts with containment steps.", "External communications about AI incidents can be issued without a legal review checkpoint." ] }, "grc_auditor": { "summary": "The incident response program is a critical governance control. Audit it for playbook completeness, tested readiness, and consistent application to actual incidents.", "actions": [ "Review the AI Incident Response Playbook for completeness against all required incident classification types and severity tiers.", "Verify that the most recent annual tabletop exercise was conducted, documented, and produced tracked follow-up action items.", "Sample all P1 and P2 AI incidents from the past 12 months and verify each followed the playbook classification, escalation, and post-incident review requirements." ], "metrics": [ "Playbook coverage rate: target 100% of defined AI incident types documented with containment procedures.", "Kill-switch test cadence: target all production agents tested at least annually.", "Post-incident review completion rate: target 100% of P1/P2 incidents reviewed within defined SLA." ], "failure_signals": [ "No AI-specific incident response playbook exists or it has not been reviewed in over 12 months.", "Kill-switch mechanism is untested or non-functional for any production agent.", "P1/P2 incidents handled without documented post-incident review." ] }, "platform_engineer": { "summary": "Kill-switch infrastructure and incident response tooling must be built into the platform before any agent goes to production. These are foundational platform capabilities, not optional add-ons.", "actions": [ "Build and expose authenticated kill-switch endpoints for all production agents with a verified 60-second suspension SLA and comprehensive audit logging.", "Implement agent state snapshot capability to support forensic evidence preservation during active incidents without interrupting the audit log.", "Integrate agent operational status and incident event types with the enterprise SIEM and incident management system using defined AI-specific event codes." ], "failure_signals": [ "Kill-switch endpoint lacks authentication, lacks audit logging, or has not been tested end-to-end.", "Agent state cannot be captured for forensic purposes during a live incident.", "No SIEM integration exists for agent operational anomaly events." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Enterprises have general IT incident response but lack AI-specific playbooks addressing autonomous action continuation, multi-agent cascade, and action irreversibility—which are qualitatively distinct from software incidents." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "AI Governance Office", "Security Operations", "AI Engineering", "Legal and Compliance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE 4.3", "fit": "direct", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation.", "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. 73", "fit": "direct", "rationale": "EU AI Act Article 73 requires providers and deployers to report serious incidents to national competent authorities within defined timeframes. An AI incident response program with regulatory notification procedures and defined reporting timelines directly addresses this mandatory serious incident reporting obligation.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "cisa_ai_guidance", "requirement_id": "Roadmap for AI — Line of Effort 3 (Protect Critical Infrastructure from Malicious Use of AI)", "fit": "adjacent", "rationale": "CISA's Roadmap for AI is an agency strategy rather than deployer guidance. Its Line of Effort 3 commits CISA to helping organizations defend against malicious use of AI, including assistance and incident reporting channels. An agent-specific incident response program is the enterprise-side capability that connects to those channels when agentic incidents occur.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "§10.2 — Nonconformity and corrective action", "fit": "partial", "rationale": "ISO/IEC 42001 §10.2 requires reacting to nonconformities and taking corrective action to prevent recurrence. An agent incident response program provides the organizational procedures for exactly that reaction when agentic systems misbehave.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre_atlas", "requirement_id": "ATLAS tactics and techniques (framework-wide)", "fit": "adjacent", "rationale": "MITRE ATLAS catalogs adversarial tactics and techniques against AI systems — prompt injection, supply chain compromise, model access abuse — that agent incident response playbooks must anticipate. AG-05 uses ATLAS as the reference threat model for playbook scenarios and tabletop exercises.", "normative_force": "industry-framework", "source_version": "v2026.06", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "defends_against" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard — rapid response to misuse", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The ASL-3 Deployment Standard requires rapid response when safeguards are circumvented or misuse is detected. AG-05's agent incident response program builds the enterprise-side capability for the same class of events: contain, investigate, remediate, and report.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Incident Response Management (SAIF control)", "fit": "direct", "rationale": "Google SAIF's Incident Response Management control requires incident response processes that cover AI-specific threats and behavioral anomalies. An agent incident response program with agentic playbooks and containment procedures is the direct implementation.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS2 — Failures and remediations", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS2 requires defined remediation paths for system failures. An agent-specific incident response program is the organizational remediation path: containment, investigation, and corrective action procedures tailored to agentic failure modes.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (incident response procedures that address agent compromise); Part V — Establish emergency change procedures in advance", "fit": "direct", "rationale": "Governance requires incident-response procedures addressing agent compromise; Part V requires pre-established emergency change/containment authorization paths — the agent incident response program.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-05", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "machine_tests": [ "Verify that every production agent has a registered kill-switch endpoint in the control plane and that the endpoint responds to authenticated suspension requests within 60 seconds", "Check the incident management system for AI-specific classification codes and automated routing rules, asserting all defined AI incident types have routing paths", "Validate that post-incident review records exist for 100% of P1 and P2 events and were completed within the 5-business-day SLA", "Scan for agents with no containment action defined in the playbook for their operational type and consequence tier" ], "human_review": [ "Assess whether severity classification criteria are calibrated to AI-specific harm characteristics — autonomous action continuation, multi-agent cascade, and irreversibility — rather than generic IT severity models", "Evaluate whether documented containment actions are technically feasible and can actually stop ongoing autonomous effects rather than only preventing future actions", "Review whether regulatory notification timelines in the playbook align with current EU AI Act Art. 73 serious incident reporting requirements", "Assess post-incident review quality for recent P1/P2 events: evaluate whether root causes are specific and actionable" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Relying on standard IT incident response procedures without any AI-specific additions, missing the unique characteristics of agentic incidents including action continuation after detection and multi-agent cascade", "Defining kill-switch capability only at the model or service level with no per-agent suspension granularity, making targeted containment impossible without broad service outage", "Treating post-incident review as an internal improvement exercise with no connection to the lessons-learned pipeline or governance control update process", "Setting severity classification criteria based solely on financial loss thresholds, missing severity signals unique to agentic incidents such as unauthorized scope expansion or orchestration cascade initiation" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-06", "layer": "AG", "plane": "control", "name": "Agent Program Metrics and KPIs", "plain": "The enterprise must define, collect, and report a standard set of governance metrics for its agentic AI program, including control coverage rates, deployment approval latency, incident counts by severity, authorization scope change frequency, and attestation production rates, enabling the governance committee to assess program health and direct improvement actions.", "threat": { "tags": [ "governance-blindness", "coverage-gap", "accountability-erosion", "metric-gaming" ], "desc": "Without defined metrics and KPIs, governance committees cannot distinguish a healthy agentic AI program from a failing one. Invisible control gaps accumulate unnoticed: agents without accountability assignments, overdue risk reassessments, and unresolved incidents persist because no reporting mechanism surfaces them. When metrics are absent, governance devolves to anecdote and committees lose the ability to direct meaningful improvement or detect systemic deterioration." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE 1.1", "title": "Selection of AI risk metrics" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, analysis, and evaluation" }, { "id": "microsoft_rai", "section": "RS3", "title": "Ongoing monitoring, feedback, and evaluation" } ], "sources": [ { "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-29", "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://agentic/controls/AG-06 Agent Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-06 Agent Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-06 Agent Program Metrics and KPIs control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-06 Agent Program Metrics and KPIs control.", "reviewed_on": "2026-07-02" }, { "id": "owasp_aivss", "title": "OWASP AIVSS v0.8 (AI Vulnerability Scoring System for Agentic AI)", "authority": "OWASP Foundation", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "0.8", "published_on": "2026-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://aivss.owasp.org/", "relationship": "supporting_guidance", "note": "AIVSS severity bands + Agentic AI Risk Score give a quantitative KPI for tracking agentic risk posture over time." } ], "implementation": { "pattern": "Define a metrics catalog covering four categories: coverage metrics (registry completeness, risk assessment coverage, accountable owner assignment rate), process metrics (deployment approval latency, incident response time-to-contain), outcome metrics (incident counts by severity, scope violation rates, near-miss counts), and attestation metrics (BehavioralAttestation production frequency, evidence freshness rate). Report monthly to the governance committee.", "steps": [ "Publish the Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline.", "Build automated data collection pipelines pulling from the agent registry, deployment pipeline audit log, incident management system, and attestation store, with data lineage documentation.", "Produce a governance dashboard accessible to the governance committee showing current period values, trend lines against prior periods, and automated threshold breach alerts.", "Review the metrics catalog quarterly for continued relevance and update thresholds as program maturity improves and the baseline shifts." ], "ai_engineer": { "summary": "Your agent's deployment and incident data feeds the governance metrics. Ensure monitoring hooks are correctly configured so your agent contributes accurate data to program KPIs.", "actions": [ "Verify that your agent's deployment approval, risk assessment, capability changes, and incident events are correctly logged to the sources feeding governance metrics.", "Review your agent's contribution to coverage metrics in the governance dashboard at least quarterly.", "Report near-misses and borderline incidents to ensure they are captured in outcome metrics and not excluded from program visibility." ], "failure_signals": [ "Agent monitoring hooks are not configured to feed the governance metrics pipeline.", "Agent-level events are not visible or traceable in the governance dashboard.", "Near-misses are not reported or not captured in program outcome metrics." ] }, "security_architect": { "summary": "Security-relevant metrics—scope violation rates, incident severity distribution, authorization change frequency—should be integrated into the enterprise security metrics program alongside traditional security KPIs.", "actions": [ "Define security-specific KPIs within the metrics catalog: scope violation rate, mean time to containment for P1/P2 incidents, and unauthorized tool invocation rate.", "Integrate agentic AI metrics into the enterprise security dashboard and include them in the quarterly security risk report.", "Set threshold alerts for security metric breaches that trigger automatic escalation to the security architecture review queue." ], "failure_signals": [ "Security-specific agentic metrics are not defined within the program metrics catalog.", "Scope violation rate is not tracked or lacks a defined threshold and owner.", "Security metric threshold breaches do not trigger automated escalation." ] }, "legal_counsel": { "summary": "Program metrics provide the documentary evidence of active governance that regulators expect. Metric definitions, data provenance, and reporting records must be maintained as formal governance documents.", "actions": [ "Review the metrics catalog to confirm it covers dimensions relevant to regulatory monitoring obligations under EU AI Act Art. 72 and sector-specific reporting requirements.", "Ensure metrics reporting records are retained under the applicable governance document retention policy with sufficient provenance.", "Advise the committee on metrics that may create admission risk if thresholds are persistently missed without documented remediation." ], "failure_signals": [ "Metrics catalog does not address regulatory monitoring obligations for high-risk AI systems.", "Reporting records are not retained or lack a documented data provenance trail.", "Persistently missed thresholds without documented remediation create unmitigated regulatory liability." ] }, "grc_auditor": { "summary": "Program metrics are the primary mechanism for continuous governance assurance. Audit the metrics catalog for completeness, data accuracy, and demonstrated use by the governance committee.", "actions": [ "Review the metrics catalog and verify it covers all four required categories: coverage, process, outcome, and attestation.", "Validate data accuracy by independently querying source systems and comparing reported metric values for two consecutive reporting periods.", "Confirm governance committee meeting minutes show metric review, trend discussion, and documented response to threshold breaches." ], "metrics": [ "Metrics catalog completeness: target 100% of four required categories with defined thresholds.", "Data accuracy rate: target 95% or greater consistency between reported values and direct source system queries.", "Governance committee metric review frequency: target monthly minimum.", "Threshold breach response rate: target 100% of breaches receive a documented remediation action within one reporting cycle." ], "failure_signals": [ "Metrics catalog does not cover one or more of the four required categories.", "Reported metric values do not reconcile with source system data within tolerance.", "Governance committee cannot demonstrate use of metrics in documented decision-making." ] }, "platform_engineer": { "summary": "The metrics pipeline is platform infrastructure. Build it as a reliable, automated data product with source traceability and threshold alerting, not as a manually maintained spreadsheet.", "actions": [ "Build automated ETL pipelines from agent registry, deployment audit log, incident management system, and attestation store to the governance metrics store with documented data lineage.", "Implement threshold breach alerting with configurable targets per KPI and automated notification to the metric owner and governance committee.", "Provide a governance dashboard with drill-down capability from program-level aggregated KPIs to individual agent or incident records." ], "failure_signals": [ "Metrics are compiled manually rather than from automated, auditable pipelines.", "No threshold alerting exists for any KPI breach.", "Dashboard does not support drill-down from aggregate metrics to individual agent records." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises lack a defined agentic AI metrics program; governance is based on periodic subjective review rather than continuous measurement against defined, threshold-based KPIs." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "AI Governance Office", "Platform Engineering", "Risk Management", "Security Operations" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE 1.1", "fit": "direct", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 9.1 requires organizations to determine what to monitor and measure in their AI management system, define methods for obtaining valid and reproducible results, and analyze and evaluate the results. The four-category program metrics catalog with automated pipelines and threshold alerting directly satisfies this performance evaluation requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires ongoing evaluation of deployed systems, which presupposes defined measures. The agentic program metrics catalog defines the coverage, incident, and drift measures by which the agent program's effectiveness is evaluated over time.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 72", "fit": "partial", "rationale": "EU AI Act Article 72 requires providers and deployers to maintain post-market monitoring plans and logs for high-risk AI systems. Program metrics tracking operational outcomes, incident rates, and control coverage partially satisfy the monitoring and measurement obligations for deployers.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part IV Phase 8 — Measure what matters (Dwell time and coverage; Detection speed)", "fit": "direct", "rationale": "Phase 8 instruments dwell time, coverage and detection speed as the leading agent-program metrics — agent program metrics and KPIs.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-06", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "machine_tests": [ "Verify that all KPIs defined in the Metrics Catalog have automated data collection pipelines with records from the current and prior reporting periods", "Assert that the governance dashboard includes all four required metric categories: coverage, process, outcome, and attestation metrics", "Check for any KPI where the most recent data point is older than 1.5 times the defined reporting interval, indicating pipeline staleness", "Validate that threshold breach alerts are configured for each KPI with a defined target threshold and confirm a synthetic threshold breach triggers the alert" ], "human_review": [ "Assess whether the defined KPI set is sufficient to reveal systemic governance failures, or whether critical coverage gaps could go unreported under the current metric catalog", "Evaluate whether metric formulas are resistant to gaming — particularly whether coverage rates that could be inflated by lower-quality approvals are validated against underlying artifact quality", "Review governance committee records to assess whether metric presentations drive substantive discussion and directed action, or are noted without response" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Collecting metrics manually from multiple disconnected sources without automated pipelines, producing reports that are too labor-intensive to sustain and too stale to drive timely decisions", "Reporting only outcome metrics (incident counts, severity totals) without leading-indicator coverage and process metrics that reveal governance gaps before harm occurs", "Defining KPI targets without baselines or trend data, making it impossible to distinguish a stable program from one in rapid deterioration", "Presenting governance dashboards to committees without threshold breach alerts, so deteriorating metrics go unflaged unless a committee member happens to notice the trend" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-07", "layer": "AG", "plane": "lifecycle", "name": "Continuous Improvement and Lessons Learned", "plain": "The enterprise must operate a systematic lessons-learned program for agentic AI that captures findings from production incidents, near-misses, governance review failures, and external threat intelligence, and translates them into documented, tracked updates to governance controls, deployment policy, risk frameworks, and technical safeguards.", "threat": { "tags": [ "repeated-failure", "lessons-not-learned", "control-staleness", "systemic-vulnerability" ], "desc": "Agentic AI systems operate in rapidly evolving threat and capability environments. Governance frameworks that are not continuously updated become stale, failing to address new attack vectors, novel agent capabilities, and lessons from real-world incidents at other organizations. Without a formal lessons-learned program, the same failure modes recur, and controls that were adequate at initial deployment remain in place long after the threat and operational landscape has shifted." }, "standard": [ { "id": "iso_42001", "section": "§10.1", "title": "Continual improvement" }, { "id": "nist_rmf", "section": "MANAGE 4.1", "title": "Post-deployment monitoring feeding change management" }, { "id": "iso_31000", "section": "§6.7", "title": "Recording and reporting" }, { "id": "microsoft_rai", "section": "RS3", "title": "Ongoing monitoring, feedback, and evaluation" } ], "sources": [ { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-07 Continuous Improvement and Lessons Learned control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-07 Continuous Improvement and Lessons Learned control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-07 Continuous Improvement and Lessons Learned control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-07 Continuous Improvement and Lessons Learned control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish four structured input channels: post-incident reviews, near-miss reports, governance committee retrospectives, and external threat intelligence. Define a lessons-learned pipeline with explicit stages: capture, triage, root cause analysis, control update recommendation, governance approval, implementation, and verification. Track all open action items with named owners and due dates.", "steps": [ "Define the lessons-learned pipeline with explicit stages, responsible parties, and SLAs: post-incident review within 5 business days for P1/P2; near-miss triage within 10 business days; governance retrospective quarterly; external intelligence review quarterly.", "Implement a lessons-learned register as a tracked artifact capturing: input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence.", "Subscribe the AI Governance Committee to external AI safety and threat intelligence feeds (CISA advisories, MITRE ATLAS updates, sector-specific AI risk bulletins) and designate a team member responsible for relevance assessment and pipeline submission.", "Require that every control update made through the lessons-learned pipeline includes an explicit mapping to the initiating finding and a defined verification method confirming the update is effective." ], "ai_engineer": { "summary": "Near-misses are as valuable as full incidents for improving governance. Report them through the defined channel—they are not failures to be hidden but data to improve program controls.", "actions": [ "Submit near-miss reports for any agent behavior that approached but did not cross an authorization or scope boundary.", "Participate in post-incident reviews when your agent is involved, providing technical root cause analysis and recommended control updates.", "Review control updates produced by the lessons-learned pipeline that affect your agent's operating parameters and acknowledge receipt." ], "failure_signals": [ "Near-misses are not being reported or are handled informally outside the pipeline.", "Post-incident reviews do not include technical root cause analysis from the responsible AI engineer.", "Control updates are not communicated to AI engineers responsible for affected agents." ] }, "security_architect": { "summary": "External threat intelligence is a critical input to the lessons-learned program. Maintain active subscriptions to AI-specific threat feeds and translate relevant findings into actionable control update proposals.", "actions": [ "Maintain active subscriptions to CISA AI advisories, MITRE ATLAS updates, and sector-specific AI threat intelligence sources.", "Produce quarterly threat intelligence review summaries for the governance committee covering relevant external findings and their applicability to the enterprise agent fleet.", "Translate applicable external findings into formal control update proposals with priority, affected control identifiers, and a proposed implementation timeline." ], "failure_signals": [ "No active subscription to any AI-specific external threat intelligence source.", "External threat findings are not translated into actionable control update proposals.", "Governance committee has not received an external threat intelligence summary in the past two reporting quarters." ] }, "legal_counsel": { "summary": "The lessons-learned program demonstrates active governance improvement, which is directly relevant to regulatory defense and liability limitation when incidents recur or escalate.", "actions": [ "Ensure the lessons-learned register is maintained as a formal governance record with sufficient detail to demonstrate systematic improvement over time.", "Review the pipeline design to confirm that privileged legal communications related to incident root cause are appropriately protected from inadvertent disclosure.", "Advise the governance committee on regulatory developments and enforcement actions that should be ingested as external intelligence inputs to the pipeline." ], "failure_signals": [ "Lessons-learned register is not maintained as a formal, retained record.", "Legal privilege protections for incident analysis communications are not established.", "Regulatory enforcement actions and guidance updates are not systematically reviewed for pipeline input." ] }, "grc_auditor": { "summary": "The lessons-learned program is evidence of a learning organization. Audit the pipeline for consistent operation, traceability from finding to implemented control update, and evidence that the program produces actual control changes.", "actions": [ "Request the lessons-learned register and verify it is current, covers all four input channels, and has entries for all known P1/P2 incidents from the past 12 months.", "Sample 5 closed action items and trace each from initiating finding through root cause analysis, governance approval, implementation, and verification evidence.", "Test that governance controls updated through the pipeline reflect the documented changes and that update rationale is traceable to the initiating finding." ], "metrics": [ "Lessons-learned register completeness: target 100% of P1/P2 incidents generating a registered finding.", "Near-miss capture rate: track as a leading indicator of reporting culture health.", "Control update implementation rate: target 90% or greater of approved updates implemented within the defined SLA.", "External intelligence review cadence: target quarterly minimum with documented relevance assessment." ], "failure_signals": [ "Lessons-learned register does not include entries for known P1/P2 incidents in the review period.", "Action items are open past their stated due dates without documented justification.", "No traceable path from finding through to an implemented control update." ] }, "platform_engineer": { "summary": "The lessons-learned register and pipeline must be tooled as a tracked workflow system, not managed in unstructured documents. Enforce stage completion and automatically surface overdue items.", "actions": [ "Implement the lessons-learned register as a tracked workflow system with mandatory stage fields, SLA tracking, and automatic overdue escalation.", "Automate overdue item escalation to the governance committee reporting dashboard when action items exceed their due dates.", "Integrate the external threat intelligence subscription feed with the governance portal so relevant advisories surface automatically as input candidates in the pipeline." ], "failure_signals": [ "Lessons-learned program is managed in untracked spreadsheets or email threads.", "Overdue action items are not automatically escalated or surfaced in governance reporting.", "External intelligence inputs are not integrated into the lessons-learned workflow and require manual entry." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Post-incident reviews exist in many organizations but are rarely connected to a systematic, traceable control update pipeline with verification evidence and external intelligence integration." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "AI Governance Office", "Security Architecture", "Risk Management", "AI Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "§10.1 — Continual improvement", "fit": "direct", "rationale": "ISO/IEC 42001 §10.1 requires continual improvement of the suitability, adequacy, and effectiveness of the AI management system. A structured lessons-learned pipeline with traceability from incident to control change is the direct mechanism of that improvement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "MANAGE 4.1", "fit": "partial", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for capturing and evaluating input from users and affected parties, feeding change management. The lessons-learned pipeline is that capture-and-evaluate mechanism for the agentic program.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_31000", "requirement_id": "§6.7", "fit": "partial", "rationale": "ISO 31000:2018 Section 6.7 requires organizations to record and report risk management activities and outcomes and use this information to improve the risk management framework over time. The lessons-learned register satisfies the recording requirement and feeds the framework improvement process.", "normative_force": "voluntary-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "RS3 — Ongoing monitoring, feedback, and evaluation", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2 Goal RS3 requires monitoring, feedback, and evaluation to feed system improvement. The lessons-learned pipeline closes that loop for the agent program: incidents, drift events, and external intelligence become documented control revisions.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cisa_ai_guidance", "requirement_id": "Roadmap for AI — Line of Effort 4 (Collaborate and Communicate on Key AI Efforts)", "fit": "adjacent", "rationale": "CISA's Roadmap for AI Line of Effort 4 commits the agency to collaboration and information sharing on AI security. AG-07's external threat-intelligence input channel is the enterprise-side counterpart: shared AI threat information feeds the lessons-learned pipeline that updates agent controls.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Governance (§4) — policy maintenance and updates", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. The RSP is explicitly versioned and revised as evaluation methods and deployment experience evolve, with changes governed under §4. AG-07's lessons-learned pipeline institutionalizes the same update discipline for an enterprise agent program: operational experience feeds documented control revisions.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Building trust (§5) — framework iteration and transparency", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. The framework is explicitly iterative — version 2 substantially revised version 1 based on evaluation experience — and §5 commits to transparency about updates. AG-07's lessons-learned pipeline institutionalizes the same iteration discipline for an enterprise agent program.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Element 5 — Adapt controls to adjust mitigations and create faster feedback loops", "fit": "partial", "rationale": "Google SAIF element 5 (Adapt controls) requires continuous adaptation of AI mitigations based on operational experience and emerging threats. The lessons-learned pipeline is the organizational mechanism that turns that experience into documented control changes.", "normative_force": "best-practice", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_zt_agents", "requirement_id": "Part III — AI governance policies (Update policies based on incident learnings)", "fit": "partial", "rationale": "Governance updates policies based on incident learnings and conducts regular reviews. Partial: doc treats this as policy maintenance rather than a formal continuous-improvement/lessons-learned program.", "normative_force": "best-practice", "source_version": "2026-05-18", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-07", "validation_objective": "The enterprise operates a closed-loop lessons-learned program with four defined input channels, a tracked pipeline from capture to verified implementation, and documented control update recommendations with named owners and due dates that are verifiably completed.", "evidence_required": [ "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes" ], "machine_tests": [ "Verify that all P1/P2 incidents have a corresponding post-incident review record in the lessons-learned register completed within the defined SLA", "Check that all open lessons-learned items have named owners and due dates, and identify any items overdue beyond the defined SLA with no documented extension", "Validate that all lessons-learned items marked as implemented have verification evidence records attached", "Assert that at least one external intelligence feed subscription record exists with a relevance assessment completed within the last 90 days" ], "human_review": [ "Assess whether root cause analyses in the lessons-learned register are specific and technically grounded, or are superficial statements that do not enable effective control updates", "Evaluate whether control update recommendations translate accurately into changes to governance control text, implementation guidance, or machine test definitions", "Review whether the pipeline consistently closes the loop from capture to verified implementation, or whether items stall at the recommendation stage without progression" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Operating the lessons-learned program as an incident post-mortem exercise only, omitting near-misses, governance retrospectives, and external threat intelligence as input channels", "Maintaining a lessons-learned register that captures findings but has no mechanism to translate them into tracked control updates with named owners, due dates, and verification evidence", "Treating the lessons-learned pipeline as a quarterly exercise rather than a continuous program, so findings from incidents between quarterly retrospectives age without timely action", "Subscribing to external threat intelligence feeds without a defined relevance assessment process, producing a backlog of unconsumed advisories that never reach the governance pipeline" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "layer_code": "AG" }, { "id": "AG-08", "layer": "AG", "plane": "control", "name": "BehavioralAttestation Production", "plain": "The enterprise must produce a BehavioralAttestation artifact that aggregates evidence from all agentic domain controls across the AA through AG layers, applies a structured completeness and freshness evaluation against defined thresholds, and outputs a signed attestation certifying that the behavioral authorization framework is implemented, evidenced, and current as of the attestation date.", "threat": { "tags": [ "attestation-gap", "evidence-incompleteness", "unverified-compliance", "stale-assurance" ], "desc": "Without a synthesized attestation artifact, enterprise stakeholders, regulators, auditors, and downstream consumers of agentic AI outputs cannot determine whether the behavioral authorization framework is actually implemented and current. Point-in-time governance reviews become disconnected from operational reality, the organization cannot demonstrate assurance continuity to regulators or customers, and stale or incomplete attestations create false confidence in governance posture that defeats the evidence fabric purpose." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN 4.2", "title": "Documentation and communication of AI risks and impacts" }, { "id": "iso_42001", "section": "§9.1", "title": "Monitoring, measurement, and evaluation" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Documentation and record-keeping" }, { "id": "microsoft_rai", "section": "Accountability goals (A1–A5)", "title": "Documentation and auditability" } ], "sources": [ { "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-29", "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://agentic/controls/AG-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-29", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://agentic/controls/AG-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy 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-29", "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://agentic/controls/AG-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" }, { "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-29", "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://agentic/controls/AG-08 BehavioralAttestation Production control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define the BehavioralAttestation schema incorporating all evidence ontology fields; implement an evidence aggregation pipeline that pulls current artifacts from all six agentic layers (AA, AB, AT, AO, AM, AG), evaluates completeness and freshness against defined thresholds, computes an overall attestation verdict, and produces a signed artifact with Ed25519 signature.", "steps": [ "Define the BehavioralAttestation schema: evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, reviewed_on, source_freshness_status, residual_risk, producer_verifier, consumer_verifiers, evidence_completeness_status, runtime_gate_required, integrity.hash (sha256), integrity.signature (Ed25519).", "Build the evidence aggregation pipeline that queries the evidence store for current artifacts from all agentic layer controls (AA-01 through AG-07), evaluates each for freshness against its defined validity window, and identifies gaps against the expected evidence manifest.", "Implement the attestation verdict engine: if evidence completeness is below the defined threshold or any Critical-tier control evidence is stale, downgrade the verdict from 'pass' to 'conditional' or 'inconclusive'; if blocking evidence is missing, set verdict to 'fail' with blocking_effect set to 'blocks-deployment'.", "Sign the completed BehavioralAttestation artifact with an Ed25519 key stored in the enterprise hardware security module, publish it to the immutable attestation store, and register it in the cross-domain evidence registry." ], "ai_engineer": { "summary": "The BehavioralAttestation is the machine-readable certification of the agentic AI governance posture. Its verdict determines whether downstream consumers and cross-domain integrations can trust the behavioral authorization framework backing your agents.", "actions": [ "Ensure all control evidence your agent generates is correctly tagged and routed for inclusion in the BehavioralAttestation aggregation pipeline.", "Review the current attestation verdict for your agent's scope before any cross-domain integration or external deployment submission.", "Respond promptly to evidence freshness alerts that risk downgrading the attestation verdict for your agent's controls." ], "failure_signals": [ "Agent-generated evidence artifacts are not tagged for attestation aggregation or are missing from the evidence store.", "Attestation verdict is 'conditional' or 'inconclusive' without a documented remediation plan and owner.", "Evidence freshness breaches are unaddressed for more than one reporting cycle, causing attestation degradation." ] }, "security_architect": { "summary": "The BehavioralAttestation is both a governance and a security artifact. Signing key management, artifact integrity verification, and attestation store access controls must meet enterprise PKI and evidence integrity standards.", "actions": [ "Define the Ed25519 signing key management policy: key generation ceremony, rotation cadence, HSM storage requirements, and key custodian designation.", "Implement integrity verification hooks for published attestation artifacts to detect tampering after production.", "Define and enforce access controls for the attestation store: read access, write access, deletion prohibition, and full audit logging." ], "failure_signals": [ "Ed25519 signing keys are not stored in an HSM or equivalent hardware-backed key management system.", "No integrity verification mechanism exists for published attestation artifacts.", "Attestation store access is not comprehensively audited or has no deletion controls." ] }, "legal_counsel": { "summary": "The BehavioralAttestation is the primary legal artifact certifying governance compliance for the agentic domain. Its format, retention, and accessibility must satisfy regulatory documentation requirements across all applicable jurisdictions.", "actions": [ "Review the attestation schema to confirm it captures all documentation elements required under EU AI Act Art. 18 and applicable sector-specific regulations.", "Establish a retention policy for BehavioralAttestation artifacts aligned with the longest applicable regulatory record-keeping period.", "Confirm that attestation artifacts are accessible to regulators, auditors, and notified bodies upon request with appropriate access controls." ], "failure_signals": [ "Attestation schema does not capture all required regulatory documentation elements.", "No formal retention policy is defined or assigned to attestation artifacts.", "Attestation artifacts are not accessible to authorized regulatory or audit reviewers without undue delay." ] }, "grc_auditor": { "summary": "The BehavioralAttestation is the synthesis of all agentic governance evidence. Audit it for schema completeness, evidence provenance integrity, verdict accuracy, and cryptographic signature validity.", "actions": [ "Verify the attestation schema is complete against the evidence ontology: all required fields are present and populated with non-null values.", "Trace a sample of evidence references in the attestation back to source control artifacts and verify completeness, freshness status, and chain of custody.", "Validate the Ed25519 signature on the current attestation artifact using the published verification key to confirm it has not been tampered with." ], "metrics": [ "BehavioralAttestation production frequency: target monthly minimum for all Critical-tier deployments.", "Evidence completeness rate: target 100% of required control evidence present and within defined validity window.", "Attestation verdict distribution: track the ratio of pass to conditional to inconclusive over time as a program health trend indicator.", "Signature verification success rate: target 100% across all published attestation artifacts." ], "failure_signals": [ "BehavioralAttestation has not been produced within the past 30 days for any Critical-tier deployment.", "Evidence completeness is below 90%, producing a persistent 'conditional' or 'inconclusive' verdict without remediation.", "Ed25519 signature does not verify against the published key on any current attestation artifact." ] }, "platform_engineer": { "summary": "The BehavioralAttestation production pipeline is core platform infrastructure. Build it as an automated, scheduled process with deterministic verdict logic, HSM-backed signing, and an immutable append-only artifact store.", "actions": [ "Implement the evidence aggregation and attestation production pipeline as a scheduled, observable job with configurable production cadence and automated failure alerting.", "Integrate with the enterprise hardware security module for automated Ed25519 signing at attestation production time, with key handle references logged in the artifact.", "Build the attestation store as an immutable, append-only repository with a content-addressed index, versioned artifact history, and a public verification API for external consumers." ], "failure_signals": [ "Attestation production pipeline is manual, undocumented, or lacks automated failure alerting.", "Signing is not automated or uses software-resident keys outside an HSM.", "Attestation store is mutable, lacks a content-addressed index, or has no public verification API." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "BehavioralAttestation production requires a mature evidence aggregation pipeline; most enterprises are at initial stage with point-in-time audit documentation rather than continuously produced, cryptographically signed attestation artifacts." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "cloud-native" ], "implementers": [ "AI Governance Office", "Platform Engineering", "Security Architecture", "GRC and Internal Audit" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN 4.2", "fit": "direct", "rationale": "NIST AI RMF GOVERN 4.2 requires teams to document the risks and impacts of the AI technology they deploy and communicate about them broadly. The BehavioralAttestation synthesizes the domain's control evidence into that communicable documentation artifact.", "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. 18", "fit": "direct", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to keep technical documentation and related records at the disposal of national competent authorities for ten years after market placement. The BehavioralAttestation gives that retained documentation a machine-verifiable governance component.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "§9.1", "fit": "direct", "rationale": "ISO/IEC 42001 Clause 9.1 requires organizations to evaluate the performance and effectiveness of the AI management system through defined monitoring, measurement, analysis, and evaluation processes with retained documented information. The BehavioralAttestation production pipeline with completeness scoring, verdict production, and signed artifact retention directly satisfies this evaluation and documentation requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Accountability goals (A1–A5)", "fit": "partial", "rationale": "Microsoft Responsible AI Standard v2's Accountability goals (A1–A5) require comprehensive documentation demonstrating that governance controls operate. The BehavioralAttestation synthesizes the domain's control evidence into that documented, signed accountability artifact.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_rsp", "requirement_id": "Risk Reports (§3)", "fit": "adjacent", "rationale": "Anthropic's Responsible Scaling Policy (v3.3) binds Anthropic's own frontier model development and deployment, not enterprise agent operators; it is cited here as adjacent industry practice. RSP §3 (Risk Reports) requires synthesized, reviewable documentation of safeguards and findings. AG-08's BehavioralAttestation is the enterprise analog: a signed synthesis of the domain's control evidence supporting deployment and continued-operation decisions.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openai_preparedness", "requirement_id": "Capabilities and Safeguards Reports (§3–§4)", "fit": "adjacent", "rationale": "OpenAI's Preparedness Framework (v2, 2025) governs OpenAI's own frontier model development and deployment decisions, not enterprise agent operators; it is cited here as adjacent industry practice. Capabilities Reports (§3) and Safeguards Reports (§4) synthesize evaluation and safeguard evidence into decision-grade documents. AG-08's BehavioralAttestation is the enterprise analog: a signed synthesis of behavioral control evidence supporting deployment decisions.", "normative_force": "best-practice", "source_version": "2.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://agentic/controls/AG-08", "validation_objective": "The enterprise produces a signed BehavioralAttestation artifact aggregating evidence from all six agentic domain layers (AA through AG), with evidence completeness and freshness evaluated against defined thresholds, outputting a structured verdict and Ed25519 signature that downstream consumers and regulators can independently verify.", "evidence_required": [ "BehavioralAttestation artifact from the most recent attestation cycle, with evidence_id, verdict, blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, evidence_completeness_status, integrity.hash (sha256), and integrity.signature (Ed25519) fields fully populated", "Evidence manifest listing the expected evidence artifacts from all AA-01 through AG-07 controls and their freshness evaluation results at the time of attestation", "Attestation production pipeline logs showing evidence aggregation, completeness evaluation, verdict computation, and signing events for the current cycle", "Ed25519 key management records confirming the signing key material, its custodian, and key rotation history", "Consumer verification records or API logs showing downstream attestation consumers successfully verifying the signature and parsing the artifact" ], "machine_tests": [ "Verify the Ed25519 signature on the most recent BehavioralAttestation artifact using the published verification key and assert the signature is valid and the hash matches the artifact body", "Parse the attestation artifact and assert all required evidence ontology fields are present and non-null: evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, collected_at, valid_from, valid_until", "Check that valid_until has not expired and that evidence freshness evaluation in the manifest reflects the current state of AA-01 through AG-07 artifacts within their defined validity windows", "Simulate a scenario where a Critical-tier control evidence artifact is missing or stale and assert the verdict engine downgrades the verdict from 'pass' to 'conditional' or 'fail'" ], "human_review": [ "Assess whether the evidence completeness threshold is calibrated to actual governance risk: evaluate whether setting the threshold too low permits a 'pass' verdict despite material control evidence gaps", "Evaluate the freshness of underlying evidence artifacts: confirm that high-frequency evidence (behavioral logs, monitoring alerts) reflects current operational state, not archived point-in-time snapshots", "Review the confidence_basis field: assess whether the stated confidence level is supported by the actual evidence quality, coverage, and recency documented in the manifest", "Assess the key management posture: confirm signing key custody, rotation policy, and access controls are consistent with the assurance level the attestation is expected to provide" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Setting the evidence completeness threshold at a level that permits 'pass' verdicts when large subsets of layer controls have no current evidence, reducing the attestation to a formality", "Producing BehavioralAttestation artifacts on an infrequent schedule (annually or at audit time only) rather than continuously, so the attestation is chronically stale relative to operational reality", "Reusing evidence artifacts from previous attestation cycles without freshness evaluation, so the attestation verdict reflects a past governance state rather than current implementation", "Generating unsigned or weakly signed attestations that cannot be independently verified by downstream consumers, defeating the purpose of a machine-readable evidence artifact" ], "update_status": "current", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "cross_domain": { "feeds": [ "apeiris://compliance/controls/AU-08" ] }, "layer_code": "AG" }, { "id": "AB-09", "layer": "AB", "layer_code": "AB", "plane": "both", "canonical_id": "apeiris://agentic/controls/AB-09", "lenses": null, "name": "Comprehensive Input Validation and Multimodal Screening", "plain": "Every input to the agent is validated before it reaches the model: length capped to the context window (reject, not truncate), reserved special tokens neutralized, and non-text inputs (image/audio/video) plus cross-modal combinations screened for adversarial or steganographic payloads.", "threat": { "tags": [ "input-manipulation", "multimodal-injection", "token-smuggling", "MR-INPUT" ], "desc": "Unbounded or malformed inputs (over-length content, injected reserved tokens, adversarial perturbations in non-text media, or coordinated cross-modal payloads) subvert model behavior before any downstream control applies (OWASP AISVS C2)." }, "standard": [ "OWASP AISVS v1.0 C2 — Input Validation" ], "sources": [ { "id": "owasp_aisvs", "title": "OWASP AI Security Verification Standard v1.0", "authority": "OWASP Foundation", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "1.0", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://owasp.org/www-project-artificial-intelligence-security-verification-standard/", "relationship": "supporting_guidance", "note": "AISVS C2 defines the input-validation requirements this control implements." } ], "implementation": { "pattern": "A validation stage in front of the model that enforces length limits, neutralizes reserved tokens, and screens non-text and cross-modal inputs before the model receives them.", "steps": [ "Reject (do not truncate) inputs exceeding the context-window token limit.", "Encode reserved special tokens as literal characters so they cannot be injected into the model context.", "Screen image/audio/video inputs for adversarial perturbations, steganography, and known attack patterns.", "Detect coordinated cross-modal attacks (e.g. steganographic image payload + text prompt injection) and block them." ], "ai_engineer": { "summary": "You own the validation stage that sits in front of the model. Length enforcement must reject over-length inputs rather than truncate them, reserved special tokens must be neutralized to literals before they reach the context, and non-text and cross-modal inputs must be screened before the model ever sees them. Truncation instead of rejection is the failure mode this control exists to prevent.", "actions": [ "Implement a pre-model validation stage in the shared agent runtime so every agent inherits it, and make over-length inputs return a rejection rather than a truncated payload.", "Encode reserved special tokens as literal characters at the boundary so a caller cannot inject control tokens into the model context.", "Wire image, audio, and video inputs through an adversarial and steganography screener before they are embedded or passed to the model.", "Add a cross-modal correlation check that blocks a coordinated payload (for example a steganographic image paired with a text injection) even when each modality passes on its own.", "Write integration tests that submit an over-length input, a reserved-token input, and a known adversarial-media pattern and assert each is rejected with the failing check recorded in the runtime log." ] }, "security_architect": { "summary": "This is a runtime-blocking integrity boundary: it decides what is allowed to reach the model at all. Because it blocks runtime action, its correctness gates every downstream behavioral and output control, and a validation stage that truncates rather than rejects silently admits the exact payloads it was meant to stop. Treat multimodal and cross-modal screening as a first-class input surface, not an afterthought bolted onto text handling.", "actions": [ "Require the validation stage to be a mandatory, fail-closed path in the runtime reference architecture so no agent code path can reach the model without passing it.", "Specify that over-length handling is rejection-only and make truncation a design-review finding.", "Define the multimodal threat model (adversarial perturbation, steganographic payloads, cross-modal coordination) and set screening coverage expectations for each modality the platform accepts.", "Ensure rejected-input runtime logs feed detection so repeated adversarial-media attempts surface as an attack signal, not just discarded traffic." ] }, "grc_auditor": { "summary": "The auditable artifacts are the input_validation_policy and the runtime logs of rejected inputs. Your job is to confirm the policy actually specifies length limits, reserved-token handling, and multimodal screening methods, and that the logs show real rejections tied to a failing check rather than an empty policy no traffic ever exercises. Because the control blocks runtime action, an unenforced policy is a material gap.", "actions": [ "Obtain the input_validation_policy and confirm it names concrete length limits, reserved-token neutralization, and per-modality screening methods.", "Pull runtime logs for the audit window and verify rejected over-length, malformed, and adversarial-media inputs each record the specific failing check.", "Request evidence that the three machine tests (over-length rejection, reserved-token neutralization, adversarial-media block) run and pass, and sample recent results.", "Confirm the validation stage covers every input path into production agents, not just the primary text endpoint." ] }, "legal_counsel": { "summary": "The rejected-input logs are the record showing the enterprise actively screened hostile and manipulated inputs before they reached an AI system that could act. That record supports a due-diligence position if a manipulated multimodal input is later alleged to have driven a harmful agent action. The evidentiary value depends on the logs being complete and retained, not sampled and discarded.", "actions": [ "Confirm rejected-input logs are retained for a period consistent with the enterprise's litigation-hold and regulatory retention obligations.", "Verify the input_validation_policy is a version-controlled document with dated approvals so the enforced standard at any point in time can be established.", "Ensure screening of user-submitted image, audio, and video inputs is disclosed where content-handling or privacy notices require it.", "Check that log entries capture enough context to demonstrate the failing check without themselves retaining the raw adversarial payload longer than necessary." ] }, "platform_engineer": { "summary": "You own the validation stage as a running service: its availability, latency budget, and fail-closed behavior. If the screener for a modality is unavailable, inputs of that modality must be rejected rather than waved through, because this control blocks runtime action. The stage has to scale with request volume without becoming an incentive to disable it.", "actions": [ "Deploy the validation stage as a mandatory hop in the request path with health checks, and make screener unavailability fail closed for the affected modality.", "Set and monitor a latency budget for validation so it does not become a bottleneck teams route around.", "Alert on rejection-rate spikes and on screener errors so a validation outage is treated as an incident, not silent degradation.", "Own the operational runbook for the reserved-token list and multimodal screening rules so updates ship without a full agent redeploy." ] } }, "validation": { "design_check": [ "An input-validation stage runs before the model and rejects over-length inputs rather than truncating. [ref:owasp_aisvs]", "Reserved tokens are neutralized and non-text/cross-modal inputs are screened before reaching the model. [ref:owasp_aisvs]" ], "runtime_check": [ "The runtime blocks inputs failing length, token, or multimodal screening." ] }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Complements AB-05 (prompt-injection defense) with the AISVS C2 input-validation edge cases (length, reserved tokens, multimodal, cross-modal).", "frameworks": [ { "framework": "owasp_aisvs", "requirement_id": "C2.1.4", "fit": "direct", "rationale": "AISVS C2.1.4 input length controls (reject over-context inputs).", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C2.1.7", "fit": "direct", "rationale": "AISVS C2.1.7 reserved special tokens encoded as literals.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C2.2.3", "fit": "direct", "rationale": "AISVS C2.2.3 non-text inputs screened for adversarial/steganographic content.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C2.2.4", "fit": "direct", "rationale": "AISVS C2.2.4 coordinated cross-modal attacks detected and blocked.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C2.2.2", "fit": "partial", "rationale": "AISVS C2.2.2 prompt-content classification for unsupported languages.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "anomalousinputhandling", "fit": "supporting", "rationale": "AB-09 screens over-length, reserved-token, and cross-modal inputs and rejects malformed ones before they reach the model, handling anomalous inputs as the AI Exchange control requires.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "evasioninputhandling", "fit": "supporting", "rationale": "AB-09 screens non-text and cross-modal inputs for adversarial or steganographic payloads, addressing the evasion-input handling AI Exchange specifies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0015", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every input is validated before reaching the model: over-length inputs are…\" enacts ATLAS mitigation AML.M0015 Adversarial Input Detection; OpenCRE crosswalks this control’s OWASP AI Exchange concept (anomalousinputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0010", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every input is validated before reaching the model: over-length inputs are…\" enacts ATLAS mitigation AML.M0010 Input Restoration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (evasioninputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0009", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that every input is validated before reaching the model: over-length inputs are…\" enacts ATLAS mitigation AML.M0009 Use Multi-Modal Sensors; OpenCRE crosswalks this control’s OWASP AI Exchange concept (evasioninputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "none", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "medium" }, "validation_objective": "Prove that every input is validated before reaching the model: over-length inputs are rejected (not truncated), reserved tokens are neutralized, and non-text and cross-modal inputs are screened for adversarial or steganographic payloads.", "evidence_required": [ "input_validation_policy specifying length limits, reserved-token handling, and multimodal screening methods", "runtime logs showing rejected over-length / malformed / adversarial-media inputs with the failing check" ], "machine_tests": [ "Submit an input exceeding the context-window token limit -> assert it is rejected, not truncated.", "Submit an input containing reserved special tokens -> assert they are neutralized (encoded as literals) before the model context.", "Submit a non-text input with a known adversarial/steganographic pattern -> assert it is screened and blocked." ], "human_review": [ "Review the multimodal screening thresholds to confirm they cover the deployment's actual input modalities." ], "blocking_effect": "blocks-runtime-action", "normative_status": "industry-framework", "anti_patterns": [ "Truncating over-length input instead of rejecting it (truncation can drop safety instructions).", "Validating text prompts while accepting images/audio unscreened." ], "update_status": "current", "lens_enrichment": "ap42 2026-07-08" } ], "profiles": [ { "profile_id": "universal-enterprise", "name": "Universal Enterprise", "description": "Baseline governance for any enterprise AI deployment. Minimum viable posture.", "required_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AG-01", "AG-08" ], "recommended_controls": [ "AA-02", "AA-04", "AA-05", "AA-07", "AB-02", "AB-03", "AB-04", "AB-05", "AB-06", "AB-07", "AG-02", "AG-03", "AG-04", "AG-05", "AG-06", "AG-07", "AM-01", "AM-02", "AM-03", "AM-04" ] }, { "profile_id": "cloud-native", "name": "Cloud-Native AI", "description": "AI systems on cloud platforms with managed services and API-based integrations.", "required_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AG-08", "AM-01" ], "recommended_controls": [ "AA-02", "AA-03", "AA-04", "AA-05", "AA-06", "AA-07", "AB-02", "AB-04", "AB-05", "AB-06", "AB-07", "AG-02", "AG-05", "AG-06", "AM-02", "AM-04", "AM-05", "AM-06", "AM-07", "AO-01" ] }, { "profile_id": "high-risk-sector", "name": "High-Risk Sector", "description": "AI in healthcare, finance, critical infrastructure, or legal contexts requiring enhanced controls.", "required_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AG-01", "AG-08" ], "recommended_controls": [ "AA-02", "AA-03", "AA-04", "AA-05", "AA-06", "AA-07", "AB-02", "AB-03", "AB-04", "AB-05", "AB-06", "AB-07", "AG-02", "AG-03", "AG-04", "AG-05", "AG-06", "AG-07", "AM-01", "AM-02" ] }, { "profile_id": "federated-enterprise", "name": "Federated Enterprise", "description": "Multi-entity environments with cross-organizational AI deployments and federated governance.", "required_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AG-01", "AG-08" ], "recommended_controls": [ "AA-03", "AA-04", "AA-06", "AB-02", "AB-03", "AB-05", "AB-06", "AB-07", "AG-02", "AG-03", "AG-04", "AG-07", "AM-01", "AM-03", "AM-05", "AM-06", "AM-07", "AM-08", "AO-01", "AO-02" ] }, { "profile_id": "multi-tenant", "name": "Multi-Tenant SaaS", "description": "SaaS platforms serving multiple enterprise customers with shared AI infrastructure.", "required_controls": [ "AA-08", "AB-08", "AG-08", "AM-01", "AM-08", "AO-08" ], "recommended_controls": [ "AA-02", "AA-05", "AA-06", "AB-04", "AB-05", "AB-06", "AG-03", "AM-02", "AM-04", "AM-05", "AM-06", "AO-02", "AO-03", "AO-05", "AO-06", "AO-07", "AT-01", "AT-02", "AT-03", "AT-04" ] }, { "profile_id": "eu-high-risk-ai", "name": "EU High-Risk AI", "description": "AI systems subject to EU AI Act high-risk classification and mandatory conformity assessment.", "required_controls": [ "AA-01", "AA-08", "AB-01", "AB-08", "AG-01", "AG-08" ], "recommended_controls": [ "AA-03", "AA-07", "AB-02", "AB-03", "AB-04", "AB-05", "AB-07", "AG-02", "AG-03", "AG-04", "AG-05", "AG-06", "AG-07", "AM-01", "AM-02", "AM-03", "AM-05", "AM-06", "AM-07", "AM-08" ] } ] } }