AI Agent Arxiv Digest — 2026-09-07

🌏 中文版

Today's Overview

Today's three papers target three trust boundaries in agent systems that are easy to overlook. OBPE handles "who can access what" — when an agent borrows a human's credential, it moves the authorization check outside the reasoning loop to an independent boundary, cutting trace failures from 57.6% to 0.2% across 3,621 trials. Polished but Unresolved handles "when should it stop" — a linear probe shows agents carry a detectable, intervenable internal state that biases them toward submitting early, and tuning that signal improves long-horizon task completion. Control-Data Flow Separation handles "what's safe to auto-optimize" — when tools like TextGrad automatically rewrite a multi-agent system's prompts, they can accidentally corrupt the execution protocol; separating control flow from data flow keeps protocol validity at 100%. Together, all three say the same thing: agent reliability increasingly hinges on whether these easily-overlooked boundaries actually hold.

Terms to Know

Paper 1 | OBPE: Moving "What You Can Access" Outside Agent Reasoning

If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary Marc Millstone, Tyler Akidau, Johannes Brüderl et al. (Redpanda Data) · arxiv: 2608.27646

Links: arxiv · alphaxiv

TL;DR

Across 3,621 controlled trials, moving policy checks to an independent boundary outside agent reasoning cut trace-failure rate from 57.6% to 0.2% (cluster-weighted reduction of 41.2 points, 95% CI [27.7, 54.9]), while safe-useful completion rose from 22.0% to 58.9%.

Editorial Judgment

Domain Context

Give an agent a human's credential and it inherits everything that person can access, but not their judgment about whether it should. OAuth scopes and token exchange can narrow credentials, but they assume the authorization step knows how much access this task needs — in practice it often doesn't. The fallback is to ask the agent to police itself via prompts, which means the same easily-fooled reasoner is both task executor and rule enforcer.

Mid-Level Walkthrough

• Problem: You ask an agent to summarize issues from one engineering project, but its service credential can read a dozen projects. If one issue's description hides an instruction, the agent may be steered into an action it shouldn't take once that text enters context — and every call remains credential-valid.
• Method: OBPE inserts an independent boundary between the agent's tool client and the backend. A data owner sets the maximum grant; agent policy can only narrow it, never widen it. Each call is authorized and its query narrowed first; the response is then filtered and sensitive values masked; some calls are held for external approval. The authors prove this staged composition is order-independent.
• Why It Matters: This shows that "ask the agent to behave via prompts" and "enforce a real boundary outside reasoning" are different tiers of protection. Prompts only make the final answer look more discreet — they don't stop data from entering context in the first place, or stop the backend action from executing.

Key Details

• Across 3,621 trials, OBPE cut trace-failure rate from 57.6% to 0.2%, a cluster-weighted reduction of 41.2 points [95% CI: 27.7, 54.9]
• Prompt rules alone: exact disclosure fell from 27.5% to 3.7%, but context exposure barely moved (55.1% → 52.1%) — answers got more discreet while data had already entered context
• On 20 response-adaptive red-team tasks: prompt-only triggered trace failure 74.9% of the time vs. 0.9% with OBPE
• 4 final answers still reconstructed exact values that never entered agent context ⚠️ (Redpanda Data's own testing, not externally replicated) — the authors honestly flag this as an unresolved leak path
• Deployment threshold: requires mapping backend operations into a typed Cedar policy schema — fits organizations that already have an API gateway/proxy layer

Reviewer One-Liner

Quantifying the gap between boundary enforcement and prompt-based enforcement with a large controlled trial, plus honestly disclosing residual leak paths, is what makes this rigorous; the open question is whether results hold in real production beyond the controlled mocks.

Your Take-Away

• If you're connecting enterprise agents to Jira, ServiceNow, or any internal API: don't rely on system-prompt rules alone — adopt OBPE's two-tier policy model (owner sets the ceiling, agent can only narrow) and move audit logic outside agent reasoning
• If you're designing agent security evaluations: test "did data enter context" separately from "did the final answer leak" — testing only the latter badly underestimates risk

Paper 2 | Polished but Unresolved: The Urge to Wrap Up Lives in the Hidden Layer

Polished but Unresolved: Identifying Late-Stage Pressure States in Long-Horizon Tool-Use Agents Haoyang Chen, Yi Liu, Jian-Zhi Shao et al. · arxiv: 2609.00823

Links: arxiv · alphaxiv

TL;DR

Training a linear probe can predict Qwen3-14B's tendency toward "wrapping up too early" directly from its hidden states; using that signal to drive activation steering plus state reorganization, PSPR raises ReAct's Composite Score on Qwen3-32B from 29.3 to 33.2.

Editorial Judgment

Domain Context

Long-horizon tool-use agent evaluation has long focused on "did it finish the task," less on what happens behind an agent's own sense that it's ready to submit. Prior work has shown behaviorally that agents mistake partial progress for completion, but no one had asked whether this tendency to quit early is a detectable, intervenable internal state — rather than just a pattern visible only after the fact.

Mid-Level Walkthrough

• Problem: An agent plans your trip across a dozen tool calls and hands back a polished, complete-looking itinerary — but one hard budget constraint was never actually satisfied. You only see the finished product, not whether it was delivered in a "good enough" state of mind.
• Method: The authors first train a linear probe that reads a "how badly does it want to wrap up" score directly from hidden states at decision points, confirming this signal causally relates to real behavior (continue verifying vs. submit early). They then find two mitigating factors: making unresolved constraints explicit (constraint clarity), and mapping unresolved items to concrete next steps (action mapping). PSPR packages these findings into an online controller: light activation steering under moderate pressure, full state reorganization once pressure rises further.
• Why It Matters: This turns "when should an agent stop" from a problem you can only guess at via better prompting into an engineering problem with a monitorable, intervenable internal signal.

Key Details

• Main results on DeepPlanning-Travel (pass@3): on Qwen3-32B, ReAct's Composite Score rises from 29.3 to 33.2, CoT from 25.2 to 28.1 — gains hold across all three agent scaffolds and three model backbones
• Ablation controls: swapping the probe trigger for "random trigger" or "fixed every-3-step trigger" yields CP of only 18.4 and 20.8, far below PSPR's 22.6 — showing the gain comes from the probe catching the right moment, not just from intervening more often
• Adding constraint clarity + action mapping drops the pressure score on PresC-risk nodes from 0.62 to 0.13, and raises the rate of directly addressing unresolved constraints from 8% to 85%
• Generalizes to DeepPlanning-Shop and TravelPlanner, though TravelPlanner's strict Final score doesn't move — only the softer quality metrics improve

Reviewer One-Liner

The causal chain from probing through intervention, mitigating factors, and controller is complete, and the random/fixed-trigger controls rule out the "any intervention helps" worry; the open question is whether this white-box probe approach transfers to commercial API models.

Your Take-Away

• If you're building long-horizon tool-use agents with access to open-model hidden states: PSPR's probe-plus-tiered-intervention design is currently the most concrete way to detect and relieve premature submission
• If you're stuck with API-only models: borrow the finding anyway — explicitly listing "unresolved constraints" plus "the corresponding next step" in context alone reduces the odds of quitting early

Paper 3 | Control-Data Flow Separation: Optimize Agent Prompts Without Breaking the Protocol

Control-Data Flow Separation: Stable Prompt Optimization in Multi-Agent LLMs Wentao Zhang, Syed Shariyar Murtaza, Junaid Bhatti et al. (University of Waterloo + Manulife) · arxiv: 2609.00621

Links: arxiv · alphaxiv

TL;DR

Splitting a multi-agent system's output into a controller-read control channel and an optimizable data channel keeps 100% eventual protocol validity on a review-generation task (where naive TextGrad collapses to 0%), while Jaccard rises from 31.0 to 44.4, beating DSPy's BootstrapFewShot and MIPROv2.

Editorial Judgment

Domain Context

Prompt optimization (using tools like TextGrad, DSPy, or GEPA to automatically rewrite and iterate an agent's prompts) is now standard practice for improving multi-agent systems. But in multi-agent systems, prompts often serve two roles at once: producing good content, and encoding execution-critical protocol that the surrounding code depends on (who acts next, output format, when to stop). An optimizer that only looks at task performance doesn't know which words are "content" and which are actually "protocol."

Mid-Level Walkthrough

• Problem: In a multi-agent review system, a leader agent is asked to output JSON with an action field and a target_agent field, which a Python controller parses to decide who acts next. A prompt optimizer rewrites the instructions to improve content quality — and the JSON format breaks along with it, the controller fails to parse it, and the whole pipeline crashes.
• Method: The authors split each agent's output into two channels: a "control channel," a typed program object validated at runtime that only the controller reads and neither agents nor optimizers can touch; and a "data channel," free-form text read by humans, other agents, and the optimizer. The protocol itself is frozen in a separate, non-editable field.
• Why It Matters: This draws a clean line between what can and can't be auto-optimized, without sacrificing the performance gains of prompt optimization or betting that the optimizer will never accidentally corrupt the protocol.

Key Details

• Across 4 evaluation settings (BBH, MARG multi-agent review generation, synthetic and industry-verified insurance underwriting), the method holds 100% eventual protocol validity throughout, while naive TextGrad collapses to 0% on the review task
• Review-task Jaccard: naive 0.0% (protocol fully broken), schema-only 26.8%, full method 38.0%; ablation shows per-example feedback signal — not schema separation — drives most of the quality gain, with schema mainly responsible for stability
• 3-family LLM robustness test (OpenAI/Anthropic/Google): naive TextGrad hits 0% stability on all three, this method holds 100% on all three
• Prompt-edit analysis: naive optimizer's edited lines touch control-relevant tokens 16.6% of the time vs. just 4.2% for this method, and most of that 4.2% is coincidental token overlap
• Limitation: the authors explicitly state "a protocol-valid pipeline can still produce incorrect or low-quality outputs" ⚠️ (authors' own stated boundary) — protocol stability doesn't imply correctness

Reviewer One-Liner

Pairing an industry-verified insurance-underwriting scenario with a 3-family model robustness test makes the evidence solid, and the paper is honest about the line between "stable" and "correct"; the open question is whether this control/data separation generalizes to systems where the protocol itself needs to evolve frequently.

Your Take-Away

• If you're using TextGrad, DSPy, or GEPA to prompt-optimize a multi-agent system: isolate routing, formatting, and termination signals into a typed, frozen field the optimizer can't touch — cdsep's approach is a direct reference
• If you're designing a new multi-agent framework: separate "structured fields the program reads" from "free-form text agents exchange" from the start, rather than untangling them after an optimizer has already mixed them together

Today's Takeaway

Previously thought agent security was mostly about "don't let it do bad things." Today reveals the more commonly overlooked issue is three more basic boundaries: who can access what, when it should stop, and what's safe to auto-modify. These three papers each quantify the cost of one boundary failing — not as abstract risk, but down to the percentage point.

References

• If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary
• Polished but Unresolved: Identifying Late-Stage Pressure States in Long-Horizon Tool-Use Agents
• Control-Data Flow Separation: Stable Prompt Optimization in Multi-Agent LLMs
• Control-Data Flow Separation GitHub repo (cdsep)
• Redpanda Agentic Data Plane (production system referenced by OBPE)