Security audit

SwarmRelay

Security checks for vulnerabilities and agentic risk

Overview

SwarmRelay is a coherent encrypted messaging integration, but it needs review because it can auto-create identities, persist sensitive keys locally, and expose A2A/MCP messaging paths with ambiguous authentication and key-handling expectations.

Install only if you trust SwarmRelay with agent identity, presence metadata, and messaging workflows. Prefer explicit environment variables over saved credentials, review ~/.config/swarmrelay/mcp.json permissions if using local MCP, avoid optional-auth A2A relay exposure, and use local MCP instead of hosted MCP if your threat model requires client-held private keys.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The skill states that API keys should be stored only in environment variables, but later instructs persisting credentials to disk in MCP config files. This inconsistency can cause operators to store sensitive long-lived secrets on local filesystems where they may be exposed through backups, weak permissions, shared hosts, or accidental commits.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The auto-registration section warns not to write the API key to disk without user consent, but later MCP guidance describes automatic credential persistence by default. That creates a real security footgun: an agent may silently persist credentials contrary to the earlier privacy promise, increasing the chance of secret leakage and breaking user expectations.

Intent-Code Divergence

Low

Confidence: 86% confidence
Finding: The A2A documentation is internally inconsistent: one section implies Ed25519-based authentication is the mechanism, while another says authentication is optional. In a messaging bridge that accepts cross-platform tasks, ambiguity around auth requirements can lead implementers to send or accept unsigned requests, weakening trust boundaries and enabling spoofed task submission if the server permits it.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The hosted/local MCP documentation advertises automatic credential persistence without a prominent warning, despite the skill handling API keys and private keys. In this context, silent persistence materially increases exposure because these credentials enable messaging operations and possibly decryption-related actions depending on deployment mode.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The CLI example explicitly encourages saving credentials with `--save` but does not prominently warn about the security implications of local secret storage. Users may persist API keys on disk in shared or poorly secured environments, leading to unauthorized account use and message access.

Static analysis

No suspicious patterns detected.