Deploy an app on AgentsPodium

• Outcome: Review
• Latest audit: Sep 13, 2026 · 8:29 PM UTC
• Version: 1.1.0

Overview

The skill is a transparent AgentsPodium deployment guide, but it deserves review because private repository tokens are stored for rebuilds and exposed inside the running pod.

Install or use this only if you are comfortable sending deployment configuration to AgentsPodium. For private repositories, use a short-lived, read-only token scoped to one repository, rotate it after deployment if possible, and do not deploy code or dependencies you do not trust while that token is available in the pod environment.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:190
• Finding: Private repository credential remains accessible to deployed application code<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 190-197 **Vulnerability Type**: Repository credential exposure to untrusted build and application code **Risk Level**: High ### Vulnerable Code Snippet ```markdown Send `repoToken` with a token that can read the repository. It is encrypted at rest, handed to the pod at deploy time, and never returned. `repoUser` you can leave out. Forges disagree about what goes next to a token — GitHub takes `x-access-token`, GitLab `oauth2`, Bitbucket `x-token-auth`, Gitea and Forgejo the token alone — and a self-hosted GitLab is indistinguishable from a self-hosted Gitea by its URL. The pod tries the forms in turn and keeps the one the server accepts; the build log names it. Send `repoUser` only to skip that. Know what you are agreeing to: the token lives in the pod's environment, and the code you deploy runs in that pod. It is your own repository token, but anything you deploy can read it. Use a token scoped to that one repository. ``` ### Technical Analysis A private-repository token is legitimately required during repository checkout. However, the documented design places the token in the pod environment where deployed code can read it. Retaining the credential after checkout exceeds the minimum privileges required for the application's build and runtime phases. Encryption at rest and suppressing the token from API responses do not protect it after injection into the pod. Application code, build scripts, lifecycle hooks, compromised dependencies, or command execution vulnerabilities may inspect the process environment and disclose the credential. The guidance to scope the token to one repository reduces the potential impact but does not eliminate the underlying exposure. ### Attack Path 1. An operator supplies a valid private-repository token through `repoToken`. 2. The platform injects that token into the deployment pod. 3. A malicious repository script, compromised dependency, build hook, o ...[truncated 883 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Perform repository checkout in a dedicated, isolated stage using an ephemeral clone-only credential. 2. Remove the credential from all environment variables, Git credential helpers, remote URLs, configuration files, and process state before running repository-controlled build commands. 3. Do not expose repository credentials to the deployed application's runtime environment. 4. Use short-lived, read-only credentials restricted to a single repository and, where supported, a single branch. 5. Separate source acquisition from builds so that build scripts and dependencies cannot access checkout credentials. 6. Redact raw, URL-encoded, and alternate representations of credentials from logs. 7. Add automated tests verifying that build and runtime processes cannot retrieve `repoToken`. 8. Document immediate revocation and rotation procedures for suspected credential disclosure. ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:77
• Finding: Unpinned package execution through npx during deployment<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 77 **Vulnerability Type**: Unsafe third-party package resolution and execution **Risk Level**: Medium ### Vulnerable Code Snippet ```bash "buildCommand": "npm ci && npx expo export -p web", ``` ### Technical Analysis Although `npm ci` installs dependencies according to the project's lockfile, `npx expo` can resolve and download the requested package from a configured package registry when a local executable is unavailable. The command does not require that `expo` be present as a locally installed, lockfile-pinned dependency. Consequently, the effective code executed during deployment may depend on mutable external registry state. Registry compromise, dependency confusion, account takeover, or an unexpected registry configuration could cause unreviewed package code to execute inside the pod. This is particularly significant because the same pod may have access to repository credentials, application environment variables, source code, persistent files, and network connectivity. ### Attack Path 1. A repository uses the documented build command without declaring a local, lockfile-pinned `expo` dependency, or configures npm to resolve packages through an unsafe registry. 2. `npm ci` completes without installing the expected local Expo executable. 3. `npx expo` attempts to resolve and download a package at build time. 4. A compromised, substituted, or otherwise unsafe package is installed and executed. 5. The package reads accessible source code, environment variables, repository credentials, or persistent files. 6. The package exfiltrates data or modifies the generated application artifacts. ### Impact Assessment Malicious package code can execute with the permissions of the deployment build process. Depending on pod isolation and available secrets, this may permit source-code theft, credential disclosure, persistent artifact tampering, access to cached files, and compromise of the deplo ...[truncated 257 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Require `expo` to be declared at an exact or lockfile-controlled version in the repository. 2. Execute only the installed local binary, for example: ```bash npm ci && npm exec --offline expo -- export -p web ``` Alternatively, invoke `./node_modules/.bin/expo` directly. 3. Configure builds to fail if the required executable is not already installed locally. 4. Require a committed and reviewed lockfile and use a trusted registry. 5. Pin dependency integrity metadata and consider an internal package mirror or allowlist. 6. Disable unnecessary package lifecycle scripts where compatible with the project. 7. Isolate builds from long-lived credentials and restrict outbound network access during build execution. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (6)

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The description says to use the skill when asked to 'ship an app somewhere' or 'move a site off Netlify or Vercel,' which is broad natural language that overlaps with many generic deployment requests. It does not clearly constrain invocation to AgentsPodium-specific deployments or provide exclusion conditions, increasing the risk of unintended activation.

External Transmission

Medium

• Category: Data Exfiltration

Content

a self-hosted Forgejo:

```bash
curl -s -X POST https://agentspodium.com/api/agents \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{
    "engine": "app",
    "tier": "small",

• Confidence: 95% confidence
• Finding: This skill instructs sending sensitive deployment data to an external service, including repository URLs, environment variables, and potentially `repoToken` for private repositories. External transmission is expected for a deployment skill, but it is still security-relevant because the deployed code runs in the same pod and the document explicitly states the repo token lives in the pod environment, meaning untrusted application code could read and misuse it.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence
• Finding: npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

External Transmission

Medium

• Category: Data Exfiltration

Content

If you do not have the id, list what the key can see:

```bash
curl -s https://agentspodium.com/api/agents -H "Authorization: Bearer $TOKEN"
# {"agents":[{"id":"agt_…","name":"hq-app","engine":"app","status":"running",
#             "endpointUrl":"https://…","app":{"repo":"…","branch":"main",…}}]}
```

• Confidence: 89% confidence
• Finding: Listing agents with an API key transmits and returns potentially sensitive metadata to an external service, including agent IDs, names, endpoint URLs, and repository information visible to that key. In context this is normal platform usage, but it remains a real security-sensitive operation because compromise or overuse of the key exposes infrastructure inventory and app details that aid follow-on attacks.

Description-Behavior Mismatch

Medium

• Confidence: 87% confidence
• Finding: The manifest frames this skill as deploying a project from a git repository onto AgentsPodium. In the documentation, however, it expands into general instance administration and billing-related operations by pointing users to status, liveness, usage, term, pause/resume/delete/export, and payment endpoints, which exceed the narrow semantic scope of 'deploy an app.'

Description-Behavior Mismatch

Low

• Confidence: 76% confidence
• Finding: The manifest describes a deployment skill focused on shipping apps from git repositories. Mentioning an alternate mailbox-based auth flow introduces account authentication behavior that is not necessary to understand or perform the core deployment task and broadens the apparent scope of the skill.

Static analysis

No suspicious patterns detected.