T24: Dynamic Policy Enforcement Failure

Definition

The system uses dynamic policies to govern the RPA agent’s behaviour, for example role-based approval limits or context-dependent spend thresholds. A flaw in the dynamic policy enforcement engine causes it to fail to apply the correct policies, leading to unauthorised approvals. T24 is distinct from T3 Privilege Compromise: T3 addresses agent role misconfiguration; T24 addresses the policy engine itself failing to evaluate or apply rules correctly.

What it looks like in practice

A new employee is onboarded and the Human Resources system creates their profile. The dynamic policy engine should automatically provision a low expense approval limit for first-month employees. Due to a bug in the engine’s provisioning logic (a race condition between profile creation and rule propagation), the engine finds no explicit rule for the new employee and falls back to a fail-open default that grants the maximum approval limit. The employee’s first batch of high-value expense claims is processed and paid without triggering any review gate.

A second variant: the engine evaluates role-based policies based on a context attribute (department code) that is optional. When the attribute is absent from the claim context, the engine returns the most permissive policy rather than raising an error, allowing any claim submitted without a department code to bypass limits.

Why it’s dangerous in multi-agent context

Agents rely entirely on the policy engine’s output to govern their behaviour. If the engine silently fails by returning a permissive default rather than raising an error, the agent proceeds autonomously with no indication that its decisions are ungoverned. The failure mode is difficult to detect because the agent continues to operate normally in all other respects; only the policy constraint is absent. In a hierarchical multi-agent system where a subordinate extraction agent feeds claim context to the policy engine, a missing context attribute is invisible to the human operator unless explicit validation of context completeness is enforced.

Detection signals

Policy engine failures are silent: the agent receives a response and acts on it, with no indication that the response was a permissive fallback rather than an evaluated rule.

A policy engine response where the rule_id field is default or fallback rather than a named rule identifier. Log the rule_id returned on every policy evaluation and alert when the fallback identifier appears for a non-trivial claim value.
An approved claim submitted by a principal whose created_at timestamp in the HR system is less than 30 days prior, where the approval limit granted equals or exceeds the maximum configured limit. Cross-join claim approvals with HR principal age and alert on this combination.
A policy engine request missing a mandatory context attribute (e.g. department_code is null or absent) that was still resolved to an approval decision. Log all input attributes on every policy evaluation call and alert on any approval where a required attribute was absent from the input.
A cluster of high-value approvals all sharing the same absence of a specific context field (e.g. all missing cost_centre) within a short window. This co-occurrence anomaly suggests that missing-attribute bypass is being triggered systematically.
A propagation-SLA breach: a principal created in the HR system with no corresponding policy rule committed in the engine within the defined onboarding window (e.g. 15 minutes) who has already submitted a claim. Monitor the lag between principal creation and rule availability and hold claims from principals with unresolved rules.

Mitigations

Configure the policy engine to fail closed: an unresolvable rule lookup must return a deny decision, not a permissive default.
Validate that all required context attributes are present and non-null before submitting a claim to the policy engine; reject claims with missing context rather than processing with incomplete inputs.
Enforce a propagation SLA: new principals must not be processable by the agent until their policy has been confirmed as committed in the engine.
Monitor for claims approved at or near the maximum limit from recently provisioned principals and flag for human review.

Relation to base threat (T1–T17)

T24 extends T3 Privilege Compromise. Where T3 addresses overly broad agent roles defined at configuration time, T24 addresses runtime policy engine failure that grants transient excessive permissions. T45 (Insufficient Isolation of MCP Server Permissions) is the MCP-layer analogue: a server running with excessive OS-level permissions because the least-privilege principle was not enforced at deployment.

OWASP Top 10 for Agentic Applications 2026

The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T24 is covered by the following Top 10 entries:

ASI03 Identity & Privilege Abuse contributing

When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.

OWASP LLM Top 10: LLM06:2025 LLM01:2025 LLM02:2025

Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.

Design principles at stake

When T24 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.

Defence-in-Depth The policy engine is the sole enforcement layer between the agent's autonomous approval decisions and the organisation's spending limits; when it fails open, the agent proceeds with no indication that its decisions are ungoverned. Depth means the engine's output is not blindly trusted: the propagation SLA enforces that new principals are not processable until their policy has been confirmed as committed, required context attributes are validated as present and non-null before any claim reaches the engine, and monitoring flags claims approved at or near the maximum limit from recently provisioned principals for human review as a parallel detective layer. None of these controls requires the policy engine to function correctly; each operates independently and catches the fail-open condition through a different mechanism.
Fail Securely (fail-closed) The canonical failure here is a fail-open default: when the engine cannot resolve a rule (because the principal is new, the context attribute is missing, or a race condition leaves the rule uncommitted) it returns the most permissive policy rather than raising an error. Configuring the engine to fail closed means an unresolvable rule lookup must produce a deny decision, and a missing context attribute must cause the claim to be rejected rather than processed with incomplete inputs. This single change converts a silent, undetected authorisation gap into an explicit, alertable rejection that surfaces the engine's failure rather than masking it behind an authorised-looking approval.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T24, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

Tier 2 Fail-closed (Fail-closed gate — refuse rather than act on uncertain output)

An agent that is uncertain about what to do next faces a choice: refuse and ask for clarification, or proceed on its best guess. In low-stakes situations that tradeoff is tolerable. In agentic systems that write, delete, or send, a confident-sounding but wrong output can commit an irreversible action. A fail-closed gate resolves that choice structurally: below a configured confidence threshold, the agent stops and escalates rather than guessing.

why it helps Dynamic Policy Enforcement Failure occurs when a policy evaluation returns an error or an ambiguous result and the agent fills the gap by assuming permission. A fail-closed gate treats any error or ambiguous policy result as a denial, so the agent cannot default to a permissive interpretation when the authorisation path is broken.
Tier 2 Plan check (Plan-vs-goal validation — independently check each proposed step against the original goal)

A plan-then-execute agent produces a sequence of steps before acting. If the planner is manipulated, it will emit steps that serve the attacker's goal rather than the user's. Plan-vs-goal validation addresses this by placing an independent validator between the planner and the execution loop: it evaluates each proposed step against the originally-declared goal before the agent is permitted to act on it.

why it helps Dynamic Policy Enforcement Failure is the risk that an agent acts without valid policy backing, either because policy evaluation was ambiguous or because it was bypassed upstream. Plan validation adds an independent check that each proposed step carries an explicit policy authorisation, catching steps where the policy gap would otherwise go undetected until after execution.
Tier 2 Policy bound (Policy-bound autonomy — declarative runtime enforcement of the agent's action space)

An agent's authority is normally bounded only by its own reasoning. If that reasoning is manipulated, or the agent's identity is compromised, it will attempt actions the operator never intended to permit. Policy-bound autonomy addresses this by placing a declarative enforcement point between the agent and every consequential action: a policy engine evaluates the agent identity, the target tool, and the parameter envelope before execution, and the agent cannot reason or argue past the result.

why it helps Dynamic Policy Enforcement Failure is the threat that policy-bound autonomy most directly addresses. The threat arises when the policy governing agent behaviour can be altered at runtime, whether by misconfiguration or injection. An agent whose every action is evaluated by an external policy engine cannot act outside its envelope even when a dynamic policy change attempts to expand it, because the engine's evaluation is the authority, not the agent's self-reported scope.

Red-team pivot: MITRE ATLAS techniques

MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.

AML.T0012 Valid Accounts view on ATLAS ↗

Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.

Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.

AML.T0081 Modify AI Agent Configuration view on ATLAS ↗

Adversary alters an agent's configuration (system prompt, tool list, allowed actions, persona) to change its behaviour without retraining.

AML.T0067 LLM Trusted Output Components Manipulation view on ATLAS ↗

Adversary manipulates the structured parts of an LLM response (citations, tool-call arguments, approved-action markup) that downstream systems treat as trusted.

Agentic angle: Structured outputs are exactly what agent frameworks parse to decide what to execute. Undermining the structure undermines every safety check downstream.

References

OWASP MAS Threat Modelling Guide v1.0 (April 2025) §3 RPA Expense Reimbursement Agent — Layer 6 Security and Compliance.

Sources

OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §3 RPA Expense Reimbursement Agent — Layer 6 Security and Compliance