There is no single globally adopted control framework for critical agentic systems today. What exists instead is a layered patchwork of risk frameworks, management system standards, legal requirements, cyber control families, human oversight requirements, runtime guardrails, and vendor or application-level safety patterns. NIST AI RMF is voluntary and broad. ISO/IEC 42001 is an AI management system standard. The EU AI Act imposes legal requirements on defined high risk AI use cases. NIST SP 800-53 and CSF 2.0 provide security and resilience control families. OWASP and vendor guidance provide increasingly practical advice for agents, tools, memory, and approvals. Taken together, these are substantial, but they are not the same thing as one unified execution time control architecture for critical agentic systems [1][2][3][9][10][11][12][13].
That distinction is important as agentic systems change the control problem. A conventional model that scores, predicts, or recommends can often be governed largely through policy, documentation, monitoring, and human sign off. A critical agentic system can go further. It can initiate payment, approve release, alter access, disclose protected data, trigger procurement, dispatch logistics, or control physical operations. Once the system can commit an external effect, governance stops being only a matter of policy quality or model behaviour. It becomes an architectural question about if authority, admissibility, and control still hold at the moment the action becomes real [1][3][9][12].
1. Governance and risk management controls
The most mature category today is ex ante governance and risk management. NIST AI RMF gives organisations a voluntary structure for managing AI risk through four core functions, Govern, Map, Measure, and Manage. It’s deliberately broad and lifecycle oriented rather than tied to one technical architecture or one sector [1]. ISO/IEC 42001 plays a related role from a management system perspective. It sets requirements and guidance for establishing, implementing, maintaining, and continually improving an AI management system inside an organisation [2]. The EU AI Act also requires a risk management system for high risk AI systems and treats risk management as a continuous lifecycle process rather than a one off gate [3][4].
These are real controls, and they are important. They define ownership, policy, accountability, assurance, documentation processes, and organisational discipline. But they aren’t, by themselves, commit-time controls. They tell an organisation how to govern AI responsibly. They don’t, on their own, specify a universal runtime mechanism that prevents a critical agentic action from committing when authority has changed, evidence is stale, or the action path has drifted [1][2][3][4].
2. Data, documentation, and transparency controls
A second strong category is data governance, technical documentation, record keeping, and transparency. The EU AI Act is especially explicit here for high risk AI systems. It requires controls for data and data governance, technical documentation, record keeping, and transparency and provision of information to deployers [3][5][6]. This is valuable because critical systems fail not only from poor decisions but also from poor evidence, unclear capabilities, incomplete instructions, and missing audit trails.
This category improves traceability and legal defensibility. It helps organisations show what the system was supposed to do, how it was developed, what data discipline was applied, and what operators were told. But it’s still mostly descriptive and evidential. It strengthens governance around the system. It doesn't necessarily stop a bad transaction or an illegitimate action at the exact moment of commitment [3][5][6].
3. Human oversight controls
Human oversight remains one of the clearest and most established control methods in today’s landscape. The EU AI Act requires human oversight for high risk AI systems and expects systems to be designed so natural persons can oversee them effectively [3][7]. OpenAI’s official agent safety guidance makes a similar practical recommendation in application design terms. It advises keeping tool approvals on and using a human approval node for operations [12]. OWASP guidance for AI agents also recommends explicit authorisation for sensitive actions and separation of trust levels across tools and agents [10][11].
These controls are useful, particularly when the main risk is premature autonomy or unclear delegation. But human oversight isn’t a magic answer. In practice, oversight can degrade into rubber stamping, be applied at the wrong stage, or miss the true commit surface entirely. If approval happens upstream while the real irreversible action occurs later on a different rail, service, or actuator path, then the existence of a human checkpoint does not guarantee that governance still exists where it matters [3][7][10][12].
4. Security, identity, access, and tool permission controls
The security control layer is better developed than many people realise. NIST SP 800-53 provides a broad catalogue of security and privacy controls for information systems and organisations, covering areas such as access control, least privilege, audit and accountability, system integrity, and contingency planning [9]. NIST CSF 2.0 provides a higher level operational structure through Govern, Identify, Protect, Detect, Respond, and Recover [13].
For agentic systems specifically, OWASP’s AI Agent Security Cheat Sheet and related agentic guidance now address tool security, least privilege, permission scoping, explicit tool authorisation for sensitive operations, separation of trust levels, and emerging agent specific threats [10][11]. This is one of the most practically relevant parts of the current landscape because agents expand risk through tools, plugins, external services, memory, and multi-step execution.
This category is essential, but it still has a boundary. Security controls answer who can access which systems and how abuse can be constrained. They do not automatically answer if a particular irreversible action remains legitimate at the moment of commitment under current authority, current state, and current admissibility conditions. In other words, cyber control is necessary for critical agentic systems, but it is not identical to runtime governance of commitment [9][10][11][13].
5. Runtime guardrails and workflow constraints
The market today also contains a growing set of runtime guardrails. These include schema validation, policy checks, constrained tool invocation, approval nodes, execution sandboxes, content filters, memory restrictions, and workflow-level gating. OpenAI’s guidance explicitly recommends guardrails for user inputs and human approval for operations, particularly when tools are involved [12]. OWASP’s current agentic guidance is similar in spirit, with practical emphasis on permission boundaries, tool misuse prevention, and securing the execution environment [10][11].
This category is important because it’s the closest thing the current market has to execution time control for agents. But it’s still fragmented. Most runtime guardrails today are vendor specific, application specific, or threat specific. They can reduce risk materially, but they usually don’t amount to a complete architectural theory of authority, irreversibility, lifecycle validity, refusal, escalation, and audit binding for critical commitment paths. That’s a defensible synthesis from the current standards and guidance landscape, not a formal consensus statement from any one source [10][11][12].
6. Logging, audit, and replay controls
Logging and audit are well established control areas. The EU AI Act requires automatic record keeping capabilities for high risk AI systems, and deployers of high risk AI systems must keep logs for at least six months in the cases specified by the Act [3][5][8]. NIST SP 800-53 likewise treats audit and accountability as a core control family [9]. NIST CSF 2.0 reinforces the ongoing need for detection, response, and recovery rather than one-time approval [13].
These controls are indispensable for accountability, incident analysis, and evidential reconstruction. But most audit controls are retrospective unless they are bound directly to an execution gate. A perfect log of an illegitimate action isn’t the same thing as a system that could have refused the action before commitment [5][8][9][13].
7. Monitoring, testing, and incident response controls
A final established category is continuous monitoring, testing, and response. NIST AI RMF and its Playbook emphasise ongoing measurement and management rather than static approval [1]. NIST CSF 2.0 formalises the operational cycle through Detect, Respond, and Recover [13]. The EU AI Act also places obligations on deployers of high-risk systems to monitor operation and act when risks appear [3][8].
This control family is essential because agentic risk is not stable. Authority can change, environments drift, integrations mutate, and external dependencies fail. Continuous testing and operational monitoring are therefore part of any serious control stack. But again, they aren’t the same as a deterministic execution boundary that refuses an irreversible action when runtime conditions are no longer satisfied [1][3][8][13].
What the current landscape does well
Taken together, today’s control landscape is strong in four areas.
First, it’s strong in organisational governance and risk management. NIST AI RMF and ISO/IEC 42001 give organisations mature structures for policy, roles, risk processes, and lifecycle discipline [1][2].
Second, it’s strong in legal and documentation obligations for regulated or high risk contexts. The EU AI Act is especially important here [3][4][5][6][7][8].
Third, it’s strong in conventional cyber controls such as identity, least privilege, access control, audit, resilience, and incident response, particularly through NIST SP 800-53, NIST CSF 2.0, and OWASP’s security guidance [9][10][11][13].
Fourth, it’s improving in practical runtime containment for agents through approval nodes, tool permissions, input guardrails, and execution constraints [10][11][12].
That’s not trivial. Anyone claiming there are no meaningful controls today is wrong.
Where the landscape is still underdeveloped
The weaker area is commit-time governed execution for critical agentic systems. The current frameworks generally tell organisations how to manage risk, document systems, secure components, preserve logs, and maintain oversight. They are much less unified on the exact question of how to prove, at the moment an irreversible or consequential action would commit, that authority is still valid, admissibility still holds, refusal is still possible, and the commit path is non-bypassable.
That’s the gap OTANIS (Operational Trust and Authority Normative Integrated System) is trying to occupy.
However, it’s not a settled industry consensus that this is the missing layer. It’s a defensible synthesis from the fact that current standards and guidance are distributed across governance, compliance, security, oversight, monitoring, and application guardrails rather than converging on one shared runtime architecture for critical agentic commitment [1][2][3][9][10][11][12][13].
Where OTANIS differs from the other methods
OTANIS is best understood not as another management framework, not as another generic legal compliance regime, and not as another cyber checklist. Its distinctive claim is architectural.
In practical terms, OTANIS treats the model or agent as fallible and places the decisive governance question at the governed execution boundary, meaning the point where the system is about to cross into irreversible or materially consequential action. On that framing, governance isn’t merely a matter of policies around the system, nor only a matter of post hoc audit, nor only a matter of human review somewhere upstream. Governance exists for a critical action path only if authority, admissibility, and commitment conditions can still be shown and enforced at the point where the system is about to act.
That positions OTANIS differently from the current mainstream categories.
Compared with NIST AI RMF, OTANIS is narrower and more operational. NIST AI RMF is a lifecycle risk framework for managing AI risk across the organisation. OTANIS is aimed at the execution boundary for critical action paths [1].
Compared with ISO/IEC 42001, OTANIS isn’t primarily a management system standard. ISO/IEC 42001 helps an organisation establish and improve an AI management system. OTANIS is closer to a runtime governance architecture for specific critical agentic actions [2].
Compared with the EU AI Act, OTANIS isn’t a statute. The AI Act sets legal obligations, especially for high-risk systems, across risk management, data governance, documentation, record keeping, transparency, human oversight, and robustness. OTANIS would sit underneath or alongside that legal layer by addressing how a critical action path is actually mediated at execution time [3][4][5][6][7][8].
Compared with OWASP and vendor guidance, OTANIS is broader in governance intent but narrower in scope. OWASP and vendor guidance are extremely useful for securing agentic applications, constraining tools, and reducing misuse. OTANIS is trying to define the stronger question of when a consequential action may legitimately commit at all [10][11][12].
Compared with traditional cyber controls such as NIST SP 800-53, OTANIS isn’t trying to replace access control, audit, or resilience families. It assumes they are needed. What it adds is a more explicit authority and commit model for critical agentic execution [9][13].
How OTANIS can be implemented at the execution boundary in practice
At an engineering level, OTANIS requires a runtime control surface, formally ARETABA, at the governed execution boundary. Its claim is architectural rather than tied to one fixed engineering pattern. What matters is that the real commit surface is interceptable, non-bypassable, and fail-closed, and that authority, admissibility, provenance validity, dependency conformance, and freshness constraints are evaluated there rather than assumed from earlier workflow state. OTANIS also requires sufficient snapshot, traceability, and audit semantics at that boundary to make the decision attributable, reviewable, and reproducible against the declared governance artefacts.
In practice, that control surface may be implemented through policy engines, execution gateways, trusted orchestration layers, cryptographic protocols, hardware-backed attestation, signed commit bundles, or other mechanisms suited to the deployment context. For asynchronous or delegated execution paths, portable commit bundles are one important implementation pattern rather than the universal mechanism. They bind the permitted action to the boundary-resolved authority decision and allow the downstream execution substrate to reject execution unless a valid governed commit artefact exists. OTANIS therefore doesn’t prescribe a single enforcement technology. Its stricter claim is that, whatever mechanism is used, the governed boundary must remain real, non-bypassable, and causally prior to any declared irreversible effect.
Model-agnostic runtime governance and adjacent approaches
OTANIS is deliberately model-agnostic. It doesn’t assume that stronger alignment, lower hallucination rates, better prompting, or future gains in general capability will make model output trustworthy enough to authorise critical action on its own. NIST AI RMF treats trustworthiness as a set of characteristics to be managed in context, not as a permanent property that can simply be assumed [1]. Recent frontier model research has also shown that strategic misrepresentation and harmful agentic behaviour can arise under some conditions, which strengthens the case for keeping decisive control outside the model rather than inside its reasoning process [17][18]. Even if future systems were to approach AGI-like breadth, that wouldn’t by itself remove the need for external architectural control.
In that respect, OTANIS sits closest to a small group of adjacent model-agnostic runtime control approaches, though none appears equivalent in full scope. Runtime Assurance architectures provide an architectural framework for bounding less trusted or complex functions at run time [14]. Open Policy Agent provides a general purpose, domain agnostic policy engine that decouples policy decision making from enforcement and can therefore serve as a runtime authorisation layer [15]. Guardrail systems such as NVIDIA NeMo Guardrails also provide programmable controls across models, agents, and systems [16]. These are useful comparators, but they mainly provide runtime bounding, policy enforcement, or behavioural guardrails. OTANIS is intended to go further by binding authority, admissibility, refusal, escalation, traceability, and commit-time control to critical agentic actions.
The most realistic way to view OTANIS
The realistic view isn’t that OTANIS replaces the existing landscape. A serious critical agentic system would still need conventional governance and risk management, legal compliance, cyber controls, human oversight design, audit logging, testing, and incident response. OTANIS would make most sense as the architectural runtime governance layer that sits across those controls on the narrow set of action classes where irreversible or materially consequential commitment is at stake. So the stack would look something like this in conceptual terms.
Ex ante governance and risk discipline would still come from frameworks and management systems such as NIST AI RMF and ISO/IEC 42001 [1][2].
Legal obligations for high risk use cases would still come from regimes such as the EU AI Act [3][4][5][6][7][8].
Cyber control baselines would still come from NIST SP 800-53, NIST CSF 2.0, and agentic security guidance such as OWASP [9][10][11][13].
Practical application guardrails and approvals would still come from platform and application design guidance, including vendor guidance [10][11][12].
Then, for the narrow class of critical execution paths, OTANIS would provide the missing runtime governance layer that tries to ensure the action can’t commit unless the declared authority and admissibility conditions still hold at the governed point of commitment.
Final assessment
The control landscape for critical agentic systems today is materially better than the market rhetoric often suggests. Mature components already exist for governance, risk management, documentation, human oversight, cybersecurity, logging, and continuous monitoring [1][2][3][9][10][11][12][13].
But the landscape is still structurally fragmented. What exists today isn’t one universally adopted control framework for critical agentic execution. It’s a stack of partially overlapping frameworks and practices, each strong in its own domain, but not yet unified around commit-time authority enforcement for consequential or irreversible agentic actions. That conclusion is a synthesis from the standards and guidance reviewed here, not a formal statement issued by any one authority [1][2][3][9][10][11][12][13]. OTANIS’s value isn’t that it duplicates what NIST, ISO, the EU AI Act, OWASP, or vendor guidance already do, but that it tries to define the runtime governance layer they do not fully specify, namely how to make authority, refusal, admissibility, and audit binding hold at the governed commit event that mediates the transition from system intent into irreversible external effect.
If that architectural layer proves implementable and reviewable in practice, OTANIS could fill a real gap. If it does not, then the current patchwork remains what organisations must rely on. At the moment, the honest position is that the gap is real, the existing landscape is substantial but incomplete for this purpose, and OTANIS is best understood as an attempt to address that missing execution-boundary problem rather than as a substitute for the rest of the control stack.
References
[1] NIST, AI Risk Management Framework and AI RMF 1.0 Core. (NIST)
[2] ISO, ISO/IEC 42001:2023 AI management systems. (ISO)
[3] European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act and EU summary of the Act. (EUR-Lex)
[4] European Commission AI Act Service Desk, Article 9 Risk management system. (ai-act-service-desk.ec.europa.eu)
[5] European Commission AI Act Service Desk, Article 12 Record-keeping. (ai-act-service-desk.ec.europa.eu)
[6] European Commission AI Act Service Desk and EU AI Act resources, Article 13 Transparency and provision of information to deployers. (ai-act-service-desk.ec.europa.eu)
[7] EU AI Act resources, Article 14 Human oversight. (artificialintelligenceact.eu)
[8] European Commission AI Act Service Desk, Article 26 Obligations of deployers of high-risk AI systems. (ai-act-service-desk.ec.europa.eu)
[9] NIST, SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations. (NIST Computer Security Resource Center)
[10] OWASP Cheat Sheet Series, AI Agent Security Cheat Sheet. (OWASP Cheat Sheet Series)
[11] OWASP GenAI Security Project, Securing Agentic Applications Guide 1.0 and Agentic AI Threats and Mitigations. (OWASP Gen AI Security Project)
[12] OpenAI, Safety in building agents. (OpenAI Developers)
[13] NIST, Cybersecurity Framework 2.0. (NIST Publications)
[14] ASTM International, ASTM F3269-21: Standard Practice for Methods to Safely Bound Behavior of Aircraft Systems Containing Complex Functions Using Run-Time Assurance. (https://store.astm.org/f3269-21.html)
[15] Open Policy Agent, Open Policy Agent (OPA) Documentation. (https://www.openpolicyagent.org/docs)
[16] NVIDIA, NVIDIA NeMo Guardrails Library Developer Guide. (https://docs.nvidia.com/nemo/guardrails/latest/)
[17] Anthropic, Alignment Faking in Large Language Models. (https://www.anthropic.com/research/alignment-faking)
[18] Anthropic, Agentic Misalignment: How LLMs Could Be Insider Threats. (https://www.anthropic.com/research/agentic-misalignment)