Governance / Comparisons

FERZ is not Runtime Application Security

FERZ is a runtime AI-action authorization architecture with built-in action canonicalization, governed state, ABSTAIN-with-override semantics, and a proof-carrying authorization artifact. 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 can be a useful component within an AI system's defensive posture; it does not by itself constitute AI-action authorization.

This comparison addresses an adjacent category that shares the runtime property with FERZ: both architectures operate at runtime and can prevent execution. The distinguishing FERZ property is that the runtime decision is an authorization verdict evaluated against encoded policy and governed state, not an attack-detection verdict evaluated against threat signatures or behavioral baselines. The architectural-class test is established in The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582) and the category-separation framework in A Taxonomy of AI Governance Approaches (Meyman, 2026; DOI 10.5281/zenodo.18275969), which frames Visibility, Alignment, and Authorization as the three governance problems. Runtime Application Security addresses defensive security, a separate concern.

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.

Runtime Application Security

At the request-handling or function-invocation boundary inside the instrumented application runtime. Inspects activity as it flows through hooks placed in the application.

Authority source
FERZ

Encoded policy evaluated against a canonicalized action specification, governed state, and policy version. The question asked is whether the action is authorized.

Runtime Application Security

Pattern matching against attack signatures, behavioral analytics, or vulnerability fingerprints. The question asked is whether the action looks like an attack.

Evidence artifact
FERZ

A verdict in the canonical verdict space {ALLOW, DENY, ABSTAIN} with a authorization artifact reconstructable from policy, action specification, and governed state.

Runtime Application Security

An attack-detection record, block log, or alert. The artifact states what attack pattern was detected and what defensive response was taken.

Default execution behavior
FERZ

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

Runtime Application Security

Configurable. Products typically offer monitor-only, alert-only, or block-on-detection modes. Default behavior varies by product and deployment.

Why the distinction is structural

The two architectures ask categorically different questions even when both operate at runtime and both can prevent execution. Runtime Application Security asks whether an action is an attack: does this request match a known attack signature, does this function call deviate from baseline behavior, does this payload contain a vulnerability fingerprint. FERZ asks whether an action is authorized: does this proposed AI action, evaluated against encoded policy and governed state, fall within what governing policy permits. Attack-detection and policy-based authorization are different decision problems, and improvements in attack-detection do not produce authorization properties.

The authority sources do not substitute for each other. Attack signatures generalize across applications because attack patterns are well-studied: SQL injection, deserialization attacks, prompt injection. Authorization policies are domain-specific to the AI system being governed: which actions are permitted, under which conditions, against which governed state. A RASP system configured with AI-specific signatures detects more AI-specific attacks; it does not begin to evaluate whether a proposed action is permitted by policy. The two authority sources address different concerns and produce different evidence artifacts.

The evidence artifacts reflect this difference. A Runtime Application Security record states what attack pattern was detected and what defensive action was taken: "request matched SQL injection signature SI-042 and was blocked." A FERZ verdict states what was authorized: "policy version P-17 evaluated against canonicalized action A-921 in governed state G-558 and emitted verdict ABSTAIN." The first is an attack-detection log; the second is a policy-versioned authorization artifact. Both can be useful; they are not interchangeable, and a more sophisticated attack-detection log does not become an authorization artifact.

The structural claim follows. Runtime Application Security and FERZ compose well: Runtime Application Security can protect the FERZ control plane from attacks; FERZ can govern AI actions within an application that Runtime Application Security also protects. But applying Runtime Application Security to AI systems does not produce AI-action authorization. The architectural class remains security and attack-detection regardless of what is being protected. Calling a Runtime Application Security capability "AI governance" in the authorization sense is a category error.

What buyers often confuse

The most common conflations involve security-class systems repositioned as AI governance under runtime framing. The architectural argument applies regardless of presentation.

RASP products with AI-related attack-pattern updates.A Runtime Application Self-Protection tool such as Imperva or Contrast Security configured with detection rules for AI-specific attack patterns (prompt injection signatures, model-extraction probes). The system detects attacks; it does not authorize proposed AI actions against governing policy.
WAFs extended to AI API endpoints.Web application firewalls such as Cloudflare or AWS WAF with rules tagged for AI and ML endpoints. The system inspects HTTP traffic for attack patterns at the network boundary; it operates one layer earlier than the AI runtime and has no view of the proposed AI action specification.
Bundled "AI security and governance" platforms.Vendor offerings that combine attack detection, prompt-injection filtering, and output safety classifiers under an AI-governance label. The combined capability addresses defensive security; the governance label conflates security with authorization.
Anomaly-detection systems applied to AI behavior.Behavioral analytics tools that flag unusual AI activity against a learned baseline. The system detects deviation from observed behavior; it does not evaluate whether a proposed action is authorized by policy.

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). 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). 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). The Authorization Artifact Test: Applying the Impossibility Result to Ex-Ante Regulatory Regimes. Zenodo. https://doi.org/10.5281/zenodo.20013582
Meyman, E. (2026). From Monitoring to Authorization: The Structural Shift in Agentic AI Governance. Zenodo. https://doi.org/10.5281/zenodo.18743974
Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. Zenodo. https://doi.org/10.5281/zenodo.18275969

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.
Runtime authorization boundary: the architectural surface at which authorization decisions are evaluated and enforced.
Three Problems Taxonomy: Visibility, Alignment, and Authorization as categorically distinct governance problems. Runtime Application Security addresses a separate concern (attack-detection) outside the three governance problems.
Proof-Carrying Decisions: cryptographically verifiable artifacts emitted for every authorization verdict.

Frequently asked questions

Isn't RASP sufficient if we configure it with AI-specific detection rules?

A RASP product configured with AI-specific signatures detects AI-specific attacks. The decision basis remains attack-pattern matching. AI-action authorization requires evaluating proposed actions against encoded policy and governed state, not against attack signatures. The two decision problems are categorically different and do not substitute for each other.

We use a WAF to protect our AI endpoints. Isn't that runtime AI governance?

A WAF inspects HTTP traffic for attack patterns at the network boundary. It operates one layer earlier than the AI runtime and does not see the proposed AI action specification. WAFs are useful defensive infrastructure; they do not constitute AI-action authorization.

Can RASP and FERZ compose, or are they competitive?

They compose. RASP protects the runtime from attacks; FERZ authorizes AI actions against policy. RASP can defend the FERZ control plane itself; FERZ can govern AI actions within an application that RASP also protects. The two address different concerns and are layered, not substitutable.

What architectural properties distinguish FERZ from RASP applied to AI workloads?

Three properties: the authority source (encoded policy and canonicalized action specification versus attack signatures), the evidence artifact (authorization verdict with policy-versioned evidence versus attack-detection record), and the default execution behavior (fail-closed by architectural design versus configurable, often fail-passive in monitor-only deployments).

Vendors describe RASP-class tools as "AI security and governance." Is that accurate?

"AI security" is accurate; RASP is a security architecture. "AI governance" in the authorization sense is a category error if the underlying capability is attack-detection. Governance in the authorization sense requires policy-based decisions about proposed actions, not signature-based decisions about attack patterns.

Cite this page

FERZ, Inc. (2026). FERZ is not Runtime Application Security. https://ferz.ai/governance/comparisons/ferz-is-not-runtime-application-security

BibTeX
@misc{ferz2026notrasp,
  author = {{FERZ, Inc.}},
  title  = {FERZ is not Runtime Application Security},
  year   = {2026},
  url    = {https://ferz.ai/governance/comparisons/ferz-is-not-runtime-application-security},
  note   = {FERZ Architectural Comparison}
}