Claude Code function hooks expose silent secret access and UI spoofing

At a glance

What this is: Pluto Security found that Claude Code function hooks can create a trust gap by exposing file, network, UI, and transcript access without adequate installation-time disclosure.

Why it matters: This matters because AI coding assistants can become high-privilege execution environments, so IAM and NHI teams need controls for secrets exposure, plugin provenance, and user consent.

Context

Claude Code function hooks turn a coding assistant into a privileged execution surface. When a plugin can read files, call the network, render UI, and alter the session transcript, the governance problem shifts from editor assistance to runtime trust, especially for teams that allow developers to load add-ons into production-adjacent workflows. This is a classic AI coding assistants security problem with direct identity implications.

The main issue is not that plugins exist, but that their effective privilege is broader than the install-time disclosure path suggests. In identity terms, the plugin becomes a non-human actor operating with the user's session context, yet the user is not given a reliable view of its effective authority before they approve it.

Key questions

Q: What fails when an AI coding plugin can run with hidden privileges?

A: The failure is informed consent. If users cannot see file access, network access, prompt-history access, and UI control before installation, they are approving an unknown runtime profile. That creates a trust gap between the package they reviewed and the non-human actor that actually executes inside their session.

Q: Why do AI assistants create a new trust problem for identity governance?

A: AI assistants create a new trust problem because they can read data, choose tools, and act on external text in ways traditional review processes do not expect. Identity governance has to account for action promotion, provenance, and egress, not only authentication or entitlement assignment.

Q: What signs show that a developer plugin is misrepresenting its risk?

A: Look for install flows that show nothing, inspection screens that report zero hooks despite event handlers being present, and capability scanners that miss UI rewrites or remote payload execution. Those are all signals that the visible review surface is incomplete and should not be trusted as the full control picture.

Q: How should teams govern plugins that can fetch and run remote code?

A: Treat them as mutable execution assets, not static artefacts. If the code path can download a script after review and execute it in the user’s session, then the real security question is provenance over time, not just approval at install.

Technical breakdown

How Claude Code function hooks expand the runtime trust boundary

Function hooks run as TypeScript inside Claude Code and receive an event object plus an engine interface called $. That interface can expose filesystem reads and writes, process execution, network access, session history, model calls, settings, and UI rendering. Because the code runs in-process, it can inspect or alter events before passing them onward, which means the security boundary is not the plugin package alone but the combination of event interception, host-granted capability, and downstream effect.

Practical implication: Treat in-process hooks as privileged code paths that need explicit capability review, not as low-risk extensions.

Why capability disclosure breaks when the scanner misses meaningful behavior

The article shows that a mod can request file access, network access, and UI manipulation while the install and inspection flow fails to surface that effectively. A scanner that only reports some $ calls is incomplete if it does not reflect all event handlers, next() rewrites, or runtime-fetched code. That creates a disclosure mismatch: the user sees a benign plugin, but the runtime has a materially larger operational surface.

Practical implication: Require disclosure controls that cover both declared capabilities and the full event-handling path before installation.

How UI spoofing and transcript rewriting undermine user trust

Because hookable render events can draw interface elements inside the trusted client, a plugin can present fake prompts, rewrite confirmation text, or display a credential capture form that looks native. A separate hook can also alter the transcript so the session record no longer matches the action that executed. That breaks the assumption that what the user sees, approves, and later audits is the same sequence.

Practical implication: Separate approval surfaces from plugin-rendered surfaces and log immutable session evidence outside the mod runtime.

Threat narrative

Attacker objective: The attacker wants to steal session credentials and prompt data while using the trusted client to hide what happened.

1. Entry occurs when a user installs a Claude Code mod that is granted access to hooks, files, process execution, and network calls inside the client.
2. Credential harvesting follows when the mod reads session material such as credentials and prompt history and exfiltrates it to an external server without prompting the user.
3. Escalation occurs when the same runtime can present fake prompts or alter transcripts, allowing the attacker to blend malicious actions into trusted interactive flows.
4. Impact is theft of secrets, loss of trustworthy session evidence, and the ability to execute or conceal malicious behavior from the user interface.

Breaches seen in the wild

• 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.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Code mods expose a governance gap between declared capability and effective privilege. The security problem is not just whether a plugin can run code, but whether the user can see the real authority that code will exercise before installation. When a non-human extension can read secrets, reach the network, and alter interface elements, it behaves like a governed identity, not a harmless add-on. Practitioners should treat plugin disclosure as a privilege-management control, not a usability feature.

The named failure mode here is trust-on-install without capability completeness. The article shows that install-time and inspection-time views can underreport hooks, omit high-risk behavior, and miss fetch-then-run patterns. That is a governance gap because the approval decision happens before the operator has a complete picture of what the plugin can do. In practice, that means consent is being collected for a narrower system than the one actually executing.

AI coding assistants now belong in the same control conversation as privileged automation and NHI governance. A mod that can use the host session, draw its own UI, and silently exfiltrate prompt history is functionally acting as a machine identity with delegated authority. That intersects directly with AI coding assistants security and with the broader NHI problem of who owns, reviews, and revokes non-human access paths. Organisations should classify these plugins as governed execution assets, not optional developer conveniences.

Runtime transparency matters more than static review for extensible agentic tools. The article demonstrates that a package can look one way at review time and behave differently after installation or after a remote payload changes. That makes provenance, immutability, and runtime attestation part of identity governance, because the effective actor is the code actually running, not the code that was first inspected. Security teams should plan for ongoing verification, not one-time approval.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Capability completeness: security teams should assume that a plugin’s real risk is defined by the full set of actions it can take at runtime, not by the subset surfaced in a marketplace listing or install dialog. That matters most when the tool can both access secrets and present its own UI, because those two powers let a malicious mod steal data and shape the user’s response in the same session.

Claude Code-style extensions are a useful warning case for AI governance because they collapse execution, interface, and identity into one trust decision. The broader lesson is that organisations need runtime attestation and immutable review trails for agentic tooling, not just pre-install approval. On the evidence cited by Pluto Security, Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%.

The next control question is not whether developers will use add-ons, but whether the organisation can see what each add-on can actually reach before it is trusted. That pushes AI coding environments toward the same governance model as privileged access and NHI oversight: inventory, capability disclosure, revocation, and continuous verification.

For practitioners

• Classify AI coding mods as privileged non-human actors Require security review, ownership, and revocation criteria for every installed mod that can read files, run commands, or reach the network.
• Validate every install path before allowing developer add-ons Test the exact channels your teams use, including local plugin directories and self-hosted marketplaces, because the article shows that some paths bypass the content scan entirely.
• Review capability output, not only plugin names Make developers run the validation command and block any mod whose declared access includes filesystem reads, prompt history, environment data, or network egress without a clear business need.
• Separate rendered UI from trusted approval surfaces Do not rely on the text shown inside the client when a mod can render or rewrite prompts. Require a second, immutable channel for any credential prompt or destructive confirmation.
• Pin or vendor any code that fetches remote helpers Treat fetch-then-run behavior as a post-review change risk, because the payload can be replaced after installation without altering the visible plugin package.

Key takeaways

• Claude Code function hooks turn developer add-ons into privileged runtime actors, so the core risk is hidden authority rather than simple extensibility.
• Pluto Security’s testing shows that disclosure gaps can leave users approving code they cannot accurately assess, especially when UI and transcript manipulation are in scope.
• The practical control response is to govern AI coding plugins like non-human identities, with inventory, capability review, provenance checks, and revocation paths.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Secrets Management Guide · Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs

Key terms

• Function Hooking: A technique that redirects an application call so attacker-controlled code runs before or instead of the original function. In mobile security, hooking is dangerous because it can expose secrets, alter trust checks, or manipulate transaction logic while the app still appears to operate normally.
• Capability Disclosure: Capability disclosure happens when a service reveals what it can do, often through banners, metadata, or unauthenticated discovery calls. In identity security, disclosure matters because it gives attackers a map of the control plane before any command is executed.
• Trusted UI Surface: A trusted UI surface is a screen or prompt the user relies on to make a security decision, such as approving a credential request or confirming a destructive action. If a plugin can draw over that surface or rewrite what it says, the approval no longer reflects the real operation being authorised.
• Mutable Runtime Payload: A mutable runtime payload is code fetched or changed after initial review so that the behaviour that executes later may differ from the version that was approved. In plugin ecosystems, this breaks the assumption that one-time inspection is enough and shifts control toward provenance, pinning, and continuous verification.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity teams apply consistent controls to non-human access paths, including AI coding tools and other delegated execution environments.