Agentic Engineering

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:43 PM UTC
• Version: 1.0.0

Overview

This is a documentation-only skill, but it gives risky coding-agent workflow advice that could expose secrets or discard repository work if followed literally.

Install only if you are comfortable treating it as informal workflow advice, not a safe operating procedure. Before following it, avoid sharing unredacted screenshots, do not let agents read or print full `.env` files, use least-privilege database credentials, and do not run `git reset --hard` in a shared worktree unless all work is backed up and explicitly confirmed.

A.I.G

Vulnerability Patterns

• 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
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• 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 (2)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: context.md:84
• Finding: Agent Guidance Encourages Access to Sensitive Environment Files<![CDATA[ ## Vulnerability Details **File Location**: `context.md`, lines 84-86 **Vulnerability Type**: Sensitive credential-file access beyond least-privilege requirements **Risk Level**: Medium ### Vulnerable Code ```markdown ## Tools - Logs: vercel cli or axiom - DB: psql (see .env for connection) ``` ### Technical Analysis The guidance directs an AI coding agent to inspect `.env` to obtain a database connection. Environment files commonly contain multiple credentials, including database passwords, API tokens, signing keys, and deployment secrets unrelated to the requested database operation. Reading the entire file violates least-privilege principles when only one designated connection variable is required. The guidance does not require the agent to limit access to a specific variable, redact values, avoid displaying secrets, or prevent credentials from entering model context, terminal logs, shell history, or generated responses. The skill itself does not read the file or exfiltrate credentials. Exploitation therefore depends on a downstream agent following this recommendation in a repository containing sensitive environment variables. ### Attack Path 1. A project adopts the suggested agent configuration. 2. The project has a `.env` file containing a database URL and other sensitive credentials. 3. A coding agent receives a database-related task and follows the instruction to inspect `.env`. 4. The agent reads the complete file rather than retrieving only the required variable. 5. Secrets become available in the agent's context and may subsequently appear in terminal output, logs, prompts, generated commands, or responses. 6. Anyone with access to those channels may obtain and misuse the exposed credentials. ### Impact Assessment Potentially exposed privileges are limited to those granted by credentials stored in the environment file. Depending on the project, this could include database access, third-party API access, deployment permissions, or cl ...[truncated 241 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace the instruction to inspect `.env` with a reference to a specific environment variable, such as `DATABASE_URL`, without displaying its value. - Explicitly prohibit reading or printing complete `.env` files. - Require a dedicated, least-privilege database account for agent-assisted operations. - Restrict credentials to the exact database, schema, and operations needed for the task. - Use a secret manager or controlled credential-injection mechanism instead of exposing plaintext secrets to the agent. - Require redaction of passwords, tokens, and connection parameters from responses, command output, logs, and screenshots. - Prefer short-lived credentials and rotate any secret that may have entered model context or logs. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: parallel.md:67
• Finding: Destructive Git Recovery Procedure Can Delete Concurrent Agents' Work<![CDATA[ ## Vulnerability Details **File Location**: `parallel.md`, lines 21-33 and 67-75 **Vulnerability Type**: Unsafe destructive repository recovery in a shared worktree **Risk Level**: Medium ### Vulnerable Code ```markdown ## Same Folder, Different Areas Most agents work in the same repo, same folder. No worktrees needed. Pick non-overlapping areas: ``` ```text Agent 1: src/api/ Agent 2: src/components/ Agent 3: tests/ Agent 4: docs/ ``` ```markdown If changes must touch the same file → serialize, don't parallelize. ``` ```markdown ## Recovery from Conflicts If agents step on each other: ``` ```bash git stash # Save current state git log --oneline # Find last good commit git reset --hard # Reset to good state git stash pop # Reapply if needed ``` ```markdown Small, atomic commits make recovery easy. ``` ### Technical Analysis The skill recommends that several agents operate in the same repository and working directory, then recommends `git reset --hard` as a conflict-recovery operation. This command resets tracked files in both the index and working tree, discarding uncommitted changes without distinguishing which agent created them. In a shared worktree, Git state is repository-wide rather than agent-specific. `git stash` may capture changes made by multiple agents, while `git stash pop` can restore a combined state, apply the wrong stash, or produce additional conflicts. The procedure also omits an explicit reset target, a clean-tree check, ownership verification, backup validation, and user confirmation. Atomic commits do not protect concurrent changes that have not yet been committed. Consequently, an agent following this procedure can destroy or mix another agent's active work even if agents were initially assigned different directories. ### Attack Path 1. Multiple agents modify tracked files in the same working tree. 2. At least one agent still has uncommitted changes. 3. A conflict or unexpected repository state ...[truncated 1023 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Use separate Git worktrees or isolated clones for concurrently writing agents. - Serialize all recovery operations when agents share a working tree. - Before any destructive operation, run and review `git status`, `git diff`, and `git diff --cached`. - Stop all agents using the worktree and obtain explicit user confirmation before resetting files. - Preserve work with a verified temporary commit, named patch, or filesystem backup rather than relying on an undifferentiated shared stash. - Specify and verify the exact reset target instead of documenting `git reset --hard` without an argument. - Prefer non-destructive recovery methods such as restoring selected paths, applying reviewed patches, or reverting known commits. - Never permit an agent to run `git reset --hard` while another agent or user may have uncommitted changes in the same worktree. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (6)

Credential Access

High

• Category: Privilege Escalation

Content

- No persistent storage required

**This skill does NOT:**
- Access credentials or make network requests
- Execute code autonomously

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## Tools
- Logs: vercel cli or axiom
- DB: psql (see .env for connection)
```

Skip:

• Confidence: 97% confidence
• Finding: The guidance tells users to use psql and specifically 'see .env for connection,' which normalizes accessing secrets from environment files during agent-assisted work. In this context, an AI coding agent may be given or infer permission to read `.env`, exposing database credentials or enabling onward misuse if the contents are pasted into prompts, logs, screenshots, or tool output.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
git stash           # Save current state
git log --oneline   # Find last good commit
git reset --hard    # Reset to good state
git stash pop       # Reapply if needed
```

• Confidence: 95% confidence
• Finding: `git reset --hard` is a destructive command that forcefully rewrites the working tree to match a commit, and here it is presented as a simple recovery action with no guardrails. Because this skill is specifically about coordinating multiple concurrent agents in the same repository, the chance of accidental execution under confusion is higher, and the resulting loss of uncommitted or partially merged work can affect a larger blast radius than in a single-user workflow.

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The 'When to Use' section describes the skill as applicable whenever a user works with AI coding agents and wants to maximize productivity, workflow optimization, coordination, or context management. These conditions are broad and do not provide specific trigger phrases, exclusions, or negative examples, which could cause the skill to be invoked in many routine coding-assistance contexts.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill explicitly encourages dragging screenshots into the terminal and states that screenshots are essential, but it provides no warning about capturing secrets visible on screen such as API keys, customer data, internal URLs, or terminal output. In an agentic coding workflow, screenshots are often sent to external model providers or stored in logs, so this guidance materially increases the risk of inadvertent sensitive data disclosure.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill recommends `git reset --hard` as a recovery step without any warning that it permanently discards uncommitted changes in the working tree and index. In a multi-agent workflow, users may run this reflexively during conflict recovery and lose work from themselves or other agents, making the omission materially risky even if not overtly malicious.