Clawdbot shadow AI exposes a new enterprise identity risk

At a glance

What this is: This analysis says Clawdbot has become a shadow AI risk because exposed instances, plaintext credentials and broad app permissions can turn an unmanaged assistant into a high-impact access path.

Why it matters: IAM, PAM and NHI teams need to treat employee-deployed AI agents as governed identities because their permissions, persistence and internet exposure can bypass standard oversight.

By the numbers:

• Token Security found that 22% of its customers have employees actively using Clawdbot within their organisations.

Context

Clawdbot is an open-source AI assistant that runs on personal devices and connects to workplace systems such as Slack, email, documents and calendars. In identity terms, that makes it more than a productivity app because it becomes a runtime access layer with its own credential exposure, permission scope and audit gap.

The governance problem is that this agent operates outside normal enterprise controls while still acting on behalf of a user. Once an assistant can read, summarise and execute across corporate data sources, existing IAM assumptions about visibility, logging and user-mediated approval start to break down.

Token Security's article treats the spread of Clawdbot as a shadow AI pattern rather than a one-off tool issue, and that is the right frame for practitioners. The operational question is no longer whether employees can install it, but whether the enterprise can govern the access it inherits and amplifies.

Key questions

Q: What breaks when employees use shadow AI for work tasks?

A: Shadow AI breaks identity visibility and lifecycle control. Employees can create or use AI accounts, connect them to work data, and move sensitive information outside approved governance. That leaves security teams unable to reliably inventory the identity, review its access, or revoke delegated permissions when the business need ends.

Q: Why do consumer AI assistants create more risk than enterprise-tied AI tools in workplace use?

A: Consumer AI assistants can sit outside the enterprise boundary, may use conversations to improve the service, and may allow human review of selected content. That means employees can expose regulated or confidential data simply by pasting it into a personal tab. Enterprise-tied tools reduce that exposure, but they still require governance over what users can access and submit.

Q: How can security teams tell whether an AI assistant has crossed from analysis into operational control?

A: Look for any path where the assistant can create, schedule or execute a remediation step rather than only describe one. If it can generate a script, open a ticket or notify stakeholders, the interface has become part of the control plane. That boundary should be explicit in policy and logging.

Q: What should teams do if they discover shadow AI in the business?

A: Teams should first identify who owns the tool, what data it touches, and which identities it uses. Then they should either bring it under policy and lifecycle control or remove access to enterprise data until governance is in place. Discovery without containment simply confirms the scale of the gap.

Technical breakdown

Why shadow AI agents become identity problems

Shadow AI becomes an identity issue when a user-installed assistant inherits the user’s enterprise permissions and then acts across email, chat, storage and browser sessions. The identity subject is no longer just the human user but the agent operating on their behalf with persistent access, local credentials and the ability to initiate actions. That changes the control boundary: access is no longer limited to a login event or a browser tab. It becomes a delegated runtime identity problem with unclear ownership, weak logging and no central policy choke point.

Practical implication: Map employee-installed AI assistants to the identities and permissions they inherit, not just to the device they run on.

Exposed control servers and plaintext secrets

When an AI assistant exposes an admin or control interface to the internet, the interface becomes a direct credential access path. In this case, Token Security describes exposed gateways that could reveal API keys, OAuth tokens and conversation histories, while plaintext storage under local directories makes those secrets readable by any process running as the user. The failure mode is not only leakage but immediate downstream abuse, because the same token set can unlock connected SaaS, messaging and storage systems. That is classic non-human identity exposure with a wider blast radius than a single account compromise.

Practical implication: Treat exposed agent gateways and local secret stores as revocation events, not just configuration findings.

Persistent memory and shell access change the trust model

An assistant with persistent memory and shell access is not equivalent to a stateless chatbot. Persistent memory means context survives sessions, so the agent can accumulate instructions, preferences and sensitive outputs over time. Shell access adds execution capability, which means prompt injection or malicious instruction can move from information retrieval into command execution. This is where the trust model breaks: the system is no longer just answering questions, it is executing within a user’s operating context. For identity governance, that creates an approval problem because the runtime actor can combine permissions dynamically.

Practical implication: Separate information access from execution rights so agent memory and command capability are not governed as if they were the same control.

Threat narrative

Attacker objective: The attacker wants to turn an employee-run AI assistant into a reusable access path for corporate credentials, internal data and execution control.

1. Entry occurs when employees install the assistant on unmanaged personal devices and connect it to corporate services such as Slack, Teams, email and cloud storage.
2. Credential access follows when exposed gateways or plaintext local files reveal API keys, OAuth tokens and session history that can be reused against connected systems.
3. Escalation happens when those permissions let the assistant read confidential data, reach internal channels and execute commands or scripts with the user’s access.
4. Impact is the loss of visibility and control over corporate data flows, with potential remote code execution and uncontrolled disclosure through consumer messaging apps.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now an identity governance problem, not a usage-policy problem. When employees deploy an assistant that can read mail, query Slack and execute commands, the real issue is delegated access scope, not software novelty. Conventional IAM programmes usually govern sanctioned apps and known service accounts, but shadow AI introduces unmanaged runtime identities that still act on enterprise data. The practitioner conclusion is that discovery must be tied to identity ownership and access scope, not app inventory alone.

Persistent access plus local secrets creates identity blast radius. The article shows how an exposed agent can reveal API keys, OAuth tokens and conversation histories, which means compromise is not limited to the assistant itself. The broader governance failure is that secrets stored locally and reused across connected services create a chained trust problem. Once one agent context is exposed, downstream SaaS, chat and storage permissions can all fall within reach. Practitioners should treat this as a blast-radius control issue across the delegated identity chain.

Clawdbot exposes a runtime governance gap that existing access reviews do not cover. Access review processes assume a stable entitlement can be observed, certified and recertified over time. That assumption weakens when a user-installed assistant can inherit permissions, retain memory across sessions and act through multiple interfaces without central logging. The implication is that governance has to move closer to issuance and runtime control, because retrospective review cannot reliably capture transient but powerful agent behaviour.

Unmanaged AI assistants are becoming third-party NHI with human-owned credentials. The article describes personal devices, consumer messaging apps and enterprise data sources converging in one workflow. That means the organisation is effectively extending trust to a non-sanctioned agent while the credential owner remains a human employee. This hybrid trust model is difficult for standard NHI programmes because ownership, approval and execution are split across user, device and service. Practitioners need to recognise that the governance boundary has already moved outside the corporate perimeter.

Named concept: shadow AI identity sprawl. This is the condition where unsanctioned AI assistants quietly accumulate enterprise permissions, persistent context and outward-facing connectivity across personal devices. The risk is not just discovery failure, but the creation of unmanaged identities that are operationally useful and therefore hard to remove. For practitioners, the implication is that NHI, endpoint and SaaS governance must converge on one view of who or what can act on corporate data.

What this signals

Shadow AI identity sprawl: unmanaged assistants can quietly accumulate enterprise permissions, persistent context and outward connectivity across personal devices. That changes the programme question from app approval to identity ownership, because the same user can now create multiple runtime access paths without a central lifecycle process.

Access reviews will miss a growing class of agent behaviour because the entitlement may exist only long enough for the assistant to use it once. Governance needs to move toward discovery, issuance control and revocation of the connected identities that the assistant depends on.

Enterprises should expect the boundary between human identity, SaaS access and non-human execution to blur further as employees adopt assistants that connect to everyday collaboration tools. The programme response is to govern those assistants as access-bearing actors, not as harmless productivity add-ons.

For practitioners

• Discover unmanaged AI assistants on endpoints Monitor for process names, directories such as .clawdbot and unusual third-party service connections to identify employees running the assistant outside approved channels.
• Revoke over-broad OAuth grants and API tokens Review connected Slack, Microsoft Teams, Google Workspace and email integrations, then remove any grants that allow an assistant to reach internal channels, files or mailboxes beyond necessity.
• Block exposed agent infrastructure Prevent gateway ports and control servers from being reachable over the internet, and alert on any agent-related infrastructure that accepts unauthenticated access.
• Separate approved AI automation from personal assistants Offer sanctioned enterprise alternatives with central logging, policy enforcement and controlled data access so employees do not create their own ungoverned assistant workflows.
• Right-size permissions for delegated AI use Limit the data sources and execution rights that any assistant can inherit, especially where shell access, browser control or persistent memory are present.

Key takeaways

• Clawdbot turns shadow AI into an identity governance issue because it can inherit enterprise permissions, retain context and act outside normal oversight.
• The article cites 22% customer adoption and exposes instances that can leak API keys, OAuth tokens and conversation histories, showing the scale is already operational.
• The most effective control point is access scope and exposure management around the connected identities, not just endpoint awareness or policy language.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated Runtime Identity: A non-human identity assigned to an AI system or workflow so it can act within a defined boundary. The identity carries credentials, tool permissions, and logging obligations that determine what the system may access and how its actions are traced.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Agent Memory: Agent memory is the stored context an AI agent uses across sessions or tasks. In governance terms, it is controlled state, because the memories an agent retains can influence future actions, permissions use, and the safety of subsequent decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.