AI-action authorization is a distinct architectural class. These comparisons demonstrate the architectural separation from eight adjacent categories that share surface features with FERZ: policy engines, AI Observability, identity and access management, Runtime Application Security, agent frameworks, guardrails, human-in-the-loop workflows, and Security Information and Event Management. Each comparison applies the same four-axis architectural test; each resolves to the same conclusion: the adjacent category operates in a different architectural layer and is not substitutable for AI-action authorization.
These comparisons are grounded in two corpus papers. The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582) establishes the architectural-class test that any AI-action authorization architecture must satisfy. A Taxonomy of AI Governance Approaches (Meyman, 2026; DOI 10.5281/zenodo.18275969) distinguishes Visibility, Alignment, and Authorization as the three categorically distinct governance problems. Each comparison page applies these frameworks to a specific adjacent category, applying the same architectural diagnostic across the set.
A policy engine is a general-purpose policy decision point that evaluates caller-provided queries against caller-provided rules. The category includes OPA, Cedar, and the broader rule-engine family (Drools, IBM ODM, business rules management systems).
A policy engine can be a useful component within an AI-action governance architecture; it does not by itself constitute one. The properties that distinguish AI-action authorization are architectural commitments, not policies that can be added.
AI Observability is the descriptive instrumentation layer: dashboards, traces, metrics, and alerts describing what AI systems did. The category produces records of behavior after the fact.
An observability artifact is produced after the action it describes. An authorization artifact must exist before the action it permits. Records and verdicts are not points on a spectrum; they are different kinds of object.
IAM authorizes identity-to-resource access: it answers whether a principal may access a resource. The decision basis is identity attributes, role and group membership, and access control rules.
IAM gates who can interact with the AI system; FERZ gates what the AI may do. The two architectures are layered, not substitutable, because IAM lacks the action specification, governed state, and policy version that AI-action authorization requires.
Runtime Application Security is a class of security tools that detects and blocks attacks at runtime by inspecting requests, function calls, and data flows against attack signatures or behavioral baselines.
Runtime Application Security asks whether an action is an attack; FERZ asks whether an action is authorized by policy. The architectural class remains security and attack-detection regardless of what is being protected.
All eight comparisons share the same architectural framework: four axes (action boundary, decision basis, artifact type, failure mode) that distinguish AI-action authorization from adjacent categories. The framework produces a portable diagnostic, anchored to The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582), applicable to any vendor or product claiming AI governance:
Is the authorization artifact reproducible from policy, canonicalized action specification, and governed state, sufficient for independent third-party verification?
3
AI-specific verdict semantics
Does the system include an ABSTAIN verdict with explicit fail-closed semantics pending authorized human override?
4
Default failure behavior
Is fail-closed the architectural default, or an opt-in configuration?
FERZ answers all four questions affirmatively by architectural commitment. Any architecture claiming AI governance that fails one or more of these is operating in an adjacent category, not in AI-action authorization.
References
Meyman, E. (2026). The Authorization Artifact Test: Applying the Impossibility Result to Ex-Ante Regulatory Regimes. Zenodo. https://doi.org/10.5281/zenodo.20013582
Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. Zenodo. https://doi.org/10.5281/zenodo.18275969
Meyman, E. (2026). On the Impossibility of Observability-Based Authorization: A Formal Impossibility Result for Ex-Ante AI Governance. Zenodo. https://doi.org/10.5281/zenodo.19647542
Governance doctrine: the doctrinal foundations underlying the comparisons (observability is not authorization; a halt is not a verdict; authorization is not monitoring).
Three Problems Taxonomy: Visibility, Alignment, and Authorization as categorically distinct governance problems.