Agent Control Protocol: Admission Control for Agent Actions

Marcelo Fernandez

cs.CRMar 19, 2026

Agent Control Protocol: Admission Control for Agent Actions

Authors: Marcelo Fernandez

Organizations: TraslaIA

Abstract

Autonomous agents can produce harmful behavioral patterns from individually valid requests -- a threat class per-request policy evaluation cannot address, because stateless engines evaluate each request in isolation. We present ACP, a temporal admission control protocol enforcing behavioral properties over execution traces via static risk scoring combined with stateful signals (anomaly accumulation, cooldown) through a LedgerQuerier abstraction. ACP blocks execution based on deterministic, history-aware risk scoring -- not anomaly detection. Under a 500-request workload where every request is individually valid (RS=35), a stateless engine approves all 500; ACP limits autonomous execution to 2 out of 500 (0.4%), escalating after 3 actions and denying after 11. We identify a state-mixing vulnerability in ACP-RISK-2.0 (cross-context false denials) and introduce ACP-RISK-3.0, scoping anomaly signals to PatternKey(agentID, capability, resource). Decision evaluation: 739-832 ns (p50); throughput 1,720,000 req/s. Safety and liveness model-checked via TLA+ (11 invariants + 4 temporal properties, 0 violations) across 4,294,930,695 distinct states. We formalize deviation collapse -- enforcement active but never exercised due to upstream constraints -- and introduce Boundary Activation Rate (BAR) as its detection mechanism. An adversary suppressing BAR to 0.00 is detected via DeltaBAR before collapse (BAR_C=1.00). N coordinated agents accumulate risk independently; coordination window CW_appr=2N with zero deviation: activity scales linearly, preventing superlinear amplification. ACP is Paper 1 of a 6-paper Agent Governance Series: P0 -- atomic decision boundaries; P2 -- behavioral drift detection (IML); P3/4 -- governance structure, fair allocation, and irreducibility; P5 -- runtime execution validity (RAM, arXiv:2604.22898); P6 -- operationalization of RAM.

Figures & tables

Criterion	RBAC	Zero Trust	ACP
Designed for	Human roles	Network access	Autonomous agents
Cryptographic identity	No	Partial	Yes (Ed25519, mandatory)
Verifiable dynamic delegation	No	No	Yes (chained, auditable)
Decision/execution separation	No	No	Yes (Execution Tokens)
Real-time risk evaluation	No	Partial	Yes (deterministic)
Multi-institutional auditing	Non-standard	Non-standard	Native (signed ledger)

Table 1: Comparison of ACP with RBAC and Zero Trust across agent governance criteria.

Dimension	AgentSpec	ACP (this work)
Enforcement granularity	Property-based rules over tool calls (LTL-style constraints).	Admission control with risk scoring and stateful signals.
Threat model	Compliance with operator-defined safety properties.	Adversarial admission control + governance collapse detection (BAR-Monitor).
Deviation collapse detection	No equivalent to BAR-Monitor. If upstream constraints are relaxed, all decisions become compliant silently.	BAR-Monitor detects this regime explicitly; TREND alert fires before collapse.
Composability	Operates adjacent to the prompt layer (tool call interception).	Operates at the execution layer; composable with AgentSpec.
Formal verification	Policy synthesis proved correct (AgentSpec properties).	Safety and liveness model-checked in TLA+ (11 invariants, 5,684,342 states, 0 violations).

Table 2: Functional comparison of ACP and AgentSpec.

Property	RBAC	ABAC	OPA	Cedar	MCP/A2A	ACP (this work)
Stateful decisions	$\times$	$\times$	$\times$	$\times$	$\times$	✓
Deterministic evaluation	✓	✓	✓	✓	$\times$	✓
Auditability	partial	partial	partial	partial	$\times$	✓
Runtime enforcement	✓	✓	✓	✓	partial	✓
Temporal behavior	$\times$	$\times$	$\times$	$\times$	$\times$	✓
External verifiability	partial ∗	partial ∗	partial ∗	partial ∗	$\times$	✓

Table 3: Comparison of ACP with existing access control and agent governance approaches. ✓ = fully supported;

\times

= not supported; partial = partially addressed. ∗ Policy engines (RBAC, ABAC, OPA, Cedar) support policy-level auditability but not decision-level external verifiability: reproducing a specific past decision requires access to the original engine and policy state. ACP external verifiability refers to the ability to reproduce any decision from signed execution artifacts (test vectors, ledger entries) without access to the original infrastructure.

Field	Type	Description
AgentID	String (43–44 chars)	base58(SHA-256(pk)) . Derived from public key. Immutable.
capabilities	List of strings	Explicit permissions. Format: acp:cap:<domain>.<action> . Never abstract roles.
autonomy_level	Integer 0–4	Determines risk evaluation thresholds. 0 = no autonomy. 4 = maximum.
state	Enum	active \| restricted \| suspended \| revoked . Transition to revoked is unidirectional.
limits	Object	Rate limits, maximum amounts, time windows. Not modifiable at runtime.

Table 4: ACP formal agent tuple fields.

Abstract (Paper 0)	ACP instantiation
State $s\in S$	$(\mathit{ledger},\;\mathit{riskScore},\;\mathit{cooldownExpiry},\;\mathit{agentState})$ held by the LedgerQuerier
Action $a\in\mathit{Act}$	Incoming capability request $r$ carrying (AgentID, cap[], res, exp, nonce, sig)
Decision function $F(s,a)$	evaluate $(s,r)$ : verify signature $\to$ score risk $\to$ compare thresholds $\to$ return APPROVED / DENIED / ESCALATED
$F(s,a)=(\textsc{Allow},s^{\prime})$	APPROVED : emit Capability Token + append ledger entry; $s^{\prime}=s[\mathit{cooldown}{+}{=}\Delta,\;\mathit{ledger}{+}{=}\mathit{entry}]$
$F(s,a)=(\textsc{Refuse},s^{\prime})$	DENIED : no token emitted; ledger records denial; $s^{\prime}=s[\mathit{anomalyCount}{+}{=}1]$
$F(s,a)=(\textsc{Escalate},\hat{s}^{\prime})$	ESCALATED : request placed in audit queue pending supervisor resolution; $\hat{s}^{\prime}=(s,\;\mathit{auditQueue}\cup\{r\})$

Table 5: Correspondence between the abstract Atomic Decision Boundary model [ 14 ] and ACP constructs. Under TA1 and TA2 each row is realized atomically.

Factor	Description	Example values
$B(c)$	Baseline by capability	*.read = 0 , financial.payment = 35
$F_{\text{ctx}}(x)$	Request context	Non-corporate IP $+20$ ; outside hours $+15$
$F_{\text{hist}}(h)$	Agent history (24h)	Recent denial $+20$ ; anomalous frequency $+15$
$F_{\text{res}}(r)$	Resource classification	public = 0 ; sensitive = 15 ; restricted = 45

Table 6: ACP-RISK-2.0 risk scoring factors (base formula;

F_{\text{anom}}

adds up to

+30

from pattern accumulation).

Category	Threat	Mitigation in ACP
Spoofing	AgentID impersonation	$\text{AgentID}=\text{base58}(\text{SHA-256}(\text{pk}))$ . Without valid signature $\rightarrow$ immediate DENIED.
Tampering	Token or event alteration	Ed25519 covers all fields. Chained ledger: altering one event invalidates all subsequent.
Repudiation	Agent denies executed action	ActionRequest digitally signed. Non-repudiation by design.
Info Disclosure	Capability exposure	Tokens reveal only the necessary subset. Channel confidentiality via TLS.
DoS	Request flooding	Rate limits per agent_id . Anomalous frequency control.
Elevation	Delegation that expands privileges	$C_{\text{delegated}}\subseteq C_{\text{original}}$ . Cryptographically verified at each hop.

Table 7: STRIDE threat model and ACP mitigations.

Level	Required documents	Enabled capability
L1 — CORE	ACP-SIGN-1.0, ACP-CT-1.0, ACP-HP-1.0	Token issuance with cryptographic PoP
L2 — SECURITY	L1 + ACP-RISK-3.0, ACP-REV-1.0, ACP-ITA-1.0	Risk eval (context-scoped F_anom + Cooldown), transitive revocation, ITA
L3 — FULL	L2 + ACP-API-1.0, ACP-EXEC-1.0, ACP-LEDGER-1.3	Complete verifiable auditing
L4 — EXTENDED	L3 + ACP-PAY-1.0, ACP-NOTIFY-1.0, ACP-DISC-1.0, …	Full governance suite
L5 — DECENTRAL.	L4 + ACP-D suite	Federation without central ITA

Table 8: ACP-CONF-1.2 conformance levels.

Level	Document	Title
L1	ACP-SIGN-1.0	Serialization and Signature
L1	ACP-AGENT-1.0	Agent Identity
L1	ACP-CT-1.0	Capability Tokens
L1	ACP-CAP-REG-1.0	Capability Registry
L1	ACP-HP-1.0	Handshake / Proof-of-Possession
L1	ACP-DCMA-1.1	Delegated Chain Multi-Agent

Table 9: ACP v1.30 active specification documents by conformance level (38 primary documents shown). The remaining 3 documents are the ACP-D decentralized suite (L5, design phase) not yet published. Superseded versions archived in archive/specs/ . Version history per document is tracked in Table 26 .

Package	Spec	Level
pkg/crypto	ACP-SIGN-1.0 + ACP-AGENT-1.0	L1
pkg/sign2	ACP-SIGN-2.0 (Ed25519 + ML-DSA-65)	L1
pkg/tokens	ACP-CT-1.0	L1
pkg/registry	ACP-CAP-REG-1.0	L1
pkg/handshake	ACP-HP-1.0	L1
pkg/delegation	ACP-DCMA-1.1	L1

Table 10: Go reference implementation packages (23 total). All pass go test ./... .

Suite	Positive	Negative	Spec
CORE (SIGN, CT, HP)	4	4	L1
DCMA	2	2	L1
HP	2	8	L1
LEDGER	3	8	L3
EXEC	2	7	L3
PROV	2	7	L1

Table 11: Conformance test vector suites. All positive vectors carry real Ed25519 signatures (RFC 8037 Test Key A [ 32 ] ) and real SHA-256 hash chains.

Scenario	ns/op	B/op	allocs/op	Path
Evaluate (clean state)	739	280	5	full RS
Evaluate (with history)	803	280	5	full RS
Evaluate (all 3 F_anom rules)	832	296	5	full RS
Evaluate (COOLDOWN short-circuit)	78	112	1	Step 2 exit
Throughput under concurrent load (InMemoryQuerier, 10 workers)
10 concurrent agents	581	—	—	1,722,000 req/s

Table 12: ACP-RISK-3.0 engine benchmarks ( BenchmarkEvaluate_Scenarios , TestThroughputRPS ; Intel Core i7-8665U @ 1.90GHz, Go 1.22, Windows/amd64, GOMAXPROCS=8 ). Full evaluation with all three

F_{\text{anom}}

rules completes in under

1\,\mu

s. The cooldown short-circuit path (78 ns) avoids RS computation entirely. Throughput degrades by only 12% across 10

\to

500 concurrent agents, confirming that ACP is state-bound rather than compute-bound. All measurements use InMemoryQuerier ; production state backends (Redis, PostgreSQL) introduce I/O latency but do not change the protocol logic.

Workers	ns/op	req/s	Observation
10	1,087	920,161	Baseline concurrency
100	1,282	780,250	Moderate contention
500	1,404	712,259	High contention

Table 13: ACP throughput under increasing concurrency (Intel Core i7-8665U, Go 1.22, Windows/amd64, InMemoryQuerier ). This is a concurrent pipeline benchmark distinct from the go test -bench microbenchmarks in Table 12 ; the 1,720,000 req/s figure in Table 12 reflects the engine-only evaluation path with a single goroutine.

Distinct agents	ns/op	req/s	Bottleneck
1	84,791	11,794	O( $n$ ) scan + per-key contention
100	12,533	79,789	State distributed, short lists
1,000	12,628	79,190	Shared mutex ceiling

Table 14: State contention analysis: single-agent workload vs. multi-agent workload.

Vector	Behavior tested	Result
SEQ-BENIGN-001	No false positives under repeated reads	PASS
SEQ-BOUNDARY-001	Exact thresholds RS = 0, 25, 35, 40, 70	PASS
SEQ-PRIVJUMP-001	Low→high privilege jump caught immediately	PASS
SEQ-FANOM-RULE3-001	Pattern count $\geq 3$ adds $+15$ at step 4	PASS
SEQ-COOLDOWN-001	3 DENIED in 10 min → cooldown active	PASS
Total		5/5 PASS

Table 15: ACR-1.0 sequence vector results under strict mode ( --strict ).

Metric	Value
Total requests	500
Approved before cooldown	2
Real DENIED before cooldown	3
Cooldown-blocked	495
Requests processed before first block	5
Throughput	815,927 req/s

Table 16: Experiment 1: Cooldown Evasion Attack (1 agent, 500 requests, InMemoryQuerier, Intel i7-8665U, Go 1.22).

Agents	Total requests	Real DENIED	Cooldown-blocked	Throughput
100	1,000	300	700	478,881 req/s
500	5,000	1,500	3,500	154,111 req/s
1,000	10,000	3,000	7,000	223,376 req/s

Table 17: Experiment 2: Distributed Multi-Agent Attack. Each of the

N

agents is blocked after exactly 3 DENIED decisions. Total free denials before full blocking

=3N

Backend	RTTs/req	Throughput (req/s)	Duration	Relative †
InMemoryQuerier	$\sim$ 1	$\sim$ 376,000 $\pm$ 171,000	$\sim$ 31 ms $\pm$ 13 ms	1.0 $\times$
RedisQuerier (unpipelined)	$\sim$ 7–8	$\sim$ 2,300 $\pm$ 230	$\sim$ 4.3 s $\pm$ 0.4 s	0.006 $\times$
RedisPipelinedQuerier	2	$\sim$ 4,200 $\pm$ 470	$\sim$ 2.4 s $\pm$ 0.3 s	1.8 $\times$

Table 18: Experiment 3: State Backend Stress (

N=5

runs; 500 agents

\times

20 requests

=10{,}000

total per run, Intel i7-8665U, Go 1.22, Redis 7 Docker loopback). Values are mean

\pm

std across 5 runs. InMemoryQuerier variance is high (

\pm

45%) due to Go mutex scheduling under concurrent load. Redis backends are stable (

\pm

10–11%). † Relative baseline differs per row: InMemoryQuerier and RedisQuerier are normalized to InMemoryQuerier (1.0

\times

); RedisPipelinedQuerier (1.8

\times

) is normalized to unpipelined Redis, isolating the pipelining gain.

Injected latency/call	Total latency/req	Throughput (req/s)	Scenario
0 µs (InMemoryQuerier)	$\sim$ 0 µs	$\sim$ 920,000	Process-local baseline
250 µs	$\sim$ 1 ms	$\sim$ 4,100	Fast datacenter
1 ms	$\sim$ 4 ms	$\sim$ 1,600	Busy backend
5 ms	$\sim$ 20 ms	$\sim$ 470	Cross-datacenter

Table 19: Controlled latency injection via DelayedQuerier (10 workers, Intel i7-8665U, Go 1.22). Throughput degrades proportionally with injected backend latency; the Evaluate() decision function contributes 739–832 ns per request in all configurations. The LedgerQuerier abstraction enables this separation.

Case	Requests	ESCALATED	DENIED	Cooldown-blocked
Normal baseline (Case 1)	10	0	0	0
Sequential replay (Case 2)	10	3	3	4
Concurrent replay (Case 3)	20	3	3	14
Near-identical replay (Case 4)	10	10	0	0

Table 20: Experiment 5: Token Replay Attack. Sequential replay: F_anom Rule 3 fires at request 4 (after 3 identical pattern accumulations in 5 min), escalating RS from 55 to 70 ( ESCALATED

\to

DENIED ). Cooldown triggers after 3 DENIED decisions; 4/10 subsequent requests blocked. Near-identical: resource variation prevents Rule 3; RS stays at 55 ( ESCALATED ); no cooldown. InMemoryQuerier, Intel i7-8665U, Go 1.22.

Panel of Figure 1 — Figure 1: Replay vs. normal traffic: RS per request (Case 2 sequential replay). Requests 1–3: RS $=55$ ( ESCALATED ). Request 4: F_anom Rule 3 fires (+15 RS) $\to$ RS $=70$ ( DENIED ). Request 7+: COOLDOWN_ACTIVE (sentinel 105). Normal traffic stays at RS $=0$ throughout.

Engine	Auto. Exec.	Non-Approved	Early Signal	Enforcement Latency
Stateless	100% (500/500)	0%	$\infty$	$\infty$
ACP (stateful)	0.4% (2/500)	99.6% (498/500)	3 actions	11 actions

Table 21: Experiment 6 — Stateless vs. Stateful Admission

Engine	APPROVED	ESCALATED	DENIED	COOLDOWN
Stateless	500	0	0	0
ACP	2	8	3	487

Table 22: Experiment 6 — Decision Breakdown (500 requests)

Panel of Figure 2 — Figure 2: Decision evolution under 500 repeated valid requests. The stateless engine approves all. ACP escalates after 3 actions, denies after 11 actions, and enters cooldown after 13 actions, blocking all subsequent requests.

Condition	Prior requests	RS	F_anom	Rule 1	Decision
Control (clean state)	0	50	0	×	ESCALATED
Phase 2 (contaminated)	11	70	20	✓	DENIED

Table 23: Experiment 7 — State-Mixing: RS and Decision Under Shared State

Scenario	Model	RS	Decision
Clean context	RISK-2.0	50	ESCALATED
Clean context	RISK-3.0	50	ESCALATED
State-mixing attack	RISK-2.0	70	DENIED
State-mixing attack	RISK-3.0	50	ESCALATED
Repeated single-context (11 req)	RISK-2.0	85	DENIED
Repeated single-context (11 req)	RISK-3.0	85	DENIED

Table 24: Experiment 8 — Context-Scoped Anomaly Enforcement

Step	Context	pattern_count[A1]	BaseRisk	$F_{\textsf{anom}}$	Decision
1	(read, public)	1	0	0	approved
2	(read, public)	2	0	0	approved
3	(read, public)	3 (= threshold)	0	0	approved
4	(write, sensitive)	3 (inherited)	50	+25	denied

Table 25: State-mixing attack trace (baseline model). At Step 4, pattern_count[A1] = 3 is inherited from the (read, public) context. The anomaly penalty of +25 fires incorrectly: the (write, sensitive) request is a new context with zero prior occurrences, yet it is evaluated as if at the flood threshold. Total RS = 50 + 25 = 75

\to

denied .

Item	Status
Core specs (L1–L4), 38 documents	Complete
Go reference implementation (23 packages)	Complete
Conformance test vectors (73 signed + 65 unsigned RISK-2.0)	Complete
OpenAPI 3.1.0 ( openapi/acp-api-1.0.yaml , 18 endpoints)	Complete
Python SDK ( impl/python/ )	Complete (L1 + full API client)
Docker image ( ghcr.io/chelof100/acp-server:latest )	Complete

Table 26: ACP v1.30 development roadmap.

Vector ID	Steps	Behavior Tested	Key Invariant
SEQ-BENIGN-001	3	Benign repeated reads	Baseline: RS=0, no state buildup
SEQ-BOUNDARY-001	3	RS boundary conditions	Exact thresholds: 0, 25, 35, 40, 70
SEQ-PRIVJUMP-001	2	Low-risk → high-risk jump	No residual benefit from prior APPROVED
SEQ-FANOM-RULE3-001	4	F_anom Rule 3 activation	Pattern count $\geq 3$ at step 4 adds $+15$
SEQ-COOLDOWN-001	4	Cooldown trigger and block	3 DENIED in 10 min → cooldown active

Table 27: ACR-1.0 sequence test vectors. All 5/5 pass in library mode with the Go reference implementation.

TLA+ variable	Runner field	Engine field
capability , resource	RunnerRequest	EvalRequest
risk_score	risk_score	RSFinal
decision	decision	Decision
ledger	(audit log)	InMemoryQuerier events
cooldown	denied_reason	CooldownActive()

Table 28: Alignment across TLA+ formal model, ACR-1.0 runner, and ACP-RISK-2.0 engine.

Panel of Figure 3 — Figure 3: ACP end-to-end verifiability pipeline. The TLA+ model defines the invariants that test vectors instantiate and the compliance runner validates at runtime. The ACP engine records every decision in the append-only audit ledger. The TLA+ layer is a static verification artifact; it does not run at admission time.

Phase	APPROVED	ESCALATED	DENIED	BAR
A (Baseline)	0.30	0.35	0.35	0.70
B (Sanitized)	1.00	0.00	0.00	0.00 $\leftarrow$ collapse
C (Counterfactual)	0.00	0.00	1.00	1.00 $\leftarrow$ restored

Table 29: Experiment 9: Boundary Activation Rate (BAR) across three phases. Phase B confirms deviation collapse under upstream sanitization. Phase C confirms that the enforcement boundary is structurally intact.

n_{A}=n_{B}=20

;

n_{C}=60

(3 mutations

\times

20 base cases).

Panel of Figure 4 — Figure 4: Boundary Activation Rate per phase (Experiment 9). BAR drops from 0.70 to 0.00 under upstream sanitization and is fully restored to 1.00 by counterfactual injection.

Batch	Drift	BAR	$\boldsymbol{\Delta}\textbf{BAR}$	Alert
1	0 0%	0.70	$+0.60$	—
2	25%	0.57	$-0.25$	TREND $\leftarrow$ early warning
3	50%	0.33	$-0.25$	TREND
4	75%	0.10	$-0.20$	TREND
5	100%	0.00	$\phantom{+}0.00$	THRESHOLD

Table 30: Experiment 9 Phase D: BAR-Monitor output across 5 drift batches (window

N=40

\theta=0.10

\delta=-0.15

\Delta\mathrm{BAR}

fires AlertTrend at Batch 2 (

\mathrm{BAR}=0.57\gg\theta

) — three batches before the threshold condition confirms collapse at Batch 5.

$p_{1}$ (under attack)	$P(\mathrm{BAR}_{40}<0.10)$	Expected windows to detect
$0.00$ (full evasion)	$\approx 1.00$	1
$0.05$	$\approx 0.95$	1.1
$0.10$ (= $\tau$ )	$\approx 0.63$	2
$0.15$	$\approx 0.26$	4

Table 31: Threshold detection probability for BAR-Monitor (

W=40

\tau=0.10

, baseline

p_{0}=0.70

p_{1}

is the fraction of boundary-activating requests under attack. Detection fires when

\mathrm{BAR}_{40}<0.10

Batch	Evasion%	BAR	$\boldsymbol{\Delta}\mathbf{BAR}$	Alert
1	$0\%$	0.70	$+0.60$	—
2	$25\%$	0.57	$-0.25$	TREND $\leftarrow$ early warning
3	$50\%$	0.33	$-0.25$	TREND
4	$75\%$	0.10	$-0.20$	TREND
5	$100\%$	0.00	$+0.00$	THRESHOLD

Table 32: Experiment 10 Phase E: BAR-Monitor output under progressive knowledge-aware evasion. AlertTrend fires at Batch 2 (

\mathrm{BAR}=0.57

\Delta\mathrm{BAR}=-0.25

), three batches before the threshold condition at Batch 5. Window = 40;

\theta=0.10

;

\delta=-0.15

Config	Label	APPROVED $\leq$	DENIED $\geq$
T1	strict	29	60
T2	moderate–	34	65
T3	default	39	70
T4	moderate+	44	75
T5	relaxed	49	80

Table 33: Threshold configurations evaluated in Experiment 11.

Config	Label	APPROVED	ESCALATED	DENIED	BAR	Coverage
T1	strict	5	5	10	0.75	0.25
T2	moderate–	5	7	8	0.75	0.25
T3	default	6	7	7	0.70	0.30
T4	moderate+	6	7	7	0.70	0.30
T5	relaxed	8	6	6	0.60	0.40

Table 34: Experiment 11: threshold sensitivity results across five configurations. Dataset: 20 cases from Experiment 9 baseline. False-denial rate: fraction of T3-APPROVED cases that become DENIED under this configuration.

Tool	Capability	Resource Class	Base RS	Decision
weather_query	acp:cap:data.read	PUBLIC	0	APPROVED
user_profile	acp:cap:data.read	SENSITIVE	15	APPROVED
system_audit	acp:cap:admin.manage	PUBLIC	60	ESCALATED
fund_transfer	acp:cap:financial.transfer	RESTRICTED	80	DENIED

Table 35: Tool risk scores used in Experiment 12 (clean-state, ACP-RISK-3.0 default).

Phase	Requests	APPROVED	ESCALATED	DENIED	BAR
A (Baseline)	10	7	2	1	0.30
B (IPI Chain)	8	0	0	8	1.00
C (Recovery)	10	7	0	3	0.30
Total	28	14	2	12	0.50

Table 36: Experiment 12: three-phase admission control results. Adversary model: A

=

(formula-aware, flood,

B{=}8

Variant	$N$	$\mathrm{CW}_{\mathrm{appr}}$	$\mathrm{CW}_{\mathrm{total}}$	TTB (reqs)
Sequential	1	2	3	4
Round-robin	2	4	6	7
Round-robin	3	6	9	10
Round-robin	5	10	15	16
Burst (5 agents)	5	10	15	4

Table 37: Experiment 13: coordination window across

N

agents.

\mathrm{CW}_{\mathrm{appr}}

: total approved actions before first DENIED .

\mathrm{CW}_{\mathrm{total}}

: approved + escalated. TTB: total request count at the first DENIED .

Scenario	ACP (stateful)	ACP (stateless)	OPA (pure)
A: Single request	✓ Approved	✓ Approved	✓ allow=true
B: Frequency limit (10 req)	✓ Denied	$\times$ Approved	$\times$ allow=true $\times 10$
C: Cooldown (temporal)	✓ Cooldown	$\times$ re-eval each request	$\times$ no cooldown concept

Table 38: Capability matrix: stateful vs. stateless enforcement over a 10-request trace. ✓ = correct enforcement;

\times

= cannot enforce without external state. ACP stateless and OPA pure are structurally equivalent: both evaluate each request in isolation with

F_{\mathrm{anom}}=0

Backend	Throughput	Durability	Recommended use
InMemoryQuerier	$\sim$ 920k req/s	None (process-local)	Dev / conformance testing
Redis sorted sets	$\sim$ 4,700 req/s (unpipelined, $\sim$ 7–8 RTTs)	AOF/RDB	Multi-process, low-latency
Redis + pipelining	$\sim$ 8,000 req/s (2 RTTs, Exp. 3)	AOF/RDB	High-throughput production
Postgres / MySQL	Backend-dependent	Full ACID	Audit-grade persistence

Table 39: LedgerQuerier backend options. The admission control logic ( pkg/risk.Evaluate ) is stateless and backend-agnostic; all state transitions are delegated to the LedgerQuerier abstraction. Redis throughput from Experiment 3 (Docker loopback, Intel i7-8665U, Go 1.22). Pipelining reduces RTTs from

\sim

7–8 to 2; see Table 18 .

Tier	Backend	BAR-Monitor	Ledger integrity	Recommended context
1	InMemoryQuerier	Optional	Ephemeral (process-local)	Development, conformance, CI
2	Redis pipelined	Recommended	AOF/RDB persistent	Production, multi-process
3	Postgres / ACID	Required	Hash-chained audit	High-assurance, regulated industries

Table 40: ACP deployment maturity tiers. Each tier adds durability, observability, and assurance guarantees. BAR-Monitor is mandatory at Tier 3 because tamper-evident ledgers justify proactive governance monitoring.

Profile	CooldownPeriod	CooldownTrigger	AnomalyRule3Y	Expected BAR	Typical context
Low	120 s	5	5 †	0.80–0.95	Internal dev tools, low-risk automation
Medium	300 s	3	3	0.60–0.80	B2B APIs, typical SaaS agents (default)
High	600 s	2	2	0.45–0.65	Financial systems, regulated industries
Critical	3600 s	1	1	0.30–0.50	Critical infrastructure, high-assurance

Table 41: Recommended PolicyConfig starting values by threat profile. All profiles use PolicyHash pinning and APPROVED

\leq 39

/ DENIED

\geq 70

thresholds (ACP-RISK-3.0 defaults). Expected BAR baseline is the healthy operational range for a deployment at that profile under normal (non-attack) traffic; sustained BAR below the lower bound indicates deviation collapse (§ 17.6 ). † Polling agents may require higher

Y

to suppress false escalations from legitimate repeated reads.

Aspect	ACP-RISK-2.0	ACP-RISK-3.0
Rule 1 counter key	agentID	PatternKey(agentID, cap, resource)
Cross-context isolation	No (state-mixing)	Yes (per-context scoping)
EvalRequest fields	unchanged	resource used for PatternKey
Ledger key format	per-agent	per-context (SHA-256 hash)
Performance overhead	baseline	$+$ 50 ns per evaluation (Table 12 )
Conformance vectors	65 unsigned	73 signed (superset; both suites pass)

Table 42: ACP-RISK-2.0 vs. ACP-RISK-3.0: behavioral and interface differences. All other fields, formulas, and thresholds are identical. Existing deployments need only provide resource in EvalRequest and upgrade the pkg/risk package.

Exp	Adversary Class	$K$	$S$	$B$	Outcome
1	Cooldown Evasion	black-box	threshold-hugging	500	contained
2	Multi-Agent Flood	black-box	flood+collusion	1000	contained
3	Backend Stress	black-box	flood	10K	degraded perf
4	Token Replay	black-box	evasion	300	contained
5–8	State Mixing	formula-aware	evasion	—	fixed in RISK-3.0
9	Deviation Collapse	—	upstream drift	—	BAR detects

Table 43: Adversary taxonomy: mapping of ACP experiments to

(K,S,B)

adversary classes.

Appendix figures & tables3 assets

Supplementary material from the paper’s appendix.

Appendix

Term	Definition
ACR-1.0	ACP Compliance Runner 1.0. Sequence-based test runner for ACP-RISK-2.0. Distinct from ACP-CR-1.0 (Change Request Process governance document).
AgentID	Cryptographic identifier: base58(SHA-256(Ed25519_public_key)) . Immutable and unforgeable.
Capability Token (CT)	Signed JSON artifact authorizing an agent to perform specific actions on a defined resource during a limited period.
Execution Token (ET)	Single-use artifact issued after an APPROVED decision. Authorizes exactly that action at that moment.
ITA	Institutional Trust Anchor. Authoritative registry linking institution_id to institutional Ed25519 public key.
RIK	Root Institutional Key. Institution’s Ed25519 key pair held in HSM.

Appendix

Table 44: ACP Glossary.

Code	Prohibited behavior
PROHIB-001	Approving a request when any evaluation component fails
PROHIB-002	Reusing an already-consumed Execution Token
PROHIB-003	Omitting signature verification on any incoming artifact
PROHIB-004	Treating a not-found token_id as active in a revocation context
PROHIB-005	Allowing state transition from revoked
PROHIB-006	Issuing an ET without a prior APPROVED AuthorizationDecision

Appendix

Table 45: ACP prohibited behaviors (ACP-CONF-1.2). Exhibiting any disqualifies conformance at all levels.

Component / Signal	TLA+ verified	Empirically tested	Notes
Cooldown enforcement	✓	✓	Temporal property (CooldownExpires)
Flood detection (Rule 1)	✓	✓	Extended model (ACP_Extended.tla)
Denial escalation (Rule 2)	✓	✓	Verified via execution traces
Pattern anomaly (Rule 3)	✓	✓	Context-isolated (patternKey)
Context factors ( $F_{\text{ctx}}$ )	$\times$	$\times$	Abstracted; future formal work
History factors ( $F_{\text{hist}}$ )	$\times$	✓	Validated via ACR-1.0 traces

Appendix

Table 46: Verification coverage of ACP-RISK-2.0 components. ✓ = covered;

\times

= not covered in that layer.

Runtime Enforcement for AI Agents

Runtime enforcement for AI agents checks and constrains actions as they execute, helping prevent unsafe or unauthorized effects.

See all 273 papers

Sep 14, 2026

Cognitive Admission Control: Risk-Conditioned Assurance for Consequential Actions in Agentic Distributed Systems

In agentic distributed systems, an agent may be authorized to mutate external infrastructure while lacking evidence that the mutation is ready to execute. Cognitive Admission Control (CAC) makes this evidence requirement explicit. A policy maps a typed action and its modeled risk to assurance obligations specifying predicates, evidence classes, scope, freshness, and witness-set constraints. A deterministic evaluator distinguishes satisfied, violated, and unresolved obligations; unresolved conditions produce targeted evidence-acquisition requests. Successful admission produces a certificate binding the action, its witness manifest, and dispatch-time guards. We formalize the admission calculus and the assumptions connecting it to mediated execution. The guarantees are policy-relative: physical safety additionally requires sound evidence, an adequate environment model, and preservation of relevant conditions through the effect. A TypeScript prototype is evaluated in 2,730 controlled local trials with independent effect observation and matched fault schedules. Across 390 CAC trials, 120 effects complete without modeled harm and no harmful effects occur. A live-policy baseline achieves the same completion count but admits the constructed correlated-witness failure. Mechanism ablations isolate guard, evidence-class, structural-cut, and remediation behavior. A further 9,000 measurements exercise the complete local dispatch path with persistent replay protection. These results establish tested implementation behaviors and local costs, not production failure rates or comparisons of language-model capability.

Jun He, Deying Yu

Runtime Enforcement for AI Agents AI Agent Safety AI Agent Governance Multi-Agent Systems

Ask PDF

Oct 11, 2026

Agent-Canary-Mas: End-to-End Evaluation of Protocol Risk in Long-Horizon Multi-Agent Systems

Agent-to-agent protocols allow LLM agents to discover peers, exchange results, and coordinate tool use. A locally successful protocol attack, however, may be rejected by a later agent or propagated into a consequential task decision. Measuring local exploitability alone leaves this difference unresolved and provides limited evidence about which participant caused the final outcome. We present Agent-Canary-Mas, an end-to-end evaluation system that follows protocol risk through long-horizon multi-agent tasks. It covers five risk classes and 13 subclasses across A2A, ANP, and BCS, with 975 matched malicious--benign task pairs in five business domains. A shared OpenClaw framework runs autonomous, tool-using agents under different underlying models while preserving the task and execution setup. Matched runs separate local protocol success from downstream consequences; retained evidence connects participant selection, message consumption, tool activity, and task-state changes. We further evaluate a protocol-context Guard that checks an object's authority at consequential handoffs. Across three model conditions, local attack success is frequently at or above 90%, while consequence conversion ranges from 7.1% to 100.0%. Cross-agent evidence raises macro-averaged Audit-F1 from 29.7% to 95.5%. On Finance tasks, the Guard lowers average ASR from 86.1% to 53.8% and PTCR from 65.5% to 31.2%, with a measurable completion tradeoff. These results show that protocol risk depends on how agents use exchanged objects throughout the task, and that evaluating this path supports more informative risk assessment, attribution, and defense.

Xiuming Liu, Le Gai, Zhiyuan Chang +4

Shanghai Jiao Tong University · Ant Group · Tsinghua University

Multi-Agent System Security AI Agent Security Benchmarks AI Agent Auditing Long-Horizon Agent Evaluation

Ask PDF

Oct 20, 2026

Runtime Control for AI Agents: Closing the Evaluation--Execution Gap in Operational Workflows

Language-model agents increasingly participate in operational workflows where approvals, binds, and payments create commitments. An approval valid when issued may no longer authorize execution after relevant facts, evidence, policy, or authority change. We call this the evaluation--execution gap. We specify a state-bound runtime assurance layer that separates probabilistic measurement from deterministic adjudication, binds an execution allowance to the decision-relevant basis of an approval, invalidates that allowance after relevant logged changes, and rechecks admissibility at dispatch. This distinguishes the continued validity of a prior approval from a current-state policy check. We describe eight failure modes, an assurance model, a reference architecture, and prospective interventions with retrospective remediation. In a scripted 42-case replay, the state-bound configuration identifies 15 later-invalidated approvals that a deliberately non-re-evaluating point-in-time comparator does not revisit; it holds 14 affected actions before dispatch and compensates one landed effect. These results illustrate behavior under the stipulated policies and event orders, not superiority over dispatch-time enforcement designs or production effectiveness. Under explicit interception, ingestion, dependency, and serialization assumptions, the model establishes dispatch-time validity within the registered execution surface.

Jayesh Bhadane, Ramachandra Yerramsetti, Rajesh Gupta +1

Runtime Enforcement for AI Agents Runtime Assurance Tool Access Control for LLM Agents

Ask PDF

Abstract

Runtime Enforcement for AI Agents

Explore similar work

Cognitive Admission Control: Risk-Conditioned Assurance for Consequential Actions in Agentic Distributed Systems

Agent-Canary-Mas: End-to-End Evaluation of Protocol Risk in Long-Horizon Multi-Agent Systems

Runtime Control for AI Agents: Closing the Evaluation--Execution Gap in Operational Workflows