BYOK Relay Builder

• Outcome: Review
• Latest audit: Sep 13, 2026 · 8:30 AM UTC
• Version: 1.0.8

Overview

The skill is coherent BYOK relay documentation, but it deserves Review because it directs apps to send reusable LLM provider API keys to a managed third-party relay and persist relay bearer tokens in browser storage.

Use the managed relay only if you are comfortable with relay.byokrelay.com storing and using your users' provider API keys. For production, team, regulated, or high-spend use, prefer self-hosting or a backend-for-frontend, pin the relay source and dependencies, restrict provider keys with budgets and scopes where possible, and avoid long-lived relay bearer tokens in browser localStorage for administrative or organization-wide access.

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 (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:117
• Finding: Provider API Credentials Are Transmitted to a Third-Party Managed Relay## Vulnerability Details **File Location**: `SKILL.md`, lines 117-127; managed destination defined at line 50 **Vulnerability Type**: Third-party credential exposure and excessive credential custody **Risk Level**: High ### Evidence ```javascript const RELAY_URL = 'https://relay.byokrelay.com'; ``` ```javascript async function storeApiKey(relayUrl, token, provider, apiKey) { // provider: 'openai' | 'anthropic' | 'google' | 'groq' | 'mistral' | 'openrouter' const res = await fetch(`${relayUrl}/keys/${provider}`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-relay-token': token }, body: JSON.stringify({ key: apiKey }), redirect: 'error' }); return res.ok; } ``` ### Technical Analysis The managed integration instructs applications to submit users' OpenAI, Anthropic, Google, Groq, Mistral, OpenRouter, or other provider API credentials to `relay.byokrelay.com`. This behavior is disclosed and is necessary for the advertised managed-relay architecture, but it creates an additional high-value credential custodian between the user and the model provider. The audited project contains only documentation and a version file; it does not contain the managed relay implementation. Consequently, claims concerning AES-256-GCM encryption, key validation, access controls, retention, deletion, and the absence of credential logging cannot be independently verified from this artifact. TLS protects credentials in transit but does not prevent the relay service from accessing credentials during ingestion or provider authentication. This design exceeds the privileges of direct server-side provider integration because an additional operator receives reusable billing credentials. The risk is particularly significant for organization-wide keys or keys without provider-side model, budget, project, or IP restrictions. ### Attack Path 1. An application developer follows ...[truncated 1352 chars]
• Remediation: ## Remediation Suggestions - Default sensitive, regulated, organization-wide, and high-volume deployments to a self-hosted relay or a backend-for-frontend that communicates directly with providers. - Require explicit, informed consent before submission. Clearly identify the relay operator, data destination, credential retention policy, and incident-response process. - Avoid absolute security statements unless they are technically enforced and independently verifiable. - Publish the exact managed-relay source revision, deployment architecture, cryptographic design, and third-party audit results. - Encrypt credentials using a managed KMS or HSM with strict separation between application and key-management permissions. - Ensure credentials and authorization headers are excluded from application, proxy, tracing, analytics, and error logs. - Support provider-scoped, project-scoped, budget-limited, and short-lived credentials where providers allow them. - Provide auditable deletion, token revocation, credential rotation, and breach-notification mechanisms. - Apply strict rate limits and anomaly detection to reduce the financial impact of credential or relay-token abuse.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:91
• Finding: Persistent Bearer Relay Tokens Are Stored in Browser localStorage## Vulnerability Details **File Location**: `SKILL.md`, lines 91-110 **Vulnerability Type**: Script-accessible persistent bearer-token storage **Risk Level**: High ### Evidence ```javascript function relayTokenStorageKey(relayUrl, appId) { const normalizedRelayUrl = new URL(relayUrl).origin; return `byok-relay:relay-token:${normalizedRelayUrl}:${appId}`; } async function getRelayToken(relayUrl, appId) { // Keep bearer tokens scoped to one relay/app. Do not reuse one global // `relay_token` key across products, tenants, or relay URLs. const storageKey = relayTokenStorageKey(relayUrl, appId); const stored = localStorage.getItem(storageKey); if (stored) return stored; // reuse across page loads const res = await fetch(`${relayUrl}/users`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ app_id: appId }), redirect: 'error' }); const { token } = await res.json(); localStorage.setItem(storageKey, token); return token; } ``` ### Technical Analysis The example persists a bearer relay token in `localStorage`. All JavaScript executing under the application's origin can read this storage, including code introduced through cross-site scripting, compromised dependencies, malicious browser extensions with suitable permissions, or compromised third-party scripts. Scoping the storage key by relay origin and application ID reduces accidental token reuse but does not provide confidentiality. The document states that a relay token grants access to all saved keys associated with that token. Although stored provider key material is reportedly not returned, possession of the token can allow an attacker to invoke models using the victim's stored provider credentials and interact with key-management endpoints authorized for that token. The token is also persistent across page reloads, increasing the useful lifetime ...[truncated 1341 chars]
• Remediation: ## Remediation Suggestions - Prefer a backend-for-frontend that stores relay credentials server-side and authenticates browsers with Secure, HttpOnly, SameSite cookies. - If a client-held token is unavoidable, make it short-lived, narrowly scoped, audience-bound, and rapidly renewable. - Separate inference privileges from key rotation, deletion, account erasure, and other administrative capabilities. - Implement token rotation, inactivity expiration, absolute expiration, revocation, and replay monitoring. - Do not place long-lived bearer credentials in `localStorage` or `sessionStorage`. - Enforce a restrictive Content Security Policy and Trusted Types where supported. - Eliminate unsafe inline scripts and event handlers, minimize third-party scripts, and audit frontend dependencies. - Sanitize untrusted content and test the application for DOM-based and reflected XSS. - Notify users of suspicious token use and provide an immediate session-revocation control.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:67
• Finding: Self-Hosting Instructions Execute Unpinned Remote Repository Code and Dependencies## Vulnerability Details **File Location**: `SKILL.md`, lines 67-71 **Vulnerability Type**: Unpinned remote source and dependency installation **Risk Level**: Medium ### Evidence ```bash git clone https://github.com/avikalpg/byok-relay.git cd byok-relay && npm install echo "ENCRYPTION_SECRET=$(openssl rand -hex 32)" > .env echo "ALLOWED_ORIGINS=https://your-app.com" >> .env npm start ``` A second installation path at lines 78-81 similarly clones the repository's mutable default branch before starting the Docker deployment. ### Technical Analysis The instructions clone the repository's mutable default branch without selecting a reviewed release tag or commit. They then run `npm install`, which resolves dependencies and may execute package lifecycle scripts. The effective code and dependency graph can therefore change after this Skill has been reviewed. The audited artifact does not contain the referenced repository source, package manifest, lockfile, container definition, or transitive dependencies. Their integrity and behavior cannot be verified from this package. This is a supply-chain weakness rather than evidence that the named repository is currently malicious. Exploitation requires compromise or malicious modification of the upstream repository, package dependencies, package registry resolution, or installation environment. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or a dependency used by the project. 2. The attacker modifies the mutable default branch or publishes a malicious dependency version. 3. A user follows the Skill and clones the repository without pinning a reviewed revision. 4. The user runs `npm install`. 5. Malicious package code or a lifecycle script executes with the privileges of the installing account. 6. The compromised application can access the relay's environment, encryption secret, stored provider credentials, database, and network tr ...[truncated 683 chars]
• Remediation: ## Remediation Suggestions - Pin installation instructions to a reviewed release tag and immutable commit hash. - Publish signed release artifacts and checksums, and instruct users to verify them before installation. - Commit a dependency lockfile and use `npm ci` rather than unconstrained `npm install`. - Review package lifecycle scripts and consider installation with scripts disabled where compatible. - Use dependency integrity checks, automated vulnerability scanning, provenance attestations, and a software bill of materials. - Pin container images by digest and review Dockerfiles and Compose definitions before deployment. - Run the relay as a dedicated unprivileged account or rootless container with a read-only filesystem and minimal Linux capabilities. - Restrict filesystem, database, secret-store, and outbound network access to the minimum required. - Separate the credential-encryption key from the application host through a managed KMS or HSM where practical. - Document an upgrade process that preserves pinning and requires review before adopting a new upstream revision.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Memory Poisoning: Persistent Context Injection, Context Window Stuffing, Memory Manipulation
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (6)

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/avikalpg/byok-relay.git
cd byok-relay && npm install
echo "ENCRYPTION_SECRET=$(openssl rand -hex 32)" > .env
echo "ALLOWED_ORIGINS=https://your-app.com" >> .env
npm start
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/avikalpg/byok-relay.git
cd byok-relay && npm install
echo "ENCRYPTION_SECRET=$(openssl rand -hex 32)" > .env
echo "ALLOWED_ORIGINS=https://your-app.com" >> .env
npm start
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/avikalpg/byok-relay.git
cd byok-relay && npm install
echo "ENCRYPTION_SECRET=$(openssl rand -hex 32)" > .env
echo "ALLOWED_ORIGINS=https://your-app.com" >> .env
npm start
```

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

- Show "Rotating…" state; confirm success or failure clearly
- Recommended cadence: every 90 days or on any suspected compromise

**Deletion (`DELETE /keys/:provider`):**
- Immediate effect — all in-flight requests using that key will fail
- Prompt the user to confirm before deleting
- After deletion, set UI state to `disconnected` and hide key actions

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

- Prompt the user to confirm before deleting
- After deletion, set UI state to `disconnected` and hide key actions

**Account erasure (`DELETE /users`):**
- Deletes all stored keys and the relay token (GDPR Art. 17)
- Include in account-deletion or data-export flows
- Irreversible — warn the user explicitly

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Context Window Stuffing

Medium

• Category: Memory Poisoning

Content

When integrating byok-relay, always generate a styled API key input component that matches the app's existing design system. This is a required part of the integration — the relay is useless without a UI for users to enter their keys.

**Never prefill the input with a stored key value.** The relay never returns stored key material. If a key is already stored, show a masked placeholder (e.g. `sk-...••••••••`) or a "Key already saved" badge — never the actual key.

**What to generate:**
- A settings panel or modal with a password-type `<input>` for the API key

• Confidence: 85% confidence
• Finding: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Static analysis

No suspicious patterns detected.