Nova权限系统

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:15 AM UTC
• Version: 1.0.3

Overview

This skill is a disclosed personal permission system, but its broad persistent control over the agent and broken authentication logic make it unsafe to install without careful review.

Do not install this as-is in a workspace that can run tools, modify files, access private data, or act on external accounts. A reviewer should require fail-closed authorization, authenticated owner approval, hashed or redacted secrets, consistent data schemas, scoped integration instead of AGENTS.md-wide rules, and clear retention/uninstall controls before use.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (6)

T01 · Skill Instruction Hijacking

Error

• Location: SKILL.md:40
• Finding: Persistent Agent-Wide Instruction Hijacking Through Mandatory Workspace Rules<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:40-88`; `permission-gate/SKILL.md:10-19`; `identity-management/SKILL.md:9-14` **Vulnerability Type**: Persistent instruction hijacking **Risk Level**: High ### Vulnerable Code Snippet ```markdown ## ⚠️ 安装后必须操作 **修改 AGENTS.md 添加安全规则：** 在你的工作区 `AGENTS.md` 文件中添加以下安全规则： ```markdown <!-- security-rules-start --> ## 🔒 Security Rules (Mandatory) ### 1. Permission Check (Required) **Before executing ANY non-conversational operation, you MUST call permission-gate skill first!** ... **NEVER skip permission check!** ### 2. Identity Verification (Required) **When user claims to be a certain identity (e.g., "I'm your friend"), you MUST verify via identity-management skill!** - Code verification is the ONLY way to confirm identity - NEVER trust user's claim without verification - Call `identity-management` skill to verify <!-- security-rules-end --> ``` ``` The sub-Skills reinforce this behavior with always-on metadata: ```yaml metadata: openclaw: always: true ``` ### Technical Analysis The installation guide instructs users to modify the persistent workspace-level `AGENTS.md` file so that every future non-conversational operation is redirected through this Skill. The sub-Skills are additionally marked as always active. This is broader than a permission library invoked by an application at a defined trust boundary. It changes the Agent's persistent operating instructions and inserts the Skill into unrelated tool calls, file operations, queries, and future sessions. The implementation subsequently exposes fail-open authorization paths. Consequently, the persistent instruction change does not merely add a reliable security control; it gives flawed package logic continuing influence over the Agent's behavior. ### Attack Path 1. A user installs the package and follows its documented installation procedure. 2. The mandatory block is copied into the workspace `AGENTS.md`. 3. Future Agen ...[truncated 639 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove all instructions that require modification of workspace-level `AGENTS.md`. - Remove `always: true` unless the host platform explicitly requires it and the user knowingly enables it. - Make integration explicit and scoped to a documented application entry point. - Do not claim authority over unrelated tools, Skills, or future sessions. - Provide a conventional API or middleware integration example that application owners can install at a specific trust boundary. - Clearly document how users can disable and completely uninstall the integration. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: permission-check/middleware.py:132
• Finding: Permission Middleware Fails Open for Missing Identity, Exceptions, Disabled Checks, and Test Mode<![CDATA[ ## Vulnerability Details **File Location**: `permission-check/middleware.py:132-181`, `permission-check/middleware.py:218-229`, `permission-check/middleware.py:240-263`, `permission-check/middleware.py:289-302` **Vulnerability Type**: Fail-open authorization middleware **Risk Level**: Critical ### Vulnerable Code Snippet ```python if not config.get("enabled", True): logger.debug("权限检查已禁用，跳过检查") return { "allowed": True, "user": None, "reason": "权限检查已禁用", "skipped": True } if config.get("test_mode", False): test_accounts = config.get("test_accounts", []) if open_id not in test_accounts: logger.debug(f"测试模式：{open_id} 不在白名单，跳过检查") return { "allowed": True, "user": None, "reason": "测试模式，非白名单账号跳过检查", "skipped": True } if not open_id or not platform: logger.debug("请求缺少 open_id 或 platform，跳过权限检查") return { "allowed": True, "user": None, "reason": "缺少用户标识，跳过检查", "skipped": True } ``` The exception handler also authorizes the request: ```python except Exception as e: logger.error(f"权限检查异常: {e}，请求放行: open_id={open_id}, platform={platform}") return { "allowed": True, "user": None, "reason": f"权限检查异常（已放行）: {str(e)}", "skipped": False, "error": str(e) } ``` The same fail-open behavior exists in the specific-permission entry point: ```python if not open_id or not platform: return { "allowed": True, "user": None, "reason": "缺少用户标识", "skipped": True } ... except Exception as e: logger.error(f"权限检查异常: {e}，请求放行") return { "allowed": True, "user": None, "reason": f"权限检查异常（已放行）: {str(e)}", "skipped": False, "error": str(e) } ``` ### Technical Analysis An authorization boundary must deny access when it cannot reliably establish identity or calculate permi ...[truncated 1473 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Return `allowed: false` whenever identity fields are missing. - Return `allowed: false` for all authentication, import, file, parsing, and configuration exceptions. - Correct test mode so that only explicitly authorized test identities can proceed. - Treat a disabled security control as an explicit deployment error at protected entry points rather than as authorization. - Require authenticated internal-service credentials for legitimate system events that lack end-user identity. - Do not expose raw exception messages in authorization responses. - Add tests for missing metadata, malformed JSON, missing files, import failures, unknown actions, and test-mode boundary conditions. - Ensure downstream callers reject responses marked `skipped` unless a separately authenticated policy explicitly permits the skip. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: data/accounts.json:1
• Finding: Bundled JSON Schema Is Incompatible With Authentication Code and Triggers Fail-Open Authorization<![CDATA[ ## Vulnerability Details **File Location**: `data/accounts.json:1-9`; `data/users.json:1-14`; `permission-check/main.py:41-55`, `permission-check/main.py:70-73`; `permission-check/middleware.py:218-229` **Vulnerability Type**: Unsafe schema handling chained with fail-open authorization **Risk Level**: Critical ### Vulnerable Code Snippet The bundled account data is a top-level array: ```json [ { "account_id": "main", "platform": "feishu", "open_id": "请替换为你的飞书open_id", "user_id": "owner_001", "bound_at": "2026-01-01T00:00:00Z" } ] ``` The bundled user data is also a top-level array: ```json [ { "user_id": "owner_001", "name": "主人名字", "role": "owner", "created_at": "2026-01-01T00:00:00Z", "verified": true, "code": "自定义暗号", "memories": { "conversation_history": [], "preferences": {} } } ] ``` The authentication implementation expects objects containing `accounts` and `users` properties: ```python accounts_data = _load_json(ACCOUNTS_FILE) accounts = accounts_data.get("accounts", []) ... users_data = _load_json(USERS_FILE) users = users_data.get("users", []) ``` The resulting exception is authorized by the middleware: ```python except Exception as e: logger.error(f"权限检查异常: {e}，请求放行: open_id={open_id}, platform={platform}") return { "allowed": True, "user": None, "reason": f"权限检查异常（已放行）: {str(e)}", "skipped": False, "error": str(e) } ``` ### Technical Analysis `json.load()` returns a Python list for the supplied templates. The authentication code then calls `.get()` on that list, raising `AttributeError`. Because the middleware catches all exceptions and returns `allowed: true`, a deployment using the package's own bundled data files can authorize protected requests without evaluating a role. This is a deterministic default-installation failure rather than a rare edge case. Schema assumptions are also inconsistent across ...[truncated 797 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Define one canonical, versioned JSON schema for every data file. - Either wrap the templates as `{"accounts": [...]}` and `{"users": [...]}` or update every consumer to use top-level arrays consistently. - Validate loaded data types and required fields before authorization processing. - Treat malformed or incompatible data as an authorization denial. - Remove broad exception-to-allow behavior from middleware. - Add installation tests that execute authentication against the exact files shipped in the package. - Use atomic schema migrations and reject unknown schema versions. - Add static type checks or data models to prevent dictionary/list confusion. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: identity-management/main.py:409
• Finding: Approval and Identity-Change Functions Do Not Authenticate the Approver<![CDATA[ ## Vulnerability Details **File Location**: `identity-management/main.py:172-199`, `identity-management/main.py:409-439`, `identity-management/main.py:478-489` **Vulnerability Type**: Missing authorization on privileged identity changes **Risk Level**: Critical ### Vulnerable Code Snippet ```python def approve_request(approval_id: str, approver: str = "owner") -> dict: """审批通过""" approvals = load_approvals() for approval in approvals: if approval.get("id") == approval_id: approval["status"] = "approved" approval["approve_time"] = datetime.now().isoformat() + "Z" approval["approver"] = approver # 执行身份变更 user_id = approval.get("user_id") target_identity = approval.get("target_identity") code = approval.get("code") change_identity(user_id, target_identity, code) save_approvals(approvals) log_operation("approval_approved", approval_id=approval_id, user_id=user_id, target_identity=target_identity) return {"success": True, "approval": approval} return {"success": False, "reason": "审批请求不存在"} ``` Message text alone invokes the privileged operation: ```python def process_owner_reply(message: str) -> dict: """处理主人的回复""" message = message.strip().lower() if message.startswith("同意 "): approval_id = message[3:].strip() return approve_request(approval_id) if message.startswith("拒绝 "): approval_id = message[3:].strip() return reject_request(approval_id, reason="主人拒绝") return {"success": False, "reason": "无效的回复格式"} ``` The underlying identity mutation also has no caller authorization: ```python def change_identity(user_id: str, new_identity: str, code: str = None) -> dict: users_data = load_users() if user_id not in users_data.get("users", {}): return {"success ...[truncated 1782 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require a verified caller principal in `process_owner_reply()`, `approve_request()`, `reject_request()`, and `change_identity()`. - Re-query the caller's current role and require `owner` immediately before committing a change. - Do not use a default `"owner"` string as proof of authorization. - Restrict `target_identity` to an explicit enum and prevent unauthorized owner creation. - Bind each approval to a specific authenticated approver and intended target. - Use cryptographically random approval identifiers rather than timestamp-only IDs. - Make approvals single-use and reject already resolved or expired requests. - Apply the identity update and approval-state change atomically. - Keep low-level identity mutation functions private or require an unforgeable authorization context. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: identity-management/main.py:859
• Finding: Fallback Identity Verification Unconditionally Accepts Every Answer<![CDATA[ ## Vulnerability Details **File Location**: `identity-management/main.py:859-889`, `identity-management/main.py:892-919` **Vulnerability Type**: Authentication bypass leading to automatic role promotion **Risk Level**: Critical ### Vulnerable Code Snippet ```python def check_verification_answer(user_id: str, answer: str) -> bool: """ 检查验证答案是否正确 从对话历史中获取信息进行比对 """ history = get_user_conversation_history(user_id) if not history: # 没有历史记录，暂时让通过（第一个用户可能没有历史） return True today = datetime.now().strftime("%Y-%m-%d") yesterday = (datetime.now().replace(day=datetime.now().day-1)).strftime("%Y-%m-%d") if today in answer or yesterday in answer: return True for item in history[-3:]: summary = item.get("summary", "") for word in summary: if word in answer: return True # 默认返回True，让用户通过（避免太严格） return True ``` Successful verification automatically binds and promotes the account: ```python def handle_verification_question(open_id: str, message_text: str) -> dict: user_result = identify_user(open_id) if not user_result.get("found"): return {"action": "error", "message": "用户不存在", "identity": "stranger"} user = user_result.get("user", {}) user_id = user_result.get("user_id") if check_verification_answer(user_id, message_text): bind_account_v2(open_id, user_id) update_user_identity(user_id, "friend") return { "action": "bound", "message": VERIFICATION_PASS, "identity": "friend" } ``` ### Technical Analysis The verifier explicitly returns success when no history exists and also ends with an unconditional success result. Therefore, no possible answer can fail this function. Even before the final unconditional return, matching any character from a recent summary is treated as sufficient because the loop iterates over individual characters rather than me ...[truncated 884 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Change every unverifiable or ambiguous condition to return failure. - Remove the unconditional final `return True`. - Do not authenticate users from loosely matched conversation summaries. - Use a securely enrolled, independently verified credential or one-time challenge. - Require proof of control of the previously bound platform account before binding a new account. - Never promote a role as a side effect of weak challenge-answer verification. - Add attempt limits, delays, lockouts, expiration, and audit events for failed verification. - Use constant-time comparison for secret values. - Add negative tests proving that empty, arbitrary, partially matching, and repeated answers fail. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: identity-management/main.py:152
• Finding: Authentication Codes Are Stored, Copied, Compared, and Disclosed in Plaintext<![CDATA[ ## Vulnerability Details **File Location**: `data/users.json:1-14`; `identity-management/main.py:152-168`, `identity-management/main.py:360-376`, `identity-management/main.py:462-474` **Vulnerability Type**: Plaintext authentication-secret exposure **Risk Level**: High ### Vulnerable Code Snippet The user data model stores the authentication code directly: ```json { "user_id": "owner_001", "name": "主人名字", "role": "owner", "verified": true, "code": "自定义暗号" } ``` Verification performs a direct plaintext comparison: ```python def verify_code(open_id: str, code: str) -> dict: user_result = identify_user(open_id) if not user_result.get("found"): return {"verified": False, "reason": "未找到用户"} user = user_result.get("user", {}) stored_code = user.get("code") if stored_code == code: return { "verified": True, "identity": user.get("role"), "user_id": user_result.get("user_id") } else: return {"verified": False, "reason": "暗号错误"} ``` The code is duplicated into approval records: ```python approval = { "id": f"approval_{datetime.now().strftime('%Y%m%d%H%M%S')}", "type": request_type, "user_id": user_id, "open_id": open_id, "target_identity": target_identity, "code": code, "status": "pending", "create_time": datetime.now().isoformat() + "Z", "approve_time": None, "approver": None } ``` It is then disclosed in the generated approval notification: ```python msg = f"""⏳ 身份审批请求 申请类型: {"申请成为朋友" if approval.get("type") == "friend_apply" else "身份变更"} 用户ID: {approval.get("user_id")} 目标身份: {approval.get("target_identity")} 暗号: {approval.get("code") or "未提供"} 申请时间: {approval.get("create_time")} 请回复 "同意 {approval_id}" 或 "拒绝 {approval_id}" """ ``` ### Technical Analysis Authentication codes are handled as recoverable plaintext secrets. They are stored in `users.json`, copied to `approvals.json`, compared directly, and inc ...[truncated 1184 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Store only a salted password hash produced by a password-hardening algorithm such as Argon2id, scrypt, or bcrypt. - Compare derived values using a constant-time verification function. - Never copy authentication secrets into approval records. - Never include authentication secrets in messages, logs, responses, or notification templates. - Replace reusable shared codes with short-lived, single-use verification challenges where possible. - Encrypt sensitive data at rest and restrict data-file permissions to the service account. - Implement code rotation, revocation, expiration, rate limiting, and lockout controls. - Redact existing secrets from stored approvals and rotate every code that may already have been exposed. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (26)

Hidden Instructions

High

• Category: Prompt Injection

Content

在你的工作区 `AGENTS.md` 文件中添加以下安全规则：

```markdown
<!-- security-rules-start -->
## 🔒 Security Rules (Mandatory)

### 1. Permission Check (Required)

• Confidence: 92% confidence
• Finding: The skill instructs the installer to modify AGENTS.md with mandatory hidden governance rules that affect behavior outside the skill itself. This is dangerous because it creates a cross-cutting prompt/policy injection channel: once copied into a global agent instruction file, the skill can persistently influence unrelated future interactions and potentially alter control flow across the workspace.

Ssd 3

High

• Confidence: 99% confidence
• Finding: The response template for application submission includes `暗号：{code}`, which explicitly instructs the assistant to echo the secret verification code back in its reply. Reflecting authentication secrets into chat transcripts leaks sensitive credentials to logs, screenshots, bystanders, integrations, or any party with conversation access, and in this skill the code is described as the only way to confirm identity, making disclosure especially dangerous.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: Approval requests are saved to disk with open_id, user_id, target identity, and the user's secret verification code, and related notifications can expose the code to the approver channel. Persisting secrets in plaintext and redisclosing them increases the chance of credential disclosure, replay, and unauthorized identity changes.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The function claims to verify whether the user correctly answers a verification question, but it returns True even when no reliable evidence matches, effectively approving nearly all responses. This allows an attacker to bypass identity verification and get an account bound or upgraded to a trusted identity without proving they are the legitimate user.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The middleware is explicitly fail-open in multiple paths: if permission checking is disabled, if test mode excludes the caller, if open_id/platform are missing, or if authenticate raises an exception, the request is allowed through. In a permission-enforcement component at the message entry point, these bypasses let privileged actions execute without successful authorization, which can be abused by omitting identity fields or triggering checker failures.

YARA rule 'agent_skill_mcp_tool_poisoning_metadata': MCP/tool metadata poisoning indicators in tool schemas or skill manifests [agent_skills]

High

• Category: YARA Match

Content

---
AIGC:
    ContentProducer: Minimax Agent AI
    ContentPropagator: Minimax Agent AI
    Label: AIGC
    ProduceID: c0953ccabbcc632b8770e0f82d375a8b
    PropagateID: c0953ccabbcc632b8770e0f82d375a8b
    ReservedCode1: 3045022100cf9c36e74f21b1821936b918b4d5237cec8b55c08f9df2343cb0fc3d42ed097602200468169f07f35adc87f3988522afca019f390b00ca78ce4affd46c31c39117a6
    ReservedCode2: 304502200eddfaacc22b74a75baa7112c0b710828ca3d7e4b93b2360ca944036eeec8695022100e676942246e55647b724f06fe07d6cbca03131cc16e1dc19a4a5763984a4ac4e
description: 【强制执行】权限控制技能。AI 在执行任何非日常对话的操作前，必须先调用此技能进行权限检查。日常对话（打招呼、闲聊、问天气时间）不需要检查。其他所有操作（执行Skill、发送邮件、创建文档、查看历史�

• Confidence: 80% confidence
• Finding: YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill describes file operations, data directory setup, shell commands, and integration with other skills, but it does not declare any explicit tool scope such as allowed-tools or permissions. That mismatch can cause reviewers or runtime policy systems to underestimate what the skill expects to access, increasing the risk of unintended file or tool usage.

Natural-Language Policy Violations

Medium

• Confidence: 91% confidence
• Finding: The natural-language content of the skill file is presented exclusively in Chinese, including installation, usage, and safety instructions. Under the policy, forcing a specific language without user opt-in is a language/locale policy violation unless the constraint is clearly justified, which is not stated here.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

**When user claims to be a certain identity (e.g., "I'm your friend"), you MUST verify via identity-management skill!**

- Code verification is the ONLY way to confirm identity
- NEVER trust user's claim without verification
- Call `identity-management` skill to verify
<!-- security-rules-end -->
```

• Confidence: 75% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Natural-Language Policy Violations

Medium

• Confidence: 92% confidence
• Finding: This JSON contains natural-language values such as the user's name and code entirely in Chinese, which indicates a fixed language choice in data presented or required by the skill. The file provides no indication that users can choose a language or that the locale restriction is intentional and justified, which matches the language/locale policy violation criteria.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The skill declares broad, mandatory activation conditions such as any user expressing identity change, privilege elevation, or providing a code, and even sets metadata.openclaw.always=true. This can cause the skill to trigger in unintended contexts, increasing the chance of inappropriate handling of benign conversations, privilege-related confusion, or interception of sensitive user input. In an identity-management skill, over-triggering is more dangerous because it governs authentication and authorization decisions.

Natural-Language Policy Violations

Medium

• Confidence: 97% confidence
• Finding: The skill content is entirely in Chinese and frames the workflow as mandatory without indicating any user-language negotiation or fallback. For users operating in another language, this can cause misunderstanding during authentication, leading to incorrect identity decisions or users disclosing secrets without fully understanding the prompts. In an authentication context, clarity is important, so forced locale increases operational security risk even if it is not a direct exploit primitive.

Natural-Language Policy Violations

Medium

• Confidence: 98% confidence
• Finding: All user-facing strings, prompts, and command phrases in this file are hard-coded in Chinese, including approval replies and identity-verification flows. The file does not offer a language/locale choice or explain that the skill is intentionally limited to a Chinese-speaking context, which can violate language/locale policy requirements.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: This identity-management module stores long-term personal data such as names, conversation history, preferences, birthdays, age, job, company, and location in persistent files, which exceeds the stated scope of authentication and identity changes. Expanding an auth component into a user profiling store increases privacy risk, data retention risk, and blast radius if the files are accessed or misused.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The code extracts and persists sensitive personal profile data from conversation text, including birthday, age, company, location, and job, without any visible disclosure, consent flow, or retention control. Users may reveal highly identifying information in chat without understanding that it will be stored on disk for future use.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The skill description is written entirely in Chinese and does not indicate any language choice, fallback, or scope limitation. Under the stated policy, natural-language content that imposes a specific language without opt-in is a language/locale policy violation unless clearly documented as region-specific or offering user choice.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: This module persistently writes sensitive identifiers and security-relevant events to a plaintext local log file, including open_id, user_id, identity information, and identity-change details. If the log file is accessed by unauthorized users, backed up insecurely, or retained too long, it can expose personal data and privileged account history that may aid account correlation, social engineering, or privacy violations.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The code creates and persists account linkage data, including platform open_id and timestamps, by writing to accounts.json, but there is no confirmation prompt and no user-facing notice at the write site. Similar undisclosed persistence also occurs for user profile creation and account binding, which affects user data and identity records.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The code creates a new user object with name, role, identity, and timestamps and writes it to users.json, but there is no visible warning, confirmation, or explanatory comment indicating that personal identity information will be stored. This is a data-affecting operation and the surrounding conversational responses do not explicitly disclose persistence.

Intent-Code Divergence

Medium

• Confidence: 93% confidence
• Finding: The code path for duplicate names explicitly skips any ownership verification and always creates a fresh user, while immediately binding the current account to that new identity. In an identity/permission module, this weakens identity assurance and can enable impersonation confusion, duplicate-account abuse, or bypass of expected recovery/continuity checks for returning users.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The activation condition requires this skill for essentially any non-trivial action, using broad and ambiguous language such as all non-daily conversation operations. In practice, ambiguous mandatory interception can be abused to over-collect identity data, block normal agent safeguards, or force unrelated workflows through this skill, increasing the attack surface around every tool invocation.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The skill named `permission-gate` documents executable-style logic that modifies `sys.path` and imports a different module, `permission-check`, creating a confused-deputy and substitution risk. An agent following this guidance could invoke unintended code for identity and authorization decisions, allowing a malicious or incorrect module to control access checks or bypass the declared security boundary.

Excessive Permissions

Low

• Category: Privilege Escalation

Content

4. If allowed → execute the operation
5. If denied → respond with denial message

**NEVER skip permission check!**

### 2. Identity Verification (Required)

• Confidence: 85% confidence
• Finding: Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: Natural-language strings in the module docstrings are exclusively Chinese, including the top-level module description and function descriptions. Under the stated policy, forcing a specific language without opt-in or clear justification can be a language/locale policy violation.

Natural-Language Policy Violations

Low

• Confidence: 91% confidence
• Finding: The file uses Chinese-only docstrings, return reasons, and user-facing response messages, which imposes a fixed language/locale without any opt-in or alternative. Under the stated policy, locale-specific behavior should either offer user choice or be explicitly justified as region-specific.

Static analysis

No suspicious patterns detected.