Back to skill

Security audit

Gougoubi Agent Register

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed wrapper for registering a ggb.ai Pre-Market agent and saving its one-time API key, with one credential-storage caution.

Install only if you intend to create a ggb.ai Pre-Market agent identity. Treat the returned API key like a password: prefer 1Password, Vault, an OS keychain, or a cloud secret manager; if you use .env, keep it out of source control and deployment artifacts and restrict file permissions.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:164
Finding

Insecure Recommendation to Store an API Key in a Plaintext .env File

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 164–166
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: Medium

Vulnerable Code

markdown
- Persist the returned `apiKey` to a secure local store
  (`.env`, `1Password`, Cloudflare Secret, Vault, etc.) BEFORE
  rendering the response to the user.

Technical Analysis

The skill presents a .env file as equivalent to managed secret-storage systems such as Vault or 1Password. A conventional .env file is an unencrypted plaintext file and is not inherently secure. The instructions do not require restrictive filesystem permissions, exclusion from source control and build artifacts, encryption at rest, or separation from files accessible to unrelated processes.

The returned API key is a long-lived bearer credential used by downstream Pre-Market operations. Possession of the raw key is sufficient to authenticate as the registered agent. Although the skill correctly prohibits logging the key, recommending an inadequately protected .env file can still expose it through source-control commits, deployment bundles, backups, support archives, CI artifacts, or access by other local users and processes.

The same insecure recommendation is also repeated in README.md, lines 91–93:

markdown
**The `apiKey` is returned exactly once.** Persist it to a secure
store (`.env`, `1Password`, Vault, Cloudflare Secret, …) before
rendering the response.

Attack Path

  1. The agent follows the documented recommendation and writes the returned pmk_… API key to a project-level .env file.
  2. The file is left with permissive filesystem permissions, copied into an application image or artifact, included in a backup, or accidentally committed to source control.
  3. An attacker with access to the repository, artifact, backup, deployment image, or local filesystem reads the plaintext API key.
  4. The attacker supplies the stolen ...[truncated 896 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove .env from the list of storage mechanisms described as secure. Prefer an operating-system keychain or a managed secret store such as Vault, 1Password, or a cloud-provider secret manager.
  2. If .env support is operationally necessary, explicitly require all of the following controls:
    • Store the credential outside the source tree where possible.
    • Add the file to .gitignore and verify it is not already tracked.
    • Apply owner-only filesystem permissions, such as mode 0600 on Unix-like systems.
    • Exclude the file from containers, deployment archives, logs, backups, crash reports, and support bundles unless those systems provide appropriate encryption and access controls.
    • Never print the value through shell tracing, CI output, telemetry, or error messages.
  3. Write the credential atomically without exposing it in command-line arguments or process listings.
  4. Document a clear revocation and rotation procedure for suspected exposure, including immediate invalidation of the previous key.
  5. Update both SKILL.md and README.md so their credential-storage guidance is consistent.
Vulnerability Patterns
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.