A new arXiv preprint released on 17 August 2026 introduces Agentao, a runtime that forces AI agents to ask permission before every action they take S¹. The code is open source on GitHub under an MIT licence S¹P². The specific dangers it aims to address include prompt injection, compromised tools, excessive permissions, and unintended consequences S¹. Whether asking permission actually stops those attacks is the question the paper itself refuses to answer.

My read: This is the first agent runtime I've seen that builds the permission boundary into the architecture itself rather than bolting it on as a wrapper. The separation of "propose" and "authorize" is the right instinct, because the core danger with tool-using agents is that the same model generating the plan is the one executing it. But I don't buy the governance framing yet, because the authors explicitly disclaim formal safety guarantees S¹. A runtime that makes permissions explicit is better than one that doesn't, but "explicit" is not the same as "enforced." The 89 stars on GitHub P² tell me there's early interest, not validation. What I'd watch is whether anyone tries to break this with adversarial prompt injection, because the paper names that risk but doesn't claim to solve it.

Why proposal and execution can't be the same step

Agentao's fundamental design principle is that the AI model suggests actions while the host system makes the final decision S¹. When an LLM agent wants to call a tool, it generates an action proposal. The runtime intercepts that proposal, checks it against a host contract (the rules the host machine has set for what agents may do), and either authorises or blocks the execution S¹.

This matters because the current model for tool-using agents is essentially trust-by-default. You give an agent access to a search tool, a database connection, or an email client, and whatever the model decides to do with those tools, it does. Agentao's proposal-execution split is a direct architectural response to these problems: if the agent hallucinates a tool or tries to run a poisoned one, the host has a chance to catch it before anything happens.

What's inside the runtime

Agentao's architecture is layered S¹. It includes interfaces for the host machine to interact with the agent, a set of permission rules known as the host contract, an execution engine for the runtime core, and a system that verifies every tool call through permissions S¹. Additional components manage memory, replay capabilities, plugins, skills, sub-agents, and protocol integration S¹.

According to the project's README, Agentao functions as a Python-based agent framework designed to be embedded locally with a focus on privacy P⁴. The GitHub repository, created on 10 February 2026, has 89 stars and 6 forks, with code in HTML, Python, Shell, and TypeScript P². The paper itself covers the motivation, threat model, design goals, governance model, execution pipeline, and structured event interface S¹. It shows how permissions, state, protocol boundaries, and execution traces can be made explicit runtime abstractions, meaning they are first-class objects the system tracks rather than implicit behaviours that happen by accident S¹.

What to do about it

Consider a data analyst at a mid-sized logistics firm who uses an LLM agent to query an internal shipment database. Today, if that agent processes a returned result set containing a prompt injection, a hidden instruction could trick it into running a destructive SQL command. Under Agentao's model, the agent would propose the query, but the runtime would check it against the host contract first. The query would need explicit authorisation before reaching the database, and the execution trace would be logged for later audit.

The practical pattern worth adopting, even without Agentao specifically, is the proposal-execution split. If you are building or evaluating tool-using agents, make sure the model cannot directly execute tool calls. Insert a layer that checks each proposed action against an allowlist before it runs. The Agentao repository at github.com/jin-bo/agentao S¹ is one reference implementation of this pattern, and the host contract concept is worth studying even if you build your own.

What we don't know yet

The paper is an arXiv preprint, not peer-reviewed S¹. The authors explicitly state that Agentao does not provide formal safety guarantees S¹. No independent third-party testing or production deployment has been verified. The GitHub repository's code state is confirmed only through metadata, not through a build or test run P².

Five risks the paper names (prompt injection, tool poisoning, over-privileged actions, weak auditability, uncontrolled side effects) S¹ are the same ones the runtime is designed to manage. But naming a risk and eliminating it are different things. Whether the permission-mediated tool system actually resists adversarial attacks is an open question the paper does not close.

Watch for independent security audits or adversarial testing of Agentao's runtime, expected to surface as follow-up arXiv papers or conference workshop submissions.

Sources: S1 — Agentao: A Governed Local-First Runtime for Tool-Using LLM Agents · P2 — jin-bo/agentao · P3 — mgarralda/governed-runtime · P4 — README.md · P5 — Huangsz2021/ToolOmni

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.