Back to skill

Security audit

Agent Architect

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent architecture-audit guide, but it includes automatic memory logging and a hard-coded named approval authority that users should review before installing.

Install only if you are comfortable with a skill that can cause agents to record audit recommendations in memory. Consider removing or changing the automatic memory-log instruction and replacing the named 'Don' approval rule with your own authenticated project governance policy.

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (2)

T02 · Agent Memory Poisoning

Warning
Location
SKILL.md:76
Finding
Untrusted Diagnostic Content Can Be Written to Persistent Agent Memory## Vulnerability Details **File Location**: `SKILL.md`, lines 76-79 **Vulnerability Type**: Persistent memory poisoning through unsanitized diagnostic logging **Risk Level**: Medium **Vulnerable Snippet**: ```markdown 8. **Log meaningful architecture recommendations** If the diagnosis leads to a real structural recommendation, log the lane, fix type, and short symptom summary to daily memory so future audits can see what changed and why. ``` ### Technical Analysis The skill instructs the agent to write the lane, fix type, and symptom summary into daily memory whenever it produces a structural recommendation. The symptom and resulting diagnosis may be derived from attacker-controlled input, but the instruction does not require: - explicit user approval before persistence; - provenance or trust-level metadata; - sanitization of the symptom summary; - separation of quoted user claims from verified facts; - retention limits or deletion controls; - exclusion of sensitive information and embedded instructions. Consequently, an attacker can present a crafted symptom or false architectural claim that is summarized and retained as persistent state. A future audit may retrieve that stored entry and treat it as established historical evidence, allowing the attacker's content to influence later sessions. This behavior also weakens the statement in `SKILL.md` that recommendations are diagnostic only: although the skill does not directly apply code patches, it can still modify durable agent state. ### Attack Path 1. An attacker submits a fabricated or adversarial symptom, such as a claim that a particular operating restriction repeatedly causes failures. 2. The skill classifies the issue and generates a structural recommendation from that input. 3. Under the logging instruction, the agent writes the lane, fix type, and attacker-influenced symptom summary to daily memory. 4. A later session retrieves the memory entr ...[truncated 980 chars]
Remediation
## Remediation Suggestions Remove automatic memory logging from the default workflow, or replace it with an explicitly controlled process: 1. Require informed user approval before writing any audit result to persistent memory. 2. Store only allow-listed structured fields, such as the selected lane and fix type. 3. Do not persist raw user text or an unconstrained symptom summary. 4. Mark every entry with provenance, timestamp, confidence, and verification status. 5. Label unverified user claims as allegations rather than established facts. 6. Exclude secrets, credentials, personal information, and embedded instructions. 7. Define retention and deletion procedures for architecture audit entries. 8. Ensure later audits do not treat prior recommendations as proof of recurrence without independent evidence. A safer replacement would be: ```markdown 8. **Offer an optional audit record** Do not write to persistent memory automatically. If the user explicitly approves, store only the lane, fix type, timestamp, confidence, and a sanitized factual summary. Mark user-provided claims as unverified and never store secrets or executable instructions. ```

T01 · Skill Instruction Hijacking

Warning
Location
references/placement-map.md:35
Finding
Hard-Coded Named Authority Can Override Host Governance## Vulnerability Details **File Location**: `references/placement-map.md`, lines 35-37 **Vulnerability Type**: Instruction hijacking through an unverified external approval authority **Risk Level**: Medium **Vulnerable Snippet**: ```markdown Avoid: - edits to Constitutional Principles in `AGENTS.md` — those are immutable unless Don gives explicit written approval - broad rewrites triggered by a narrow failure ``` ### Technical Analysis The skill introduces a project-specific governance instruction that assigns approval authority to a person identified only as “Don.” The skill does not establish that identity, explain how approval is authenticated, or limit the rule to a specific repository or organization. Because skill text is loaded as operational guidance, an agent may treat this embedded instruction as authoritative in environments where it conflicts with the current repository owner, user authorization, or host governance policy. It can therefore alter the agent's decision criteria and redirect authorization toward an identity that was not established by the invoking user. The instruction also creates an authentication ambiguity: “explicit written approval” does not define an approved channel, cryptographic identity, account, or verification process. An attacker capable of supplying text attributed to “Don” may attempt to satisfy the condition without legitimate authority. ### Attack Path 1. The skill is installed or invoked in an environment unrelated to the project from which the named-authority rule originated. 2. A legitimate user requests an authorized change to constitutional material in `AGENTS.md`. 3. The agent loads the placement guidance and treats “Don” as the required approval authority. 4. The agent either refuses the legitimate request or asks for approval from the hard-coded identity. 5. Alternatively, an attacker presents a message or document claiming to be written approval from “Don.” 6. Becau ...[truncated 980 chars]
Remediation
## Remediation Suggestions Remove the named-person exception and defer authorization to authenticated, environment-specific policy: 1. Replace “Don” with the authorized repository owner or governance authority defined by the active environment. 2. Require the agent to follow higher-priority system policy, repository ownership rules, and verified user permissions. 3. Define how sensitive approval is authenticated rather than accepting arbitrary written text. 4. Scope any immutability rule to the repository in which it is declared. 5. Require confirmation for high-impact governance edits, but do not invent an authority absent from host configuration. 6. Reject approvals based solely on a name appearing in user-provided content. A safer replacement would be: ```markdown Avoid: - edits to constitutional principles unless the authenticated repository owner or governing policy explicitly authorizes the change - broad rewrites triggered by a narrow failure ``` Where practical, enforce this requirement through repository permissions and protected-review workflows rather than relying solely on natural-language instructions.
Vulnerability Patterns
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Ae1

High
Category
analysis-evasion
Content
- skills → a specific skill's `SKILL.md`, `references/`, or a new narrow skill only if earned
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Self-Modification

High
Category
Rogue Agent
Content
If the fix changes **how the agent sounds**, patch persona.
If it changes **how the agent decides**, patch rules.
If it changes **what the agent retains or recalls**, patch memory.
If it changes **how the agent repeatedly executes a task category**, patch skills.
Confidence
85% confidence
Finding
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Static analysis

No suspicious patterns detected.