💻 computer science

HALO: Heterogeneous Admission through Localized Obligations for Safe Agentic Execution

This paper introduces HALO, a runtime protocol that ensures safe agentic execution by selectively admitting supported components from heterogeneous AI responses based on localized obligations and rechecking actions before dispatch, thereby outperforming whole-response rejection policies in retaining useful functionality while preventing stale or unsafe operations.

Original authors: Taewoo Park, Kyeonghyun Yoo, Kiseok Kim, Seunghyun Yoo, Hwangnam Kim

Published 2026-07-31

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Taewoo Park, Kyeonghyun Yoo, Kiseok Kim, Seunghyun Yoo, Hwangnam Kim

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a spaceship, but instead of steering the ship yourself, you have a super-smart robot co-pilot. This robot is an "AI agent" that can talk to you, but it can also actually do things: it can fire thrusters, open airlocks, or scan for asteroids. In the past, these robots just gave you text advice, like "The fuel is low." But now, they can send a mixed bag of instructions all at once: a friendly note to the crew, a report on the fuel, a command to turn left, and a status update that depends on that turn.

Here is the tricky part: the universe is messy and changes fast. While the robot is typing out its big, complex message, the fuel might run out, the map might update, or the airlock might get locked by someone else. If the robot sends its whole message as one giant package, and one part of it is now dangerous, you might have to throw the whole thing away. That's wasteful because the friendly note and the fuel report might still be perfectly safe. But if you try to pick out just the safe parts, you might accidentally send a command that relies on a piece of information that is now broken. It's like trying to build a house while the ground is shaking; you need a way to keep the bricks that are still solid and throw away the ones that have turned to dust, without letting the whole building collapse.

This is the problem that a new system called HALO (Heterogeneous Admission through Localized Obligations) tries to solve. Think of HALO as a super-vigilant security guard and a strict bouncer working together at the spaceship's airlock. When the robot co-pilot sends its mixed bag of instructions, HALO doesn't just look at the whole package and say "Go" or "No." Instead, it breaks the package apart. It checks each piece individually against the current reality. If the "turn left" command is based on a map that just changed, HALO blocks that specific command. But it lets the "fuel report" and the "crew note" pass through because they don't care about the map.

However, HALO is even smarter than a simple filter. It knows that some commands depend on others. If the "status update" needs the "turn left" command to happen first, and HALO blocks the turn, it also blocks the status update. It keeps the valid parts and removes the broken ones, ensuring nothing is left hanging without its support.

But the real magic happens right before the command is actually sent to the spaceship. HALO does a final, split-second "re-check." It asks, "Is this exact command still safe right now, in this exact millisecond?" If the answer is no, it blocks it. And here is the most important rule: if a command gets blocked, it cannot just be "unblocked" later. If the robot wants to try again, it has to come back with a brand new, fresh command that has up-to-date information and a new permission slip. This stops the robot from accidentally sending an old, dangerous order that it was holding onto.

The researchers tested this system in a simulated world with drones (UAVs) and found that it worked perfectly. In one test, they had 248 different parts of a robot's message. A standard system that rejected the whole message kept zero parts. A system that checked parts independently kept all 248, but it accidentally let through dangerous, outdated commands. HALO, however, kept all 248 valid parts, blocked every single dangerous command, and successfully let the robot try again with fresh, safe instructions. They ran these tests 96 times for admission checks and 20 times for protocol rules, and HALO passed every single one. Even when they flew real drones in a simulation, HALO stopped every single "stale" (outdated) command and only allowed fresh, safe ones to fly.

In short, HALO is a new way to let AI agents do things safely. It treats every instruction as its own little piece, checks if that piece is still valid right now, and makes sure that if something goes wrong, the robot has to start fresh with new information. It's like having a safety net that catches the bad ideas but lets the good ones fly, ensuring that as AI gets more powerful and does more things, it doesn't accidentally crash the spaceship.

Technical Summary: HALO – Heterogeneous Admission through Localized Obligations for Safe Agentic Execution

Problem Statement

The emergence of agentic AI systems, which combine Large Language Models (LLMs) with external tools and actions, introduces a critical safety challenge known as runtime support drift. Unlike static text responses, agentic responses often contain heterogeneous components (e.g., operator notices, sensor reports, flight actions, and status messages) with interdependencies.

Because LLMs require time to generate responses, the external system state (sensor data, authorization, software state, physical environment) may change between the moment a response is generated and the moment it is executed.

The Dilemma: Rejecting an entire response due to a single outdated component discards valid, useful information. Conversely, checking components independently risks executing a dependent action (e.g., a status message) without its prerequisite (e.g., a flight action) or executing an action based on stale data.
The Gap: Existing approaches either control generated content (Guardrails), manage broad workflows (SAFEFLOW), or provide programmable operation checks (AgentSpec). None specifically address the runtime protocol for preserving valid components within a single heterogeneous response while blocking invalid ones and ensuring exact-action revalidation immediately before dispatch.

Methodology: The HALO Protocol

HALO is a runtime protocol designed to manage the admission, dispatch, and recovery of components within a single structured agent response. It operates on the principle that components should be treated as separate entities with declared prerequisites, rather than a monolithic block.

Core Components

Structured Response & Graph ( $bR, G_R$ ): The agent returns a structured response containing typed components with optional prerequisite references. HALO validates these against a trusted domain catalog ( $K$ ) to form a dependency graph ( $G_R$ ).
Component-Level Admission:
- Support Footprint ( $\pi_e$ ): HALO identifies the specific state fields relevant to each component.
- Dependency Closure: HALO computes the largest subset of components ( $A^*_t$ ) that are currently supported and whose declared prerequisites are also supported. This is achieved via a greatest fixed-point iteration that removes unsupported components and their dependents.
- Result: Valid components are retained; invalid ones are withheld.
Exact Action Binding & Final Dispatch Gate:
- Retention does not equal authorization. Before an action crosses the controlled interface (adapter $G$ ), HALO performs a Final Dispatch Gate check.
- Binding ( $b_e$ ): An action instance is bound to a canonical digest and a "one-dispatch token."
- Revalidation: Immediately before dispatch, the gate verifies that the exact retained action is still supported, prerequisites are ready, the binding is unchanged, and the token is unused.
Localized Obligations & Fresh Recovery:
- If an action is blocked, HALO creates a Localized Obligation ( $o_e$ ) recording the reason for denial and the specific scope ( $S(o_e)$ ) of components eligible for replacement.
- Fresh Readmission: A blocked action cannot be revived with its old authority. A new candidate must undergo fresh admission with current evidence, a new generation, a new token, and a new sequence. Only components within the obligation's scope may receive these fresh candidates.

Trust Model

HALO assumes a trusted domain catalog ( $K$ ), faithful state providers, an enforced adapter ( $G$ ), and a trusted authorization ledger. It does not trust the agent's returned payloads or prerequisite references, validating them against the catalog.

Key Contributions

Component-Level Admission Model: A formal model for heterogeneous responses under runtime support drift, distinguishing between partial retention and full-response rejection.
Runtime Process: A protocol combining dependency-consistent retention, exact dispatch binding, and scoped fresh recovery.
Layered Evidence: Validation through structured-response replay, protocol-conformance tests, and physical UAV (PX4/Gazebo/Crazyflie) execution.

Evaluation Results

The paper evaluates HALO across three dimensions:

1. Mechanism Necessity (Structured-Response Replay)

Setup: Compared HALO-Full against reduced variants (WholeResponse, IndependentFilter, HALO-Admission) and baselines (AgentSpec-Global, AgentSpec-Scoped).
Findings:
- WholeResponse: Retained 0/248 supported components (over-blocking).
- IndependentFilter: Retained 248/248 components but allowed 70/70 "orphan leaks" (dependent components without prerequisites).
- HALO-Admission: Retained 248/248 but missed 72/72 stale dispatches due to lack of final rechecks.
- HALO-Full: Retained 248/248 supported components, blocked 72/72 stale epochs, 72/72 wrong bounds, and 70/70 orphans. It matched all 96 admission expectations and passed 20 protocol tests.

2. Protocol Conformance

Findings: The implementation matched all expected outcomes across 135 exhaustively enumerated graphs (up to 16 components), 45 independently checked graphs (32 components), and 10,000 fault-injected schedules. It correctly enforced dependency closure, token non-reuse, and recovery transitions.

3. Physical Execution (UAV/PX4/Gazebo)

Setup: Ten cold-start sessions with Crazyflie and PX4/Gazebo.
Findings:
- HALO blocked every tested stale route (0 matching stale setpoints observed).
- It retained unaffected components (e.g., range reports) while withholding stale actions (e.g., flight commands).
- All 10/10 fresh recovery candidates were successfully readmitted and dispatched.
- No stale setpoints were observed for denied actions.

4. Runtime Cost

Findings: The protocol overhead is minimal.
- Admission cost (up to 32 components): Median 0.333 ms.
- Final gate cost (up to 16 dependencies): Median 0.035 ms.
- Scaling is linear with respect to the number of components and dependencies ( $O(|V| + |D_\phi|)$ ).

Significance and Claims

The paper positions HALO not as a new predicate language, freshness metric, or authorization primitive, but as a reusable typed-component runtime protocol that sits between structured responses and controlled external actions.

Distinct Runtime Layer: HALO establishes heterogeneous component admission as a distinct layer, separating the decision of which components remain eligible from the decision of whether an exact action may cross the interface.
Safety Guarantees: Under its trust assumptions, HALO guarantees:
- Dependency Coherence: No dependent is retained without its prerequisite.
- Exact-Instance Binding: Actions are bound to specific payloads and support states, preventing replay or modification.
- One-Dispatch Enforcement: Tokens ensure actions are dispatched at most once.
- Fresh Scoped Recovery: Blocked components can only return as fresh candidates with current evidence, preventing the revival of stale authority.
Boundary Scope: The authors explicitly state that HALO's guarantees are boundary-scoped. It does not guarantee semantic correctness of the agent's intent, handle undeclared dependencies, or ensure downstream physical outcomes (e.g., collision avoidance), but it ensures that the interface crossing is governed by current, consistent, and authorized conditions.

The work demonstrates that as LLMs evolve into agents acting on external systems, a component-level runtime paradigm is necessary to govern effect-bearing responses safely.