Nanobot Plugins — Security Guide

Nanobot plugins connect to external APIs. If they disable TLS verification, your data travels in plaintext.

Nanobot’s plugin model is built around connectivity: plugins are the bridge between the AI agent and external services, APIs, and data sources. That connectivity is what makes them useful and what makes them dangerous. A plugin that disables TLS certificate verification — one line of code, often added to “fix a dev environment issue” that never gets reverted — means every connection the plugin makes can be intercepted. API keys sent in request headers. User data in response bodies. Tool outputs that flow back to the agent. All of it is readable by anyone on the network path.

The filesystem access side of Nanobot’s plugin model adds a second attack surface. Plugins can request write access to arbitrary paths. A plugin that writes to /etc/, ~/.ssh/, or system init directories has achieved host persistence — the ability to survive reboots, re-installs, and even explicit removal of the plugin itself. This is not a theoretical risk: Firmis detects this pattern in production plugin code.

Firmis scans Nanobot plugin manifests, handler code, and configuration files across 209 detection rules covering TLS misconfiguration, filesystem abuse, credential exposure, tool poisoning, and supply chain attacks in plugin dependencies.

What Firmis detects

Threat Category	Rules	Coverage	Example Finding
Tool Poisoning	10	High	Instruction override text in tool description
Insecure Config	3	High	`rejectUnauthorized: false` disabling TLS validation
Secret Detection	60	High	Hardcoded API key in `nanobot.yaml`
Data Exfiltration	12	Medium	File system read followed by external HTTP POST
File System Abuse	10	Medium	Write access to sensitive directories (`/etc`, `~/.ssh`)
Prompt Injection	13	Medium	Role manipulation in plugin description
Supply Chain	8	Medium	Known malicious package in plugin dependencies
Access Control	3	Medium	Authentication bypass flag in plugin settings
Agent Memory Poisoning	7	Medium	Code writing to agent configuration directories

Files Firmis scans

File Pattern	What It Contains
`nanobot.yaml`	Plugin configuration, capabilities, and settings
`nanobot-config.json`	Alternative JSON config format
`src/*/.ts`, `src/*/.js`	Plugin handler code
`*/.py`	Python-based plugin implementations
`package.json`, `requirements.txt`	Plugin dependency declarations

Scan Nanobot Plugins

npx firmis scan --platform nanobot

Common findings and remediation

Insecure TLS configuration

CRITICAL  ic-002  SSL/TLS Verification Disabled
          src/http-client.ts:12
          Pattern: rejectUnauthorized: false

What it means. The plugin’s HTTP client has TLS certificate verification disabled. This single setting turns every HTTPS connection the plugin makes into an unencrypted channel from a security standpoint: a man-in-the-middle attacker who can intercept the traffic — on a shared network, a compromised router, or a malicious DNS resolver — can read every byte in both directions.

That includes API keys in request headers. User data in request bodies. Tool outputs and agent responses flowing back through the connection. And because this is a plugin connecting the agent to external services, the scope of what travels through this channel is everything the plugin does.

This configuration is almost always introduced as a quick fix for a self-signed certificate issue in a development environment. The fix works, the developer moves on, and the setting ships to production.

How to fix. Remove rejectUnauthorized: false immediately. If the plugin connects to a server using a self-signed certificate, provide the CA certificate explicitly via the ca option — tls.connect({ ca: fs.readFileSync('ca.pem') }) — rather than disabling verification entirely. If the certificate is from a legitimate CA and verification is failing, diagnose the actual cause (expired cert, hostname mismatch, missing intermediate) and fix it properly. Never disable certificate verification in any code that could reach production.

Hardcoded credentials in nanobot.yaml

HIGH  ic-003  Default or Hardcoded Credentials in Config Files
      nanobot.yaml:6
      Pattern: api_key: "nbt-..."

What it means. An API key is hardcoded in the plugin’s YAML configuration. YAML config files are routinely committed to version control and shared between team members. Once a credential appears in git history, it cannot be fully removed without rewriting the entire history — and even a rewritten history may have been cloned by other contributors before the rewrite. Nanobot plugins often connect to data-sensitive external services, making exposed credentials high-value targets with a long exploitation window.

How to fix. Remove the hardcoded value and rotate the credential immediately. Reference secrets at runtime via environment variables (process.env.NANOBOT_API_KEY) or a secrets manager. Use .env files for local development and exclude them from version control. Add secret scanning to your CI pipeline so this cannot recur silently.

File system write to sensitive directory

CRITICAL  po-005  Agent Filesystem Write to Sensitive Directories
          src/config-writer.ts:28
          Pattern: writeFileSync('/etc/...')

What it means. The plugin writes to a sensitive system directory — /etc/, /root/, or ~/.ssh/. Writing to these locations is a host persistence technique. A plugin that appends to /etc/cron.d/ survives reboots. A plugin that writes to ~/.ssh/authorized_keys maintains remote access after it is uninstalled. A plugin that modifies /etc/hosts can redirect DNS queries for any domain on the system.

These are not write operations that any legitimate Nanobot plugin needs. The presence of this pattern is a strong signal of either a compromised plugin or a plugin written without any security consideration — both of which warrant the same response: do not run it.

How to fix. Plugins must not write to system directories under any circumstances. Confine all filesystem write operations to the plugin’s own data directory — ~/.nanobot/data/ or a user-specified application path. Implement a path allowlist and validate every write path against it before performing any write operation. Reject any plugin requesting filesystem access to paths outside the application’s own directory tree.