How can organisations reduce the risk from malicious extensions and agent skills?

Why This Matters for Security Teams

Malicious extensions and agent skills turn a signed-in browser session into an execution surface. That matters because delegated code often inherits too much trust: it can read page content, call APIs, trigger workflows, and sometimes reach secret issuance or token exchange endpoints. The result is not just data exposure, but authority transfer from the human to opaque runtime code.

This risk is especially acute in agentic environments because the code is goal-driven and can chain actions in ways a reviewer may not anticipate. Current guidance suggests treating extensions and skills as untrusted workloads, not as convenience features. NHI Management Group’s research shows how often identity controls fail once secrets and runtime authority are blended, and broader incident patterns documented in the OWASP Agentic Applications Top 10 align with that concern.

In practice, many security teams only discover the problem after an extension or skill has already acted with the same power as the logged-in user.

How It Works in Practice

The safest pattern is to separate human console permissions from extension and agent permissions, then enforce runtime checks on every sensitive action. That means a browser extension or agent skill should not inherit broad console scope simply because it is operating inside an authenticated session. Instead, it should receive a narrower workload identity, per-task authorization, and short-lived credentials that expire automatically when the task ends.

For agentic workflows, static role-based access is usually too coarse. An AI agent may have multiple tool calls, change intent mid-session, or be prompted into an unsafe branch. This is why modern guidance increasingly points toward intent-based or context-aware authorization, evaluated at request time rather than pre-approved as a fixed role. Policy engines such as OPA or Cedar can support this model when paired with strong workload identity and explicit allowlists for tools, domains, and API methods. The NIST AI Risk Management Framework is useful here because it pushes organisations to define measurable controls around governance, mapping, and monitoring rather than assuming the model or extension will self-limit.

In NHI terms, the practical control points are clear:

• Deny access to secret-issuing endpoints by default, including token brokers, OAuth consent surfaces, and API key creation flows.
• Issue JIT credentials only for the specific task, with a short TTL and automatic revocation on completion.
• Bind the extension or skill to workload identity, not the user session alone, so the system knows what code is acting.
• Log every delegated action with the originating prompt, tool call, and policy decision for investigation.

NHI Management Group’s guidance on the Ultimate Guide to NHIs — 2025 Outlook and Predictions is particularly relevant because long-lived secrets and excessive privilege are the conditions that make delegated code dangerous. These controls tend to break down when an extension can silently reuse the user’s browser state across multiple authenticated consoles because token scope and session scope were never separated.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, requiring organisations to balance safer delegation against developer friction and workflow latency. That tradeoff is real, especially when teams rely on extensions for automation inside admin consoles, data platforms, or support tooling.

There is no universal standard for this yet, but best practice is evolving toward two patterns. First, high-risk actions such as exporting data, issuing credentials, changing IAM policy, or approving payments should require step-up verification even when initiated by an authenticated extension. Second, agent skills should be scoped to the minimum tool set needed for the task, with explicit deny rules for browser storage, secrets panes, and identity management endpoints. This is consistent with the threat analysis in CSA MAESTRO agentic AI threat modeling framework and the control expectations in OWASP Top 10 for Agentic Applications 2026.

Edge cases appear when a browser extension is trusted for productivity but later gains access to privileged tabs, or when a skill is embedded in a workflow platform that can reach multiple back-end systems. In those environments, permission boundaries must be explicit and temporary, not inferred from login state. Organisations that skip that distinction usually learn about the weakness through token theft, unauthorized consent grants, or unexpected data exfiltration rather than through a planned review.

Related resources from NHI Mgmt Group

• When do AI agent credentials create more risk than they reduce?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?
• What are Agent Skills and how do they enhance AI performance?