Skill Kannaka Radio
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This instruction-only radio operator skill is mostly coherent, but it documents live broadcast/social controls and sensitive token use without enough scoping or approval guidance.
Use this skill only if you are an authorized Kannaka Radio operator. Before running any command, verify the local CLI/server/scripts, configure least-privilege tokens, and require explicit confirmation before toggling DJ voice, restarting services, broadcasting audio, or posting to social channels.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run in the wrong context, an agent could toggle broadcast features or trigger public-facing output on the station without the user realizing the operational impact.
The skill documents commands and flows that can alter a live broadcast and fan out to public social channels, but it does not state what authentication, user confirmation, or safety checks are required.
curl -X POST https://radio.ninja-portal.com/api/dj-voice/toggle ... synthesized speech broadcast to Icecast + social fan-out (Bluesky / Mastodon / Telegram / Nostr)
Only allow these operations after explicit user confirmation, document the required operator authentication, and add previews or dry-run behavior before public broadcast or social-posting actions.
Using the skill may require tokens that can publish to a service or incur provider usage charges.
The skill expects sensitive provider or publish credentials for its integrations. This is purpose-aligned, but those credentials are not declared in the registry requirements.
`FLUX_TOKEN` Flux Universe publish token ... `ELEVENLABS_API_KEY`, `REPLICATE_API_TOKEN` Voice DJ + AI music.
Use least-privilege tokens, keep them out of chat/log output, and ensure the skill metadata clearly declares any required or optional credentials.
A user following the runbook would rely on local or external code whose behavior was not inspected in this artifact set.
The submitted package contains only SKILL.md, so the referenced CLI, backend, and scripts were not available for review.
Architecture: 13-module backend in `server/` ... Entry point: `node server/index.js` ... node scripts/post-track-announce.js
Verify the source and contents of the Kannaka CLI, Node server, and scripts before running them, and pin trusted versions where possible.
Radio state, perception data, or listener/broadcast events may be shared across services or peers if those integrations are enabled.
The skill describes NATS, Flux, and WebRTC communication paths, but does not describe identity, authentication, or data-boundary controls for those channels.
`nats-client.js` | swarm NATS client (raw TCP, NATS 2.12.5) ... Flux Universe publish to `pure-jade/radio-now-playing` ... WebRTC peer-to-peer broadcasting
Confirm NATS, Flux, and WebRTC endpoints are authenticated and scoped to the intended peers before enabling the integrations.
Broadcast or track metadata could affect what memories or context are surfaced to other parts of the system.
Track-change events can influence memory retrieval through the attention/memory bridge. This is part of the described design, but the artifact does not explain retention, filtering, or trust boundaries for reused memories.
NATS publish to `KANNAKA.attention.ear` so attention beam pulls in memories thematically related to the track.
Document what memory stores are accessed, how retrieved memories are filtered, and whether radio-triggered context is reused outside the radio task.
