Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly transparent about using Beatra for paid image generation, but it asks for and preserves broader account powers than a handover-sign generator needs.
Install only if you are comfortable connecting a Beatra account to this skill with a shared full-scope device token, paid wallet spending authority, registration metadata, and default silent package updates. Consider disabling auto-updates with the documented command and use a Beatra account where the spending balance and generated content exposure are acceptable.
The requested scope includes wallet:spend plus unrelated capabilities such as videos, music, speech, and voice management, which are not justified by a still-image handover-sign skill. If the credential is issued, the package or any component reusing the shared credential could spend funds and access or generate unrelated content far outside user expectations.
The skill references uninstall/disconnect behavior, reading and modifying shared state under ~/.beatra, inventory inspection, token revocation, and deleting configuration files, none of which are implied by a handover-sign generator. Hidden lifecycle-management powers increase the blast radius from simple content generation to local configuration tampering and account disruption.
The skill references uninstall/disconnect behavior, reading and modifying shared state under ~/.beatra, inventory inspection, token revocation, and deleting configuration files, none of which are implied by a handover-sign generator. Hidden lifecycle-management powers increase the blast radius from simple content generation to local configuration tampering and account disruption.
The skill references uninstall/disconnect behavior, reading and modifying shared state under ~/.beatra, inventory inspection, token revocation, and deleting configuration files, none of which are implied by a handover-sign generator. Hidden lifecycle-management powers increase the blast radius from simple content generation to local configuration tampering and account disruption.
Automatic download and installation of package updates is not necessary to generate sign stills, yet the skill states it may silently replace package-owned files. That creates a strong supply-chain risk: compromise of the update channel or signing/verification process could turn a design skill into a code-delivery mechanism on the host.
Referencing a local credential file in the manifest is a strong indicator that the skill relies on user-stored secrets to perform remote authenticated actions. In the context of a sign-generation skill, this is more dangerous because the requested capability is disproportionate to the advertised purpose, increasing the risk of credential misuse, overbroad access, or unexpected account actions if the remote service or skill behavior is abused.
},
"mcp": {
"authentication": "device-bearer",
"credential_file": "~/.beatra/credentials.json",
"name": "beatra",
"transport": "streamable-http",
"url": "https://mcp.beatra.ai/mcp"
The documentation describes an automatic outbound registration call on first use and on multiple environment changes, even though the skill is presented as a local handover-sign generator. That creates undisclosed or unjustified network behavior outside the user’s core task, expanding the trust boundary and enabling metadata exfiltration from environments that may expect offline/local-only processing.
The file states that installation, network route, install source, OS/runtime facts, locale, and timezone data are collected and sent, despite the skill’s stated purpose being generation of handover sign stills. This over-collection is dangerous because it leaks environment and network metadata that can aid profiling, correlation, or targeting, especially in enterprise or restricted environments where such data is sensitive.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
The host follows this computer's network route, described below.
They share the one full-scope Device Token stored in
`~/.beatra/credentials.json`. Installing or switching packages must not trigger
another authorization when that credential is already valid. Do not add,
enable, trust, or configure a host Beatra Connector. Never print or move the
token into command arguments, environment variables, logs, chat, or another
The script is an authorization helper for a narrowly described handover-sign generation skill, yet it provisions a full Beatra account/device authorization workflow and establishes a long-lived shared credential store. That creates capability expansion far beyond the manifest's stated purpose and can grant the package durable access to the user's account context.
The script writes a long-lived bearer access token to a shared device-local credentials.json file for reuse by 'every helper'. Even though file permissions are restricted, storing a reusable high-privilege bearer token in a shared location increases the blast radius if the account, host, or another skill component is compromised.
scope = _required_string(polled, "scope")
if set(scope.split()) != set(SCOPE.split()):
raise RuntimeError("Beatra authorization returned an unsupported scope")
credential_path = state_dir / "credentials.json"
with _SIGNALS.deferred():
_atomic_json(
credential_path,
The self-update subsystem downloads manifests and archives, then replaces and deletes installed files on disk. Even with checksum validation, a skill whose stated purpose is sign creation should not silently carry broad package-management authority, because compromise of the update channel, signing process, or server-side release pipeline would yield code execution persistence on the host.
The client exposes a generic remote MCP tool runner, local file upload, installation registration, and self-update behaviors that go far beyond the declared sign-generation purpose. In a skill context, this materially expands remote capability and data-flow surface, making the package able to invoke arbitrary server-side tools and modify itself even when users would reasonably expect a narrow media/layout utility.
The package explicitly supports self-modification through its update command and related automatic update path. Self-modifying code is dangerous in a narrowly scoped skill because it can alter future behavior, persist malicious changes if the update supply chain is compromised, and bypass the expectation that installed skill code remains static unless separately updated by trusted platform mechanisms.
)
update = subparsers.add_parser(
"update",
help="Check, install, or configure Beatra package self-updates",
)
update.add_argument(
"--check",
The function reads an access token directly from ~/.beatra/credentials.json so the skill can use it for authenticated remote revocation. Direct skill-level access to bearer tokens is dangerous because it violates least privilege: any compromise or modification of the skill grants access to shared account/device credentials unrelated to sign-generation.
def _device_token(state_dir: Path) -> str | None:
path = state_dir / "credentials.json"
try:
value = json.loads(path.read_text(encoding="utf-8"))
except (OSError, ValueError):
The skill invokes a bundled Python client, performs network calls, reads reference files, and supports package updates, but the manifest declares no explicit tool/permission scope. That leaves a much broader effective capability surface than users would expect and prevents least-privilege enforcement by the host.
The manifest frames this skill as a studio for turning provided inscriptions into handover sign stills and matching sign packs. Adding explicit capabilities to query account balances and billing ledger history goes beyond that creative production purpose and exposes financial-account information not obviously required to generate or edit signs.
The manifest presents a sign-generation workflow, yet the runtime includes silent automatic self-updates of the bundled client. Allowing software changes unrelated to the current task violates user expectations and expands the attack surface to supply-chain compromise or unexpected behavior changes.
Although auto-update is mentioned later in the document, the skill does not provide upfront warning before normal use that invoking the bundled client may trigger software changes without separate confirmation. This weak disclosure increases the chance users unknowingly authorize code changes while expecting only image generation.