other
Error
- Location
- SKILL.md:33
- Finding
- Third-Party Exposure of LLM Conversations and Provider Credentials## Vulnerability Details **File Location**: `SKILL.md`, lines 33–35, 56, and 75–84 **Vulnerability Type**: Credential and Conversation Data Exfiltration **Risk Level**: Critical **Vulnerable code and instructions:** ```text - The full prompt and message history your agent sends - The full response returned by the upstream LLM - Your upstream LLM provider key, which Vaikora forwards to the provider on your behalf ``` ```text `LLM_PROVIDER_API_KEY` is whatever key the provider issues you. OpenAI's `sk-...`, Anthropic's `sk-ant-...`, a Google API key, etc. Vaikora does not store it beyond the request lifetime, but it does see it in cleartext. ``` ```yaml llm: provider: openai base_url: https://api.vaikora.com/v1 headers: x-api-key: "${VAIKORA_API_KEY}" Authorization: "Bearer ${LLM_PROVIDER_API_KEY}" x-vaikora-agent: "${VAIKORA_AGENT_ID}" ``` ```text - `Authorization: Bearer` carries your upstream provider key. Vaikora forwards this to OpenAI, Anthropic, or whichever provider your chosen model maps to. ``` ### Technical Analysis The Skill directs users to replace the LLM provider's endpoint with a third-party reverse proxy at `api.vaikora.com`. It then transmits the upstream provider API key in the `Authorization` header to that proxy. As explicitly documented by the Skill, the intermediary receives the complete prompt, message history, model response, and provider credential in cleartext at the application layer. TLS can protect these values in transit from network observers, but it does not prevent the terminating proxy from accessing them. The statement that the credential is not stored beyond the request lifetime is an external operational claim and is not technically enforced or independently verifiable by anything in the reviewed project. The intermediary's access to a reusable provider credential also exceeds the access required solely to analyze prompt and response content. ...[truncated 1596 chars]
- Remediation
- ## Remediation Suggestions - Do not send reusable upstream provider credentials through third-party infrastructure. Prefer direct provider communication combined with local or provider-native security monitoring. - Where intermediary routing is unavoidable, use narrowly scoped, short-lived delegation tokens rather than general-purpose provider API keys. - Restrict credentials with minimum permissions, low spending limits, rate limits, model allowlists, source restrictions, and rapid expiration where supported. - Redact or tokenize credentials, personal data, regulated data, proprietary content, and unrelated conversation history before transmitting requests for analysis. - Require explicit, informed administrator approval before enabling third-party routing, with clear disclosure of all transmitted fields and trust boundaries. - Establish contractual and technically verifiable controls for retention, access logging, encryption, personnel access, incident notification, deletion, and subprocessors. - Provide a local deployment option so security inspection can occur inside the user's trust boundary. - Rotate any upstream provider credential that has already traversed the proxy, then review provider usage and billing logs for unauthorized activity. - Test the integration with an isolated account, synthetic prompts, a dedicated test credential, and strict usage limits before considering production deployment.