ClawHub
Back to skill

Security audit

Auth Guard

Security checks for vulnerabilities and agentic risk

Overview

This security skill is not clearly malicious, but its authorization guard can be bypassed and it may expose request details, so it should be reviewed carefully before use.

Install only if you understand this is not a reliable mandatory security boundary as written. Use STRICT mode only, avoid AUDIT/disabled mode, do not rely on verify_token or emergency-stop for protection, protect the decision directory, and do not configure webhooks for sensitive operations unless parameters are redacted and the destination is trusted.

A.I.G

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (7)

T09 · Insecure Skill Coding Practices

Error
Location
auth_guard.py:108
Finding
Emergency Stop Disables Authorization Enforcement and Fails Open<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:108-115` and `auth_guard.py:425-429` **Vulnerability Type**: Fail-open authorization logic **Risk Level**: Critical ### Vulnerable Code ```python if not self.config.get("enabled", True): return { "authorized": True, "auth_token": "disabled", "expires_at": (datetime.utcnow()() + timedelta(hours=1)).isoformat() + "Z", "note": "Auth Guard 已禁用" } ``` ```python def emergency_stop(self): """紧急停止 - 禁用所有授权""" self.config["enabled"] = False self._save_config() print("⚠️ 紧急停止已激活 - 所有授权已禁用") ``` ### Technical Analysis The `emergency_stop()` method persists `enabled = False`. However, `request_authorization()` interprets that state as permission to authorize every request instead of rejecting requests. This reverses the expected behavior of a security shutdown control. The project describes emergency stop as stopping all authorization, but invoking it removes the authorization requirement and returns an accepted result with the placeholder token `disabled`. The control therefore fails open precisely when the operator expects the strongest restriction. ### Attack Path 1. An attacker, compromised automation, or misleading instruction causes the user to invoke `python cli.py emergency-stop`. 2. `emergency_stop()` writes `"enabled": false` to the configuration file. 3. A subsequent guarded operation calls `request_authorization()`. 4. The disabled-state branch immediately returns `"authorized": true`. 5. The calling integration proceeds with the external API operation without user confirmation. ### Impact Assessment Any external operation routed through this guard can be approved without confirmation after emergency stop is activated. The effective scope depends on the permissions of the downstream API credentials, potentially including sending messages, reading private data, creating resources, or modifying remote services. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Change the disabled and emergency states to fail closed: ```python if not self.config.get("enabled", True): return { "authorized": False, "reason": "Auth Guard is disabled or emergency stop is active" } ``` - Maintain a separate explicit development-only bypass option if bypass behavior is genuinely required. - Require deliberate, authenticated administrative action to enable any bypass. - Add tests asserting that emergency stop rejects every mode and operation. - Revoke all pending and active tokens when emergency stop is activated. - Record emergency activation in an append-only security audit log. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
auth_guard.py:408
Finding
All Authorization Tokens Are Accepted and Revocation Is Ineffective<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:408-419` **Vulnerability Type**: Broken token validation and revocation **Risk Level**: Critical ### Vulnerable Code ```python def verify_token(self, auth_token: str) -> Dict: """验证授权令牌""" # 简单实现 - 实际应该检查令牌有效性 return { "valid": True, "token": auth_token } def revoke_token(self, auth_token: str) -> bool: """撤销授权令牌""" # 实现令牌撤销逻辑 return True ``` ### Technical Analysis `verify_token()` unconditionally returns `valid: True`, regardless of whether the supplied value was issued by the guard, has expired, was issued for a different action, or was revoked. `revoke_token()` similarly reports success without changing any persisted or in-memory token state. Consequently, any integration that trusts these methods has no effective authorization-token boundary. ### Attack Path 1. An attacker selects any arbitrary string, such as `attacker-controlled-token`. 2. The attacker supplies it to an integration that calls `verify_token()`. 3. The method returns `{"valid": true}`. 4. The integration treats the attacker as authorized and performs the protected operation. 5. Calling `revoke_token()` does not prevent continued reuse. ### Impact Assessment An attacker can bypass user approval wherever token verification is relied upon. Tokens also cannot be reliably revoked. The resulting privileges are those of the protected downstream integration and may include access to email, messaging, calendars, or other external APIs. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Store issued tokens as hashed records containing: - Request identifier - Service and action - Parameter or request digest - Issuance and expiration times - Single-use status - Revocation status - Reject unknown, expired, consumed, context-mismatched, and revoked tokens. - Use cryptographically random tokens generated with `secrets.token_urlsafe()`. - Use constant-time comparisons where token material is compared. - Make revocation an actual atomic state change. - Do not return the submitted token from verification responses. - Add negative tests for arbitrary, expired, revoked, reused, and context-mismatched tokens. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
auth_guard.py:359
Finding
Unauthenticated Local Decision Files Permit Forged Approvals<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:359-373` and `cli.py:48-62` **Vulnerability Type**: Unauthenticated approval channel **Risk Level**: High ### Vulnerable Code ```python def _check_decision(self, request_id: str) -> Optional[Dict]: """检查用户决策（轮询决策文件）""" decision_path = os.path.expanduser( f"~/.auth_guard/decisions/{request_id}.json" ) if os.path.exists(decision_path): with open(decision_path, 'r', encoding='utf-8') as f: decision = json.load(f) # 删除决策文件（一次性使用） os.remove(decision_path) return decision return None ``` ```python def cmd_approve(args): """批准请求""" decision_path = os.path.expanduser( f"~/.auth_guard/decisions/{args.request_id}.json" ) Path(decision_path).parent.mkdir(parents=True, exist_ok=True) decision = { "approved": True, "decided_at": datetime.utcnow().isoformat() + "Z", "ttl": args.ttl if hasattr(args, 'ttl') else 3600 } with open(decision_path, 'w', encoding='utf-8') as f: json.dump(decision, f, indent=2) ``` ### Technical Analysis Approval is represented by a plain JSON file. The guard performs no signature validation, authenticated-origin check, file ownership check, permission verification, secure-open operation, or binding between the decision and the original service, action, and parameters. This is particularly unsafe because the automation being constrained may run under the same operating-system account and therefore may be able to write into the decision directory. A process able to learn or predict a request identifier can approve its own request. ### Attack Path 1. A process initiates an authorization request. 2. It obtains the request identifier from console output, notification data, or other same-user observations. 3. It creates `~/.auth_guard/decisions/<request_id>.json` containing: ```json { "approved": true, "ttl": 3600 } ``` 4. The poll ...[truncated 453 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace decision files with authenticated inter-process communication. - Require decisions to be signed or authenticated with a secret unavailable to the guarded automation. - Bind each decision to the complete request context, including service, action, parameter digest, requester, expiry, and nonce. - Create directories with mode `0700` and files with mode `0600`. - Validate ownership and reject symbolic links and unexpected file types. - Use atomic, exclusive file creation if filesystem decisions must remain supported. - Separate the approval interface into a distinct user-controlled process or account. - Reject malformed decisions, excessive TTL values, stale timestamps, and duplicate approvals. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
auth_guard.py:262
Finding
Sensitive Request Parameters Are Sent to an Arbitrary Webhook Without Redaction<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:262-270` and `auth_guard.py:330-334` **Vulnerability Type**: Sensitive-data disclosure over the network **Risk Level**: High ### Vulnerable Code ```python channel = self.config.get("notification", {}).get("channel", "feishu") webhook_url = self.config.get("notification", {}).get("webhook_url") # 构建通知消息 message = self._build_notification_message( request_id, service, action, params, reason, requester, priority ) if channel == "feishu" and webhook_url: try: response = requests.post(webhook_url, json=message, timeout=10) return response.status_code == 200 ``` ```python { "tag": "div", "text": { "tag": "lark_md", "content": f"**参数预览：**\n```{ json.dumps(params, ensure_ascii=False)[:500] }...```" } } ``` ### Technical Analysis The authorization request's `params` object is serialized and copied into an outbound webhook notification. API parameters commonly contain email bodies, recipients, access tokens, authorization headers, personal information, or confidential business data. The code does not recursively redact sensitive field names, classify content, constrain the destination to a trusted host, or require per-request consent before disclosure. Although webhook notification is related to the declared confirmation workflow, transmitting raw parameters is not the minimum disclosure necessary to request approval. The destination is entirely configuration-controlled, so a malicious or accidentally modified URL can receive the data. ### Attack Path 1. A webhook URL is configured or replaced with an attacker-controlled HTTPS endpoint. 2. A guarded API operation includes confidential values in `params`. 3. `_build_notification_message()` serializes the first 500 characters of those parameters. 4. `_send_notification()` submits the resulting JSON to the configured endpoint. 5. The external endpoint records the confidential ...[truncated 341 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Send only minimal metadata—such as service, action, risk level, and request identifier—by default. - Recursively redact fields matching names such as `token`, `authorization`, `password`, `secret`, `api_key`, `cookie`, and `credential`. - Require explicit opt-in before including message bodies or request parameters. - Allowlist trusted HTTPS webhook origins rather than accepting arbitrary destinations. - Reject plaintext HTTP endpoints and validate certificates normally. - Clearly disclose the external recipient and exact data categories in documentation. - Provide a local-only approval interface for sensitive requests. - Add tests proving that nested credentials and authorization headers are never transmitted. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
auth_guard.py:53
Finding
Advertised API-Key, Source-IP, and Rate-Limit Controls Are Not Enforced<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:53-59` and `auth_guard.py:77-201` **Vulnerability Type**: Missing access-control enforcement **Risk Level**: High ### Vulnerable Code ```python "security": { "api_key": self._generate_api_key(), "allowed_ips": ["127.0.0.1"], "rate_limit": { "requests_per_hour": 100 } }, ``` The authorization method accepts caller-controlled request metadata without applying the configured security controls: ```python def request_authorization( self, service: str, action: str, params: Dict[str, Any], reason: str = "", requester: str = "unknown", priority: str = "normal" ) -> Dict: ``` The only implemented counter is scoped to whitelist operations, held in memory, and never reset on an hourly boundary: ```python current_count = self._cache.get(f"rate_{key}", 0) if current_count >= max_per_hour: return {"allowed": False, "reason": "超过速率限制"} self._cache[f"rate_{key}"] = current_count + 1 ``` ### Technical Analysis The configuration defines an API key, an IP allowlist, and a global hourly request limit, but `request_authorization()` does not accept or validate credentials or source identity. The documented HTTP server module is also absent from the reviewed project. The in-memory whitelist counter is not equivalent to the advertised global rate limit. It resets whenever a new `AuthGuard` object or process is created and does not use a real hourly time window. This discrepancy creates a false security boundary for integrators who expect the declared controls to be active. ### Attack Path 1. An untrusted caller invokes the library or a wrapper around it without presenting an API key. 2. No source-IP or requester authentication is performed. 3. The caller creates repeated strict-mode authorization requests. 4. Requests trigger notifications and polling loops without an effective global limit. 5. Depending on surrounding integration behavior, the calle ...[truncated 391 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Implement authenticated request handling before exposing the guard as a service. - Validate API keys using constant-time comparison and store only derived or securely protected values. - Authenticate the actual transport identity rather than trusting caller-provided `requester`. - Enforce source restrictions at both the application and network layers. - Implement persistent, time-window-based rate limiting per authenticated principal and source. - Bound concurrent pending requests and notification frequency. - Remove unsupported server and security claims until the corresponding code exists. - Add integration tests demonstrating rejection of missing, invalid, excessive, and unauthorized requests. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
auth_guard.py:127
Finding
Policy Evaluation Order and Unsupported Wildcards Permit Blocking-Rule Bypass<![CDATA[ ## Vulnerability Details **File Location**: `auth_guard.py:127-146`, `auth_guard.py:231-244`, and `whitelist.example.json:27-36` **Vulnerability Type**: Incorrect authorization-policy evaluation **Risk Level**: High ### Vulnerable Code Whitelist authorization occurs before blacklist evaluation: ```python if self.config.get("mode") == "WHITELIST": whitelist_check = self._check_whitelist(service, action, params) if whitelist_check.get("allowed"): self._log_audit( request_id, service, action, requester, "whitelisted", None ) return { "authorized": True, "auth_token": request_id, "expires_at": ( datetime.utcnow() + timedelta(seconds=whitelist_check.get("ttl", 3600)) ).isoformat() + "Z", "note": "白名单操作" } # 检查黑名单 blacklist_check = self._check_blacklist(service, action) ``` Blacklist matching only supports an exact value or a full `*`: ```python for op in blocked_ops: op_service = op.get("service", "*") op_action = op.get("action", "*") if (op_service == "*" or op_service == service) and \ (op_action == "*" or op_action == action): return { "blocked": True, "reason": op.get("reason", "黑名单操作") } ``` The shipped policy uses unsupported suffix patterns: ```json { "service": "*", "action": "*.delete", "reason": "删除操作必须人工确认" }, { "service": "*", "action": "*.create", "reason": "创建操作必须人工确认" } ``` ### Technical Analysis An operation matching an allow rule returns immediately, so a conflicting deny rule is never evaluated. This contradicts the expected security convention that explicit denies take precedence. Additionally, patterns such as `*.delete` are treated as literal strings because `_check_blacklist()` only recognizes a full-string `*`. An action such as `files.delete` therefore does not match the example blocking rule. Administrators ...[truncated 794 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Evaluate explicit deny rules before all allow rules. - Define and document a deterministic policy precedence model. - Either implement tested glob matching with a safe standard library or reject wildcard syntax other than a full `*`. - Normalize service and action names before comparison. - Validate policy files during loading and fail closed on unsupported patterns. - Add tests for overlapping allow/deny entries, suffix wildcards, malformed rules, case differences, and unknown actions. - Avoid returning request identifiers as authorization tokens for whitelist approvals. ]]>

T08 · Insecure Dependencies

Warning
Location
install.sh:42
Finding
Installer Retrieves an Unpinned Dependency from the Active Package Index<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:42-44` **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash # 3. 安装 Python 依赖 echo "✓ 安装 Python 依赖..." pip install requests --quiet ``` ### Technical Analysis The installer resolves `requests` from whichever Python package index and pip configuration are active at installation time. No version, integrity hash, lock file, or isolated environment is specified. Although `requests` is a legitimate package, this installation method is non-reproducible and allows package-index configuration, future dependency changes, or a compromised repository to alter the code executed during installation. ### Attack Path 1. An attacker influences the user's pip index configuration, network package source, or repository account. 2. The user runs `install.sh`. 3. `pip install requests` resolves packages from the attacker-influenced source. 4. The selected package or transitive dependency executes installation-time or runtime code under the user's account. 5. The malicious dependency obtains the filesystem and network privileges of that account. ### Impact Assessment A compromised dependency can execute code with the privileges of the user running the installer. This may expose home-directory data, configuration files, API credentials, and network-accessible resources. Running the installer with elevated privileges would substantially increase the impact. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Pin an audited dependency version. - Use a lock file containing cryptographic hashes. - Install with `python -m pip` to ensure the intended interpreter is used. - Create and use a dedicated virtual environment. - Use `--require-hashes` for reproducible installations. - Document the trusted package index and avoid inheriting untrusted index configuration. - Periodically scan and update pinned dependencies through a controlled review process. - Do not run the installer with administrative privileges. ]]>

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (37)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The skill presents itself as an authorization enforcement layer, yet much of the documented content concerns installation, environment setup, file changes, and CLI operations rather than a guaranteed interception mechanism. This can mislead users into believing they have a mandatory protection layer when the implementation appears to depend on optional integration steps and surrounding infrastructure.

Tp4

High
Category
MCP Tool Poisoning
Confidence
92% confidence
Finding
The skill presents itself as an authorization enforcement layer, yet much of the documented content concerns installation, environment setup, file changes, and CLI operations rather than a guaranteed interception mechanism. This can mislead users into believing they have a mandatory protection layer when the implementation appears to depend on optional integration steps and surrounding infrastructure.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The skill presents itself as an authorization enforcement layer, yet much of the documented content concerns installation, environment setup, file changes, and CLI operations rather than a guaranteed interception mechanism. This can mislead users into believing they have a mandatory protection layer when the implementation appears to depend on optional integration steps and surrounding infrastructure.

Intent-Code Divergence

High
Confidence
98% confidence
Finding
The documentation says no automation can bypass authorization, but WHITELIST and AUDIT modes explicitly allow some operations to proceed without per-request explicit user confirmation. This discrepancy undermines the core trust model and may cause administrators to approve deployment under false assumptions about how strictly access is gated.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
AUDIT mode directly contradicts the stated guarantee that all external API operations require explicit user authorization, because it records activity without blocking it. In a security control advertised as mandatory authorization enforcement, a non-blocking mode can lead to silent policy bypass if enabled intentionally or by mistake.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The module claims to require explicit user authorization for all external API operations, but both disabled mode and AUDIT mode automatically return authorized=true without any user approval. This creates a policy bypass where callers can perform sensitive actions under a false assurance that user consent was enforced.

Intent-Code Divergence

High
Confidence
100% confidence
Finding
verify_token accepts any presented token as valid and does not verify signature, issuance, binding to request/service/action, expiration, or revocation status. Any component relying on this method can be trivially bypassed by supplying an arbitrary token string, completely defeating the authorization guard.

Natural-Language Policy Violations

Medium
Confidence
93% confidence
Finding
The primary skill description is written as a Chinese-only instruction/title line, and the rest of the README continues exclusively in Chinese. Under the policy, language restrictions should either provide user choice or clearly document a justified region-specific constraint, which is not present here.

Session Persistence

Medium
Category
Rogue Agent
Content
```bash
# 创建配置目录
mkdir -p ~/.auth_guard

# 复制示例配置
cp config.example.json ~/.auth_guard/config.json
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium
Category
Rogue Agent
Content
```bash
# 创建配置目录
mkdir -p ~/.auth_guard

# 复制示例配置
cp config.example.json ~/.auth_guard/config.json
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Natural-Language Policy Violations

Medium
Confidence
95% confidence
Finding
The skill description is presented as a Chinese-language tagline and the usage example also uses Chinese output/reason text, with no indication that other languages are supported or that the user can opt in to this locale. Under the policy, forcing a specific language without user choice is a natural-language policy violation.

Session Persistence

Medium
Category
Rogue Agent
Content
```bash
# 初始化配置
mkdir -p ~/.auth_guard
cp config.example.json ~/.auth_guard/config.json
cp whitelist.example.json ~/.auth_guard_whitelist.json
```
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Lp3

Medium
Category
MCP Least Privilege
Confidence
93% confidence
Finding
The skill documents file access, local HTTP calls, configuration handling, and audit logging, but declares no explicit tool scope or permission boundaries. This creates a capability/manifest mismatch that can cause reviewers or execution frameworks to under-estimate what the skill can access or transmit.

Natural-Language Policy Violations

Medium
Confidence
95% confidence
Finding
The manifest description and the entire user-facing documentation are written exclusively in Chinese, and the skill does not indicate any option for the user to choose another language or locale. This can violate a language/locale policy when skills are expected to respect user language preferences or provide opt-in for a fixed language.

External Transmission

Medium
Category
Data Exfiltration
Content
请求授权：
```bash
curl -X POST http://localhost:8765/authorize \
  -H "Content-Type: application/json" \
  -d '{
    "service": "google-mail",
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def guarded_api_call(service, action, params):
    # 1. 请求授权
    auth_response = requests.post('http://localhost:8765/authorize', json={
        'service': service,
        'action': action,
        'params': params,
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def guarded_api_call(service, action, params):
    # 1. 请求授权
    auth_response = requests.post('http://localhost:8765/authorize', json={
        'service': service,
        'action': action,
        'params': params,
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def guarded_api_call(service, action, params):
    # 1. 请求授权
    auth_response = requests.post('http://localhost:8765/authorize', json={
        'service': service,
        'action': action,
        'params': params,
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Internal Network Request

Medium
Category
Server-Side Request Forgery
Content
def guarded_api_call(service, action, params):
    # 1. 请求授权
    auth_response = requests.post('http://localhost:8765/authorize', json={
        'service': service,
        'action': action,
        'params': params,
Confidence
70% confidence
Finding
Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.

Internal Network Request

Medium
Category
Server-Side Request Forgery
Content
def guarded_api_call(service, action, params):
    # 1. 请求授权
    auth_response = requests.post('http://localhost:8765/authorize', json={
        'service': service,
        'action': action,
        'params': params,
Confidence
70% confidence
Finding
Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.

External Transmission

Medium
Category
Data Exfiltration
Content
result = execute_api(service, action, params)
    
    # 3. 记录审计日志
    requests.post('http://localhost:8765/audit', json={
        'service': service,
        'action': action,
        'result': 'success',
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
解决：
```bash
# 查看所有待处理请求
curl http://localhost:8765/pending

# 批量拒绝所有待处理
curl -X POST http://localhost:8765/batch-decide \
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Natural-Language Policy Violations

Medium
Confidence
94% confidence
Finding
The manifest description is written entirely in Chinese and does not indicate that the skill is region-specific or that users can choose their preferred language. This can violate language/locale policy guidance because it imposes a language constraint without explicit opt-in or justification.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The code sends service, action, requester, reason, and a preview of params to an external webhook, which may expose sensitive operational data or secrets embedded in parameters. Because this occurs as part of an authorization flow, users may not realize their request contents are being disclosed to a third-party endpoint.

External Transmission

Medium
Category
Data Exfiltration
Content
if channel == "feishu" and webhook_url:
            try:
                response = requests.post(webhook_url, json=message, timeout=10)
                return response.status_code == 200
            except Exception as e:
                print(f"发送飞书通知失败：{e}")
Confidence
80% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.