TL;DR: Employees are deploying OpenClaw agents on corporate endpoints with misconfigurations that can expose API keys, OAuth apps, cloud credentials and persistent access into systems like Salesforce, GitHub and Slack, according to Astrix Security. That risk shows shadow AI is now an identity governance problem, not just an endpoint one.
At a glance
What this is: This is an analysis of shadow AI on corporate endpoints, showing that unmanaged autonomous agents can expose non-human identities and expand access into business systems.
Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern agent-installed access paths on endpoints, not just sanctioned identities in core platforms.
Context
Shadow AI on endpoints is a governance gap, not only an endpoint detection problem. When employees install autonomous agents without security oversight, the identity issue is not the device itself but the non-human identities, tokens, and app grants the agent can inherit and misuse.
In the OpenClaw example, the risk comes from unmanaged agent deployment, misconfiguration, and the access attached to that deployment. Once those identities exist outside approved inventory and review cycles, traditional controls lose visibility into who or what can reach Salesforce, GitHub, Slack, and similar systems.
The primary question for identity teams is whether current governance models can still describe and approve machine-like actors that appear on user endpoints and then reach into enterprise SaaS and cloud control planes. In this case, the answer is no: the shadow layer sits outside normal lifecycle control.
Key questions
Q: What breaks when shadow AI agents appear on corporate endpoints without oversight?
A: The break point is governance visibility. Endpoint agents can inherit non-human identities, API keys, OAuth apps, and cloud credentials outside approved lifecycle control, so access exists before security teams can inventory, review, or certify it. The result is unmanaged reach into SaaS and cloud systems, not just an unmanaged application on a laptop.
Q: Why do shadow SaaS environments create so much operational risk for identity teams?
A: Shadow SaaS creates risk because security teams lose consistent control over discovery, user justification, and access revocation. When applications appear outside sanctioned processes, analysts must sift through noisy telemetry and decide what matters before they can act. The result is slower remediation, more manual work, and a wider window for unauthorized use or policy drift.
Q: How should security teams discover shadow AI agents in the enterprise?
A: Use endpoint artefacts first. Look for agent directories, service definitions, local ports, and process names that prove the software is installed and active. Network traffic alone is too ambiguous because legitimate browser and API activity can look identical to agent behaviour. Discovery should produce an inventory of where the agent runs, what it can reach, and whether it is sanctioned.
Q: What should teams do when an endpoint agent is using credentials that were never approved?
A: Contain the agent, verify the business owner, and revoke the credentials or app grants that give it enterprise reach. If the access cannot be justified and inventoried quickly, treat the agent as an unmanaged identity and remove its persistence path before it spreads into core systems.
Technical breakdown
How shadow AI on endpoints turns into identity exposure
Shadow AI on endpoints becomes an identity problem when a locally installed agent is granted or can discover credentials that were never meant to belong to it. The article points to exposed API keys, OAuth apps, cloud credentials, and other NHIs, which means the agent is not just software on a laptop. It is an access intermediary that can act through inherited trust. Once that trust is embedded in the endpoint, security teams are no longer dealing with a simple software installation. They are dealing with a new identity subject that can expand beyond its original purpose.
Practical implication: Map endpoint-discovered agents to the NHIs they can reach and treat that attachment as an access control event, not just a device finding.
Why autonomous agents create a wider blast radius than traditional controls expect
Traditional controls assume identities are provisioned, reviewed, and then used within a known operating pattern. Autonomous agents break that expectation because they can be installed outside governance workflows, operate with embedded access, and connect to multiple services from a single endpoint. In the OpenClaw case, the agent could potentially extend from employee devices into Salesforce, GitHub, and Slack using already-granted identities. That is a broader blast radius than endpoint policy alone can describe, because the relevant exposure is not the binary being present but the access context it inherits and reuses.
Practical implication: Evaluate every endpoint agent for downstream SaaS reach, not just local execution risk.
Why discovery and forensic proof matter for NHI governance
Discovery is the only way to govern shadow AI when the agent itself sits outside standard procurement or approval paths. The article highlights inventory views, identity graphs, and command-line signatures because those artefacts identify what is installed, who owns it, and which access paths it may carry. For NHI governance, that evidence matters more than the label attached to the tool. If the organisation cannot inventory the agent and the identities it touches, it cannot certify offboarding, prove accountability, or decide whether the access should exist at all.
Practical implication: Use discovery and forensic artefacts to build an authoritative inventory of endpoint agents and their attached non-human identities.
Threat narrative
Attacker objective: The objective is to gain persistent access to corporate systems through unmanaged endpoint-installed agents and the non-human identities they expose.
- Entry occurs when an employee installs an autonomous agent on a corporate endpoint without security oversight or approved governance.
- Credential access follows when the agent is associated with exposed API keys, OAuth apps, cloud credentials, or other non-human identities.
- Escalation and lateral reach occur when that inherited access can touch enterprise systems such as Salesforce, GitHub, and Slack.
- Impact is persistent unauthorized access into sensitive corporate systems and a larger unmanaged attack surface across the organisation.
Breaches seen in the wild
- Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
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 on endpoints is now an identity governance problem disguised as endpoint sprawl. The article shows that the meaningful risk is not the presence of a new tool but the access it inherits when employees deploy autonomous agents outside oversight. Once those agents can carry API keys, OAuth apps, or cloud credentials, the governance boundary shifts from device management to non-human identity control. Practitioners should treat endpoint agent discovery as an identity inventory problem, not a malware-only problem.
Access review assumptions do not survive agent-installed identities. Access review was designed for identities that persist long enough to be observed, certified, and revoked through a stable lifecycle. That assumption fails when an autonomous agent can be installed ad hoc on an endpoint, obtain access quickly, and extend its reach before any review cycle begins. The implication is not just better review cadence, but a rethink of whether review can remain the primary control for these actors at all.
Ephemeral endpoint presence does not equal ephemeral identity risk. The article’s OpenClaw example shows that a short-lived installation can still attach to long-lived enterprise access. That creates what we would call identity blast radius: a small local deployment with disproportionate reach into SaaS and cloud systems. For security leaders, the practical conclusion is that exposure is defined by attached authority, not by how long the endpoint process remains visible.
Shadow AI discovery must become part of non-human identity lifecycle governance. Inventory, ownership, and approved status are lifecycle questions, even when the subject is an autonomous agent rather than a conventional service account. The article’s workflow around discovery, investigation, and approval shows the shape of the problem, but the deeper issue is that organisations now need lifecycle controls that span employees, endpoints, and agent-issued access. Practitioners should align governance around the identity attached to the agent, not the novelty of the agent itself.
Endpoint controls alone cannot govern delegated access from autonomous agents. The moment an agent can authenticate to business systems through inherited credentials, the access problem leaves the endpoint and enters IAM and PAM territory. That means governance must connect device context, ownership, and downstream authorisation in one control plane. The conclusion for practitioners is straightforward: shadow AI is only contained when identity authority is visible from endpoint to SaaS.
From our research library:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Shadow AI and AI Agent Discovery Guide
What this signals
Identity blast radius: endpoint shadow AI should be measured by how far its attached access can reach, not by how visible the process is on the device. When a local agent can touch SaaS, cloud, and collaboration systems, the control question becomes whether identity authority is still bounded by procurement and approval.
Autonomous agents on endpoints force a merger of endpoint telemetry and identity lifecycle governance. Discovery without ownership is incomplete, and ownership without credential inventory leaves the real risk untouched. Security teams should expect this pattern to surface first as unmanaged access, then as an offboarding problem.
The governance model changes once the organisation accepts that a user-installed agent can carry enterprise authority. That means review cycles, device posture, and NHI inventory need to converge around the same object: the access the agent can actually exercise.
For practitioners
- Inventory endpoint-installed agents Scan corporate devices for autonomous agents and map each instance to the human owner, device, and attached access paths.
- Trace attached non-human identities For every discovered agent, identify exposed API keys, OAuth apps, cloud credentials, and other non-human identities that the agent can use.
- Verify business need with the owner Require a documented approval path before an endpoint agent can retain access to enterprise systems or remain on managed devices.
- Isolate or remove unapproved agents Use containment actions when a shadow AI agent appears outside policy, and revoke the credentials or app grants that make persistence possible.
Key takeaways
- Shadow AI on corporate endpoints becomes an identity risk when autonomous agents inherit non-human identities and enterprise credentials outside governance.
- The article’s OpenClaw example shows that unmanaged agents can potentially extend from employee devices into systems such as Salesforce, GitHub, and Slack.
- The practical control gap is inventory and offboarding of agent-attached access, not just endpoint detection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centers on unmanaged agent-installed access paths that can expose third-party identities. |
| NHI-05 — Overprivileged NHI | The risk is broad enterprise reach from access granted to endpoint-installed agents. | |
| NHI-10 — Human Use of NHI | Employees are deploying agents on corporate endpoints and effectively using NHIs outside formal control. | |
| Recommendation — Inventory and govern agent-attached third-party identities before they can reach enterprise systems. Reduce the privileges attached to endpoint agents to the smallest viable access scope. Restrict human delegation of NHI credentials to approved workflows and monitored ownership. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Exposed API keys, OAuth apps, and cloud credentials require lifecycle control and revocation. |
| Recommendation — Apply authenticator management to revoke exposed agent credentials and govern their lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about uncontrolled permissions attached to shadow AI agents. |
| Recommendation — Review and constrain entitlements for any agent that can access business systems. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential exposure leading to reach into downstream systems. |
| Recommendation — Map exposed agent credentials to credential-access and lateral-movement detections in your monitoring pipeline. | ||
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.
- Autonomous Agent: A software entity that can act with its own execution authority and use tools or data sources to complete tasks. In security terms, an autonomous agent is also a non-human identity, so its permissions, approval boundaries, and credential lifecycle must be governed like any other privileged workload.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- 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.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org