Governing the Action Layer

Governing the Action Layer How ISO 42001, NIST AI RMF and the EU AI Act Converge on Agentic AI Runtime Controls

A Practitioner Reference for CISO and GRC Audiences Prepared in Collaboration with Weaver and Assury Enforce | August 2026

GenAI Governance Is Not Agentic AI Governance Even as organizations are still struggling to establish effective governance for generative AI, adoption is rapidly shifting toward a more powerful — and more complex — model: agentic AI. Gartner predicts that by the end of 2026, 40% of enterprise applications will embed task specific AI agents, up from less than 5% in 2025, signaling one of the fastest technology adoption curves in recent history. Unlike early generative AI assistants, which were designed to respond to a single prompt with a single output, agentic AI systems can operate autonomously, invoking tools, executing multistep workflows, adapting behavior based on environmental feedback and re-initiating actions without direct human intervention. This fundamental shift breaks many of the assumptions underlying current AI governance frameworks, bringing into consideration whether and how nascent GenAI governance must adapt to systems that plan, act, observe and iterate without human oversight.

40%

<10s

of enterprise applications will embed task-specific AI agents by the end of 2026 — up from less than 5% in 2025 (Gartner)

the window in which a single autonomous agent deleted an entire production database and all volume-level backups

INCIDENT SPOTLIGHT — WHEN EVERY CONTROL PASSED The risks this shift introduces are no longer hypothetical. In April 2026, an AI coding agent deployed by PocketOS, an automotive SaaS startup, encountered a credential mismatch in the company’s staging environment and, rather than halting for human review, autonomously resolved the problem — locating an API token provisioned for an unrelated purpose and leveraging it to issue a single destructive API call that deleted the company’s entire production database and all volume-level backups in under ten seconds. This despite the agent’s own system prompts explicitly prohibiting destructive, irreversible actions without user approval. Yet not a single control failed. Governance failed by not anticipating the agent’s ability to autonomously resolve an issue and ignore system prompts restricting the execution of the task at hand, and no compensating mechanism existed to interrupt an autonomous action chain before it became irreversible.

Governance for generative AI and agentic AI are not evolutions of the same problem, but distinct approaches for distinct operating models — one focused on content and interaction, the other on autonomy, orchestration, control boundaries and accountability at machine speed.

Existing frameworks — including the NIST AI Risk Management Framework, ISO/IEC 42001 and the EU AI Act — were not designed with agentic AI in mind; each was conceived and published before autonomous, multistep AI systems reached meaningful production scale. Indeed, in January 2026, NIST’s Center for AI Standards and Innovation issued a formal request for information seeking public input on practices and methodologies for the secure development and deployment of AI agent systems.

However, the apparent governance gap does not render these frameworks irrelevant. Each contains controls and provisions that speak directly to the risks agentic AI introduces — around accountability, human oversight, risk classification and operational governance — even if those provisions were not written with agent-specific deployment patterns in their authors’ view. Auditors and those in charge of AI governance within their organizations should review the existing requirements within their favored AI governance guidance documentation, such as AI RMF, ISO/IEC 42001 and the EU AI Act, to identify how they can materially reduce agentic AI risk today and could constitute a baseline for the implementation of future agent-based AI deployments, whether developed internally or acquired from a vendor.

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 2

The Governance Gap in Agentic AI An Overview of AI Governance Organizations that are actively incorporating artificial intelligence risks and threats within their governance frameworks often rely on one of the three best-known frameworks to date:

ISO 42001

ISO 42001 — Artificial Intelligence Management System — is a very familiar framework for organizations already certified to ISO 27001 for their cybersecurity practices, with a heavy emphasis on prescriptive controls that organizations must implement to be certified against the standard.

NIST RMF

NIST AI Risk Management Framework (AI RMF) — is a guidance document that helps organizations manage risks from AI systems by focusing on four iterative functions — Govern, Map, Measure and Manage — to integrate risk and trustworthiness considerations across the AI lifecycle.

EU AI Act

The EU AI Act was not designed to be a governance framework; however, it is often interpreted as one as it enforces stringent obligations on the use of high-risk AI systems within the European Union, bans practices deemed to create unacceptable risks and sets a baseline of transparency rules and governance requirements for lower risk AI uses.

Other frameworks and regulatory requirements exist or are in development, including the Cloud Security Association’s AI Security Maturity Model which focuses on AI security programs, the Texas Responsible AI Governance Act (TRAIGA) which borrows heavily from specific elements of the EU AI Act and the NIST AI RMF or the upcoming AIUC-1 certification.

© COPYRIGHT 2026, 2023, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 3

Why Existing Controls Fail Traditional AI governance frameworks were designed around a simple model: one prompt in, one response out, one log entry.

The risk surface was bounded and static. A human reviewed the output. Remediation was manual but feasible.

Agentic AI systems operate on fundamentally different assumptions. A single user session may produce 20-50 autonomous tool calls. The agent decides which tools to invoke, what parameters to pass and in what sequence — based on intermediate results from prior calls. Risk is cumulative across the session, not static per call. The agent may hold permissions appropriate for some actions but not others within the same session.

This expanded universe of possible actions introduces governance gaps that existing requirements, regulations or controls may not address:

Gap

What It Means in Practice

Session-Level Risk Accumulation

Current AI governance controls evaluate whether an AI prompt stays within its authorization boundary solely within the context of the prompt being evaluated.

However, a sequence of individually permitted steps can collectively exfiltrate data, modify production systems or violate segregation of duties. No existing control evaluates whether the cumulative effect of an agent's multiple actions has crossed an authorization boundary or presents a risk that the tasks evaluated individually do not.

Action-Level Authorization

Current credential-based controls validate only whether an agent can call a tool, without considering whether this specific call, with these specific parameters, is within the authorized scope at a specific point in a session. Agentic AI’s ability to autonomously initiate calls to various tools as deemed necessary by the agent, not by a human-defined or monitored prompt, requires that the full context around the call is evaluated: tool, parameters, agent identity, session state prior actions.

Dynamic Autonomy Management

There is no mechanism to downgrade or escalate an agent's authorized autonomy midsession based on risk accumulation. An agent that begins a session with broad read/write permissions cannot be automatically restricted to read-only for the remainder of the session when a threshold is crossed or a task initiates access to a more sensitive context than where the agent started.

Chain-of-Custody Evidence

Demonstrating governance control implementation requires collecting evidence that an action was evaluated before it was performed. Given agentic AI’s ability to autonomously select what sequence of tasks and tools to initiate, that evaluation must be performed at every step of the agentic AI execution chain, without human intervention. The artifact must show that each tool call was evaluated against policy, the decision was PERMIT, and the session context at the moment of evaluation must be documented.

© COPYRIGHT 2026, 2023, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 4

The Four Compliance Patterns That Appear Sufficient — But Are Not When designing a controls inventory for the agentic AI era, many organizations implement the foundational controls to align with their selected framework and conclude that they have provided sufficient coverage across their agents. Depending on the framework and the complexity of the environments, risks exist that compliance components may appear to provide the level of coverage required, while leaving elements exposed that fail to address the gaps outlined above:

1

2

3

4

Policy-only compliance Every existing AI framework requires extensive policy and governance documentation, none less than Clauses 4-5 of ISO 42001 (context and leadership). Documentation produces no technical evidence that those policies are enforced in production. Auditors checking Clause 8 will find documented intent with no enforcement artifact.

Logging as governance Security Information and Event Management (SIEM) and observability tools can track and document what actions agents took and what tools they deployed. However, ISO 42001 Clause 8.1 (operational planning and control), NIST AI RMF MANAGE 1.3 and EU AI Act Article 14 (human oversight) each require that a governance control evaluated the action before execution. Logging is a necessary and required component of the three frameworks (ISO Clause 9.1 and Annex A.6.2.8 Event logging, NIST MEASURE 3.3, EU AI Act Article 12), but not sufficient. Logs don’t capture whether the proposed agent’s next step was evaluated before it was authorized, but merely that it happened, irrespective of whether it should have been allowed or not.

Identity and Access Management (IAM) and Role-Based Access Control (RBAC) practices Identity controls govern which credentials can invoke the AI system. They do not evaluate whether a specific AI action — with specific parameters, in a specific session context — is within authorized scope.

IAM answers: can this agent call this tool? Governance answers: should this agent make this specific call, right now, given what has already happened in this session?

Vendor compliance inheritance Though unique to agentic AI governance, there is often a misunderstanding about the compliance activities that organizations can inherit from their vendors. Anthropic, Azure OpenAI and AWS Bedrock compliance attestations document the model provider’s controls; however, the controls cannot and do not address how the organizations relying on these vendors’ models deploy tools as required by the organization. Specifically, the EU AI Act explicitly places these obligations on the deployer (the organization using the models), not the provider (the AI model vendor).

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 5

The Role of the Model Control Protocol Often, organizations seeking to implement governance around their agentic AI activities focus on the Model Control Protocol (MCP) to support their efforts and evidence collection.

MCP is an open protocol that standardizes how AI systems connect to external data sources, tools and services. Prior to MCP, integrating an AI model with external systems required bespoke, vendor-specific connectors for every tool or data source — a model that did not scale as agentic deployments grew in complexity. MCP addresses this by defining a common communication layer between an AI host application, a client that manages tool calls on the model’s behalf and servers that expose discrete capabilities such as database queries, API calls, file operations or code execution. The protocol addresses two important aspects of agentic AI: a standardized method for sharing data with large language models and a standardized way for those models to act on behalf of users. In doing so, MCP has become the de facto infrastructure layer through which agentic AI systems exercise real-world authority, making it directly relevant to any organization with governance obligations over AI deployment.

CONNECTIVITY STANDARD — NOT A GOVERNANCE FRAMEWORK As a platform principally designed to unify authentication and communications between agents and the tools they may invoke, MCP isn’t designed to close the agentic AI governance gaps identified above. However, thanks to its central coordination role, MCP may support improved governance by providing a single interface to monitor and log tool invocations, authorization decisions and data access patterns. MCP is best understood as a connectivity and interoperability standard, not a governance framework—and the gap between those two functions is precisely where the controls embedded in the AI RMF, ISO/IEC 42001 and the EU AI Act must operate.

Practitioner Guidance: What to Ask For The following questions are designed for CISO and GRC audiences evaluating an organization’s agentic AI governance posture — whether in an internal assessment, a design partner qualification or a third-party audit. They are organized by the gap they surface.

For CISOs ⊲ Can you show me a governance receipt for a specific agent tool call that occurred last Tuesday? Not the log — the receipt that shows what policy evaluated it, what the decision was and what the session context was at the time of evaluation. ⊲ What happens when an agent’s cumulative risk score crosses a threshold midsession? Is there a runtime mechanism that downgrades its autonomy, or does a human have to manually intervene? ⊲ If I revoke an agent’s permissions today, can it still call downstream tools using credentials it already holds? Or does it only hold credentials to the governance proxy? ⊲ What is the chain-of-custody for a governance receipt from the moment it’s written to the moment an auditor reads it?

Can the receipt be modified without detection? ⊲ Show me the policy that governed agent X’s access to the financial reporting database last quarter. What version was it? When was it last changed?

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 6

For GRC and Compliance Teams ⊲ For our ISO 42001 Clause 8.1 evidence package: can you produce governance receipts for all agent tool calls in the period under audit, filtered by Annex A control reference? ⊲ For our EU AI Act Article 14 evidence: show me the HITL escalation log for the audit period, including the escalation trigger, the human decision and the resolution timestamp. ⊲ For NIST AI RMF Govern 1.2: is principal identity captured at the time of each enforcement decision, or only at authentication? Can I filter the log by principal and see every action that principal agents took? ⊲ For our post market monitoring posture (EU AI Act Article 72): what is the process for identifying a serious incident in the governance log, and what does the regulatory reporting artifact look like? ⊲ Can you demonstrate that the governance controls functioned continuously throughout the audit period — not just on the days we tested?

For Auditors ⊲ Request governance receipts, not audit logs. The distinction matters: an audit log records that an action occurred; a governance receipt records that a control evaluated the action before it occurred. ⊲ Ask for continuous production evidence spanning the full audit period. Predeployment test results and point-in-time sampling do not satisfy ISO 42001 Clause 9 or EU AI Act Article 26. ⊲ Verify chain integrity independently. A hash-chained receipt log should be verifiable without access to the live governance system. If it cannot be verified independently, it does not meet tamper-evident evidence requirements. ⊲ Distinguish NIST AI RMF from NIST 800-53. An 800-53 control mapping does not demonstrate AI RMF Govern/Map/ Measure/Manage function coverage. Ask for explicit AI RMF subcategory mappings. ⊲ Do not accept vendor compliance inheritance as deployer compliance. Model provider attestations document providerside controls. Article 26 of the EU AI Act places deployer-side obligations on the organization. ISO 42001 does not use the provider/deployer construct; the analogous duties flow from Clauses 5 and 8 and Annex A.2, A.3, and A.9.

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 7

Enhancing Agentic AI Governance with ISO/IEC 42001 ISO/IEC 42001:2023 is the first international standard for AI Management Systems. Unlike framework guidelines, it has an auditable certification pathway. Auditors evaluate evidence of operational control — not documentation of intent. The standard runs from Clause 4 (organizational context) through Clause 10 (continual improvement). Two clauses expose the most persistent gaps in organizations deploying agentic AI.

The Two Clauses That Matter Most Clause

Requirement and Audit Implication

Clause 8 — Operation

Requires that AI system impact assessments are performed and that operational controls are in place and demonstrably functioning. Annex A.9 specifically addresses controls on AI system use — including autonomous decisions made by deployed AI. Auditors look for technical evidence of enforcement, not documented intent. The auditor's question: "Show me evidence that your AI governance controls were applied to actual AI decisions in production, in the period under audit, and that the controls functioned as intended."

Clause 9 — Performance Evaluation

Requires continuous monitoring of AI system performance and control effectiveness. "Continuous" means ongoing production evidence — not point-intime testing or pre-deployment results. Evidence must span the audit period. A sample of test results from a staging environment does not satisfy Clause 9 for a system in production.

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 8

Key Controls and the Evidence They Require Clause / Control

Requirement Summary

Evidence Request

8.2

AI risk assessment

Real-time cumulative risk scoring per session; tool sensitivity classification; Human-In-The-Loop (HITL) thresholds documented and enforced

8.4

AI system impact assessment

AI system impact assessment records (effects on individuals, groups and society) linked to the operational controls that address the assessed impacts; per-call runtime enforcement evidence belongs under Clause 8.1 (Operational planning and control)

10.1

Nonconformity and corrective action

Records of enforcement events triggering escalation, session termination or HITL intervention; incident classification separate from general logs

A.9.3

Objectives for responsible use of AI systems

Documented responsible-use objectives mapped to enforcement policy; policy denial records with explicit reason; principal accountability on every enforcement decision

9.1

Monitoring, measurement, analysis and evaluation

Hash-chained audit logs; tamper-evident storage; evaluation latency metrics; records spanning the full audit period without gaps

9.2

Internal audit

Immutable log files; checksums; retention periods meeting minimum requirements (90 days default for most frameworks); chain integrity verifiable independently of the governance system

A.5

Assessing impacts of AI systems

Assessed risks mapped to functioning runtime controls — not just documented in a risk register

A.9.2

Autonomy management

Records showing the mechanism by which agent autonomy was managed during sessions, including any escalation, restriction or demotion events

A.10

Third-party AI use

Evidence that the organization's own governance controls apply to deployed agent behavior — not inherited from the model vendor

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 9

NIST AI RMF — Runtime Coverage Requirements The NIST AI Risk Management Framework (AI 100-1, 2023) organizes requirements into four functions: Govern, Map, Measure and Manage. Unlike NIST SP 800-53, the AI RMF uses subcategory identifiers (e.g., Govern 1.1) rather than traditional control IDs. The following subcategories are most directly implicated by agentic AI deployments.

Subcategory

Requirement Summary

Evidence Required for Agentic AI

Govern 1.1

Legal and regulatory requirements involving AI are understood, managed and documented.

Policies-as-code with version control; pertenant policy sets; enforcement decisions logged with policy IDs cited

Govern 1.2

The characteristics of trustworthy AI are integrated into organizational policies, processes, procedures and practices.

Principal tracking (identity, roles) on every enforcement decision; tenant isolation; API key scoping

Govern 1.7

Processes for decommissioning and phasing out AI systems safely are in place.

Tool de-registration records; agent autonomy zone enforcement preventing orphaned agents from continuing to operate

Govern 2.2

The organization’s personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures and agreements.

Tool sensitivity classification (low/medium/ high/critical); autonomy zones; policy catalog with risk scores on every log entry

Map 1.1

Context is established for AI risk assessment by defining purpose, scope and use cases.

Autonomy zones define operational context; tool registration declares endpoint, sensitivity and authorized scope

Map 1.5

Organizational risk tolerances are determined and documented.

Autonomy levels 0–3; risk thresholds (HITL at ≥80, hard deny at ≥120); configurable per tenant; enforced at runtime

Measure 1.1

Approaches and metrics for measurement of AI risks are selected and implemented.

Cumulative risk scoring per session; tool sensitivity increments; risk bands; evaluation latency

Measure 2.5

The AI system to be deployed demonstrated to be valid and reliable. Limitations of generalizability beyond the conditions under which the technology was developed are documented.

Per-call decision records with tool, parameters, risk delta, cumulative session score and outcome

Manage 1.3

Responses to high-priority AI risks are developed, planned and documented.

Real-time block/allow/HITL enforcement; autonomy downgrade mid-session; approval workflows with logged reason

Manage 2.4

Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.

HITL approval chains; break-glass policies; session-level autonomy demotion; approval lifecycle tracked end-to-end

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 10

EU AI Act — High-Risk AI System Obligations The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) introduces binding obligations for providers and deployers of high-risk AI systems. Agentic AI systems operating in critical infrastructure, employment and worker management, access to essential private and public services (including credit and insurance eligibility), law enforcement, migration and border control and administration of justice are likely to qualify as high-risk under Annex III. Health Care AI systems typically qualify as high-risk via Annex I (the medical devices / MDR pathway), not Annex III. The following articles create the most direct runtime governance obligations.

Article

Title

Runtime Governance Requirement

Evidence Required

Art. 9

Risk management system

Establish, document, implement and maintain a risk management system for highrisk AI systems throughout their lifecycle.

Risk management must be ongoing — not a point-in-time assessment.

Session-level risk scoring; realtime autonomy controls; HITL thresholds; risk management records spanning the audit period

Art. 12

Record-keeping

High-risk AI systems must automatically log events sufficient to enable post market monitoring, including the start and end of operation, input data references, verification data and identification of involved persons.

Immutable, tamper-evident, hashchained audit logs; automatic logging on every tool invocation; S3-compatible retention with object lock

Art. 13

Transparency

High-risk AI systems must be sufficiently transparent to enable deployers to understand and interpret outputs. Every governance decision must be traceable to specific policy logic.

Per-decision reason strings; policy ID attribution; human-readable explanation of why a call was permitted, blocked or escalated

Art. 14

Human oversight

High-risk AI systems must be designed to enable effective human oversight. Humans must be able to intervene, override or halt the system. Oversight mechanisms must be built into the system — not added as a manual process after the fact.

HITL approval workflows; autonomy level demotion midsession; breakglass override capability; approval lifecycle records from trigger to resolution

Art. 17

Quality management system

Providers of high-risk AI systems must implement a quality management system covering the entire lifecycle. Policy governance and control versioning are foundational requirements.

Policy-as-code in version control; policy catalog with explicit control IDs; tenant-scoped policy sets; audit trail of policy changes

Art. 26 §5

Deployer monitoring obligations

Users (deployers) of high-risk AI systems must monitor AI system operation on the basis of instructions for use and report serious incidents to the provider and competent authorities.

Per-session risk monitoring; realtime autonomy demotion; tool call count tracking; session termination records with reason

Art. 72

Post-market monitoring

Serious incidents and malfunctioning must be identified, reported and documented.

Incident data must be available in a structured format for regulatory reporting.

Denial reason records; risk threshold hard-deny logs; approval rejection records; incident severity classification separate from general telemetry

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 11

Deployer vs. Provider Obligations A COMMON MISCONCEPTION Model provider compliance documentation (Anthropic, Azure OpenAI, AWS Bedrock) does not satisfy deployer obligations under the EU AI Act. Article 26 places explicit monitoring and oversight duties on the organization deploying the AI system. The deployer must implement and maintain their own governance controls and must be able to demonstrate their operation independently of any vendor attestation.

Framework Convergence: What All Three Require Despite different structures, scopes and jurisdictions, ISO 42001, NIST AI RMF and the EU AI Act converge on the same foundational requirements when applied to agentic AI. The following table maps the requirement areas that appear in all three frameworks — and the specific artifacts each requires.

Requirement Area

ISO 42001

NIST AI RMF

EU AI Act

Required Artifact

Tamper-evident audit logs

Clause 9.1, A.6.2.8

Govern 1.1, Measure 2.5

Article 12

Hash-chained log entries; S3 object lock retention; chain integrity verifiable independently

Per-call governance receipts

Clause 8.1, A.6.2.8

Govern 1.1, Measure 2.5

Articles 12, 13

Timestamp, tool, parameters, policy evaluated, decision, reason, session context — on every call

Policy-version traceability

Clause 7.5, 9.1

Govern 1.1

Articles 13, 17

Policy IDs and versions cited on every enforcement decision; policy change history in version control

Continuous risk scoring

Clause 9.1, 8.2

Measure 2.5, Map 1.5

Article 9

Cumulative session risk score; risk band; tool sensitivity delta; updated on every tool call

Violation and block logging

Clause 10.1, A.9.2

MANAGE 1.3, MANAGE 2.4

Articles 9, 72

Block decisions with explicit reason; threshold breach records; denial reason preserved in log entry

Human oversight mechanisms

Clause 8.1, A.9.2

Manage 2.4

Article 14

HITL approval trigger records; approval/ rejection with reason; autonomy demotion events with timestamp

Principal accountability

Clause 5.3, A.3.2

Govern 1.2

Articles 14, 26

Agent identity, user principal, roles and tenant on every enforcement decision

Post-market monitoring

Clause 9.3, 10.2

MANAGE 4.1, MANAGE 2.4

Articles 26, 72

Session-level aggregates; incident classification; regulatory export format; severity tagging

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 12

The One-Layer Insight ONE ENFORCEMENT LAYER, THREE FRAMEWORKS The most operationally important observation from this mapping: because all three frameworks require the same underlying evidence — tamper-evident per-call records linking every agent action to a governance decision, a policy version and a principal identity — a single runtime governance layer, properly instrumented, can satisfy the core evidence requirements of all three simultaneously. This has material implications for compliance program design: organizations pursuing ISO 42001 certification, NIST AI RMF alignment and EU AI Act compliance do not need three separate technical programs. They need one enforcement layer that produces the right log schema.

Agentic AI Governance Tools The market for agentic AI governance tools is nascent, with capabilities and coverage that may differ significantly from one tool to another. Tools such as cloudeagle.ai focus on ensuring that human users activate agents only under controlled, leastprivileged conditions, while others like big.id emphasize discoverability of unsanctioned agents within the enterprise network, assigning identities to all agents and extending the existing data governance framework to include provisions regulating how much access agents should be given to data.

An option to enforce governance across all steps of the agentic AI execution chain is to leverage MCP and require a call evaluation every time an agent attempts to connect to a data source or a tool. Assury Enforce is one such tool that acts as a zero-trust runtime governance proxy for MCP tool calls. Its capabilities map to the control requirements documented above to implement agentic AI governance and close the coverage gaps left by traditional tools.

Architecture Overview Assury Enforce operates at the MCP execution boundary — between an AI agent and every downstream tool server it can reach. Every tool call passes through the proxy before execution. The proxy evaluates the call against OPA/ Rego deterministic policy (no LLM in the enforcement path) in under 5ms, produces a governance receipt and either permits, blocks or escalates the call.

Key architectural properties relevant to compliance evidence:

Credential starvation

Deterministic policy

Agents hold credentials only to the proxy endpoint — not tounderlying tool servers. The proxy holds and manages downstream credentials. This eliminates the possibility of credential bypass and produces a single, auditable enforcement point.

OPA/Rego policy evaluation is deterministic and explainable. Every permit and deny decision maps to a specific Rego rule. The rule ID is recorded in the governance receipt.

Hash-chained receipts

Self-hosted

Each governance receipt includes a SHA-256 hash of the prior receipt, producing a tamper-evident chain. Chain integrity is verifiable independently of the Enforce deployment.

No governance telemetry leaves the client’s infrastructure. Compatible with PHI data residency requirements and EU AI Act data sovereignty considerations.

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 13

Governance Receipt Schema — Mapped to Framework Controls Log Field

Framework Control(s) Evidenced

Purpose

Notes

event_id, timestamp

ISO 9.1 / EU Art. 12 / NIST Measure 2.5

Unique, ordered record of every enforcement event

Required for post-market monitoring; timestamp must be UTC

hash, previous_hash

ISO 9.1 / EU Art. 12

Tamper-evident chain integrity

SHA-256 chain; verifiable without access to live system

principal.id, principal. email, principal.roles

Clause 5.3, A.3.2 / NIST GOVERN 2.1 / EU Art. 14

Principal accountability on every decision

Roles captured at time of call — not just at authentication

agent.autonomy_level, agent.autonomy_zone

ISO A.9.2 / NIST Manage 2.4 / EU Art. 14

Autonomy state at time of call

Enables demonstration that autonomy was managed — not just documented

tool.name, tool. sensitivity, tool.mcp_url

Clause 8.2, A.6.2 / NIST MAP 1.1 / EU Art. 9

Tool identity and risk classification

Sensitivity (low/medium/high/ critical) drives risk delta calculation

decision.allow, decision. reason

Clause 8.1, A.9.2 / NIST MANAGE 1.3 / EU Art. 13

Permit/block outcome with humanreadable reason

Reason string is required for EU Art. 13 transparency; plain English

decision.policy_ids, decision.control_ids

ISO 7.5 / NIST Govern 1.1 / EU Art. 17

Policy version traceability

Specific Rego rule IDs; maps to policy version in version control

decision.needs_ approval, approval_id (top-level)

Clause 8.1, A.9.2 / NIST MANAGE 2.4 / EU Art. 14

HITL escalation trigger and approval lifecycle

Approval record linked by approval_id; outcome must be logged on resolution

workflow.cumulative_ risk_score, workflow. risk_band

Clause 8.2, 9.1 / NIST MEASURE 1.1, MAP 1.5 / EU Art. 9

Session-level risk state at time of call

Demonstrates ongoing risk management — not point-in-time assessment

decision.evaluation_ duration_ms

Clause 9.1 / NIST MEASURE 4.2

Policy performance measurement

Confirms governance layer is not introducing unacceptable latency

request.params, response.status_code, response.data

Clause 9.1, A.6.2.8 / EU Art. 12

Complete input/ output evidence for post-market monitoring

Params and response bodies included in receipt; subject to tenant redaction policy for PHI/PII fields

workflow.session_id, workflow.tool_call_ count, workflow.least_ autonomy_limits

Clause 8.3 / NIST MANAGE 1.3, MEASURE 1.1 / EU Art. 9, 14

Session continuity and least-autonomy enforcement state across the call chain

Enables demonstration that autonomy was dynamically constrained as tool-call count and risk accumulated within a session

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 14

Known Gaps in Current Reference Implementation No runtime governance implementation is complete. The following gaps are acknowledged in the Assury Enforce architecture as of Q1 2026 and represent areas where supplementary controls or roadmap items are required: EU AI Act Article 72 (post-market monitoring): Incident data is present in logs but there is no automated severity classification or regulatory reporting pipeline. Supplementary tooling required.

NIST AI RMF MEASURE 2.11 (fairness and bias): No bias or fairness telemetry is currently captured in the governance receipt schema. Requires additional instrumentation.

ISO 42001 Clause 9.3 (management review): Raw telemetry is available but there is no aggregated management dashboard export. Reporting layer required for formal management review evidence.

Geo-field absence: The geo-based access control policy exists, but the application-layer audit receipt does not currently record IP address, port or geolocation. A kernel-layer capture path (destination IP, port and SNI) is in development but not yet generally available; even once released, geo-IP enrichment for country and ASN attribution will require supplementary tooling. As of this writing, NIST 800-53 AU-3 (Audit Record Content) and AU-12 (Audit Generation) cannot be fully evidenced from the receipt alone; AC-17 (Remote Access) location-based restrictions and SC-7 (Boundary Protection) also depend on this telemetry.

Attestation period support: Current log offload produces continuous files with no concept of generating a bounded evidence package for a specific audit period. Export API enhancement required.

These gaps do not diminish the core evidence produced for Clause 8.1 and 9.1, Annex A.6.2 (AI system life cycle, including A.6.2.8 Event logging) and A.9.2 (Processes for responsible use), NIST AI RMF GOVERN 2.1 and 3.2, MANAGE 1.3 and 2.4, and MEASURE 1.1, and EU AI Act Articles 9, 12, 13, 14 and 15 — but they represent material items for organizations preparing for ISO 42001 certification or EU AI Act compliance assessment

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 15

Conclusion ISO 42001, NIST AI RMF and the EU AI Act were written by different bodies for different purposes. Their convergence on the same technical requirement — a runtime control that evaluates and records every autonomous agent action before execution, with tamper-evident evidence spanning the audit period — is not a coincidence. It reflects a shared recognition that the risk surface of agentic AI is structurally different from prior AI systems and that documentation, logging and identity controls are not sufficient governance responses.

The organizations that will demonstrate genuine compliance — rather than documented intent — are those that treat the runtime governance layer as a first-class infrastructure component: designed for auditability, operated continuously and capable of producing examiner-ready evidence on demand.

For CISOs, the near-term priority is establishing a single enforcement point at the agent-tool boundary — before the next compliance assessment cycle requires one. For GRC teams, the priority is updating control frameworks to include the new artifact types these frameworks require: governance receipts, session risk timelines, HITL escalation logs and policy version audit trails. For auditors, the priority is asking for these artifacts by name — and not accepting legacy evidence patterns as substitutes.

The frameworks have already converged. The evidence gap is structural. The path to closing it is operational.

ABOUT THIS PAPER This white paper was prepared in collaboration with Weaver and Assury, Inc. It reflects control findings from practical analysis of ISO/IEC 42001:2023, the NIST AI Risk Management Framework (AI 100-1, 2023) and EU Regulation 2024/1689 (EU AI Act) as applied to agentic AI deployments in enterprise environments. The Assury Enforce reference implementation is based on the AARM (Autonomous Action Runtime Management) specification — Errico, 2026 — arXiv:2602.09433. Control gaps identified are specific to implementations reviewed as of Q1 2026 and may not reflect current product capabilities.

© COPYRIGHT 2026, WEAVER AND TIDWELL, L.L.P. | FOR MORE INFORMATION VISIT WEAVER.COM | PAGE 16