Clawdbot exposure shows how insecure AI assistants leak credentials

At a glance

What this is: Intruder says Clawdbot deployments are being exposed through misconfiguration, prompt injection and unsafe plugin handling, creating credential leakage and unauthorized actions.

Why it matters: IAM, PAM and AI security teams need to treat self-hosted assistants as identity-bearing systems because exposed secrets and delegated integrations can turn them into live compromise paths.

Context

AI assistants that can read messages, call external services and execute tasks create a governance problem, not just a model-risk problem. When they are deployed without enforced validation, guardrails or sandboxing, the assistant becomes a place where credentials, integrations and delegated actions can be exposed at the same time. Clawdbot’s exposure shows how quickly that boundary collapses when secure-by-default controls are absent.

The article describes a mixed risk pattern spanning cloud misconfiguration, prompt injection, malicious plugin distribution and unauthorised actions. That combination matters to identity teams because the assistant is acting through secrets, tokens and connected service accounts, which means NHI governance and AI governance now overlap in the same deployment boundary.

Key questions

Q: What breaks when an AI assistant is deployed without guardrails?

A: The assistant can turn untrusted prompts into unauthorized actions, data leakage and unsafe tool calls because there is no policy layer separating input from execution. In practice, the failure is not only model behaviour. It is delegated access without containment, which means connected accounts and secrets become part of the attack surface.

Q: Why do exposed credentials make self-hosted AI assistants so risky?

A: Because the assistant often runs in the same environment that stores or uses the secret, an exposed token can unlock connected accounts immediately. Once attackers obtain that token, they inherit whatever access the assistant had, which can include mail, cloud, social, or internal systems. The issue is blast radius, not just secret hygiene.

Q: What are the signs that an assistant has been compromised through prompt injection?

A: Look for unexplained posts, messages, data exports, tool calls or account activity that the operator did not request. The strongest indicator is behaviour that aligns with an external prompt rather than the user’s intent, especially when the assistant interacts with public channels or untrusted content sources.

Q: How should teams govern third-party AI skills and plugins?

A: Treat them as privileged dependencies with explicit permission review, provenance checks, and narrow scope. The question is not only whether the extension works, but what it can read, invoke, or persist once installed. If the answer is unclear, the dependency is too trusted for production use.

Technical breakdown

Exposed credentials in self-hosted assistant deployments

Self-hosted AI assistants often rely on cloud instances, configuration files and connected service tokens to operate. When those assets are left publicly accessible, the exposure is not limited to the assistant itself: API keys, authentication tokens and environment files can be harvested and reused outside the platform boundary. The technical weakness is usually not sophisticated exploitation but a failure to enforce basic instance hardening, secret storage discipline and access restriction around the deployment surface. Once a credential is visible, the assistant becomes a pivot point into whatever services that secret can reach.

Practical implication: Treat assistant deployments as credential-bearing systems and remove any public exposure path before the first integration goes live.

Prompt injection through connected channels and replies

Prompt injection occurs when untrusted external content is crafted to manipulate an assistant into disclosing data or taking an action it should not take. In this case, the risk increases when the assistant is connected to channels such as social platforms or messaging systems, because attacker-controlled text becomes input to the decision layer. Without guardrails, the model can be induced to reveal private content, post on behalf of the user or call tools outside intended scope. The issue is architectural: the assistant is being asked to decide inside a trust boundary that was never enforced.

Practical implication: Separate untrusted input from tool execution and require policy checks before the assistant can act on external content.

Malicious skills and plugin supply chain risk

Community-distributed skills or plugins extend assistant capability, but they also extend trust. If unverified extensions can scrape content, harvest credentials or recruit other systems into a botnet, then the assistant’s supply chain becomes part of the threat surface. The problem is not only code quality but the absence of sandboxing, signing, allow-listing and behavioural inspection before installation. In practical terms, each plugin inherits the assistant’s access context unless the platform explicitly isolates it, which makes extension governance a core control rather than an optional enhancement.

Practical implication: Require verified extension sources and isolate plugin execution from the assistant’s primary credentials and data paths.

Threat narrative

Attacker objective: The attacker wants to turn the assistant’s delegated access into data theft, unauthorized actions and persistence across connected services.

1. Entry occurs through misconfigured cloud instances or connected services that expose API keys, authentication tokens or configuration files to public access.
2. Credential abuse follows when attackers use those exposed secrets to access assistant-connected services, social accounts or internal data sources.
3. Impact appears as private data leakage, unauthorized posting, exfiltration of email content and execution of commands beyond user intent.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Clawdbot-style assistants create a new identity plane that security teams are still governing too loosely. These systems do not behave like ordinary applications because they can read, decide and act through delegated integrations. That means the real control problem is no longer only model safety, but who or what is allowed to authorize the assistant’s actions. Practitioners should treat assistant identity, connected service identity and plugin trust as one governance surface.

Prompt injection is a control failure, not just a content problem. The exploit works because the assistant is allowed to turn untrusted text into tool use or disclosure without sufficient policy gating. That makes the issue structurally similar to broken authorization in other systems: the model is being trusted to decide inside a boundary that has not been enforced. Practitioners should move validation and approval earlier in the execution path.

Malicious skills are the agentic equivalent of untrusted third-party code running with inherited access. Once a plugin can scrape, exfiltrate or trigger downstream actions, the assistant’s effective privilege model expands beyond what the operator intended. This is exactly where governance debt accumulates: inventory, provenance, sandboxing and revocation are all needed before extensions can be treated as safe. Practitioners should assume every skill is a potential access path until proven otherwise.

Insecure-by-default deployment choices are now the decisive failure mode. The article’s core lesson is not that AI assistants are inherently unsafe, but that ease of deployment can outrun control design. When security friction is absent, organisations create a live path from public exposure to credential compromise in a single setup flow. Practitioners should re-evaluate whether any self-hosted assistant can be placed in production without mandatory guardrails.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity governance now has to cover the assistant itself, not just the services it touches. A self-hosted AI assistant that can read messages, call APIs and execute actions behaves like a delegated identity with broad reach. That makes secret handling, approval boundaries and revocation paths as important as model prompts. Practitioners should expect assistant deployments to appear in NHI inventories and access reviews, not just in AI governance registers.

Prompt injection exposes a verification trust gap. The assistant is asked to decide which instructions are legitimate, but the source content shows that external text can be used to manipulate that decision path. That means the control point is issuance and execution time, not only output filtering. Practitioners should design for untrusted input at every integration boundary, especially where tools can move data or trigger actions.

For practitioners

• Harden assistant deployments before integration Disable public exposure, enforce firewall allow-lists and block access to configuration files, secrets stores and admin endpoints before connecting any service accounts.
• Revoke and rotate exposed secrets Assume any API key, token or password stored near the deployment may already be exposed and rotate it immediately across email, social and internal service integrations.
• Sandbox untrusted skills and plugins Install only verified extensions, isolate them from the assistant’s primary credentials and inspect execution logs for scraping, exfiltration or botnet behaviour.
• Gate tool use with policy checks Require policy evaluation before the assistant can post, send messages or access sensitive data so prompt injection cannot directly trigger tool execution.
• Monitor connected accounts for anomalous actions Review API activity, mail sends, social posts and admin changes from all connected accounts to identify unauthorized actions that indicate compromise.

Key takeaways

• Clawdbot exposure shows that insecure assistant deployment can turn public misconfiguration into credential theft and unauthorized action paths.
• The core failure is not just model misuse. It is delegated access without enforced guardrails, sandboxing or secret hygiene.
• Teams should govern assistants like identity-bearing systems and apply access, isolation and revocation controls before production rollout.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Agentic SOC Skill: A task-focused AI workflow that can choose actions, use tools, and produce operational outputs inside a security operations process. Unlike a fixed automation rule, it may adapt its path based on data and context, which makes scope, provenance, and approval controls essential.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners connect identity controls to the broader systems that now depend on delegated access and automated actions.