Governance / Comparisons

FERZ is not IAM

FERZ is a runtime authorization architecture that emits pre-execution verdicts on proposed AI actions. IAM is an identity-and-access management architecture that authorizes principals to access resources. The two systems govern different objects, and no extension of IAM produces governance over AI-proposed actions.

This comparison addresses a distinction within the authorization category: identity-and-access authorization (IAM) and AI-action authorization (FERZ) operate on different objects. The architectural-class test is established in The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582); the category separation is grounded in A Taxonomy of AI Governance Approaches (Meyman, 2026; DOI 10.5281/zenodo.18275969).

Where the categories diverge

The two architectures diverge along four architectural axes.

Execution locus
FERZ

At the AI action proposal boundary. The authorization verdict precedes execution of the proposed action, with built-in action canonicalization and AI-action semantics.

IAM

At the identity-to-resource access boundary. The access decision precedes resource access by an authenticated principal.

Authority source
FERZ

Encoded policy evaluated against a canonicalized action specification, governed state, and policy version. The decision is action-centric.

IAM

Principal identity, role and group membership, ACL or RBAC/ABAC rules. The decision is identity-centric.

Evidence artifact
FERZ

A verdict in the canonical verdict space {ALLOW, DENY, ABSTAIN} with a proof-carrying authorization artifact sufficient for third-party verification.

IAM

An access grant, token, or session credential. Typically logged but not structured as a policy-versioned authorization artifact reconstructable from action specification and governed state.

Default execution behavior
FERZ

Fail-closed. Execution is blocked when governance conditions are not met.

IAM

Implementation-dependent. Many systems fail-open or have ambiguous semantics on policy gaps; default behaviors vary by vendor.

Why the distinction is structural

The two architectures authorize different objects. IAM authorizes identity-to-resource access: it answers "may this principal access this resource?" by evaluating identity attributes, role and group membership, and access control rules. FERZ authorizes AI-proposed actions: it answers "may this AI execute this proposed action in this context?" by evaluating a canonicalized action specification against governing policy and the current governed state. The model of an IAM system contains principals, resources, and permissions. The model of a FERZ system contains agents, actions, policy state, and execution context.

The authority source is categorically different. IAM evaluates the principal making a request: who they are, what roles they have, what permissions are attached. The decision is identity-centric. FERZ evaluates the proposed action itself: what operation is being attempted, with what parameters, against what governing policy, in what context. The decision is action-centric. An IAM system cannot evaluate whether a proposed AI action is permitted because the action specification is not in its model. It can only evaluate whether the calling principal is authorized to make calls to the underlying API.

The evidence artifacts also differ. IAM produces access grants, tokens, or session credentials that encode the result of an identity-to-resource decision. These artifacts are typically logged but not structured as policy-versioned authorization artifacts reconstructable from action specification and governed state. FERZ produces a verdict with an authorization artifact: each verdict is reconstructable from policy, context, and action specification, with evidence sufficient for independent verification without access to the governing system.

The structural claim follows. IAM is necessary in any complete system that handles authenticated principals; FERZ is necessary in any system where AI agents propose actions that require governance. The two architectures are layered, not substitutable: identity authorization gates who can interact with the AI system; FERZ gates what the AI may do. No extension of IAM to AI contexts produces AI-action authorization, because IAM lacks the action specification, governed state, and policy version that AI-action authorization requires.

What buyers often confuse

The most common conflations involve identity-class systems extended to AI workloads under AI-governance framing. The architectural argument applies regardless of presentation.

Traditional IAM platforms with AI service accounts.IAM platforms such as Okta or Azure AD configured with service accounts representing AI workloads. The platform authorizes the service account's access to backend resources, not the AI's proposed actions against governing policy.
Identity governance suites extended to AI workloads.Identity governance solutions such as SailPoint or Saviynt with AI-related entitlements and access reviews. The system addresses identity attestation and entitlement management, not runtime authorization of proposed AI actions.
Workload identity services for AI agents.Workload identity capabilities such as SPIFFE/SPIRE or cloud workload identities used to authenticate AI agents to backend systems. The system establishes identity for service-to-service calls; it does not evaluate proposed actions against governing policy.
Privileged access management applied to AI operators.PAM tools such as CyberArk or BeyondTrust regulating elevated access for engineers working on AI systems. The system gates access for human operators; AI agents and their proposed actions are outside its decision model.

Architectural diagnostic

Any vendor or product claiming AI governance can be evaluated against four architectural questions, anchored to The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582):

1
Pre-execution artifact

Does the system produce an artifact for the proposed AI action that exists before the action executes?

2
Reconstructable decision

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
Meyman, E. (2026). Observability Is Not Enforcement: A Doctrinal Framework for Distinguishing Compliance Instrumentation from Runtime Authorization in AI Governance Architectures. Zenodo. https://doi.org/10.5281/zenodo.18663864
Meyman, E. (2026). From Monitoring to Authorization: The Structural Shift in Agentic AI Governance. Zenodo. https://doi.org/10.5281/zenodo.18743974

The full corpus is available at FERZ Research and at the FERZ community on Zenodo.

Related doctrine and concepts

Observability is not authorization: visibility into AI behavior is necessary for oversight but does not constitute permission to act.
Authorization is not monitoring: monitoring describes; authorization decides.
A halt is not a verdict: stopping execution is an event; a verdict is a decision with a verifiable authorization artifact.
Three Problems Taxonomy: Visibility, Alignment, and Authorization as categorically distinct governance problems. Identity governance and AI-action authorization sit in different categories within this taxonomy.
Runtime authorization boundary: the architectural surface at which authorization decisions are evaluated and enforced.
Proof-Carrying Decisions: cryptographically verifiable artifacts emitted for every authorization verdict.

Frequently asked questions

Isn't IAM the standard for authorization in enterprise systems?

IAM is the standard for identity-to-resource authorization in enterprise systems. AI-action authorization is a structurally different problem: it operates on proposed AI actions, not on principals accessing resources. The two are layered, not substitutable. A complete AI deployment requires both.

Can IAM be extended to authorize AI actions?

No. The structural object of an IAM decision is the principal making a request. The structural object of an AI-action authorization decision is the proposed action itself, evaluated against governing policy and governed state. Extending IAM with additional attributes or rules does not introduce an action specification into the IAM model; the system continues to authorize identities, not actions.

Where does IAM fit in a FERZ-governed AI system?

IAM gates access to the AI system itself: who can submit prompts, who can call APIs, who can configure policies. FERZ gates what the AI may do once invoked. The two layers compose: an authenticated principal accesses the AI system through IAM; the AI proposes actions that FERZ evaluates. Both are necessary; neither replaces the other.

Some IAM vendors describe their products as "AI governance." Are those products providing AI-action authorization?

The word "governance" is broadly applied in enterprise software marketing. IAM products typically address identity governance, access governance, and entitlement management. These operate on identities and resources, not on AI-proposed actions. Without an action specification in the decision model and a policy-versioned verdict as the artifact, the product is not providing AI-action authorization.

What evidence does AI-action authorization produce that IAM cannot?

A verdict over a defined decision space for a proposed AI action, with an authorization artifact reconstructable from policy, context, and action specification, sufficient for independent third-party verification. IAM produces access decisions over identity-to-resource pairs; these are categorically different artifacts and do not constitute AI-action authorization.

Cite this page

FERZ, Inc. (2026). FERZ is not IAM. https://ferz.ai/governance/comparisons/ferz-is-not-iam

BibTeX
@misc{ferz2026notiam,
  author = {{FERZ, Inc.}},
  title  = {FERZ is not IAM},
  year   = {2026},
  url    = {https://ferz.ai/governance/comparisons/ferz-is-not-iam},
  note   = {FERZ Architectural Comparison}
}