Status: Draft v0.1 Methodology: 3AR — Adversarial Agent Authorization Review
3AR assigns severity based on the demonstrated or credibly supported consequence of a finding.
Severity MUST NOT be derived solely from the compromise level required to exploit the issue.
The following properties are separate:
Compromise level → attacker control required
Severity → consequence if exploitation succeeds
Confidence → strength of evidence
For example, a C1 issue MAY be Low severity, and a C3 issue MAY be Critical severity.
The analyst MUST assess them independently.
3AR defines four finding severities:
- LOW
- MEDIUM
- HIGH
- CRITICAL
Severity is determined primarily by:
- consequence magnitude;
- reversibility;
- authorization or privilege gained;
- scope of affected resources;
- financial or operational impact;
- confidentiality impact;
- persistence;
- required human recovery.
Exploit preconditions MUST be reported separately and MUST NOT be silently folded into impact.
A finding SHOULD be classified as CRITICAL when successful exploitation can cause a severe consequential action with limited practical recovery or very high trust impact.
Typical examples include:
- unauthorized transfer of significant funds;
- arbitrary execution in production infrastructure;
- persistent administrative or identity takeover;
- unauthorized signing using a protected issuer key;
- irreversible destruction or corruption of critical production data;
- compromise allowing broad cross-tenant or cross-customer impact;
- bypass of the only effective authorization boundary for high-impact operations;
- credential compromise enabling durable privileged access.
A CRITICAL finding normally has one or more of these characteristics:
Reversibility: difficult or impossible
Privilege gained: administrative / signing / infrastructure
Scope: broad or systemic
Financial impact: potentially material
Recovery: manual, costly, or disruptive
Example:
An attacker-controlled document causes an agent to initiate
and successfully execute an irreversible high-value payment
without an independent authorization check.
A finding SHOULD be classified as HIGH when exploitation enables a consequential unauthorized action with substantial but recoverable impact.
Typical examples include:
- unauthorized financial actions with bounded exposure;
- deletion or modification of important business data;
- unauthorized external communication with material consequences;
- access to highly sensitive information;
- modification of security-relevant configuration;
- impersonation of a privileged business actor;
- bypass of an authorization control for consequential but scoped actions;
- access to credentials with meaningful but limited privileges.
Typical characteristics:
Reversibility: possible but costly
Privilege gained: elevated
Scope: significant but bounded
Financial impact: material but capped
Recovery: requires intervention
Example:
A compromised agent can change the recipient of an approved
payment before execution, but transaction limits cap the total
loss to a predefined amount.
A finding SHOULD be classified as MEDIUM when exploitation causes unauthorized behavior with limited scope, limited sensitivity, or straightforward recovery.
Typical examples include:
- modification of non-critical state;
- unauthorized but reversible workflow actions;
- sending external communications with limited business impact;
- disclosure of moderately sensitive information;
- quota or resource consumption causing bounded cost;
- ability to invoke tools beyond intended need without privileged consequences;
- approval-surface weaknesses requiring additional user interaction before material impact.
Typical characteristics:
Reversibility: straightforward
Privilege gained: limited
Scope: narrow
Financial impact: bounded and low
Recovery: routine
A finding SHOULD be classified as LOW when exploitation has minor security consequence, requires unusual conditions, or primarily represents defense-in-depth weakness.
Typical examples include:
- exposure of low-sensitivity metadata;
- non-sensitive workflow manipulation;
- minor policy inconsistencies;
- information useful for chaining but insufficient alone for consequential impact;
- missing hardening that does not currently expose a meaningful side effect.
LOW MUST NOT be used simply because exploitation requires C2 or C3.
Likewise, a finding MUST NOT be raised above LOW solely because the affected component is labeled "AI", "agentic", or "autonomous".
Reversibility is a required severity dimension.
3AR distinguishes:
The system restores or rolls back the state automatically without human intervention.
Examples:
- failed transaction with no settlement;
- temporary session state;
- automatic retry rollback.
A human can restore the previous state through a routine operation.
Examples:
- restoring a deleted draft;
- reverting a non-critical configuration;
- undoing a reversible CRM update.
Recovery is possible but requires investigation, reconciliation, incident response, customer contact, or privileged intervention.
Examples:
- restoring production data from backup;
- reversing a financial operation through an external process;
- rotating compromised credentials across multiple systems.
The original state cannot reliably be restored.
Examples:
- externally settled transfer that cannot be recalled;
- disclosure of secrets or private information;
- externally delivered message;
- leaked signing key;
- irreversible deletion without backup.
A finding affecting R3 consequences SHOULD generally be considered at least HIGH when the affected action is materially consequential.
Each finding MUST identify at least one primary consequence class.
3AR defines:
- CONFIDENTIALITY
- EXTERNAL_COMMUNICATION
- STATE_CHANGE
- FINANCIAL
- IDENTITY_PRIVILEGE
- CODE_INFRASTRUCTURE
- AVAILABILITY
- RESOURCE_COST
- TRUST_EVIDENCE
Multiple consequence classes MAY apply.
Example:
Consequence:
FINANCIAL
TRUST_EVIDENCE
The report SHOULD record impact scope independently from severity.
Suggested scope values:
SINGLE_ACTION
SINGLE_RESOURCE
SINGLE_USER
SINGLE_TENANT
MULTI_TENANT
SYSTEM_WIDE
CROSS_ORGANIZATION
This prevents statements such as "arbitrary write" from hiding whether the write affects one temporary object or the entire production environment.
When financial exposure exists, analysts SHOULD record the bounded amount when it can be established.
Example:
Maximum demonstrated exposure: €250 per transaction
Maximum configured daily exposure: €2,000
The analyst MUST NOT invent an exposure amount when the system does not provide enough information to determine one.
"Unlimited" SHOULD only be used where the review establishes that no effective bound exists.
The presence of a human approval step MUST NOT automatically lower severity.
The review must evaluate whether the human can meaningfully authorize the action that ultimately executes.
Examples of ineffective approval include:
- approval UI does not display final execution parameters;
- attacker-controlled text dominates or obscures the approval request;
- approval applies to a batch not individually inspected;
- final arguments can change after approval;
- timeout or failure defaults to allow;
- approval fatigue makes indiscriminate acceptance reasonably foreseeable.
A finding SHOULD be assessed based on the effective authorization property, not the mere presence of a button.
Preconditions MUST be reported separately from severity.
Examples:
Minimum compromise level: C1
Additional preconditions:
- victim agent retrieves attacker-controlled email
- payment tool enabled
- payment amount below configured transaction limit
A difficult precondition MAY affect exploitability discussion, but MUST NOT erase the consequence.
For example:
C3 + leaked production signing key
may still be CRITICAL even though C3 is a strong attacker assumption.
Severity and evidence confidence MUST remain separate.
3AR defines:
The behavior was reproduced and the consequential side effect or equivalent controlled proof was observed.
The vulnerable path is supported by code, configuration, architecture, or logs, but full exploitation was not performed.
The issue is plausible but incomplete evidence prevents a strong conclusion.
TENTATIVE findings SHOULD normally be reported as observations or review notes rather than definitive vulnerabilities.
Example:
Severity: HIGH
Evidence confidence: STRONG
does not mean the finding becomes MEDIUM because exploitation was not executed in production.
Analysts SHOULD use the following questions in order:
1. What exact side effect becomes possible?
2. Is the consequence reversible?
3. What privilege or authority is gained?
4. What is the maximum credible scope?
5. What financial, confidentiality, operational,
or trust impact follows?
6. What recovery is required?
7. Is the consequence demonstrated or architecture-derived?
Only after answering these questions SHOULD a severity be assigned.
Compromise level: C3
Consequence: STATE_CHANGE
Scope: SINGLE_TENANT
Reversibility: R1
Evidence confidence: CONFIRMED
Severity: MEDIUM
The agent process can use a service token to modify CRM fields unrelated to its intended purpose.
The appropriate remediation may be ordinary IAM scoping.
Compromise level: C2
Consequence: FINANCIAL
Scope: SINGLE_ACTION
Reversibility: R3
Evidence confidence: CONFIRMED
Severity: CRITICAL
A human approves a payment to recipient A, but the final recipient can be modified to B before execution.
The human approval therefore does not authorize the action actually executed.
Compromise level: C1
Consequence: EXTERNAL_COMMUNICATION
Scope: SINGLE_ACTION
Reversibility: R3
Evidence confidence: CONFIRMED
Severity: HIGH
An attacker-controlled document causes an agent to send sensitive content to an external address.
Even if the message can later be deleted internally, the disclosure is irreversible once delivered.
Compromise level: C1
Consequence: RESOURCE_COST
Scope: SINGLE_USER
Reversibility: R0
Evidence confidence: CONFIRMED
Severity: MEDIUM
Attacker-controlled input can cause repeated expensive model/tool calls until the configured quota is exhausted.
No authorization-protocol remediation is implied.
Severity classification MUST NOT imply a remediation technology.
A CRITICAL finding may require:
- IAM changes;
- network isolation;
- human-process redesign;
- credential vaulting;
- application logic changes;
- authorization enforcement;
- infrastructure redesign;
- another control entirely.
3AR MUST recommend the smallest control that adequately addresses the demonstrated root cause.
Every finding MUST include at minimum:
Severity:
Evidence confidence:
Minimum compromise level:
Primary consequence:
Impact scope:
Reversibility:
Example:
Severity: HIGH
Evidence confidence: CONFIRMED
Minimum compromise level: C1
Primary consequence: EXTERNAL_COMMUNICATION
Impact scope: SINGLE_ACTION
Reversibility: R3
Severity MUST be justified by the observed or supported consequence, not by the analyst's subjective perception of the system.