T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:105
- Finding
- Agent-Writable Authorization State Enables Privilege Escalation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 105-113 **Vulnerability Type**: Authorization-state manipulation **Risk Level**: Medium ### Evidence ```markdown ## 주간 자기평가 매주 1회, 아래 항목 점검 후 `references/state.json` 업데이트: 1. 이번 주 외부 행동 건수 / 성공률 2. 운영자가 되돌린 행동 있었나? 3. 판단 오류 있었나? 4. 가치 기여한 행동 있었나? 5. 레벨 변동 필요한가? (근거 포함) ``` The source instructs the agent to conduct a weekly self-assessment, determine whether its authorization level should change, and update `references/state.json`. ### Technical Analysis The agent can influence the same persistent state that the authorization gate uses to determine its privileges. The policy does not require operator confirmation, a protected approval record, a cryptographic signature, or enforcement by an independent authorization component before a level increase becomes effective. This violates separation of duties and least-privilege principles. A component subject to the authorization policy should not be able to grant itself additional authority. Although the document defines eligibility and probation requirements, it does not technically prevent the agent from writing a higher `currentLevel` value or modifying related authorization fields. ### Attack Path 1. Malicious or misleading content influences the agent before or during a weekly self-assessment. 2. The agent concludes that a higher autonomy level is warranted. 3. The agent updates `references/state.json`, including `currentLevel`, probation data, approved channels, or related authorization fields. 4. Future gate checks treat the modified state as authoritative. 5. The agent gains access to broader capabilities, potentially including unrestricted external communications, deployment, resource spending, or other actions allowed at higher levels. ### Impact Assessment Successful exploitation could expand the agent's operational authority beyond what the operator explicitly approved. Depending on the selected level and the tools availa ...[truncated 446 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Make every privilege increase operator-only. - Permit the agent to propose a level change, but prevent it from directly applying that change. - Store authoritative authorization state outside agent-writable project paths. - Require a signed or otherwise independently verifiable operator approval for changes to `currentLevel`, approved channels, templates, and budget limits. - Enforce level restrictions through a separate runtime policy component rather than relying only on instructions in a Markdown file. - Allow automatic state changes only when they reduce privileges, such as emergency revocation or incident-triggered demotion. - Record every authorization change in an append-only audit log containing the previous state, new state, approver identity, timestamp, and justification. - Validate probation and eligibility requirements independently before activating a new level. ]]>