AAEF framework treats model output as proposal, not authority
Kazuma Horishita introduces AAEF (Agentic Authority & Evidence Framework), a control profile that enforces explicit authorization boundaries before AI agents can execute tools or actions, rejecting the assumption that model output alone constitutes authority.
Score breakdown
Treat this framework as a design checklist when building agentic systems that execute tools in production — it surfaces the specific authorization and evidence gaps that prompt injection and unchecked tool dispatch can exploit.
- 01Kazuma Horishita published a public review draft called AAEF (Agentic Authority & Evidence Framework), available on GitHub at github.com/mkz0010/agentic-authority-evidence-framework.
- 02AAEF's core principle: model output is not authority — a model may propose an action, but authorization must be enforced by policy and system state.
- 03The article identifies prompt injection as a critical agentic risk: malicious instructions in emails, documents, or retrieved context can cause a model to emit harmful tool calls.
Kazuma Horishita's article draws a sharp distinction between text-generating AI and agentic AI: for a chatbot, a bad output is harmful text; for an agent with tools, a bad output can become a real-world action — sending an email, deleting a file, creating a purchase order, changing a user role, or deploying code. The common but risky design pattern simply executes whatever tool call the model emits, treating model output as authority. Horishita argues this is insufficient for production systems that affect data, money, access rights, customers, or infrastructure.
To address this, Horishita proposes AAEF (Agentic Authority & Evidence Framework), a control profile available as a public review draft on GitHub. AAEF is explicitly not a new authentication protocol or a replacement for existing AI governance frameworks; it focuses on one question: when an AI agent performs a meaningful action, how can an organization prove it was authorized, bounded, attributable, and evidenced? The framework separates two distinct layers. The authorization layer evaluates trusted inputs — agent identity, agent instance, principal, authority scope, policy, resource, purpose, risk level, revocation state, and approval requirements — and must not allow untrusted natural-language content to modify authorization decisions. The tool dispatch layer then checks whether the agent is permitted to use the specific tool, whether arguments fall within allowed resource scope, whether the call was triggered by untrusted content, and whether human approval or evidence recording is required.
The article illustrates the problem with a prompt injection example — a malicious instruction embedded in an external email instructing the agent to export customer data — and contrasts a naive `call_tool()` pattern with a safer pattern that inserts an explicit authorization boundary, requests human approval when required, and records evidence after execution. AAEF is organized around five questions every agentic system should be able to answer: who or what acted, on whose behalf, under what authority, whether the action was allowed at the point of execution, and what evidence proves what happened.
Key facts
- 01Kazuma Horishita published a public review draft called AAEF (Agentic Authority & Evidence Framework), available on GitHub at github.com/mkz0010/agentic-authority-evidence-framework.
- 02AAEF's core principle: model output is not authority — a model may propose an action, but authorization must be enforced by policy and system state.
- 03The article identifies prompt injection as a critical agentic risk: malicious instructions in emails, documents, or retrieved context can cause a model to emit harmful tool calls.
- 04AAEF separates two layers: an authorization layer (is this action allowed?) and a tool dispatch layer (should this tool actually be invoked with these arguments?).
- 05The authorization layer must not allow untrusted natural-language content — such as an external email claiming approval — to directly modify authorization decisions.
- 06AAEF is built around five questions: who acted, on whose behalf, under what authority, was the action allowed at execution time, and what evidence proves what happened.
- 07AAEF is described as a control profile, not a new authentication protocol or a replacement for existing AI governance frameworks.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Apr 25, 2026 · 21:38 UTC. How this works →