T09 · Insecure Skill Coding Practices
- Location
SKILL.md:95- Finding
Authentication and Gateway Credentials Exposed Through Chat and Command-Line Arguments
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:23-40,SKILL.md:95-100, andreferences/payment-flows.md:17-20
Vulnerability Type: Sensitive credential exposure
Risk Level: HighVulnerable Code
From
SKILL.md:23-40:bash curl -s "https://paypilot.agms.com/v1/auth/register" -X POST \ -H "Content-Type: application/json" \ -d '{"name":"BUSINESS_NAME","email":"EMAIL","password":"PASSWORD"}'bash curl -s "https://paypilot.agms.com/v1/auth/login" -X POST \ -H "Content-Type: application/json" \ -d '{"email":"EMAIL","password":"PASSWORD"}'bash curl -s "https://paypilot.agms.com/v1/auth/configure" -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TOKEN" \ -d '{"gateway_key":"YOUR_GATEWAY_KEY"}'From
SKILL.md:95-100:bash Prompt the user for their password — never store it or read it from environment variables:bash # Re-login LOGIN=$(curl -s "$API/v1/auth/login" -X POST \ -H "Content-Type: application/json" \ -d "{\"email\":\"$(echo $CONFIG | jq -r '.email')\",\"password\":\"$USER_PASSWORD\"}")From
references/payment-flows.md:17-20:text User: "I got approved, here's my security key" Agent: → POST /v1/auth/register (create account) Agent: → POST /v1/auth/configure (encrypt + store gateway key) Agent: → "You're all set! Try: 'charge $50 to vault token XYZ'"Technical Analysis
The Skill explicitly instructs the Agent to prompt for a merchant password and depicts the user supplying a gateway security key in the conversation. Secrets entered through an Agent conversation may be retained in conversation history, diagnostic logs, telemetry, memory systems, or service-provider records. This conflicts with the Skill's separate rule that API tokens and gateway keys must never appear in chat.
The provided
curlcommands also place passwords, gateway keys, JWT bearer tokens, and complete request bodies in process arguments. Depending on the operatin ...[truncated 2051 chars]- Remediation
View remediation
Remediation Suggestions
-
Prohibit secrets in conversation
- Explicitly instruct users never to enter passwords, gateway keys, JWTs, card data, or recovery credentials into chat.
- Remove the instruction to prompt conversationally for the user's password.
- Replace the example in
payment-flows.mdwhere the user supplies a security key in chat.
-
Use a secure browser-based authorization flow
- Redirect registration, login, token refresh, and gateway-key configuration to a trusted hosted HTTPS page.
- Prefer OAuth 2.0 authorization code with PKCE, device authorization, or another short-lived delegated authorization mechanism.
- Return only a short-lived authorization result to the Agent, not the merchant's password or gateway key.
-
Avoid passing credentials through command arguments
- Do not interpolate passwords, gateway keys, or bearer tokens directly into shell command lines.
- Use a dedicated API client that accepts secrets through protected in-memory interfaces.
- If command-line tooling is unavoidable, use protected standard input or a credential helper and disable shell tracing.
- Ensure execution telemetry and error reporting redact
Authorizationheaders and sensitive request fields.
-
Harden token handling
- Use narrowly scoped, short-lived access tokens and rotate them after suspected exposure.
- Store refresh credentials in an operating-system credential store rather than a regular JSON file where supported.
- Enforce restrictive permissions and validate ownership before reading local credential files.
- Never print API responses containing access tokens.
-
Add operational controls
- Require explicit user confirmation before charges, refunds, voids, subscriptions, and fraud-rule changes.
- Record non-sensitive audit events for security-sensitive operations without logging credentials.
- Support immediate token and gateway-key revocation.
- Add automated secret-redact ...[truncated 76 chars]
-