From Shadow IT to Shadow AI: Clawdbot (Moltbot/Openclaw) and the Rise of Unmanaged Agent Gateways

The New Frontier of Shadow IT: Unmanaged AI Agent

From “Shadow IT” to “Shadow AI”

The cybersecurity landscape of 2026 has been altered by the democratization of “Agentic AI.” We are witnessing a paradigm shift from centralized, cloud-native chatbots to decentralized agents running on the network edge (like Mac Minis, Edge Servers).

Unlike traditional data leaks where internal data leaves the perimeter to a foreign server, here the perimeter itself dissolves. Users are turning their personal devices into always on servers that hold API keys to every connected service (Gmail, Slack, GitHub) and exposing them to the internet via unhardened gateways.

Analyst Note

During our research for this report, the tool formerly known as Clawdbot officially rebranded to Moltbot. This change was initiated following a trademark request from Anthropic, which noted the similarity between “Clawd” and their “Claude” model. The project has transitioned to the new handle @moltbot, and while the founder reported some initial issues with handle-squatting during the move, the core functionality of the tool remains unchanged.

Why Developers are Deploying Unsecured LLM Wrappers

The adoption of tools like Clawdbot is driven by “Adoption Velocity” rather than security. Developers seek the utility of a “JARVIS-like” experience, an assistant that proactively checks emails and manages files.

However, unlike a standard application, an AI Agent requires extensive permissions: read/write access to the file system (‘fs‘), shell execution (‘exec‘), and network access. When deployed on consumer hardware without enterprise governance, these tools create a decentralized, unhardened attack surface of unprecedented value.

Case Study: Anatomy of a Leak (Clawdbot)

The “Insecure by Default” Trap (Port 18789/3000)

Our analysis of the Clawdbot architecture reveals a critical systemic failure. By default, the Clawdbot gateway listens on port 18789 (while predecessors like Flowise used 3000). While the documentation suggests binding to ’127.0.0.1’, the functional pressure to access these assistants remotely leads users to bind the gateway to ’0.0.0.0’ or misconfigure reverse proxies.

Recent independent public reports observed a four-digit exposure scale exposed to the public internet within days of the tool’s viral release. These are not just web servers; they are remote command consoles.

OSINT Discovery Methodology: Measuring Internet Exposure

To avoid turning this case study into a step-by-step reconnaissance guide, we describe our discovery process at a methodological level and disclose only aggregated statistics.

We performed a point-in-time measurement using two independent, internet-scale scanning datasets to estimate how many Clawdbot gateway interfaces were publicly reachable. Rather than relying on a single identifier, we used a layered fingerprinting approach:

(i) a broad UI identifier (page title),

(ii) one or more structural HTML anchors unique to the UI,

and (iii) validation using the default gateway port.

Analyst Note

Responsible disclosure in reporting:  This section intentionally omits copy-pasteable search queries and does not enumerate targets. The purpose is to illustrate a repeatable defensive measurement pattern (asset inventory and exposure reduction), not to provide operational guidance for abuse.

Point-in-TimeExposure Snapshot

At 2026-01-27 (13:00, UTC+3), our measurement yielded the following results:

• Broad UI fingerprint: 634 reachable instances.

• Tightened fingerprint (UI + structural anchors + default port): 611 reachable

instances.

• Cross-validation dataset: 530 reachable instances.

Interpretation

The difference between the broad UI fingerprint and the tightened signature suggests that not every exposed instance is trivially classifiable using a single trait. Some deployments may be proxied, hosted behind non-default ports, or partially match the UI fingerprint. For defenders, the tightened signature is typically more actionable for remediation prioritization because it reduces noise and focuses on likely genuine gateways.

Best Practice/Analyst Advice

Analyst Tip — Reporting without over-disclosing: When publishing exposure research, prefer aggregated counts, explain the fingerprint categories (title, structural anchor, default port), and avoid publishing exact query strings or target lists. This preserves the core security lesson while reducing operational value for attackers.

No Auth, No Problem: How Easy is Access?

The critical vulnerability lies in the “Localhost Fallacy.” To reduce friction for local development, Clawdbot often auto-approves requests that appear to originate from localhost.

When a user deploys a simple Nginx or Caddy proxy to access their agent from the office, they often fail to configure ‘X-Forwarded-For‘ header validation. The Gateway sees the request coming from the local proxy IP and bypasses authentication completely. This allows an external attacker to gain full administrative control over the agent without a single exploit, simply by navigating to the URL.

What’s at Risk? Observations from the Wild

The “Prompt History” Nightmare: PII and Corporate Secrets

What makes agent gateways uniquely dangerous is that the attack surface is not limited to a traditional admin panel. These systems aggregate high context operational data (project details, errors, access patterns) and store it persistently. In Clawdbot deployments observed in the wild, this persistence can manifest as plaintext memory artifacts (e.g., MEMORY.md) and local state databases (e.g., SQLite) under the user’s home directory (e.g., ~/.clawdbot/memory/). In other words, a compromise yields a “cognitive dossier” rather than a single session transcript.

Observed data categories.

Based on field observations and platform behavior, the leaked or exposed dataset can include:

• Operational context: error logs, local paths, project names, and troubleshooting notes that reveal internal architecture.
• Social graph signals:       who the operator interacts with (tools,      channels, repositories), and which systems are “trusted”.
• Credential-adjacent material: configuration artifacts and integration tokens that enable follow-on access.

Analyst Note

Why this matters: A persistent agent memory enables contextual abuse. Even without “exploiting” the host, an attacker who gains read access to memory artifacts can craft highly tailored social engineering and lateral movement attempts.

Storage Model: Plaintext Memory + Local Databases

Clawdbot data persistence typically blends human-readable files (for memory) with structured state (for sessions). The defensive implication is straightforward: any exposure of the gateway UI or its backing store can become an exposure of the operator’s full workflow history. This includes both plaintext artifacts (e.g., MEMORY.md) and local databases (e.g., .sqlite).

3.2.1. API-like session surfaces (conceptual).

The platform’s session tooling concepts (e.g., session_history, session_list) reflect a common pattern: a control UI that can enumerate sessions and retrieve historical context. In misconfigured deployments, these surfaces may become reachable without the intended trust boundary.

Best Practice/Analyst Advice

Analyst Tip — What to treat as “sensitive data”: Any artifact that contains (i) long-lived chat history, (ii) provider keys, (iii) integration tokens, or (iv) file paths and internal identifiers should be treated as sensitive and handled like credentials.

The Financial Impact: Stolen LLM Provider Keys

The most immediate impact is financial loss.        Agent gateways commonly store third-party LLM provider credentials (e.g., OpenAI/Anthropic) in plaintext configuration

artifacts (such as .env, config.json, or service-specific credential files). Once harvested, these keys can be abused for high-volume inference workloads and resold in underground ecosystems.

Network Indicators and Detection Pivots (Defensive)

To support defensive inventory and monitoring, we summarize practical indicators and pivots observed during the case study. These indicators can be used for internal asset discovery, exposure validation, and detection engineering in authorized environments.

Indicator	Value	Defensive Use
Default port	18789	Exposure validation and inventory prioritization for agent gateways.
Alternate ports	18790, 18800	Secondary validation for related services/dev modes (verify per environment).
mDNS service	_clawdbot-gw._tcp.local	LAN discovery signal; useful for internal scanning and endpoint hygiene.
Service name	clawdbot-gw	Local service identification in internal discovery workflows.
UI anchors	clawdbot-app,  CLAWD BOT_CONTROL_UI_BASE_P ATH	Higher-confidence structural markers for classification and false-positive reduction.
Favicon hash	-805544463	Clustering pivot for internet-scale exposure measurement (use with care in reporting).

Table 1: Defensive indicators and pivots derived from case study observations.

Real-World Attack Scenarios

Scenario 1: The “Free LLM” Abuse (Quota Theft)

Vector: Automated scanning for port 18789.

Attack: An attacker identifies an unauthenticated Clawdbot instance. They query the ’/api/config’ endpoint to retrieve the ’OPENAI_API_KEY’.

Outcome: The key is added to a rotation pool for a spam botnet. The victim’s credit card is charged thousands of dollars for token usage before the breach is discovered.

Scenario 2: Lateral Movement via Integration Tokens

Vector: Supply Chain Poisoning via “ClawdHub.”

Attack: Based on the “Eating Lobster Souls” research, an attacker uploads a malicious skill (e.g., “Stock Market Analyzer”) to the skill registry. The victim installs it.

Outcome: The skill executes with the agent’s privileges. It accesses the user’s connected Slack and GitHub tokens, allowing the attacker to pivot from the personal Mac Mini into the corporate code repository and internal communication channels.

Immediate Remediation: Securing Your AI Stack

Quick Fix: Network Segmentation & Reverse Proxies

For organizations and individuals running edge agents,       “defense-in-depth” is mandatory:

• Bind to loopback by default: Ensure the gateway listens on 127.0.0.1 unless there is a justified, controlled access requirement.
• Eliminate direct internet exposure: Do not expose agent gateways via public port-forwarding. Prefer authenticated overlay access (e.g., corporate VPN, device posture-aware tunnels).
• Reverse proxy hardening (fail-closed): If a proxy is required, explicitly define trusted proxy boundaries and validate forwarded client IP headers. Avoid any authentication logic that implicitly trusts “local” traffic unless the trust chain is cryptographically or network-wise enforced.

Best Practice/Analyst Advice

Practical rule: Treat agent gateways like remote administration consoles. If you would not expose an SSH jump host without MFA and strict allow-listing, do not expose an agent gateway.

Secrets Hygiene: Reduce the Blast Radius

• Move secrets out of plaintext where possible: use OS keychains, secret managers, or environment injection at runtime; avoid committing or copying .env style files across systems.
• Rotate aggressively after exposure risk: if a gateway was ever reachable from untrusted networks, assume compromise and rotate LLM provider keys and integration tokens.
• Apply least privilege to integrations: Slack/GitHub/Gmail-like tokens should be scoped minimally (read-only where feasible), and separated per environment (personal vs. corporate).

Local Network Hygiene: Discovery Signals and mDNS

Edge agents are commonly deployed on consumer hardware within home or small office networks. Local discovery mechanisms (e.g., mDNS service advertisements) can unintentionally increase visibility to nearby adversaries or compromised hosts inside the same LAN. Defensive steps:

• Inventory discovery broadcasts: identify whether the gateway advertises services on the LAN (mDNS/Bonjour) and disable or segment if unnecessary.
• Segment “lab” devices: place edge devices (Mac Minis, homelabs) in isolated VLANs with controlled egress.

Strategic Fix: Governance and Monitoring

• Container isolation: run agents inside containers or constrained sandboxes to limit filesystem and process access on the host.
• Supply chain auditing: treat “skills” and plugins as untrusted code. Review sources and pin versions; monitor for anomalous outbound connections and unexpected tool executions.
• Observability: log access attempts, administrative actions, and token usage. Alert on sudden spikes in LLM consumption and on access from unusual networks.

Conclusion: The Need for AI Observability

The emergence of unmanaged AI agents represents a new phase of Shadow IT, where personal productivity tools quietly become high-privilege infrastructure. The Clawdbot exposure shows how easily these deployments can turn into externally reachable control planes containing credentials, operational memory, and integration access.

Unlike traditional data leaks, such exposures compromise workflow context and decision history, enabling financial abuse, lateral movement, and targeted social engineering as natural follow-on effects.

For this reason, visibility remains the primary control gap. AI agents running on edge devices must be inventoried, monitored, and governed as first-class assets. Without this shift, Shadow AI will persist as a silent and highly attractive attack surface.