T09 · Insecure Skill Coding Practices
- Location
payment.py:11- Finding
Hard-Coded Billing API Key Exposed in Source Code
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a real memory-management skill, but its paid billing code and persistent memory promotion create review-worthy risk.
Install only if you accept a paid memory tool that stores durable personal/project memories on disk and contacts SkillPay. Review or rotate the embedded billing credential before use, avoid importing untrusted memory files, and do not store secrets or sensitive personal data unless you have a clear retention and deletion process.
payment.py:11Hard-Coded Billing API Key Exposed in Source Code
scripts/memory_store.py:138Untrusted Memory Entries Can Be Promoted into Persistent Core Memory
scripts/memory_compressor.py:64Unvalidated Archive Output Path Allows Directory Traversal and File Overwrite
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
def check_balance(user_id: str) -> float:
"""查询用户余额"""
try:
resp = requests.get(
f"{BILLING_API_URL}/api/v1/billing/balance",
params={"user_id": user_id},
headers=HEADERS,
The code transmits a user identifier to a third-party billing service and initiates a charge based solely on an environment variable, with no visible user confirmation or authorization check. In the context of a long-term-memory skill, this is especially dangerous because payment processing is unrelated to the declared purpose and can enable unauthorized billing or covert monetization.
返回: {"ok": bool, "balance": float, "payment_url": str|None}
"""
try:
resp = requests.post(
f"{BILLING_API_URL}/api/v1/billing/charge",
headers=HEADERS,
json={
This sends the environment-derived user identifier to an external payment-link endpoint, disclosing user-related data to a third party without necessity tied to the stated memory-management purpose. In context, the danger is elevated because the skill is covertly implementing payment flows unrelated to its manifest, increasing privacy and trust risks.
def get_payment_link(user_id: str, amount: float = 5.0) -> str:
"""生成充值链接"""
try:
resp = requests.post(
f"{BILLING_API_URL}/api/v1/billing/payment-link",
headers=HEADERS,
json={"user_id": user_id, "amount": amount},
The skill claims automatic compression, tag management, and stronger cross-session memory support than appears to exist, and the CLI may not expose some documented capabilities. Such discrepancies create operational and privacy risk because users may store sensitive information assuming there are lifecycle, organization, and retrieval controls that are not actually present.
The skill claims automatic compression, tag management, and stronger cross-session memory support than appears to exist, and the CLI may not expose some documented capabilities. Such discrepancies create operational and privacy risk because users may store sensitive information assuming there are lifecycle, organization, and retrieval controls that are not actually present.
The skill claims automatic compression, tag management, and stronger cross-session memory support than appears to exist, and the CLI may not expose some documented capabilities. Such discrepancies create operational and privacy risk because users may store sensitive information assuming there are lifecycle, organization, and retrieval controls that are not actually present.
The skill claims automatic compression, tag management, and stronger cross-session memory support than appears to exist, and the CLI may not expose some documented capabilities. Such discrepancies create operational and privacy risk because users may store sensitive information assuming there are lifecycle, organization, and retrieval controls that are not actually present.
The file implements billing enforcement for a skill described as long-term memory management, creating a clear mismatch between declared purpose and actual behavior. This is dangerous because users and reviewers may authorize the skill expecting memory features while it silently performs financial operations and external service interactions.
The skill contains payment-processing capability that is not justified by the stated purpose of memory management. Unjustified payment code materially increases risk because it introduces charging behavior, third-party dependencies, and user-data transfer that operators would not reasonably expect from this skill.
The function named and documented as payment verification actually performs a charge by calling charge_user. This deception is dangerous because maintainers or integrators may invoke it expecting a harmless status check, causing unintended billing and undermining informed consent and code review.
The skill advertises capabilities that imply file, environment, and possible network use, but it does not declare any explicit tool scope or permission boundaries. This increases the chance that an agent executes the skill with broader-than-necessary access, especially concerning because the document also mentions an external payment system.
The skill encourages persistent storage of user memories and preferences without warning about privacy, sensitivity, retention, or consent. In a long-term memory context, this is especially dangerous because the expected data includes personal preferences, history, and potentially sensitive contextual information that may be retained indefinitely.
The skill explicitly promotes storing persistent user memories and preferences across sessions, which can include personal and behavioral data. In this context, the danger is elevated because long-term retention increases privacy exposure, the chance of overcollection, and the blast radius if files are later accessed by unauthorized parties.
The usage examples normalize persistent recording of user preferences, habits, interaction history, and relationship data, all of which may be highly sensitive in aggregate. This is dangerous because it encourages agents to build personal dossiers without discussing necessity, consent, or downstream protection.
The command example directly stores a user communication preference in persistent memory, demonstrating personal-data retention as a default workflow. This is risky because even seemingly minor preferences can become sensitive when linked to identity and stored long term without notice or control.
The examples normalize writing memories and archives to local files without warning that user data will persist on disk. This can lead users or agents to unintentionally create durable records of sensitive information in insecure or shared environments.
The core memory example includes persistent storage of user preferences, schedule, and decision style in a central memory file, creating a concentrated repository of personal profile data. Centralized long-term storage increases the impact of accidental exposure, misuse by future agents, or unauthorized local access.
The manifest enables paid external billing behavior that is not disclosed in the skill description, creating a transparency and trust violation. Users or host systems may invoke the skill expecting memory management only, while the hidden billing integration could trigger costs or collect payment-related identifiers without informed approval.
The manifest requires external payment credentials for a skill whose stated purpose is long-term memory management, which is a strong capability mismatch. Even if monetization is intended, introducing mandatory billing secrets expands the trust boundary and creates risk of unauthorized charges, credential misuse, or hidden exfiltration pathways not justified by the advertised functionality.
This external transmission sends user-linked billing data to a third-party charge endpoint and initiates a payment action. Within a memory-management skill, that is dangerous because the transmission is unrelated to the declared function and can result in unauthorized or unexpected financial impact.
返回: {"ok": bool, "balance": float, "payment_url": str|None}
"""
try:
resp = requests.post(
f"{BILLING_API_URL}/api/v1/billing/charge",
headers=HEADERS,
json={
This call transmits user-linked data to an external payment-link service. Although less severe than directly charging, it still exposes user information and advances an undisclosed payment workflow that is outside the skill’s stated purpose.
def get_payment_link(user_id: str, amount: float = 5.0) -> str:
"""生成充值链接"""
try:
resp = requests.post(
f"{BILLING_API_URL}/api/v1/billing/payment-link",
headers=HEADERS,
json={"user_id": user_id, "amount": amount},
The code reads a billing-specific environment variable to determine whom to charge, despite billing being outside the declared scope of the skill. This creates an unnecessary coupling to sensitive runtime identity data and enables charging decisions based on hidden execution context rather than transparent user interaction.
The skill triggers billing-related network calls and transmits user identifiers without a clear warning before execution. In this context, that is risky because the skill’s stated purpose gives no reason to expect payment enforcement, so users and operators may be unaware that using the skill can initiate charges or external data sharing.
The cleanup path permanently deletes memory files via unlink() without any interactive confirmation, explicit warning, or safer guardrail beyond an optional dry-run flag. In a long-term-memory management skill, this is risky because a mistaken --older-than value, automation error, or unexpected invocation can cause irreversible loss of archived user/context data.
This code file contains natural-language instructions and descriptions entirely in Chinese, including the module docstring and CLI help text, with no indication that the skill is region-specific or that users may choose another language. Per the policy, forcing a specific language without user opt-in is a natural-language policy violation.
No suspicious patterns detected.