Two Control Planes, Two Questions: A Technical Comparison of Falcon AIDR and EnforceAuth

Abstract

Two runtime control architectures for AI agents are converging on similar vocabulary — “continuous authorization,” “runtime enforcement,” “control plane” — while implementing fundamentally different decision functions at different points in the request path. CrowdStrike’s Falcon AI Detection and Response (AIDR), combined with Continuous Identity for AI Agents, implements risk-adaptive access management: probabilistic threat detection at the prompt/interaction layer, cryptographically verifiable workload identity (SPIFFE), and event-driven access revocation via the Shared Signals Framework. EnforceAuth implements deterministic transaction authorization: a resource-side policy decision point evaluating OPA/Rego policy-as-code against full business context — tenant boundaries, delegated authority, segregation of duties, and commit-time application state — for every action by every identity.

This paper states an explicit threat model for agentic systems, decomposes both architectures against the NIST SP 800-207 / XACML reference model (PEP, PDP, PIP), analyzes decision semantics, enforcement-point placement, context resolution, delegation handling, revocation-versus-authorization timing, evidence artifacts, and failure modes, and specifies a composed reference architecture — with a three-policy Rego library and a validation methodology — in which Falcon risk signals become policy inputs to EnforceAuth authorization decisions. The conclusion is architectural and pointed: the systems answer different questions — “should this identity retain access?” versus “is this specific action permitted?” — and a complete agentic architecture requires both. For the first question, the market offers several credible platforms. For the second, the analysis in Sections 6–7 supports a stronger claim: EnforceAuth is the only platform purpose-built for deterministic, continuous authorization across applications, infrastructure, data, and AI workloads at runtime — and the alternatives usually proposed (rely on detection, extend IAM, build on raw OPA, wait for the endpoint platform) each fail on structural rather than roadmap grounds. Sections 7–8 make that case and quantify what it is worth.

1. Introduction and scope

Enterprises deploying autonomous agents face a control problem that neither classical endpoint security nor classical IAM was designed for: software identities that invoke tools, call APIs, mutate business records, and delegate to sub-agents at machine speed. Two vendors’ architectures now claim runtime control over this surface using overlapping language. This paper compares them at the level where the differences actually live — decision functions, enforcement-point placement, and context resolution — rather than at the level of marketing category.

1.1 Systems under comparison

• Architecture A — CrowdStrike. Falcon AI Detection and Response (AIDR) plus Continuous Identity for AI Agents, delivered on the Falcon platform. AIDR performs real-time inspection of prompts, responses, agent and MCP traffic. Continuous Identity — built on technology from CrowdStrike’s SGNL acquisition — eliminates standing privileges and grants, denies, and revokes access dynamically based on real-time risk, using SPIFFE-based workload identity and the Shared Signals Framework (SSF).
• Architecture B — EnforceAuth. The AI Security Fabric: a control-plane/data-plane authorization architecture in which OPA/Rego-compatible policies are evaluated at a resource-side decision point for every action, across four domains — applications, infrastructure, data, and AI workloads — for human and non-human identities, producing an immutable decision record per evaluation.

1.2 Method and posture

The comparison uses publicly documented behavior of Architecture A (vendor announcements and technical documentation, June–July 2026) and the documented architecture of EnforceAuth. Where Architecture A’s internals are not public, this paper reasons from the stated standards it employs (SPIFFE, SSF/CAEP) and the documented placement of its sensors and gateways, and says so explicitly. Performance figures for Architecture A are that vendor’s published claims; figures for Architecture B are design targets with the validation methodology given in Section 10. The posture is compositional: both architectures are treated as legitimate solutions to distinct sub-problems, and the fairness is deliberate — the paper’s pointed conclusion (Section 7: for the authorization layer, there is no second option) is only worth making if the comparison that produces it would survive the other vendor’s own architects reading it.

Framing note — AI safety vs. AI security. Neither system under comparison is an AI-safety (content guardrail) system, though AIDR includes content-policy detection. Both address AI security: control over what AI systems can access and do. The distinction within AI security — detection/access-risk versus business authorization — is the subject of this paper.

2. Reference model and terminology

To compare unlike architectures precisely, this paper maps both onto the policy-architecture vocabulary shared by XACML and NIST SP 800-207 (Zero Trust Architecture):

• PEP — Policy Enforcement Point. The component in the request path that intercepts an access or action and enforces the decision.
• PDP — Policy Decision Point. The component that computes the decision.
• PIP — Policy Information Point. Sources of attributes the PDP consumes: identity attributes, risk signals, application state.

Two further definitions carry the weight of the analysis:

• Access decision: whether an identity may hold or retain a session, token, credential, or entitlement to a resource class. Granularity: identity × resource. Typical verbs: grant, deny, revoke, step-up.
• Transaction authorization decision: whether one specific invocation — with its parameters, target record, and the application’s state at commit time — is permitted. Granularity: identity × action × parameters × state. Typical verbs: allow, deny, allow-with-obligations.

Formally: a detection/risk system computes D: signals → [0,1], compared against a threshold τ, with tuning trading false positives against false negatives. A deterministic authorization system computes A: (policy P, input i, data d) → {allow, deny} × obligations — a total, reproducible function of versioned artifacts. The consequences of that difference — for evidence, testing, and failure analysis — recur throughout Sections 6–10.

3. Threat model and control objectives

Comparing controls without stating the threat model invites category errors. Agentic deployments face at least four distinct failure classes, and the two architectures were built against different subsets of them:

The asymmetry is the point. T1 and T2 are adversarial problems: the input distribution is chosen by an attacker, novelty is guaranteed, and statistical generalization (detection) is the correct — indeed the only — tool. T3 and T4 are authorization problems: the action may be indistinguishable from normal behavior at the telemetry level, because it is normal behavior aimed at the wrong object or scale. A control that keys on anomaly cannot, even in principle, address a failure class defined by its non-anomalousness.

Control objective statement: a complete agentic architecture must (i) detect and evict adversarial presence (T1/T2) and (ii) bound every action — adversarial or not — to explicit business authority (T3/T4). Architecture A addresses (i); Architecture B addresses (ii); Section 9 composes them.

4. Architecture A: Falcon AIDR + Continuous Identity

4.1 Components and placement

• Falcon sensor (endpoint). The platform’s foundational telemetry source and enforcement hook on managed hosts. Announced endpoint capabilities extend AIDR to desktop AI applications and map prompts to downstream file, credential, process, and MCP activity (pre-beta at time of writing; GA targeted Q3 2026).
• AIDR interaction-layer inspection. Inline analysis of prompts, responses, agent traffic, and MCP server communications — detecting prompt injection, jailbreaks, model manipulation, data-leakage patterns, and unauthorized tool execution — deployed at browser, endpoint, and via native integrations with AI gateways (Azure API Management, Databricks, Kong, LiteLLM, and others). Published vendor figures: up to 99% detection efficacy at sub-30ms latency.
• Continuous Identity (SGNL technology). Risk-aware access management for human, non-human, and agent identities: SPIFFE-based verifiable workload identity replacing static credentials; access evaluated on who owns the agent, who is calling it, and device risk posture; standing privileges eliminated in favor of dynamic grant/deny/revoke; delegation context preserved through agent-to-sub-agent chains.
• Cross-component loop. AIDR inspects prompts and intent for permission misuse or manipulation and triggers Continuous Identity to revoke access — a detect→revoke loop propagated via the Shared Signals Framework.

Figure 1. Architecture A: interaction-layer PEPs feeding a platform risk PDP; enforcement expressed as access grant/deny/revoke via SSF.

4.2 Decision semantics

Mapped to the reference model (Figure 1): the PEPs are the Falcon sensor, browser extension, and gateway integrations — positioned at the interaction layer or on the managed endpoint. The PDP is a risk engine: detections and risk scores from native and third-party signals feed continuous evaluation of whether an identity should retain access. The PIPs are telemetry-shaped: endpoint posture, identity risk, prompt/traffic analysis, threat intelligence. Three properties follow:

• The decision object is access, not the transaction. Continuous Identity decides whether the agent keeps its entitlement; it does not evaluate the parameters of one API call against a business rule. SPIFFE answers “which workload is calling” with cryptographic strength — authentication of workloads — not “is this refund within this workload’s delegated limit.”
• The decision function is probabilistic. Risk scores and detections drive enforcement. This is the correct design for the adversarial classes T1/T2 — attacks are novel by construction and require statistical generalization — and it necessarily carries a residual false-negative rate and a tuning trade-off.
• Revocation is event-propagated. SSF/CAEP is a transmitter→receiver event framework: a risk event is emitted and receivers act on it. This is eventually consistent by design — excellent for killing sessions and tokens quickly, but it is not a synchronous allow/deny computed inside an individual transaction’s critical path.

5. Architecture B: EnforceAuth AI Security Fabric

5.1 Components and placement

• Control plane. Policy Studio (visual + Rego code editing), Git-backed Policy Registry integrated with CI/CD, unified Identity Graph across human and non-human identities, Decision Analytics, and a Compliance Engine mapping decisions to DORA, EU AI Act, SOX, HIPAA, and NIST AI RMF frameworks.
• Data plane. The Enforcement Agent is the PEP+PDP co-located at the resource side — deployed as a Kubernetes sidecar, an embedded library, or a gateway/service-mesh filter — evaluating policy in-path. Design targets: p50 < 2ms and p99 < 5ms at 100K+ decisions/sec/node (validation methodology, Section 10). An Identity Resolver normalizes the caller (user, service account, API key, AI agent); a Decision Logger writes an immutable record per evaluation; Policy Sync distributes updates in < 500ms.
• Policy model. OPA/Rego-compatible policy-as-code, extended for AI-workload patterns (agent identity, tool-call authorization, chain-of-agent delegation). Policies are versioned in Git, unit-tested and simulated in CI, composable across organizational units; every runtime decision cites the exact policy version that produced it.

Figure 2. Architecture B: Git-native control plane distributing policy to resource-side enforcement agents; every evaluation emits a decision record.

5.2 Decision semantics

The PEP and PDP are fused at the resource (Figure 2): the decision executes inside the transaction’s critical path, before commit. The PIPs are threefold — the Identity Graph (who/what is calling, ownership, delegation chain), external signal feeds (including third-party risk such as Falcon’s, Section 9), and the application’s own state at evaluation time (the record’s tenant, its approval history, current limits). Three properties follow:

• The decision object is the transaction. Parameters (amount, target record, tool arguments) and commit-time state are first-class inputs. “Agent may refund up to $500 on orders in its own tenant, unless it approved the originating transaction” is directly expressible and directly enforced.
• Correctness is a testable artifact. A deterministic policy has no false-negative rate; it has bugs — found by unit tests, simulation against historical decision logs, and code review in the same pull-request workflow as any other software.
• Evidence is a decision record. Every evaluation emits {decision, reason, actor, action, parameters, policy_version, timestamp} — the artifact an auditor needs to answer “was this allowed, under which rule, and why,” as distinct from “was an attack observed.”

6. Comparative analysis

6.1 Summary matrix and decision functions

Figure 3. The two decision functions side by side: statistical scoring against a threshold versus total, reproducible evaluation of versioned policy.

6.2 Enforcement-point placement and the bypass surface

Architecture A’s PEPs sit where its telemetry is: on managed endpoints, in browsers, and at instrumented AI gateways. Enforcement therefore holds where the sensor or gateway is in the path. Agentic traffic that originates from unmanaged infrastructure — a SaaS vendor’s hosted agent, a partner’s workload, a serverless function calling the business API directly without traversing an instrumented gateway — presents no interception point (Figure 4). This is not a design flaw; it is the geometry of interaction-layer enforcement: coverage by instrumentation.

Architecture B’s PEP is attached to the resource being protected: coverage by construction. Any caller — managed or unmanaged, human or agent, on-path or off-path — must pass the decision point to reach the resource, because the decision point fronts the resource. The trade-off runs the other way: EnforceAuth sees the action and its context but does not see prompt content or endpoint process trees; it cannot detect an injection attempt it is never shown. Placement determines visibility, and visibility determines what each system can decide.

Figure 4. Coverage by instrumentation versus coverage by construction: the unmanaged caller bypasses interaction-layer PEPs but cannot bypass a PEP that fronts the resource.

6.3 Context resolution: the PIP gap

The decisive technical difference is which attributes each PDP can consume. Falcon’s PIPs are telemetry-shaped: device posture, identity risk, prompt analysis, threat intel — attributes about the caller and the channel. The attributes that most business rules require are application-shaped, and they exist only inside the application’s data model at the moment of the write:

• Tenant boundary: which customer’s record the target actually is — resolvable only against the application’s ownership model.
• Delegated authority: this agent’s refund limit — a business assignment, not an infrastructure attribute.
• Segregation of duties: whether this identity approved the transaction it is now trying to settle — requires the record’s approval history at commit time.
• Resource relationships and state: order status, prior partial refunds, account standing — mutable state that is stale the moment it is exported to an external risk engine.

A time-of-check/time-of-use argument applies with force: even if business attributes were replicated into an access-management plane, decisions made against a replica are made against potentially stale state. Evaluating at the resource, inside the transaction, is the only placement that closes the TOCTOU window for state-dependent rules.

Business impact. This gap is not hypothetical: 97% of organizations that suffered an AI-related breach lacked proper AI access controls, and 63% had no AI governance policy at all (IBM Cost of a Data Breach Report 2025). The PIP gap described here is the mechanism behind that statistic — controls that cannot see business context cannot govern business actions.

The structural point: no volume of endpoint or interaction-layer telemetry converges to application state. The gap is not a missing feature; it is a missing information channel — a PIP that only resource-side evaluation possesses.

6.4 Delegation semantics: provenance versus attenuation

Both architectures treat agent→sub-agent delegation seriously, differently. Architecture A preserves calling context through the chain — the sub-agent carries who owns it and who invoked it, and risk evaluation applies at each hop. This answers provenance: the chain is known and attributable. Architecture B evaluates policy at each hop with the chain as input, which additionally answers attenuation: delegated scope may only narrow, depth is capped, and forbidden capability combinations cannot co-occur in one chain (Figure 5). Provenance is necessary for attenuation but not sufficient; attenuation requires a policy evaluation per hop with business semantics attached.

Figure 5. Per-hop attenuation: a sub-agent can never exercise authority its parent never held, regardless of chain provenance.

Worked trace — a three-hop chain attempting an over-limit action:

6.5 Revocation versus authorization: timing

SSF/CAEP-style continuous access evaluation is a signal-propagation architecture: transmitters emit risk events; receivers revoke sessions and tokens. Its unit of effect is the session, and its consistency model is eventual — appropriate, because its job is to shrink the window between compromise-detection and access-termination from hours to seconds. Per-transaction authorization has a different unit of effect (the single action) and a different consistency requirement (synchronous, in-path). The two compose precisely because they do not overlap: revocation bounds how long a bad identity can act at all; authorization bounds what any identity — good or bad — can do on each individual action. Neither substitutes for the other: revocation cannot stop the first unauthorized action of a clean-risk identity, and per-action denial does not terminate a compromised session’s access to systems outside the fabric.

6.6 Evidence and regulatory mapping

Detection systems produce investigative evidence: what was observed, what fired, what the score was. Deterministic authorization produces decisional evidence: what was permitted or denied, under which policy version, for which reason. Regulatory regimes increasingly demand the latter — SOX segregation-of-duties findings turn on proving the control operated on each transaction; DORA and the EU AI Act frame requirements around demonstrable, continuous control over ICT and high-risk AI operations. A risk log demonstrates vigilance; a decision record demonstrates control. Audit programs need both, but only one of the two architectures emits the second artifact.

Business impact. Decision records convert audit preparation from manual evidence assembly — screenshots, ticket archaeology, sampled log pulls — into a query. The design outcome is audit-preparation time measured in hours rather than weeks, quantified per organization in the Section 8 value model.

6.7 Failure modes and operations

• Degradation. A detector degraded (model drift, evasion) fails silent — the residual false-negative rate is unobservable in the moment. A policy engine degraded (PDP unreachable) fails loud and configurably: EnforceAuth supports per-action-class fail-open/fail-closed, with fail-closed the default for privileged writes.
• Change management. Detector updates ship as model/content updates whose behavior is characterized statistically. Policy updates ship as code: diffed in a pull request, unit-tested, simulated against historical decision logs, attributable line-by-line — with < 500ms distribution once merged.
• Latency budget position. Sub-30ms at a gateway and single-digit milliseconds in a sidecar are both compatible with production request paths; the operative difference is not speed but position — gateway inspection spends its budget before the application, resource-side evaluation inside it, adjacent to commit.

7. Why the authorization layer has exactly one occupant

Sections 3–6 establish that the authorization layer is architecturally distinct from detection and access management: different decision object, different decision function, different PIPs, different placement, different evidence. This section makes the claim the analysis supports, and stress-tests it against every alternative an architect would reasonably propose. The claim: for deterministic, continuous business authorization across applications, infrastructure, data, and AI workloads — for human and non-human identities, at runtime — EnforceAuth is the only purpose-built platform. Not the best of several; the only occupant of the layer.

7.1 Coverage: one platform spans the four domains

Adjacent categories each hold a real position — in a different layer or a subset of one. Endpoint/XDR platforms (including Falcon) hold detection depth with partial reach into infrastructure and AI-workload telemetry. IAM suites hold authentication and coarse entitlement. App-layer fine-grained authorization products cover one domain of four. CSPM covers posture, not runtime. Access-governance products answer who has access, not what they may do with it per action. Mapped against the four domains, exactly one row is full across all four:

Figure 9. Runtime-authorization coverage: adjacent categories are partial by design; EnforceAuth is the only platform whose decision function is deterministic business authorization in all four domains.

Figure 10. Market structure. The axes are different decision functions (§6.1), so depth on one cannot be converted into depth on the other — which is why the upper band has one occupant and why the orange arrow (Falcon signals feeding EA policy) is an integration, not an overlap.

7.2 Alternatives considered — and why each fails structurally

“Only choice” is an engineering claim here, not a slogan, so it must survive the four standard counterproposals:

• “Rely on detection; tune it tighter.” Fails on Section 3: failure class T4 is defined by its non-anomalousness. No threshold τ applied to D: signals → [0,1] converts a risk scorer into an evaluator of delegated authority, tenancy, or segregation of duties. The information is not in the signals; tuning cannot put it there.
• “Extend the IAM suite.” IAM decides at authentication and issues session-scoped entitlements. It has no transaction PDP, no application-state PIP, and no presence in the commit path. Authentication answers who; authorization answers what this specific action may do — extending the former does not produce the latter, it produces coarser versions of the same access decision.
• “Build it in-house on raw OPA.” OPA is the right engine — EnforceAuth is OPA/Rego-compatible for exactly that reason — but an engine is not a platform. The in-house path must independently build the identity graph across human and non-human identities, NHI lifecycle management, AI-workload policy patterns (tool-call authorization, delegation attenuation), the decision-evidence pipeline, compliance mapping, and multi-domain enforcement distribution. That is a multi-year platform program competing for the same engineers the AI initiatives need — to arrive at the layer EnforceAuth already occupies.
• “Wait — the endpoint platform will extend downward.” The limits documented in Sections 6.2–6.3 are geometric, not roadmap items. Interaction-layer enforcement cannot acquire commit-time application state without deploying a decision point at the resource — at which point it has rebuilt Architecture B, not extended Architecture A. A vendor may of course do that someday; an enterprise deploying agents now is exposed on T3/T4 every quarter it waits, and IBM’s 2025 data (Section 8.1) prices that exposure.

Figure 13. The five-lane stack. Lanes 1–2 have strong occupants and are consumed as inputs; lanes 3–5 have exactly one.

The positioning sentence, precisely: detection has credible alternatives; authorization does not. For the layer that decides whether the agent’s business action is permitted, EnforceAuth is not the leading choice among several — it is the only purpose-built choice that exists.

8. Business value and ROI

8.1 The priced cost of the Authorization Gap

The gap this paper describes is now independently measured. IBM’s Cost of a Data Breach Report 2025 (Ponemon Institute, 600 organizations) prices the environment an ungoverned agent operates in: a global average breach cost of $4.44M — $10.22M in the United States — with 13% of organizations already reporting breaches of AI models or applications. Two findings bear directly on this paper’s subject: 97% of organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policy to manage AI or prevent shadow AI — which itself added an average $670,000 to breach costs where prevalent. The market is not short of detection; it is short of authorization, and it is paying for the difference.

Figure 11. Exposure scaling. Detection bounds the adversarial classes; the T3/T4 curve keeps compounding with agent count, autonomy, and delegation depth until explicit authority bounds it.

8.2 The value model

EnforceAuth’s business value decomposes into four drivers, each independently measurable during the Section 10 evaluation. Platform investment is deployment-specific and intentionally left as a variable — the model is offered so that any organization can compute its own return:

Figure 12. Four value drivers and the return formula. Inputs are organization-specific; the worked example below shows the model’s shape with deliberately conservative, clearly illustrative values.

8.3 Worked example (illustrative)

The following model is illustrative, not measured — every input should be replaced with organization-specific values during evaluation. Assumed profile: a US-regulated enterprise with 150 production agents, two major audit cycles per year, and an active AI roadmap.

Two properties of the model matter more than its illustrative total. First, V1 uses a deliberately thin 2-point probability delta against a single-incident anchor; organizations running hundreds of agents against regulated data will justify materially larger deltas — and the $670K shadow-AI cost premium and 31% operational-disruption rate for AI incidents (IBM 2025) sit outside this model entirely, as upside. Second, V2–V4 are not risk-probability arguments at all: they are operational line items that accrue whether or not an incident ever occurs, which is what makes the investment defensible to a CFO independent of threat assumptions.

8.4 Time to value

The value model is not a year-three promise. The standard six-week evaluation (Section 10) produces the first enforced deny of an out-of-policy agent action in week 4 and the first audit-ready decision evidence in week 5 — the quantified gap analysis and ROI projection are the week-6 deliverable, computed from the organization’s own measured inputs rather than this paper’s illustrations.

Figure 14. Time-to-value: enforcement in week 4, audit-grade evidence in week 5, an organization-specific ROI computation in week 6.

Business impact, summarized: the authorization layer pays for itself twice — once as risk reduction against the incident classes detection cannot see, and once as operating leverage on audits, policy operations, and AI launch velocity that accrues in quiet years too.

9. Composed reference architecture

The architectures compose along a single clean seam: Falcon’s outputs become EnforceAuth PIP inputs (Figure 6). Detection widens what a policy can reason about; the decision remains deterministic and evidenced.

Figure 6. The composed plane: SSF events stream into the Identity Graph; high-sensitivity actions fetch risk synchronously; the decision record captures both systems’ contributions.

9.1 Signal plumbing

• Streaming path: EnforceAuth’s Telemetry Collector subscribes as an SSF receiver to Falcon-emitted risk events (identity risk changes, agent-risk elevation, active-threat flags) and projects them onto the Identity Graph with a short TTL.
• Decision-time path: for high-sensitivity action classes, the Enforcement Agent fetches the current score synchronously at evaluation, trading a few milliseconds for zero staleness.
• Staleness policy: signal freshness is itself a policy input — a stale Falcon attribute on a privileged write evaluates as fail-closed by default.

9.2 Reference policy library

Three policies spanning three of the four domains. Each shows the same pattern: business gates and risk gates as independent conjuncts — Falcon signals tighten the envelope, never widen it.

Policy 1 — Application domain: delegated refund authority, tenancy, SoD, chain attenuation.

package enforceauth.refund

import future.keywords.if

import future.keywords.in

default allow := false

allow if {

input.action == "issue_refund"

input.actor.type == "ai_agent"

business_authorized

falcon_risk_ok

}

business_authorized if {

input.amount <= data.delegations[input.actor.id].refund_limit

input.tenant == input.record.tenant

not input.actor.id in data.approvers[input.record.id] # SoD

delegation_attenuated

}

delegation_attenuated if {

every hop in input.actor.delegation_chain {

hop.scope_subset_of_parent == true

}

count(input.actor.delegation_chain) <= data.limits.max_delegation_depth

}

falcon_risk_ok if {

input.falcon.freshness_ms <= 5000 # stale signal => gate fails

input.falcon.agent_risk < 70

input.falcon.endpoint_posture == "compliant"

count(input.falcon.threat_flags) == 0

}

Policy 2 — AI-workload domain: MCP tool-call authorization with argument constraints.

package enforceauth.toolcall

import future.keywords.if

import future.keywords.in

default allow := false

allow if {

input.action == "mcp_tool_invoke"

input.tool in data.agents[input.actor.id].allowed_tools

argument_constraints_met

not forbidden_combination

input.falcon.agent_risk < data.tools[input.tool].max_risk # riskier tools, lower ceiling

}

argument_constraints_met if {

every c in data.tools[input.tool].arg_constraints {

constraint_holds(c, input.args)

}

}

# e.g. send_email + read_customer_pii may never co-occur in one chain

forbidden_combination if {

some pair in data.forbidden_tool_pairs

pair[0] in input.actor.chain_tools_used

input.tool == pair[1]

}

Policy 3 — Data domain: query-time row/column authorization driven by classification.

package enforceauth.dataaccess

import future.keywords.if

default allow := false

allow if {

input.action == "query"

row_scope_valid

count(denied_columns) == 0

}

row_scope_valid if {

input.query.tenant_filter == input.actor.tenant # rows constrained to caller tenant

}

denied_columns contains col if {

some col in input.query.columns

data.classification[col] == "pii"

not input.actor.entitlements["pii_read"]

}

# obligation: mask instead of deny when partially entitled

obligations["mask_columns"] := denied_columns if {

count(denied_columns) > 0

input.actor.entitlements["masked_read"]

}

9.3 Canonical flows

Figures 7 and 8 trace the two flows that define the division of labor. Figure 7 is the Authorization Gap made concrete: no threat exists, detection correctly stays silent, and the deny comes from policy. Figure 8 is the integration dividend: detection raises risk, and enforcement tightens with scope instead of killing the workload.

Figure 7. Scenario A — clean-risk agent, unauthorized business action: the failure class (T3/T4) only resource-side authorization addresses.

Figure 8. Scenario B — threat detected: the SSF event tightens the authorization envelope; sessions outside the fabric are revoked in parallel.

10. Validation methodology

A technical comparison is only as good as its numbers’ provenance. This paper deliberately labels Architecture A figures as vendor claims and Architecture B figures as design targets. The following methodology converts targets into measured results in a standard six-week evaluation, and is offered so that any figure in this paper can be independently reproduced:

• Latency (weeks 2–3, monitor-only): deploy the Enforcement Agent as sidecar and as embedded library against a representative service; measure decision latency at p50/p95/p99 under production-shadow traffic with policies of realistic complexity (≥ 3 data references, ≥ 1 delegation-chain walk). Pass: p99 < 5ms sustained.
• Throughput: synthetic load at 2× peak production decision volume per node; measure decisions/sec at the latency SLO. Pass: ≥ 100K/sec/node or documented scale-out equivalence.
• Correctness (weeks 4–5): replay ≥ 30 days of historical action logs through candidate policies in simulation; measure policy coverage (fraction of actions matched by an explicit rule rather than default) and false-deny rate against adjudicated ground truth. Pass criteria are set per organization; the artifact is the simulation report itself.
• Signal integration: inject synthetic SSF risk events; measure propagation time from event emission to first tightened decision, and verify stale-signal fail-closed behavior on privileged writes.
• Evidence audit: hand a sampled set of decision records to the internal audit function; verify each answers who/what/when/under-which-policy-version without reference to any other system.

Detection-side efficacy figures (e.g., published detection rates) should be validated by the corresponding vendor’s methodology; this paper takes no position on them beyond citing their source.

11. Evaluation checklist for architects

Questions that separate the two decision planes in any vendor conversation, including with EnforceAuth:

• What denies a fully authenticated, clean-risk agent’s first out-of-policy business action — before commit, not after detection?
• Which PIPs can the PDP consume: telemetry attributes only, or application state (tenancy, approval history, limits) at evaluation time?
• Is the enforcement point in the path by construction (fronting the resource) or by instrumentation (sensor/gateway coverage)? What reaches the resource without traversing it?
• Is the decision reproducible — same inputs, same version, same answer — and is the version cited in the evidence artifact handed to an auditor?
• How is delegation constrained — provenance only, or per-hop policy with scope attenuation and depth limits?
• What is the failure semantics per action class — and who chose it: a detector’s threshold, or a reviewed line of policy?
• Which threat classes from Section 3 does each control in the proposed stack actually address — and is T4 (benign overreach) covered by anything at all?

12. Conclusion

Reduced to decision theory: CrowdStrike’s architecture computes whether an identity should retain access, using probabilistic evaluation of telemetry-shaped attributes, enforced at the interaction layer, with event-propagated revocation — the right instrument for the adversarial failure classes. EnforceAuth computes whether a specific transaction is permitted, using deterministic evaluation of versioned policy over business-shaped attributes, enforced at the resource, synchronously, with a decision record per action — the only instrument for the authorization failure classes, adversarial or not. The vocabularies collide; the functions do not.

An agentic enterprise needs both computations. It needs to know when an agent is compromised and cut its access in seconds — and it needs every action of every agent, compromised or pristine, evaluated against the business’s actual rules before the write lands. The first without the second leaves the Authorization Gap open: the clean-risk agent’s unauthorized action sails through. The second without the first fights adversaries with a rulebook. Composed — Falcon signals as Rego inputs, revocation bounding duration, authorization bounding each act — they form the layered control plane the agentic era actually requires.

The asymmetry between the layers, however, should shape procurement. For detection and risk-adaptive access, the market offers several credible platforms, CrowdStrike prominent among them — keep them, and feed their signals into policy. For the authorization layer there is no field to choose from: detection cannot be tuned into it, IAM cannot be extended into it, raw OPA arrives at it only after a multi-year platform build, and the endpoint platform reaches it only by becoming it. EnforceAuth is the only platform purpose-built for deterministic, continuous authorization across all four domains for human and non-human identities at runtime — and per Section 8, the layer returns value through audits, operations, and launch velocity even in years when nothing goes wrong.

EnforceAuth is the AI Security Fabric — deterministic, continuous authorization for every action by every identity, human and non-human, across applications, infrastructure, data, and AI workloads. Technical briefings and Authorization Gap assessments: enforceauth.com.

Appendix A — Standards and terminology map

Document control: v3.0 · July 15, 2026 · EnforceAuth, Inc., San Diego, CA. Architecture A behavior cited from public vendor announcements and documentation as of July 2026; verify against current releases before external redistribution. Figures 1–14 © EnforceAuth. Business-value figures in Section 8 are explicitly labeled illustrative; external statistics cite IBM Cost of a Data Breach Report 2025.