Token Management
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: token-management Version: 1.0.1 The skill instructs the AI agent to execute shell commands (e.g., `gog calendar create`, `echo`, `grep`, `cat`) and make network requests (via Python's `requests` library) using placeholders that would be filled by user input or dynamic variables. The `SKILL.md` provides no instructions for the agent to sanitize or validate these inputs, creating a significant vulnerability for prompt injection, potentially leading to shell injection or Server-Side Request Forgery (SSRF) if the agent is not robustly designed to handle untrusted input safely. This risk is present in the 'Workflow' and 'Commands' sections of `SKILL.md`.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The agent could gain access to multiple important third-party accounts from one local file and may use tokens with write or repository permissions.
The skill instructs the agent to read a central local credential file and shows broad third-party account scopes, but it does not bound which credentials may be used or require per-token user confirmation.
**ALWAYS check `~/Documents/life/.env` FIRST before asking for tokens!** ... | GitHub | `GITHUB_TOKEN` | repo, gist | ... | Jira | `JIRA_TOKEN` | read-write |
Use least-privilege tokens, require explicit user approval before reading or using each token, and prefer an OS keychain or secrets manager over a blanket always-read .env file.
Secrets or unrelated private files could be placed in git history or exposed in the chat/log output when listing tokens.
The suggested commands stage every file in the directory and print every token value, rather than using scoped, masked, or secret-safe operations.
If .env is in a git repo: `cd ~/Documents/life && git add -A && git commit -m "Before updating TOKEN_NAME"` ... `cat ~/Documents/life/.env`
Do not commit .env secrets, avoid `git add -A` for credential workflows, and replace token listing with masked output or service-specific lookups.
Long-lived local records could reveal which services you use and how to access them, and future agent tasks may over-trust stale or modified connection data.
The skill creates persistent cross-task records about tokens, capabilities, renewal links, and local skill state outside the workspace, but does not define access controls, retention, or safe reuse boundaries.
Create or update `~/Documents/life/connections/SERVICE.md` ... `Your index:` Keep your own list in this section (local copy of skill). ... `Survives workspace wipes`
Keep persistent token metadata minimal, protect the directory with strict permissions, avoid storing token values in documentation, and require confirmation before reusing saved connection information.
A user may believe the workflow is secret-safe while actually placing credentials where they are easier to share, sync, or expose.
The security framing conflicts with storing API secrets in a location explicitly described as shareable/public and designed to persist beyond workspace cleanup.
description: "... ensures token security ..." ... **Why here:** - ✅ Life infrastructure (shareable, public) - ✅ Survives workspace wipes
Revise the documentation to avoid unsupported security claims and clearly warn users not to store unencrypted secrets in public, shared, or synced folders.
Users may need to install or authorize tools separately, and should verify their source before using them with tokens or calendars.
The skill depends on external tools for testing and calendar reminders, while the supplied registry data has no install spec or required binaries; no automatic installation is shown.
dependencies: - python3 - requests - gog (for calendar reminders)
Declare dependencies in metadata and provide safe, pinned installation guidance or tell users to install them through trusted package managers.