other
- Location
SKILL.md:32- Finding
Upstream API Credential Disclosure to a Third-Party Relay
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:32-68
Vulnerability Type: Disclosure of reusable upstream credentials to a third-party service
Risk Level: MediumVulnerable Code
bash curl -X POST https://a2a-hub.fly.dev/agents/register \ -H "Content-Type: application/json" \ -d '{ "agentCard": { "name": "Agent Name", "description": "What this agent does", "url": "https://agent-endpoint.example.com", "version": "1.0", "supportedInterfaces": [{"type": "INTERFACE_DEFAULT"}], "capabilities": {"streaming": false}, "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"], "skills": [{ "id": "skill-id", "name": "Skill Name", "description": "What this skill does", "tags": ["tag1", "tag2"] }] }, "urlFormat": "openai", "upstreamApiKey": "sk-your-agents-api-key", "model": "gpt-4" }'The associated documentation states:
text upstreamApiKey (optional): API key sent as Authorization: Bearer [key] to the agent's upstream endpoint.Technical Analysis
The registration example encourages users to submit a reusable upstream API key to the externally operated public relay at
a2a-hub.fly.dev. For authenticated proxying to work, the relay must receive and subsequently process or retain this credential.This creates a significant third-party trust boundary. Anyone with access to the relay's application, logs, database, backups, administrative interfaces, or runtime environment could potentially recover and misuse the credential. The documentation does not describe encryption at rest, log redaction, credential retention, operator-access restrictions, or deletion guarantees.
Supplying this credential is optional and is not required for registration, registry searches, or communication with upstream agents that support another authent ...[truncated 1931 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove
upstreamApiKeyfrom the default registration example and present unauthenticated or separately brokered upstream access as the default. - Add a prominent warning that any supplied key is disclosed to and entrusted to the third-party hub.
- Require a dedicated credential created only for this relay rather than a general-purpose provider or account key.
- Scope the credential to the minimum endpoint, model, operations, and resource limits required.
- Use short-lived credentials where supported and document rotation and immediate revocation procedures.
- Apply strict rate limits, spending limits, and network restrictions to the upstream credential.
- Document the relay's encryption-at-rest, log-redaction, retention, backup, operator-access, and deletion controls.
- Prefer a design based on short-lived signed requests, delegated tokens, mutual TLS, or another mechanism that does not require the relay to retain a reusable upstream secret.
- Ensure PATCH operations that clear
upstreamApiKeyalso securely delete the credential from active storage, logs, caches, and backups according to a documented retention policy.
- Remove
