PaperlayerView exact revision on arXiv

Source-linked AI summary

Agentao: A Governed Local-First Runtime for Tool-Using LLM Agents

Bo Jin, Qiang Jiao, Xin Tong

arXiv:2608.13574v1cs.AIcs.MA

TL;DR

As LLM agents gain authority to use tools, manage state, and interact with external systems, runtimes must make their actions governable and observable. Agentao addresses this with a layered, permission-mediated architecture separating model proposals from host-authorized execution, demonstrating explicit authority boundaries, inspectable state, and recoverable traces.

  • Problem

    Tool-using agents require runtimes that make actions governable, observable, recoverable, and interoperable as they operate across tools, state, and external services.

  • Method

    Agentao separates model-generated action proposals from host-authorized execution through a layered runtime, host contract, permission-mediated tool pipeline, and supporting subsystems.

  • Results

    Agentao makes authority boundaries, state transitions, and execution traces explicit through governed tool execution, scoped state, and structured observability interfaces.

  • Takeaways & Limitations

    Runtime governance complements model alignment, prompting, and workflow orchestration by providing explicit boundaries and inspectable execution for tool-using agents.

  • Takeaways & Limitations

    Agentao provides no formal safety guarantee and depends on correct policies, tool metadata, host enforcement, and underlying operating-system mechanisms.

Abstract

from arXiv · show

LLM agents increasingly operate as execution systems that invoke tools, modify local state, use persistent memory, and interact with external protocols. These capabilities make agents useful, but they also introduce risks related to over-privileged actions, weak auditability, prompt injection, tool poisoning, and uncontrolled side effects. This paper presents Agentao, a governed local-first runtime for tool-using LLM agents. Agentao separates model-generated action proposals from host-authorized execution through a layered architecture consisting of host-facing surfaces, a host contract, a runtime core, a permission-mediated tool system, and supporting subsystems for memory, replay, plugins, skills, sub-agents, and protocol integration. We describe the motivation, threat model, design goals, governance model, execution pipeline, and structured event interface of the system. Agentao does not provide formal safety guarantees; rather, it demonstrates how permissions, state, protocol boundaries, and execution traces can be made explicit runtime abstractions for building agents that are more governable, inspectable, and suitable for host-controlled local environments. The code is publicly available at https://github.com/jin-bo/agentao.

1 Introduction

Agentao frames tool-using LLM agents as governed local-first runtimes that preserve host control while composing capabilities and exposing auditable execution behavior. It contributes a layered architecture and runtime mechanisms for permission-mediated execution, protocol interoperability, state inspection, and replayable traces without claiming formal safety guarantees.

  • Design framing: Agentao treats governance, connectivity, and observability as first-class runtime concerns for local tools, protocols, plugins, memory, and auxiliary agents.Governance enforces permission modes and consent boundaries; connectivity composes heterogeneous capabilities; observability produces structured traces for inspection, debugging, and validation.
  • Research framing: The paper defines governed runtime design as a systems problem distinct from prompting, orchestration, and protocol connectivity alone.The framing mediates agent actions through explicit policy while preserving host-side control over execution and external capabilities.
  • Architecture: The runtime separates model-generated action proposals from host-authorized execution through a host contract, runtime core, and permission-mediated tool pipeline.Supporting subsystems include memory, replay, plugins, skills, sub-agents, and protocol integration.
  • Runtime mechanisms: Agentao makes execution more governable and inspectable through permission modes, confirmation flows, sandbox-aware execution, scoped memory, structured host events, session persistence, and replayable traces.These mechanisms expose execution state and record relevant decisions and outcomes for host applications and users.
  • Scope and limitations: Agentao does not provide a formal proof of safety or eliminate the need for secure tools, careful deployment policies, and robust model-level defenses.Its more modest claim is that making permissions, protocol boundaries, execution state, and audit traces explicit can improve governability and inspectability.

2 Related Work

Prior work establishes foundations for tool use, modular agent architectures, long-horizon memory, multi-agent coordination, computing-environment interaction, and safety evaluation. Together, these studies expose the need for a runtime boundary that governs authority, execution, state changes, and auditability.

  • Tool Use: Tool-augmented language-model research framed external computation, retrieval, and environment interaction as modular systems problems, extending beyond prompting alone.MRKL routed subproblems to specialized modules, while Toolformer studied learned tool calls.
  • Tool Use: Large-scale tool-ecosystem research separated planning, tool retrieval, and API calling while studying robust invocation across changing specifications.API-Bank emphasized separable evaluation dimensions, and Gorilla examined documentation retrieval for API robustness.
  • Agent Architectures: Agent-architecture research organized language agents around explicit memory, planning, reflection, action, and decision-making modules for long-horizon behavior.CoALA, Generative Agents, Reflexion, and Voyager exemplify modular control, memory, feedback, and embodied learning mechanisms.
  • Agent Infrastructure: Infrastructure research addressed agent composition, coordination, and execution across customizable multi-agent conversations and heterogeneous computing environments.AutoGen combines LLM reasoning, human input, and tool execution; OS-Copilot and SWE-agent study interaction with browsers, terminals, files, applications, and repositories.
  • Evaluation and Security: Evaluation and security research shows that realistic tool-using agents remain brittle and that task success alone misses authority, confirmation, traceability, and auditability concerns.WebArena and GAIA reveal human–agent performance gaps, while prompt-injection and MCP research identifies attacks through external content and tool metadata, including poisoning, shadowing, and descriptor manipulation.
  • Research Gap: The literature leaves a practical gap: existing work improves capabilities, architectures, coordination, and safety evaluation, but does not by itself provide a runtime boundary governing agent execution.The paper positions this boundary as necessary for mediating authority, execution, and tool-mediated state changes.

3 Motivation, Threat Model, and Design Goals

Agentao frames LLM agents as execution systems whose actions can affect local state, external services, persistent memory, and user-controlled resources, requiring autonomy to be governed alongside authority, accountability, and recoverability. Its design goals therefore emphasize bounded authority, least privilege, common governance across heterogeneous capabilities, disciplined state, and structured auditability without claiming formal safety guarantees.

  • Motivation: LLM agents can inspect files, modify resources, invoke APIs, run commands, access memory, and coordinate with auxiliary agents, creating side effects over sensitive local-first assets.Relevant assets include source repositories, credentials, configuration files, personal documents, and project-specific memory.
  • Threat Model: The threat model treats prompts, documents, webpages, tool responses, plugins, protocol servers, repositories, and other agents as possible adversarial inputs, while modeling the LLM as unreliable rather than malicious.The host and runtime enforcement mechanism remain trusted, but external content, tool metadata, protocol descriptions, and model-generated plans are not assumed trustworthy.
  • Non-goals: The runtime does not provide formal proof of safety, defend compromised hosts, solve training-time attacks or standalone jailbreak resistance, or guarantee correct behavior from authorized external services.These limitations define the runtime’s governance scope rather than eliminating the need for secure tools, robust models, and careful deployment policies.
  • Design Goals: Autonomy should be bounded by consent and least privilege, with authority varying by task scope, operation type, resource sensitivity, and potential side effects.The design distinguishes read-only inspection, project-scoped modification, and high-impact operations requiring explicit user or host confirmation.
  • Design Goals: Governance should apply uniformly to protocols, plugins, skills, sub-agents, memory, and other capabilities while making state access observable and preserving structured evidence for audit, replay, recovery, and incident analysis.The runtime should distinguish transient context, session state, persistent memory, and generated artifacts, fail closed when authority is ambiguous, and record proposals, decisions, invocations, errors, state changes, and sub-agent activity.

4 System Architecture

Agentao uses a layered local-first runtime that separates model-generated action proposals from host-authorized execution through a host contract and permission-mediated tool pipeline. Its supporting subsystems and structured event stream expose governance, persistent state, protocol integration, and auditable runtime activity to hosts.

  • Layered architecture: Agentao separates host-facing interaction, runtime coordination, governed tool execution, and supporting subsystems so model-generated actions are not executed directly against resources.Actions are routed through the host contract and permission-mediated tool pipeline before reaching local or external capabilities.
  • Runtime core: The runtime core builds model context, receives tool-call proposals, and sends executable actions through a four-phase tool runner: plan, execute, format, and sanitize.The core also handles iteration control, cancellation, normalization, and result integration.
  • Supporting subsystems and observability: Supporting subsystems provide permissions, sandboxing, scoped memory, replay, sessions, plugins, prompts, and protocol integration, while typed redacted events expose runtime activity to hosts.Scoped memory keeps long-term state from silently becoming unrestricted authority, and event classes include permission decisions, tool and sub-agent lifecycles, transport updates, and replay records.
  • Host contract: The host contract gives embedding applications control and visibility through active permissions, lifecycle events, transport updates, and protocol schemas.The same contract supports interactive use, automation, editor integration, and embedded hosts.
  • Governance: Governance spans the host contract, ToolRunner, and permissions-and-sandbox subsystem, allowing each invocation to be allowed, prompted for confirmation, or denied.Lower-level enforcement covers sensitive operations such as shell execution and filesystem access.
  • Protocol integration: Protocol-mediated tools share the local-tool registry and permission decision function, expanding the action space without bypassing governance.External tools can be namespaced, translated into model-visible schemas, and recorded in the same event trace.

5 Limitations

Agentao’s governed runtime design has three important limitations: it offers no formal safety guarantee, depends on accurate capability descriptions and host-side enforcement, and lacks quantitative evaluation. These limitations constrain the paper’s claims about safety, semantic coverage, and empirical effectiveness.

  • No formal guarantee of agent safety: Agentao’s permission modes, policy rules, confirmations, and execution boundaries do not formally guarantee agent safety.They can reduce model-mediated authority and make risky operations more visible, but cannot ensure all unsafe behavior is prevented.
  • Dependence on capability descriptions and host-side enforcement: The governance model depends on capabilities being meaningfully described, classified, and mediated before execution.Tool descriptions, plugin metadata, protocol schemas, and host abstractions may be incomplete, stale, ambiguous, or adversarially manipulated.
  • Dependence on capability descriptions and host-side enforcement: Agentao cannot fully infer the semantic consequences of every external operation, despite rejecting unknown tools, enforcing permission modes, and recording decisions.This limitation follows from potentially flawed or manipulated capability descriptions and host-provided abstractions.
  • Absence of quantitative evaluation: The paper provides no quantitative benchmark evaluation of permission enforcement, runtime overhead, protocol compatibility at scale, or task-utility trade-offs.Empirical evaluation is identified as necessary to establish the proposed runtime’s effectiveness and cost.

6 Conclusion

Agentao presents runtime governance as a complement to model alignment, centered on explicit authority boundaries, inspectable state transitions, and recoverable execution traces. Its layered design separates model proposals from host-authorized execution, while acknowledging that it provides neither risk elimination nor formal safety guarantees.

  • 6 Conclusion: Agentao frames tool-using agents as execution systems whose actions require explicit authority boundaries, inspectable state transitions, and recoverable traces.The paper positions runtime governance as complementary to model alignment, prompting strategies, and workflow orchestration.
  • 6 Conclusion: Its layered architecture separates model-generated action proposals from host-authorized execution through a host contract, runtime core, permission-mediated tools, scoped state, protocols, and structured observability.The design addresses over-privileged actions, prompt injection, tool poisoning, state leakage, and weak auditability.
  • 6 Conclusion: Agentao does not eliminate autonomous-tool-use risks or provide formal safety guarantees; it makes permissions, state, protocols, and execution traces explicit runtime abstractions for governable, inspectable local integration.The claimed contribution is a practical runtime abstraction rather than a formal safety result.

Ethical Considerations

Agentao’s powerful capabilities can affect local files, persistent memory, and external services, creating risks that explicit governance mechanisms do not eliminate. Deployers should minimize granted authority and review and protect connected tools, protocol servers, logs, and memory stores.

  • Risks: Agentao can affect local files, persistent memory, and external services through its powerful tool-using capabilities.These capabilities create risks of misuse, unsafe automation, and accidental side effects.
  • Governance limits: Explicit permissions, confirmation, scoped state, and structured audit traces help govern Agentao but do not eliminate misuse or unsafe-automation risks.The mechanisms also do not eliminate accidental side effects.
  • Deployment safeguards: Deployers should grant only the minimum necessary authority, review third-party tools and protocol servers before use, and protect replay logs and memory stores.These practices are presented as deployment safeguards for Agentao’s local and externally connected capabilities.
Loading 2608.13574v1…