T05 · Unauthorized Access and Privilege Escalation
- Location
core/agent.js:8- Finding
Path Traversal in Agent and Project Persistence Identifiers
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill broadly matches its purpose, but it needs review because it stores state locally and has concrete file path and dashboard rendering weaknesses.
Review this before installing in sensitive or multi-user environments. Do not pass user-controlled project IDs or agent IDs until path validation is added, avoid storing secrets or regulated data in project goals, outputs, blockers, errors, or lessons, and treat the dashboard as unsafe for untrusted status data until it stops using innerHTML.
core/agent.js:8Path Traversal in Agent and Project Persistence Identifiers
ui/dashboard.js:114Stored DOM-Based Cross-Site Scripting in the Dashboard
The description promises a persistent multi-agent operating system with cross-session memory, learning, and coordination features. The code does provide limited persistence by saving/loading project state to disk and it coordinates tasks at a basic level through assignment and sequential execution. However, it does not implement agent memory across sessions in a meaningful sense, learning from experience, or deduplication/avoidance of duplicate work. Its primary behavior is narrower: it is a sequential executor and project status tracker with simulated task progress. Therefore the declared description overstates the implemented capabilities and does not accurately represent this code chunk.
The code supports the general idea of coordinating multiple agents on project execution: it registers agents, initializes routing/execution components, runs projects, and exposes status. However, the declared description emphasizes persistent memory across sessions and learning from experience. In this code chunk, persistence is limited to a toJSON export helper; there is no loading/restoring state, storage backend, or session-spanning memory mechanism shown. There is also no visible implementation of learning or adaptation from prior experience. The coordination claim is partially supported through TaskRouter and Executor orchestration, but the stronger persistence and learning claims are not represented by the supplied code.
The code chunk is narrowly focused on project task decomposition and routing. It defines static templates for research/design/development/planning, assigns one agent per task type based on capability matching, enforces simple sequential dependencies, and tracks completion/progress in memory. It does not implement persistence, storage, cross-session memory, experiential learning, or sophisticated multi-agent coordination features implied by the description. While task assignment and coordination are loosely related to the declared purpose, the primary described claims are not represented in this code.
The declared description promises a persistent multi-agent operating system with memory across sessions, learning from experience, and coordination mechanisms. The supplied code does not implement those behaviors. Instead, it is purely a UI dashboard that reads a saved JSON blob from localStorage or returns fixed mock data, then displays project, agent, and task information in the browser. There is no agent runtime, no learning logic, no memory management beyond reading a single localStorage key, no scheduling or coordination logic, and no duplicate-work prevention. The code's primary purpose is status visualization, not operating a persistent agent system.
Referenced artifact was not completely inspected
See `examples/research-project.js` for the canonical example:
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
</head>
<body>
<div class="container">
<!-- Header -->
<header class="header">
<div class="header-content">
<h1>🤖 Agent OS Dashboard</h1>
This is a real integrity issue: the document advertises capability tracking and smart routing as implemented benefits while the same file explicitly says those features are not in v0.1. In a security-sensitive agent ecosystem, overstating autonomy and learning behavior can mislead users into deploying the skill with incorrect assumptions about controls, routing quality, and operational maturity.
The portfolio section lists a 'Capability learning system' as an existing feature even though earlier sections state that capability learning is not part of v0.1. This kind of contradictory documentation can cause downstream users, reviewers, or publishers to trust automation features that do not exist, increasing the risk of unsafe or inappropriate deployment decisions.
The README explicitly describes persistent storage of agent memory, state, and project data to disk, but it does not warn users about retention, sensitivity of stored content, or operational/privacy implications. In an agent framework, persisted memory can easily contain prompts, project details, internal notes, or other sensitive data, so failing to disclose and guide safe handling increases the risk of accidental data exposure or non-compliant retention.
The skill explicitly states that agent memory, state, and project data are persisted to a local data directory, but it provides no warning about retention, sensitivity, access controls, or cleanup. In an agent system, these files may contain prompts, project details, internal reasoning summaries, or other sensitive operational data, so silent retention increases the risk of privacy leakage, unintended reuse, and exposure to other local users or processes.
This code persistently writes agent memory and execution state to JSON files, including task details, outputs, blockers, and learned lessons. Although comments describe the behavior for developers, there is no user-facing disclosure, confirmation, or visible runtime notice that user-related task data will be stored on disk.
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.
}
/**
* Save state to disk
*/
saveState() {
try {
The architecture explicitly makes persistence a core design principle and states that all agent and project state is written to local JSON files, but it does not mention user consent, retention limits, or the risk that prompts, outputs, lessons, or other sensitive workflow data may be stored on disk. In an agent OS context, persistent memory increases the chance of unintentionally retaining secrets, proprietary project content, or personal data across sessions.
The example memory schema includes durable fields such as lessons learned, capabilities, activity history, and task statistics, normalizing long-term retention without warning that these entries may capture sensitive business context or user-derived information. Because this system is designed for cross-session memory, such data can accumulate and become a privacy or information exposure issue if files are accessed by other local users, tooling, backups, or later agents.
The file I/O section gives concrete read/write paths for agent memory, state, and project artifacts and emphasizes persistence after each state change, but it still omits an explicit warning that task and project content is continuously written to disk. In this skill's context, that makes the risk more credible because project goals, outputs, blockers, and notes may include confidential material that users may not expect to be retained locally.
This markdown file states that agent memory and state persist to disk, and later provides git add . / publish commands, but it does not warn users that generated data files may contain project state or should be reviewed before publishing. For markdown files, SQP-2 applies when potentially impactful behavior affecting user data or system integrity is described without warning.
This JSON manifest contains a high-level goal, "Build AI-powered trial member follow-up system for ClawdGym," but does not define any explicit trigger phrases, activation scope, or exclusion conditions. For manifest files, the lack of specificity around when this skill should activate can lead to unintended invocation from broadly related user requests.
The document declares lang="en", which enforces an English-language locale in the UI. Under the stated policy, locale-specific behavior should either be user-selectable or clearly justified as region-specific, neither of which is present in this file.
The code explicitly calls toLocaleTimeString with 'en-US', which hard-codes a specific locale for all users. This is a natural-language/locale policy concern because the file does not offer user opt-in, locale selection, or a documented reason for restricting display to U.S. English formatting.
No suspicious patterns detected.