Agent Stack Audit

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:09 AM UTC
• Version: 1.0.0

Overview

This is a plausible maintenance-audit skill, but it asks an agent to inspect sensitive operational data too broadly and permits limited code changes without a clear approval gate.

Install only if you are comfortable giving the agent a narrowly scoped maintenance-audit role. Before running it, specify exact directories, scheduled jobs, accounts, and memory files in scope; prohibit reading or storing secret values; require redaction in reports; and require explicit approval for every code or cleanup change.

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 (4)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:32
• Finding: Unbounded System and Process Reconnaissance<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:32-50` **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### 1. Crons — Are they alive and earning their keep? For each launchd agent / cron job / scheduled task: - Is the process actually running? (check PID, plist/cron status) - When did it last fire successfully? - What does it produce? Is that output being consumed by anything? - Is there a newer/better approach that renders this obsolete? **Questions to answer:** - "This cron runs every hour. Has its output file been read in the last 30 days?" - "This watchdog monitors a bot that was killed 2 months ago — is the watchdog still running?" ### 2. Scripts — Dead code? Scan your automation directories for Python/shell scripts: - Last modified date vs last executed date - Scripts referencing killed bots or cancelled APIs - Scripts built for old projects that are now closed - Duplicate scripts doing the same job ``` ### Technical Analysis The skill instructs the agent to enumerate launch agents, cron jobs, scheduled tasks, process identifiers, status files, output files, and automation scripts. It does not establish an explicit project boundary, ownership requirement, allowlist, or minimum-privilege access model. If the executing agent has host-level filesystem or shell access, these broad instructions may cause it to inspect scheduled tasks and scripts belonging to unrelated projects or users. Process state, execution schedules, script names, and output-consumption patterns reveal operational topology that may be sensitive. The issue is not privilege escalation through a software exploit. It is an instruction-level failure to constrain privileged tools to the legitimate scope of the audit. ### Attack Path 1. A user or automated scheduler invokes the stack-audit skill. 2. The agent interprets “each launchd agent / cron job / scheduled task” as host-wid ...[truncated 1017 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Require the user to approve a specific audit scope before enumeration begins. 2. Restrict scans to explicitly listed project directories, scheduled-task identifiers, and service accounts. 3. Do not inspect system-wide cron, launchd, process, or log data by default. 4. Add ownership checks before reading a task definition, PID file, script, or output file. 5. Collect only minimal status metadata, such as enabled state and last successful execution time. 6. Require separate approval before reading task output or log contents. 7. Redact usernames, absolute paths, command-line arguments, environment values, and service identifiers from reports where they are not essential. 8. Record every inspected resource in an audit log so the user can verify that scope boundaries were respected. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:52
• Finding: Unsafe Discovery and Reporting of API Credential Inventory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:52-59` **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### 3. API Keys — Are you paying for something unused? Cross-reference your API inventory against actual script usage: - Any API key configured but never called in the last 30 days? - Any paid subscription that maps to zero active script usage? - Any free-tier key that's been maxed out — is an upgrade worthwhile? Common culprits: data providers, news APIs, notification services, AI APIs at old models. ``` ### Technical Analysis The skill directs the agent to discover configured API keys and correlate them with scripts, subscriptions, and historical usage. It does not distinguish safe metadata—such as a secret identifier or provider name—from the secret value itself. There are no instructions prohibiting access to plaintext credentials in environment files, shell profiles, source code, deployment configuration, or secret-manager responses. There is also no mandatory redaction policy for the generated `state/stack_audit_YYYY-MM-DD.md` report. Consequently, an agent following these instructions could read credential values unnecessarily and persist them, or identifying fragments of them, in a comparatively less protected audit report. ### Attack Path 1. The stack audit is invoked with filesystem, environment, or secret-manager access. 2. The agent searches scripts and configuration files to identify configured API keys. 3. Because the instructions do not limit collection to metadata, the agent may read complete credential values. 4. The agent correlates credentials with provider usage and billing information. 5. Sensitive values or identifying details may be included in the persistent audit report. 6. A user, process, backup system, or repository with access to that report can recover credential or subscription information. 7. If a complete active key ...[truncated 671 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Explicitly prohibit reading, printing, storing, hashing, or transmitting API secret values. 2. Inspect only secret identifiers, provider names, creation dates, last-used timestamps, and access-scope metadata. 3. Use secret-manager metadata APIs that do not return secret material. 4. Never scan environment values, `.env` contents, shell history, or plaintext credential files unless the user separately authorizes a narrowly scoped investigation. 5. Require automatic redaction of tokens, authorization headers, account identifiers, and billing details. 6. Add a report-validation step that detects likely credentials before writing the report. 7. Store reports with restrictive permissions and exclude them from source control and broad backup destinations. 8. If accidental credential access or disclosure occurs, stop the audit, remove the exposed material safely, rotate the credential, and review provider access logs. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:61
• Finding: Unbounded Inspection of Installed Skills and Persistent Agent Context<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:61-73` **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### 4. Skills — Superseded or never used? Review your installed skills: - Any skill built but never actually invoked? - Any skill replaced by a newer, better version? - Any skill with overlapping functionality that could be merged? ### 5. Memory Files — Stale project context? Review project memory and context files: - Any project memory not updated in 30+ days? - Projects marked "on hold" for 60+ days with no activity? - Contradictions between your main context file and individual project files? ``` ### Technical Analysis The skill instructs the agent to inspect installed skills and persistent memory or context files without specifying which projects, users, workspaces, or content categories are in scope. Determining whether context files contradict one another generally requires reading their contents rather than merely checking timestamps. Such files may contain confidential project data, operational instructions, personal information, historical decisions, or references to credentials. Installed-skill enumeration can also disclose the capabilities and security posture of the agent environment. Although the skill does not instruct the agent to alter memory, it permits broad access to persistent agent state without explicit consent or least-privilege restrictions. ### Attack Path 1. The user invokes the audit for maintenance purposes. 2. The agent enumerates all installed skills available under its current permissions. 3. It locates persistent memory and context files across accessible projects. 4. To identify inactivity and contradictions, it reads metadata and potentially complete file contents. 5. It summarizes capability and project-context findings in the audit report. 6. Access to that report discloses information from projects or context ...[truncated 638 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make skill inventory and memory review separate, opt-in audit modules. 2. Require the user to select the exact workspace, project, and files to inspect. 3. Use file timestamps and user-provided project status before reading file contents. 4. Require additional approval before performing semantic comparison of context files. 5. Exclude global agent memory, unrelated workspaces, system prompts, credentials, and private user data by default. 6. Report aggregate findings without copying sensitive context into the audit output. 7. Apply content redaction and restrictive permissions to generated reports. 8. Document every memory and skill resource accessed during the audit. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:132
• Finding: Unauthorized Source Modification Through Cleanup Exception<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:132-136` **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ## Execution Rules 1. **Never delete anything without explicit user approval** — only RECOMMEND 2. **One exception:** If a script references a dead API that has been confirmed cancelled → safe to comment out the call and log it. Don't delete the file. 3. **If unsure → classify as ⚪ UNKNOWN.** Never guess on deletions. 4. After approvals: execute cleanup and write `state/stack_cleanup_YYYY-MM-DD.md` confirming what was removed and what the before/after count was. ``` ### Technical Analysis Rule 2 authorizes the agent to modify source code without explicit user approval when it concludes that an API is dead and cancelled. This conflicts with the recommendation-only posture of Rule 1. The terms “dead API” and “confirmed cancelled” have no defined verification process. The instructions also omit a required diff, backup, version-control checkpoint, dependency analysis, test execution, or rollback plan. Commenting out an API call can break control flow, leave variables undefined, suppress required side effects, or disable a legitimate integration that is temporarily unavailable rather than permanently cancelled. This is an insecure change-management practice even though the instruction says not to delete the file. ### Attack Path 1. The audit scans scripts for references to old or cancelled APIs. 2. Incomplete usage records, stale documentation, or a transient provider failure causes an active API to be classified as dead. 3. The agent invokes the exception and comments out the API call without requesting approval. 4. Dependent logic remains unchanged and may consume missing or stale data. 5. The modified script is later executed manually or by a scheduled task. 6. The automation fails, silently skips required work, or produces incorrect output. 7. Without a manda ...[truncated 702 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the exception permitting automatic code changes. 2. Require explicit approval for every source modification, including commenting out a single call. 3. Present a proposed patch and explanation before applying it. 4. Define authoritative evidence required to classify an API as permanently cancelled. 5. Search for all call sites and downstream dependencies before proposing a change. 6. Confirm that the repository is under version control and create a recoverable checkpoint. 7. Run syntax checks, unit tests, integration tests, and relevant scheduled-job dry runs after an approved change. 8. Provide a rollback procedure and include the exact changed files and lines in the cleanup report. 9. Prefer configuration-based disabling or feature flags over editing source code directly. ]]>

SkillSpector

Vulnerability Patterns

• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (3)

Vague Triggers

Medium

• Confidence: 96% confidence
• Finding: The manual trigger condition is broad enough that ordinary user complaints like unexpected bills or degraded reliability could invoke a high-scope audit over crons, scripts, API keys, memories, and subscriptions without clear confirmation boundaries. In an agent environment, ambiguous invocation increases the chance of unintended reconnaissance across sensitive operational data and can lead to risky follow-on recommendations or edits.

Vague Triggers

Medium

• Confidence: 96% confidence
• Finding: The listed trigger phrases are common conversational requests that could easily appear in normal dialogue, causing accidental activation of a privileged maintenance workflow. Because this skill inspects scheduled tasks, scripts, keys, memory files, and tools, accidental invocation expands access to sensitive metadata and increases the chance of unintended state changes later in the workflow.

Session Persistence

Medium

• Category: Rogue Agent

Content

### 1. Crons — Are they alive and earning their keep?

For each launchd agent / cron job / scheduled task:
- Is the process actually running? (check PID, plist/cron status)
- When did it last fire successfully?
- What does it produce? Is that output being consumed by anything?
- Is there a newer/better approach that renders this obsolete?

• Confidence: 75% 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.

Static analysis

No suspicious patterns detected.