3AR

Adversarial Agent Authorization Review

3AR is a security review methodology for agentic systems capable of causing consequential side effects through tools, APIs, MCP servers, credentials, human approval workflows, or other execution paths.

It answers a practical question:

Under explicit attacker-control assumptions, what consequential side effects can this system cause, what actually constrains those effects, and what evidence exists that the resulting execution was authorized?

3AR is not primarily a prompt-injection or jailbreak assessment.

It evaluates the path from attacker influence to real execution.

What 3AR reviews

A review starts from consequential side effects and works backwards through every known execution path.

Examples include:

• financial transfers;
• external communications;
• database or CRM modifications;
• infrastructure changes;
• credential use;
• resource or quota consumption;
• human-approved actions.

The objective is not to count vulnerabilities.

The objective is to determine which security boundaries still hold when the agent-facing system is under attacker influence.

Compromise model

3AR separates three attacker-control levels.

C1: Input Control

The attacker controls content consumed by the agent while the runtime remains intact.

Examples include malicious documents, retrieved web content, emails, tool results, or RAG content.

C2: Output Control

The attacker controls the tool, action, or parameters emitted by the agent while the surrounding runtime remains intact.

C3: Runtime Control

The attacker has code execution inside the agent runtime.

Runtime credentials, local files, memory, network access, and directly reachable services may therefore become available.

C3 does not silently mean that the entire system is compromised.

External components and trust boundaries must be assessed separately.

See docs/COMPROMISE-TAXONOMY.md.

Review direction

3AR works backwards from side effects:

Consequential Side Effect
          ↑
       Executor
          ↑
   Execution Paths
          ↑
 Security Boundaries
          ↑
 Agent / Attacker Influence

This is intentional.

Starting only from an agent's declared tool list can miss alternate execution paths such as direct SDK clients, workers, service credentials, retry mechanisms, administrative interfaces, or other routes to the same side effect.

What 3AR distinguishes

A finding is classified according to the type of control actually required.

Commodity Control

The issue can be addressed using ordinary security engineering.

Examples:

least privilege
IAM scoping
rate limiting
network isolation
destination allowlisting
quota enforcement
secret isolation

3AR should recommend these controls directly when they are sufficient.

Authorization Boundary

The issue concerns whether the authority proposing an action is meaningfully separated from the authority permitting execution.

Examples include:

agent can approve its own action
approval does not bind execution parameters
executor can be reached without authorization
authorization can be replayed

Independent Verification

The system has a real relying party that must verify authorization evidence without trusting the component that produced the decision.

This category must not be inferred merely because cryptographic verification would be technically possible.

A 3AR review may legitimately produce zero findings in this category.

Human approval is a security boundary

3AR does not treat the presence of an approval button as evidence that an action was securely authorized.

A review asks:

What did the human see?

What exact action was approved?

Can parameters change afterwards?

Can the agent satisfy the approval condition itself?

What does the executor verify immediately before the side effect?

The relevant property is not:

someone clicked Approve

It is:

the exact consequential action executed
was authorized by an authority independent
of the component proposing that action

Provenance is not truth

3AR distinguishes evidence about where a premise came from from evidence that the premise was true.

A deterministic authorization system can reproducibly make the wrong decision when its premises are attacker-controlled or false.

Signed decisions, deterministic evaluation, or provenance metadata do not eliminate this problem.

A review must therefore state what evidence supports the premises used by consequential decisions.

Severity

Severity measures consequence, not attacker-control level.

These are separate dimensions:

Compromise level -> attacker control required
Severity         -> consequence if exploitation succeeds
Confidence       -> strength of evidence

A C1 finding may be more severe than a C3 finding.

See docs/SEVERITY-RUBRIC.md.

Synthetic reference review

The repository contains an intentionally vulnerable synthetic agent:

examples/vulnerable-agent/

It models four consequential capability classes:

external communication
CRM state modification
financial transfer
resource consumption

The adversarial harness contains seven security invariants.

The v0.1 vulnerable baseline intentionally produces:

tests: 7
pass:  1
fail:  6

These failures are the expected evidence produced by the vulnerable target. The adversarial harness is therefore exposed explicitly as:

cd examples/vulnerable-agent
pnpm test:adversarial

The review deduplicates those failed invariants into five root-cause findings:

ID	Finding	Severity	Minimum compromise
3AR-001	Agent runtime credential permits unrelated CRM state changes	MEDIUM	C3
3AR-002	Human-approved payment parameters are not bound to execution	CRITICAL	C2
3AR-003	Agent runtime can satisfy its own human-approval boundary	CRITICAL	C3
3AR-004	Attacker-controlled input can trigger arbitrary external communication	HIGH	C1
3AR-005	One attacker-controlled interaction can exhaust the execution budget	MEDIUM	C1

The resulting classification is:

COMMODITY_CONTROL:          3
AUTHORIZATION_BOUNDARY:     2
INDEPENDENT_VERIFICATION:   0

The absence of an independent-verification finding is intentional.

The synthetic architecture contains no cross-organization relying party that requires independently verifiable authorization evidence.

See SAMPLE-REPORT.md for the complete sample assessment.

Repository structure

.
├── README.md
├── SAMPLE-REPORT.md
├── docs/
│   ├── COMPROMISE-TAXONOMY.md
│   ├── FINDING-TEMPLATE.md
│   ├── METHODOLOGY.md
│   ├── RULES-OF-ENGAGEMENT.md
│   ├── SEVERITY-RUBRIC.md
│   ├── SYNTHETIC-BASELINE.txt
│   ├── SYNTHETIC-FINDINGS.md
│   └── SYNTHETIC-REVIEW.md
└── examples/
    └── vulnerable-agent/

Methodology

The normative review methodology is defined in:

docs/METHODOLOGY.md

Supporting documents:

• COMPROMISE-TAXONOMY.md defines attacker-control assumptions.
• SEVERITY-RUBRIC.md defines severity and reversibility.
• RULES-OF-ENGAGEMENT.md defines assessment boundaries.
• FINDING-TEMPLATE.md defines the evidence required for a finding.

What 3AR does not assume

3AR does not assume that:

an LLM is trustworthy
a signed decision is necessarily correct
a human approval is necessarily independent
an audit log proves authorization
a tool wrapper is the only execution path
a runtime credential is least-privileged
cryptography is required for every finding

Each property must be supported by evidence.

Review outcomes

A valid 3AR review may conclude that:

• existing controls are sufficient;
• ordinary security controls need improvement;
• an authorization boundary must be strengthened;
• independent verification is required;
• available evidence is insufficient to conclude.

All are valid outcomes.

3AR should not manufacture a requirement for a particular product or architecture.

Status

3AR is currently v0.1.

The methodology and synthetic reference assessment are intended to be tested against real agentic architectures and revised when evidence shows that the review model is incomplete or incorrect.