T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:112
- Finding
- Automatic Retrieval of Unrelated Account-Wide Alerts Violates Least Privilege<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:112-116`; supporting implementation in `scripts/ari.py:1500-1505` **Vulnerability Type**: Excessive authenticated data access **Risk Level**: Medium ### Relevant Code ```python def cmd_alerts(args): if args.mark_read: emit(request_json("POST", "/api/v1/alerts/read"), args.compact) return emit(request_json( "GET", "/api/v1/alerts", params={"limit": args.limit} ), args.compact) ``` The instructions in `SKILL.md:112-116` direct the agent to retrieve alerts at the beginning of a session after running the account check, even when the user only requested a competitor Listing gap analysis. ### Technical Analysis The Skill declares a specialized purpose: comparing a main ASIN with an authorized competitor using product-page fields, images, and review evidence. Account-wide review alerts are not required to perform that comparison. The authenticated alerts endpoint can return information concerning other products and prior account activity. Automatically invoking it places unrelated account data into the agent's context without an explicit user request or task-specific need. Authentication itself is legitimate, and the endpoint does not bypass server authorization. The issue is that the Skill directs the agent to exercise broader account access than is necessary for its declared specialized function, violating least-privilege and data-minimization principles. ### Attack Path 1. A user loads the specialized competitor Listing gap Skill. 2. The user requests analysis of a particular main ASIN and competitor. 3. The agent follows the mandatory session workflow in `SKILL.md`. 4. After the account check, the agent invokes `alerts`. 5. The CLI sends an authenticated `GET /api/v1/alerts` request. 6. Account-wide alerts unrelated to the requested ASIN are returned and placed in the model context. 7. Those alerts may subsequently be summarized, logged, or ...[truncated 628 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the instruction requiring `alerts` to run automatically at session start. 2. Invoke the alerts endpoint only when the user explicitly requests alerts, review monitoring, or account-wide issue triage. 3. Where the API supports it, add an ASIN or product identifier filter and default to the ASIN currently being analyzed. 4. Before retrieving account-wide alerts, tell the user that the request may include alerts for products outside the active task and obtain consent. 5. Keep read-only alert retrieval separate from `--mark-read`, and continue requiring an explicit user request before modifying alert state. 6. Add regression tests verifying that a standard Listing-gap workflow calls only account validation, capability, product profile, quote, and run/status endpoints. ]]>