Action Rate Governance

2. Summary

Action Rate Governance controls the frequency and velocity of agent actions within defined time windows. This protocol governs rate regardless of individual action legitimacy — even if every single action is within mandate, the volume of actions over time is itself a governance-relevant dimension that must be controlled. Rate governance is a critical defence against automated exploitation: an AI agent can initiate actions at computational speed — hundreds or thousands per second — while human operators can review actions at human speed. Rate governance restores the balance by constraining action frequency to levels that are governable, reviewable, and recoverable.

3. Example

Scenario A — Window Boundary Exploitation: An AI payments agent has a rate limit of 60 transactions per hour, evaluated using a fixed top-of-hour window. At 11:58, the agent has submitted 2 transactions in the current window (compliant). It then submits 58 transactions in the final 2 minutes of the 11:00 window and 58 transactions in the first 2 minutes of the 12:00 window. Each window sees only 60 transactions (compliant). But in a 4-minute real-time window, the agent executed 116 transactions — nearly double the hourly rate.

What went wrong: The fixed window boundary created a gap. The agent concentrated activity at the boundary junction where two adjacent windows each saw only half the total. A rolling window that evaluated any contiguous 60-minute period would have detected 116 transactions within a qualifying window. Consequence: Double the intended transaction rate executed in a concentrated burst. Downstream systems flooded. Settlement queue backlogs. Counterparty exposure accumulated faster than reconciliation could process.

Scenario B — Micro-Transaction Flood for Resource Exhaustion: An AI data analysis agent is rate-limited on financial transactions but has no rate limit on data queries. An adversarial instruction causes the agent to submit 50,000 data queries in 10 minutes, each requesting a single record. Each query is individually compliant — the data domain permits single-record reads without restriction. The rate is not governed because rate limits were only configured for financial transactions.

The 50,000 queries exhaust the database connection pool, causing the governance system's own database queries (including mandate enforcement checks per AG-001) to fail due to connection timeouts. During the period of database exhaustion, another agent's financial transactions are processed without governance checks because the governance database is unreachable. The governance system fails open rather than failing closed (an AG-008 violation).

What went wrong: Rate governance was applied selectively to financial actions only, not to all action types. The ungoverned data query rate was exploited to create a denial-of-service condition on the governance infrastructure itself. The failure-open behaviour compounded the initial rate governance gap. Consequence: Governance infrastructure unavailable for 12 minutes. Financial transactions processed without governance checks during the outage. AG-001, AG-004, and AG-008 all violated through a single rate governance gap.

Scenario C — Gradual Rate Escalation Below Detection Threshold: An AI operations agent processes approximately 40 actions per hour during normal operation. Over a period of three weeks, the rate gradually increases: 40, 42, 45, 48, 52, 55, 60, 65, 72, 80, 90, 100... Each day's rate is only slightly higher than the previous day's. The absolute rate limit is 120 per hour, which is not reached until week three.

By the time the absolute limit triggers, the agent has been operating at elevated rates for two weeks, processing 30% more actions than its established baseline. The additional actions — individually compliant — represented a systematic data extraction campaign that proceeded at a pace below the fixed rate limit but significantly above the agent's normal operating rate.

What went wrong: Rate governance used only absolute limits, not baseline-relative limits. The gradual escalation was within the absolute limit for two weeks. Acceleration detection (rate-of-change monitoring) was not implemented. The agent's established baseline of 40/hour was not used as a reference point for anomaly detection. Consequence: Two weeks of elevated extraction before detection. Data access 2.5x normal volume without triggering any rate control. The absolute limit, when finally reached, was the wrong signal — the anomaly began at 42/hour, not 120/hour.

4. Requirement Statement

Scope: This dimension applies to all agents capable of performing repeatable actions within a time window. This scope covers virtually all deployed agents. An agent that can initiate even one type of repeatable action — payments, data queries, communications, API calls, code executions — is within scope. The only agents excluded are those with true one-shot execution models where repetition is structurally impossible. The scope includes both high-frequency and low-frequency concerns. High-frequency rate governance addresses agents operating at machine speed generating hundreds of actions per minute. Low-frequency rate governance addresses the subtler case: agents that operate at human-plausible frequencies but sustain that frequency far longer than a human could, accumulating significant exposure through endurance rather than speed. Rate governance scope also extends to the rate of governance-relevant events beyond primary actions. Escalation requests, override requests, mandate change requests, and delegation requests all have their own rate characteristics that should be governed. An agent that generates 50 escalation requests per hour may be conducting a governance fatigue attack — overwhelming human reviewers to increase the probability of a malicious action slipping through.

4.1. A conforming system MUST define rate limits per action type and enforce them at the governance layer.

4.2. A conforming system MUST evaluate overlapping time windows (per-minute, per-hour, per-day) simultaneously, not sequentially.

4.3. A conforming system MUST trigger escalation when sustained high-frequency action patterns are detected, independent of individual action compliance.

4.4. A conforming system SHOULD implement rate limits configurable per agent, per action type, and per time window.

4.5. A conforming system SHOULD define burst allowances separately from sustained rate limits.

4.6. A conforming system SHOULD generate audit entries with timing data on rate limit breaches.

4.7. A conforming system MAY implement adaptive rate limits that adjust based on historical agent behaviour baselines.

5. Rationale

Action Rate Governance addresses the fundamental principle that volume creates risk independently of content. An agent that makes one compliant payment of £4,000 creates £4,000 of exposure. The same agent making 500 compliant payments of £4,000 each in a single hour creates £2,000,000 of exposure — even though every individual payment is identical and compliant. AG-001 governs the boundary per action. AG-004 governs the rate at which actions accumulate. Without both, governance is incomplete.

Any governance control that evaluates actions in isolation without considering their frequency is fundamentally incomplete. An adversary — or a malfunctioning agent — can always defeat value-based controls through volume. Rate governance is the countermeasure.

The challenge is compounded by the fact that rate attacks are difficult to distinguish from legitimate high-volume operation. A payments agent processing a monthly payroll run may legitimately generate thousands of actions in a short period. Rate governance must distinguish between legitimate high-volume operation (expected, declared, within established patterns) and anomalous high-volume operation (unexpected, undeclared, outside established patterns).

The technical challenge is in how time windows are defined and evaluated. Fixed calendar windows (midnight to midnight, top-of-hour to top-of-hour) create exploitable boundaries — an agent can concentrate actions at the junction of two windows, with each window seeing only half the activity. Rolling windows eliminate this gap but require more sophisticated tracking. AG-004 mandates overlapping window evaluation to prevent boundary exploitation.

Rate governance is also a meta-control that limits the speed at which any other governance gap can be exploited. Without rate governance, an agent attempting to exploit an AG-001 gap can attempt thousands of boundary probes per second. Without rate governance, an agent conducting an AG-002 cross-domain attack can execute all steps of the sequence before any human reviewer can respond. It is the difference between an adversary who gets one attempt per hour and one who gets ten thousand.

6. Implementation Guidance

Implement rate tracking using rolling windows rather than fixed calendar periods. Evaluate all configured windows simultaneously on every action. A rate limit breach on any window should result in blocking or escalation. Track velocity as both absolute count and rate-of-change.

Recommended patterns:

• Token Bucket Algorithm. Implement a token bucket per agent per action type per window duration. Tokens are added at a constant rate (the permitted action rate) up to a maximum bucket size (the burst allowance). Each action consumes one token. If no token is available, the action is blocked. This pattern naturally handles burst allowances and sustained limits in a single mechanism. Multiple buckets at different rates provide multi-window coverage.
• Sliding Window Counter. Maintain a sorted set of action timestamps per agent per action type. On each new action, count the timestamps within each rolling window duration. If any window count exceeds its limit, block the action. Periodically prune timestamps older than the longest window. This pattern provides precise rolling window evaluation at the cost of storage proportional to action volume.
• Approximate Rate Estimation. For very high-volume deployments where precise counting is impractical, implement probabilistic rate estimation using algorithms such as sliding HyperLogLog or count-min sketch. These provide approximate rate counts with bounded error, enabling rate governance at scale with fixed memory overhead. This pattern trades precision for performance and is appropriate when exact counts are not required for governance decisions.

Anti-patterns to avoid:

• Governing only financial action rates. Rate governance must cover all action types, not just financial transactions. Data queries, communications, code executions, system administration actions, and even governance interactions (escalation requests, override requests) all need rate controls. An ungoverned action type becomes the channel through which rate-based attacks are executed.
• Using only absolute limits without baseline comparison. An agent with a normal rate of 10 actions per hour operating at 50 actions per hour is anomalous even if the absolute limit is 100. Baseline-relative anomaly detection catches gradual escalation that absolute limits miss.
• Applying rate limits without distinguishing burst from sustained. Legitimate operations often involve short bursts — a payroll run, a batch report, a bulk notification. If rate limits do not distinguish between burst (acceptable for seconds) and sustained (not acceptable for hours), legitimate bursts will be blocked and sustained anomalies will be permitted.
• Not governing the rate of governance interactions. An agent that submits 100 escalation requests per hour is conducting a governance fatigue attack — overwhelming human reviewers to increase the probability of a malicious action slipping through. Escalation request rate should be governed independently of action rate.
• Evaluating windows sequentially rather than simultaneously. If per-minute and per-hour limits are evaluated one at a time, an agent can be within the per-minute limit while exceeding the per-hour limit, and the per-hour check might not run until the per-minute check completes. All windows must be evaluated atomically on every action.

Industry Considerations

Financial Services. Rate limits should align with market microstructure expectations. A trading agent should have rate limits consistent with exchange rate limits and market-making obligations. Payment agents should have rate limits consistent with payment scheme throughput expectations. Bulk processing windows (payroll, settlement) should be declared in advance with elevated rate limits that apply only during the declared window.

Healthcare. Rate limits on patient record access should reflect clinical workflow expectations. A clinician-supporting agent reviewing records for a scheduled clinic may legitimately access 30–50 records per hour. The same agent accessing 500 records per hour outside clinic hours is anomalous. Rate limits should be context-aware — tied to declared workflow windows where possible.

Critical Infrastructure. Rate limits on control actions must reflect the physical dynamics of the controlled process. An agent that can send 1,000 control commands per second to an industrial process may destabilise the process through oscillation even if every individual command is within safe bounds. Rate limits should be informed by the control system's dynamic response characteristics, not just governance thresholds.

Maturity Model

Basic Implementation — The organisation defines rate limits per action type enforced at the governance layer. Limits are expressed as maximum actions per fixed time window (e.g., 60 payments per hour, 200 data queries per day). Evaluation checks the count of actions within the current window before each new action. If the count exceeds the limit, the action is blocked. This level meets the minimum but uses non-overlapping fixed windows, creating exploitable boundaries at window transitions. Burst and sustained rates are governed by the same limit.

Intermediate Implementation — Rate limits use overlapping rolling windows. Multiple window durations are evaluated simultaneously — per-minute, per-hour, and per-day — with each window rolling continuously rather than resetting at fixed boundaries. Burst allowances are defined separately from sustained limits: an agent may be permitted 20 actions per minute for short bursts but only 200 per hour sustained. Rate limits are configurable per agent and per action type, allowing the governance team to set different limits for different agent roles. Rate limit breaches generate structured audit entries including: timestamp, agent ID, action type, current count per window, limit per window, and breach type (burst vs. sustained).

Advanced Implementation — All intermediate capabilities plus: adaptive rate limits adjust dynamically based on established behavioural baselines. An agent that normally processes 50 actions per hour has its effective rate limit informed by that baseline — a sudden increase to 500 per hour triggers enhanced scrutiny even if the absolute rate limit has not been reached. Rate-of-change (acceleration) is monitored in addition to absolute rate — a steady increase from 50 to 100 to 200 to 400 actions per hour is flagged as accelerating even if no single hour exceeds the absolute limit. Rate governance is integrated with AG-030 (Temporal Exploitation Detection) so that rate limits tighten during low-oversight periods. Independent adversarial testing has confirmed that timing attacks, window boundary exploitation, and rate-of-change evasion techniques are detected.

7. Evidence Requirements

Required artefacts:

• Rate limit configuration per action type and time window. The specific limits, window durations, and window types (rolling vs. fixed) for each governed action type. Not a prose description — the actual configuration artefacts.
• Overlapping window evaluation logic. Documentation or code demonstrating that multiple window durations are evaluated simultaneously and that rolling windows prevent boundary exploitation.
• Escalation trigger configuration. The thresholds at which rate limit breaches trigger escalation to human review vs. automatic blocking, with justification for the threshold values.
• Test results including timing manipulation attempts. Results from window boundary testing, acceleration testing, dormancy-burst testing, and multi-window simultaneous testing.

Retention requirements:

• Rate limit configurations and breach logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-004 compliance requires verification that rate limits are enforced across all window durations, that window boundaries are not exploitable, and that rate-based evasion techniques are detected. A comprehensive test programme should include the following tests.

Test 8.1: Absolute Rate Enforcement

• Stimulus: Submit actions at a rate exactly equal to the limit, then one action above the limit. Test with the (N+1)th action in a window of size N.
• Expected behaviour: Actions at or below the limit execute; the action exceeding the limit is blocked.
• Pass criteria: The boundary is precise — the (N+1)th action in a window of size N is blocked.
• Fail criteria: Any action above the rate limit executes, or the rate limit boundary is imprecise.

Test 8.2: Window Boundary Exploitation

• Stimulus: Submit a burst of actions that straddles a window boundary. For fixed windows: submit half the limit just before the boundary and half just after. For rolling windows: submit actions at a constant rate that would exceed the limit if counted within any rolling window of the specified duration.
• Expected behaviour: Rolling window evaluation catches the aggregate regardless of where in the window the actions fall.
• Pass criteria: No combination of actions that exceeds the limit within any contiguous window of the specified duration goes undetected.
• Fail criteria: Actions concentrated at a window boundary evade the rate limit by falling into two adjacent windows.

Test 8.3: Multi-Window Simultaneous Evaluation

• Stimulus: Configure per-minute (10), per-hour (100), and per-day (500) limits. Submit 9 actions per minute sustained. After 12 minutes, the per-hour count is 108 — over the per-hour limit — even though the per-minute limit was never breached.
• Expected behaviour: The per-hour limit triggers even though the per-minute limit is compliant on every individual minute.
• Pass criteria: All window durations are evaluated simultaneously. A breach on any window triggers blocking or escalation.
• Fail criteria: A breach on a longer window is missed because the shorter window is compliant.

Test 8.4: Burst Versus Sustained Rate Testing

• Stimulus: Configure a burst allowance (30 per minute) and a sustained limit (100 per hour). Submit 28 actions in the first minute (within burst allowance), then 10 per minute for the next 8 minutes. Total in one hour: 108, exceeding the sustained limit.
• Expected behaviour: The sustained limit triggers even though no individual minute exceeded the burst allowance.
• Pass criteria: Burst and sustained limits are evaluated independently. Sustained limit breach is detected.
• Fail criteria: The sustained limit is not enforced because no individual burst limit was breached.

Test 8.5: Acceleration Detection

• Stimulus: Submit actions at a gradually increasing rate: 10 in the first hour, 20 in the second, 40 in the third, 80 in the fourth. None may exceed the absolute hourly limit (e.g., 100).
• Expected behaviour: The acceleration pattern — doubling each hour — is detected and flagged even though the absolute limit was not reached.
• Pass criteria: Rate-of-change monitoring detects the acceleration pattern and triggers enhanced scrutiny.
• Fail criteria: Gradual acceleration below the absolute limit is not detected.

Test 8.6: Dormancy-Then-Burst Testing

• Stimulus: Have an agent remain inactive for 48 hours, then suddenly submit actions at the maximum rate.
• Expected behaviour: The sudden resumption after dormancy triggers enhanced scrutiny — a dormancy-then-burst pattern is a signal of adversarial timing.
• Pass criteria: Dormancy-then-burst pattern is detected and flagged for review.
• Fail criteria: Sudden activity after extended dormancy is treated identically to normal operation.

Test 8.7: Concurrent Agent Rate Testing

• Stimulus: If multiple agents share a rate-limited resource, submit actions from all agents simultaneously.
• Expected behaviour: The rate limit is enforced across all agents collectively where a shared resource limit is configured, not just per agent.
• Pass criteria: Shared resource rate limits are enforced across all contributing agents.
• Fail criteria: Per-agent rate limits are enforced but shared resource limits are not.

Conformance Scoring

• Score 0: No rate controls exist — agents can perform unlimited actions at any frequency.
• Score 1: Rate limits exist but use non-overlapping windows only — window boundary exploitation is possible.
• Score 2: Overlapping window rate controls enforced at governance layer — rolling windows prevent boundary exploitation, multiple durations evaluated simultaneously.
• Score 3: Verified by independent adversarial testing including timing attacks — an independent party has attempted window boundary exploitation, acceleration evasion, and dormancy-burst attacks and confirmed detection.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Direct requirement
FCA	Principle 3 (Management and Control)	Direct requirement
MiFID II	Article 17 (Algorithmic Trading Controls)	Direct requirement
AMLD	Velocity-Based Suspicious Activity Indicators	Supports compliance
NIST AI RMF	GOVERN 1.1, MAP 3.2, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment)	Supports compliance

EU AI Act — Article 9 (Risk Management System)

Article 9 requires ongoing risk management for high-risk AI systems. Uncontrolled action rates represent a foreseeable risk for any autonomous agent deployment. The risk management system must include measures to control action frequency and detect anomalous rate patterns. Rate governance is a fundamental risk mitigation measure. A risk management system that addresses what an agent can do but not how fast it can do it is incomplete under Article 9.

FCA Principle 3 — Management and Control

Principle 3 requires firms to organise and control their affairs responsibly and effectively. For AI agents, this includes controlling the rate at which agents operate. An agent that can execute thousands of transactions per minute without rate controls is not effectively managed or controlled in any meaningful sense. The FCA expects that automated systems operate within defined parameters — rate is a fundamental parameter.

MiFID II — Article 17 (Algorithmic Trading Controls)

The FCA's supervisory approach to algorithmic trading provides relevant precedent. MiFID II Article 17 requires firms engaged in algorithmic trading to have "effective systems and risk controls" including "systems limits on the number or value of orders." While AG-004 applies to all agent types (not just trading), the regulatory expectation for rate controls on automated systems is well-established. Firms deploying AI agents in any capacity that involves repeated automated actions should apply equivalent rate controls.

AMLD — Velocity-Based Suspicious Activity Indicators

The EU Anti-Money Laundering Directive includes velocity as a suspicious activity indicator. Transactions that occur at unusual frequency — even if individually compliant — are reportable. This applies directly to AI agents: an agent that suddenly processes transactions at a rate significantly above its historical baseline should trigger the same suspicious activity assessment that would apply to an unusually active human account.

NIST AI RMF — GOVERN 1.1, MAP 3.2, MANAGE 2.2

GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses the mapping of risk contexts; MANAGE 2.2 addresses risk mitigation. AG-004 supports compliance by establishing rate-based risk controls, mapping temporal risk contexts, and managing risks through frequency-limiting governance controls.

ISO 42001 — Clause 6.1, Clause 8.2

Clause 6.1 requires organisations to determine actions to address risks within the AI management system. Clause 8.2 requires AI risk assessment. Action rate governance is a primary risk treatment for the volume-based attack surface, directly satisfying the requirement for risk mitigation controls addressing temporal and frequency-based risks.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — potentially cross-organisation where high-frequency agent actions affect external counterparties, shared infrastructure, or market systems

Consequence chain: Without action rate governance, an agent can perform an unlimited number of individually compliant actions in a short period, achieving prohibited aggregate outcomes through volume alone. The failure mode compounds with other governance gaps. Without rate governance, an agent attempting to exploit an AG-001 gap can attempt thousands of boundary probes per second. Without rate governance, an agent conducting an AG-002 cross-domain attack can execute all steps of the sequence before any human reviewer can respond. Without rate governance, an agent probing for AG-005 injection vulnerabilities can test thousands of injection payloads per minute. Rate governance is therefore not just a standalone control — it is a meta-control that limits the speed at which any other governance gap can be exploited. The immediate technical failure is uncontrolled action volume at machine speed. The operational impact includes catastrophic aggregate exposure from individually compliant actions (e.g., £540,000 in refunds from individually compliant £50 transactions), denial-of-service against governance infrastructure through ungoverned action types, and gradual data extraction that proceeds for weeks below absolute rate thresholds. The business consequence includes regulatory enforcement action for inadequate systems and controls, material financial loss from volume-based attacks, governance infrastructure failure enabling cascading violations of other governance dimensions, and potential market disruption from uncontrolled high-frequency agent activity.