Kazuma Horishita

Posted on Apr 26

AAEF v0.2.0: Model Output Is Not Authority

#ai #agents #security #llm

AAEF v0.2.0: Model Output Is Not Authority

I released AAEF v0.2.0 Public Review Draft.

AAEF stands for Agentic Authority & Evidence Framework.

It is an action assurance control profile for agentic AI systems.

The core idea is simple:

Model output is not authority.

A model may propose an action.

A model may explain an action.

A model may generate a tool call.

But model output alone should not be treated as permission to execute a high-impact action.

That distinction becomes increasingly important as AI systems move from answering questions to taking actions through tools, APIs, workflows, agents, and external systems.

Repository:

https://github.com/mkz0010/agentic-authority-evidence-framework

Release:

https://github.com/mkz0010/agentic-authority-evidence-framework/releases/tag/v0.2.0

Discussion:

https://github.com/mkz0010/agentic-authority-evidence-framework/discussions/42

Why AAEF exists

Many AI security discussions focus on whether a model can be tricked.

That matters.

Prompt injection, indirect prompt injection, data poisoning, unsafe tool use, and excessive agency are real problems.

But for agentic AI systems, there is another layer:

What happens when a model-generated output becomes an actual action?

For example:

sending an email,
exporting a file,
calling an API,
modifying a production system,
changing access rights,
creating a purchase order,
writing persistent memory,
delegating authority to another agent.

The core security question is not only:

Did the model produce a bad output?

It is also:

Was the resulting action authorized, bounded, attributable, and evidenced?

AAEF is an attempt to structure that question.

The five practical questions

AAEF helps reviewers and implementers ask five practical questions about agentic AI actions:

Question	Meaning
Who or what acted?	Agent identity and runtime instance
On whose behalf?	Principal binding and delegated authority
What was allowed?	Authority scope, constraints, and action boundary
Was it allowed at execution time?	Authorization, runtime state, revocation, and ambiguity checks
What evidence exists?	Structured evidence for review, audit, and reconstruction

This shifts the discussion from model behavior alone to action assurance.

What changed in v0.2.0

AAEF v0.2.0 expands the initial public review draft into a more implementation- and assessment-oriented framework.

Major additions include:

44 controls
Evidence Event JSON Schema
Evidence Schema validation workflow
High-Impact Action Taxonomy
OWASP Agentic Top 10 mapping
Assurance Model and Residual Risk Mapping
Assessment Quick Start
Assessment Worksheet
One-page Overview
Reference Architecture
v0.2.0 Release Preparation Checklist

The goal of this release is not to claim that AAEF is complete.

The goal is to make the framework reviewable, testable, and useful for discussion.

Expanded control catalog

The control catalog now contains 44 controls across domains such as:

governance and scope,
agent identity,
principal binding,
delegation and authority,
action authorization,
tool invocation control,
memory and context control,
evidence and auditability,
human oversight,
response and revocation.

New v0.2 control areas include:

Intent-Authority Alignment
State-Dependent Authorization
Defer on Material Ambiguity
Authority Denial and Reauthorization Flow
Conditional Authority Freeze
Delegation Lineage Reconstruction
Non-Execution Evidence
Reauthorization Evidence
Human Override Evidence
Break-Glass Authority Control

These additions clarify an important point:

Having access is not the same as being authorized to perform a specific action at a specific time.

An AI agent may technically be able to call a tool.

That does not mean the action should be allowed.

Evidence Event Schema

AAEF v0.2.0 adds and expands an Agentic Action Evidence Event Schema.

The schema is intended to support structured evidence for high-impact agentic actions.

It includes support for:

authorization decision artifacts,
intent alignment,
runtime state checks,
input influence assessment,
delegation lineage,
human override,
non-execution,
and reauthorization.

This matters because agentic AI failures are often difficult to reconstruct.

A useful evidence event should help answer questions such as:

which agent instance acted,
which principal it acted for,
what action was requested,
what authority was available,
what policy decision was made,
what input influenced the action,
whether untrusted content was involved,
whether the action executed,
and why the action was allowed, denied, deferred, escalated, or frozen.

High-impact actions

AAEF v0.2.0 adds a draft High-Impact Action Taxonomy.

A high-impact action is an agentic action that can materially affect people, money, access, systems, sensitive data, legal obligations, security posture, or downstream agent behavior.

Examples include:

external communication,
sensitive data access or export,
payment or financial commitment,
access rights change,
production system change,
code execution or deployment,
legal or regulatory commitment,
customer-impacting decision,
security response,
persistent memory write,
cross-agent delegation.

The point is not that every AI action needs heavy controls.

The point is that high-impact actions should not be treated like ordinary text generation.

Reference Architecture

AAEF v0.2.0 also includes a Reference Architecture.

The architecture separates four layers that are often blurred together:

Layer	Question
Model	What does the AI propose?
Authority	Is the action permitted?
Enforcement	Can only the permitted action execute?
Evidence	Can the action be reviewed later?

This is the core design separation.

The model can suggest.

The authority layer decides.

The enforcement layer constrains.

The evidence layer records.

A key component is the Tool Dispatch Enforcement Point.

The model should not directly turn a proposed tool call into an executed high-impact action.

There should be a control boundary where the system checks authority, policy, principal context, runtime state, revocation state, and evidence requirements.

Assurance and residual risk

AAEF v0.2.0 adds an Assurance Model and Residual Risk Mapping.

It classifies controls by assurance type:

Preventive
Detective
Evidentiary
Responsive
Governance

This is important because not every control prevents a failure.

Some controls detect risk.

Some produce evidence.

Some support response and revocation.

Some support governance.

AAEF also explicitly avoids overclaiming.

AAEF does not guarantee that:

a model will always reason correctly,
natural-language intent will always be interpreted correctly,
prompt injection will always be detected,
semantic influence from untrusted content can always be excluded,
revocation is instantaneous in distributed systems,
human approval will always be meaningful,
evidence is complete unless evidence collection is correctly implemented,
or an implementation is secure simply because it claims to use AAEF.

AAEF is intended to reduce, constrain, evidence, and review agentic action risk.

It is not a magic safety layer.

Assessment materials

AAEF v0.2.0 includes an Assessment Quick Start and a draft Assessment Worksheet.

The worksheet helps reviewers record:

control applicability,
assessment result,
evidence reviewed,
finding summary,
residual risk,
remediation notes,
owner,
target date,
related threats,
assurance type,
implementation assumptions.

The goal is to make AAEF usable not only as a conceptual framework, but also as a starting point for structured review.

It is not a certification scheme.

It is a public review draft for discussion and refinement.

Why this matters for agentic AI

Agentic AI systems blur boundaries.

They may combine:

user instructions,
retrieved documents,
emails,
chat logs,
tool outputs,
external web content,
memory,
workflow state,
API calls,
delegated tasks,
and autonomous planning.

To the model, many of these things become “context.”

But from a security perspective, they are not equivalent.

An external email is not a user instruction.

A web page is not an authorization grant.

A GitHub issue is not production approval.

A retrieved document is not permission to exfiltrate data.

A model-generated tool call is not authority.

That is the core problem AAEF is trying to address.

Request for feedback

I would especially appreciate feedback on: