No. Machines with production access, saved sessions, or privileged tokens are the wrong place to experiment with untrusted skills. If a skill can influence local execution or credential stores, the blast radius includes account takeover, source control compromise, and cloud access abuse before anyone notices.
Why the answer is no for corporate machines
Agent skills are not harmless add-ons when they run on endpoints that already hold production credentials, saved browser sessions, or privileged tokens. The machine becomes part of the trust boundary, so any skill that can execute code, read local state, or interact with the browser can pivot from “tool use” into account takeover, source control abuse, or cloud access abuse.
That is why the safer default is to keep experimental skills off corporate machines unless the environment is intentionally isolated, tightly observed, and disposable. If the same workstation can reach production systems and also run untrusted skills, the organisation has already mixed experimentation with standing access.
What changes when a skill can touch local execution or secret material
The security issue is not the label “skill”, it is the capability boundary. A skill that can invoke local commands, inspect files, or influence a browser session can interact with credential stores, session cookies, password managers, browser profiles, synced tokens, and development tooling. Once that happens, compromise no longer requires bypassing the application the person intended to use; it only needs the skill to exploit whatever the machine can already reach.
This is especially dangerous on developer and admin laptops because they often carry multiple identities at once: SSO, Git hosting, cloud consoles, password vaults, and sometimes SSH or API credentials. A single poisoned skill can therefore turn one local execution path into a broad authentication and authorization failure.
Safer practice is to treat skills like any other high-trust automation surface and give them only the minimum access needed for the task. The same principle used for secret handling and identity scoping applies here, because the skill is effectively acting through the machine’s credentials rather than through a clean, bounded sandbox.
Where organisations get this wrong in practice
The common mistake is assuming a corporate laptop is protected because it is managed. Management helps with posture, but it does not change the fact that the endpoint already contains live sessions and reusable credentials. If a skill can read or influence them, the endpoint becomes a privilege aggregation point.
Another failure mode is allowing “harmless” productivity skills to be installed broadly and only reviewing them after a problem. That model works poorly for skills because their actual blast radius depends on the local context they inherit, not just the published description. A skill that seems useful in a browser-only setting can become dangerous the moment it runs beside a vault, a CLI token cache, or a cloud login session.
For deeper guidance on the underlying secret and identity risks, see Guide to the Secret Sprawl Challenge and AI Agent Authorisation Guide, which both reinforce why access should be scoped before a tool is trusted with anything that can reach production systems.
Risk and Threat Considerations
When untrusted skills run on machines with corporate credentials, the main risk is lateral trust collapse. The skill does not need to steal a password directly if it can use an existing session, extract a token from local state, or trigger a browser or CLI action that the user would normally approve. That creates a fast path from local compromise to enterprise compromise.
Failure mechanism: the skill abuses inherited trust on the endpoint, reaches saved sessions or privileged tokens, and then performs authenticated actions that look legitimate to downstream systems.
Impact: attackers can gain account takeover, commit malicious changes in source control, access cloud resources, or move from one managed identity to another before standard detection catches the abuse.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Corporate machines with sessions and tokens can expose secrets to untrusted skills. |
| NHI-05 — Overprivileged NHI | Untrusted skills on corporate machines inherit excessive access through local credentials. | |
| Recommendation — Isolate skills from devices that store reusable secrets or sessions. Limit any skill to the minimum access it needs and separate it from production authority. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | A skill can misuse local tools, browsers, or shells to reach sensitive actions. |
| ASI03 — Identity & Privilege Abuse | Skills on corporate machines can abuse inherited identity sessions and privileges. | |
| Recommendation — Restrict tool access so skills cannot invoke sensitive local actions by default. Treat inherited credentials as privileged and gate skill execution behind explicit approval. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Saved tokens and credentials on endpoints require lifecycle control and protection. |
| AC-6 — Least Privilege | Skills should not inherit broad corporate access from the host machine. | |
| Recommendation — Protect and rotate authenticators that a skill could reach on the endpoint. Apply least privilege so a skill cannot act with more authority than its task requires. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Controls should separate endpoint use from privileged access and limit exposure. |
| CIS-5 — Account Management | Corporate accounts on shared or skill-capable machines raise account abuse risk. | |
| Recommendation — Restrict privileged access paths on devices that can run untrusted automation. Segment and review accounts that can be reached from skill-enabled endpoints. | ||
Practitioner Guidance
What to verify: Only allow skills on isolated, low-privilege environments where no production sessions, cached secrets, or admin tokens exist. If the machine must retain corporate access, assume any skill installed there can interact with that access and require a stronger approval gate.
Decision rule: If a skill needs local execution, browser access, or file visibility on a device that already holds production credentials, treat it as a privileged integration and not a convenience feature. Use a separate sandboxed device, disposable profile, or dedicated test account instead.
Common mistake: organisations often review the skill store listing but not the local trust context. The listing is not the risk boundary, the endpoint state is.
Practitioner takeaway: The question is not whether the skill is useful, it is whether the machine can afford to trust it. If the endpoint holds production authority, the skill must be isolated from it.