T05 · Unauthorized Access and Privilege Escalation
- Location
references/phase-1-asset-scan.md:79- Finding
Unrestricted processing and copying of secret-bearing configuration files
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a real code-migration skill, but it can read or copy sensitive project configuration and make autonomous project changes without enough safeguards.
Install only for repositories where broad source-tree review is acceptable. Before use, remove or sanitize live secrets such as `.env.*`, credential JSON/YAML, private keys, and production config, and require human approval before copying config into the target project or letting PGR loops apply fixes automatically.
references/phase-1-asset-scan.md:79Unrestricted processing and copying of secret-bearing configuration files
scripts/scan_assets.py:17Unpinned package installation recommended with system-package protections disabled
The code chunk is related to the broader migration domain, but its actual function is much narrower than the declared description. It only scans a project tree and generates an asset-inventory YAML with auto-classified file types and migration-strategy hints. It does not translate code, port projects between languages, verify equivalence, enforce no skipped files beyond directory walking with explicit skip patterns, maintain cross-session workflow state in a substantive way, or implement verification/human-gating policies. Therefore the declared description materially overstates the behavior of this specific code chunk.
Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.
- [ ] Every `source_faithful_behavior` finding has a `SOURCE-FAITHFUL` comment in target code AND `known_source_behaviors` entry in IPO registry
- [ ] Every `consumer_error` finding has its fix in the caller/test, NOT in the translated function
- [ ] No `known_source_behaviors` with `intentional: false` is unresolved (must be BLOCKED or human-approved)
- [ ] Target project builds cleanly (no warnings treated as errors)
- [ ] Original CI pipeline (adapted) passes on the target project
- [ ] `migration-state.yaml` final stats are updated
- [ ] `decisions_log` includes all human decisions made during the migration
The file explicitly states that no human involvement is required or permitted inside the PGR loop, which conflicts with the skill's stated human-gated blocking requirement. In a code-migration skill that can modify project state and advance phases autonomously, this creates a governance bypass where the agent can self-approve changes and continue operating without required human review.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
- path: "internal/loop/loop.go"
verdict: FIXED
notes: "toolRegistry — iteration order mattered"
- path: "internal/memory/keychain/keychain.go"
verdict: FIXED
notes: "lookupChain iterates in registration order — same issue"
- path: "internal/frontends/conductor/conductor.go"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Environment / config
# Both .yml and .yaml default to environment_config (strategy: preserve).
# The classify_file() refine block promotes .github/workflows/*.yml|yaml → ci_config.
".env": "environment_config", ".env.example": "environment_config",
".yml": "environment_config",
".yaml": "environment_config",
"Dockerfile": "environment_config",
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Environment / config
# Both .yml and .yaml default to environment_config (strategy: preserve).
# The classify_file() refine block promotes .github/workflows/*.yml|yaml → ci_config.
".env": "environment_config", ".env.example": "environment_config",
".yml": "environment_config",
".yaml": "environment_config",
"Dockerfile": "environment_config",
The v1.2 section states that every phase transition advances only after an autonomous self-auditing loop completes with 'zero findings' and explicitly says 'No human involvement.' Later, the same README states the process is 'not fully autonomous' and requires human judgment when blocked, creating a direct contradiction in the documented intent of autonomy.
The state-machine section documents a strict human-gated blocking model: when status is BLOCKED, the AI must stop and wait for operator input. This conflicts with the earlier documentation claiming phase transitions require no human involvement, so the documented operational model is internally inconsistent.
该文件标题和正文主体均为中文,并在语言切换处明确标注“English | 中文”且当前文档固定为中文版本。对于技能说明文档,若面向通用用户却默认强制特定语言而无明确用户选择机制,属于自然语言层面的语言/locale 限制。
At L041-L043, the document says phase progression happens only after a self-audit loop and that the process requires '全程无需人类干预'. However, later sections explicitly require operator waiting on BLOCKED states and note sustained human participation for approvals and decisions (for example L182 and L485-L487). This is an active contradiction in the skill's own intent documentation, not merely an omitted detail.
The skill explicitly instructs the agent to read and write files in the workspace, but it does not declare any tool scope or allowed-tools boundary. That creates an authorization gap where a host agent may grant broader file access than users expect, increasing the chance of unintended modification of project files or persistent state.
The invocation criteria are so broad that the skill can auto-trigger on many ordinary code translation or rewrite requests, potentially causing large-scale file creation and workflow takeover without sufficiently specific user intent. In a skill that persists state and directs workspace modification, overbroad triggering increases the risk of surprise side effects and excessive access to project contents.
The skill persistently creates and updates YAML files in a workspace across sessions, but the description does not clearly warn users about ongoing file creation and modification. This undermines informed consent and can lead users to invoke the skill without realizing it will leave durable artifacts and potentially alter repository state.
L227 instructs the agent to set phases.P0_bootstrap: DONE immediately after bootstrapping. But L184 and L188-L190 explicitly state that phase status DONE must only be set by PGR-N and must never be set directly at the end of a phase, so the documentation contains an active contradiction about completion behavior.
The file explicitly states that unittest.mock is prohibited, imposing a blanket no-mock policy without scope limits, justification, or user override. In a migration skill, this can pressure the agent into unsafe or impractical verification strategies, such as invoking real external systems, credentials, networks, or destructive side effects during testing, rather than using isolated test doubles where appropriate.
The sample C code presents allocation and buffer-manipulation patterns that omit essential safety checks: malloc results are not validated, buffer_push performs no capacity check, and cleanup paths for partial allocation failure are absent. In a code-migration skill, users may copy these examples directly into generated code, leading to null dereferences, heap corruption, out-of-bounds writes, and difficult-to-detect memory safety flaws.
The line unittest.mock | PROHIBITED | Real implementations only` is a natural-language instruction that mandates a specific testing policy rather than offering guidance or context. Because the file does not explain a justified organizational or regional policy basis for this prohibition, it reads as an unqualified policy constraint embedded in the skill content.
Line L263 states "NO EQUIVALENT — mocks prohibited" as a blanket natural-language instruction. This is an organizational-policy style restriction embedded in the skill content, but the file does not explain that the prohibition is optional, context-specific, or justified for a particular environment, making it a natural-language policy violation.
These instructions explicitly permit remediation in the integration layer, including prompt-engineering changes such as adding system-prompt examples or trigger rules, during a code migration verification phase. That expands the skill's authority from validating language-port correctness into modifying higher-level agent behavior, which can be abused to alter safety boundaries or silently change how the overall system responds.
The trigger list includes very broad natural-language phrases like "gap report", "还差什么", and "show migration status", which can cause the skill to activate on ambiguous status questions rather than an explicit user opt-in. In an agentic workflow, unintended invocation can redirect execution flow, generate or overwrite audit artifacts, and cause the agent to perform file-system analysis the user did not clearly request.
The protocol mandates autonomous self-auditing and forbids oversight, which strips the user of meaningful control over iterative fixes and phase advancement. Even if framed as process rigor, this design enables unattended changes across a project workspace and reduces opportunities to catch harmful or incorrect modifications before they propagate.
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.
## Why PGR Exists
Each phase has exit criteria. Without PGR, an AI can mark a phase DONE the moment the last
task appears finished, without checking whether the sum of all outputs meets the stated criteria.
PGR closes this gap by requiring a systematic, exhaustive audit before the phase status changes.
The same anti-cheating principles that govern individual tasks apply here:
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
### `inferred_invariants` format
The invocation guidance lists a Chinese phrase ("还差什么") alongside English commands, but the document does not explain whether multilingual invocation is optional, configurable, or limited by user preference. Because this is natural-language behavior guidance in a skill README, it can be read as imposing or assuming a specific locale without explicit opt-in context.
The skill treats broad phrases such as "show status" and "gap report" as triggers for P6 without stating that they apply only within an already active migration session. These phrases are common in ordinary conversation and could cause accidental activation absent explicit context limits.
No suspicious patterns detected.