OpenClaw, Rogue Agents, and Application Hygiene

What it is

Huntress analysis of how the OpenClaw AI agent (formerly Moltbot/ClawdBot) manifests as a service principal inside Microsoft Entra ID, and the specific Graph permissions that turn it into an identity attack surface. The framing is deliberately behavioral rather than code-level: treat OpenClaw as a semi-trusted service principal, regardless of the friendly label on it.

How it works

Two consent modes carry different risk. Application permissions grant tenant-wide access with no signed-in user ("read or modify every mailbox") and require admin consent. Delegated permissions are scoped to one user's rights — but by default users can grant these with no admin approval or visibility, which is the oversight gap.

Beyond the permissions in the summary, the page names two the summary omits:

• UserAuthMethod-Email.ReadWrite.All — modify user auth methods via email, a direct account-takeover path.
• DelegatedPermissionGrant.ReadWrite.All — grant OAuth permissions on others' behalf, enabling consent bypass.

Combined with AppRoleAssignment.ReadWrite.All, a compromised agent can escalate and self-grant privileges. Attackers inherit these by compromising the vendor, stealing app secrets, or tampering with backend infrastructure — bypassing endpoint-centric defenses entirely.

Preconditions / Affected

Entra ID tenants where OpenClaw/Moltbot has been installed — either self-service by an individual user (scoped, but severe if that user is IT/finance/exec) or registered centrally with sweeping directory/mail/SharePoint scope. User consent to applications must be enabled for the self-service path to exist.

What to do

The page states these concretely:

• Disable user consent to applications — named as "a key mitigation" that closes the delegated-permission oversight gap.
• Scan tenants for service principals named OpenClaw, Moltbot, and similar variants — this is the detection method Huntress used to find dozens of apps.
• Audit granted scopes, not just app presence — establish a durable process to review what assistants can do, how scope changes over time, and which approvals were granted. The page's core finding is the absence of this process, not any single permission.

flowchart TD
    A[OpenClaw install request] --> B{User consent enabled?}
    B -- yes --> C[User self-grants delegated perms\nno admin visibility]
    B -- no --> D[Blocked / requires admin]
    A --> E{Admin consent for\napp permissions?}
    E -- granted --> F[Tenant-wide service principal]
    C --> G[Persistent identity path]
    F --> G
    G --> H[Compromise agent/secrets\n= inherit privileges]

Caveats

Disabling user consent addresses only the delegated self-install path; centrally registered "too-powerful" apps with admin-consented application permissions are a separate governance problem the page flags but does not give a command for. The permission examples are observations across sampled customer tenants, not a fixed manifest — any given OpenClaw install may hold a different scope.