What should security teams do when extension behaviour differs from its published manifest?

What behavioural drift means in an extension

When an extension behaves differently from its published manifest, the manifest is no longer a reliable description of what the package can actually do. That gap matters because users, reviewers, and platform checks may have trusted the declared permissions, entry points, or event hooks. The security question is not whether the manifest looks clean, but whether the shipped artefact matches it.

In practice, drift can come from post-review changes, build-time substitution, injected code, or a package that loads additional logic after installation. A manifest may understate the extension’s reach while the runtime behaviour still accesses files, network endpoints, or local tooling. That is why behavioural verification is as important as static review.

For a useful deeper read on how extension ecosystems can conceal credential exposure and supply-chain abuse, see Secrets in VS Code extensions 2025.

Why this is a security problem, not a packaging inconsistency

Behavioural drift creates a trust-boundary mismatch. Security teams are not just checking whether the extension was published, signed, or reviewed, they are checking whether the running code respects the same boundary that the manifest implied. If the extension can do more than the manifest advertised, the package may be capable of privilege escalation, data access, or local command execution that users did not meaningfully consent to.

Quarantine is the correct first response because the issue is uncertainty about effective capability, not cosmetic noncompliance. Once the package is isolated, teams should inspect the built artefact, compare declared versus observed behaviour, and trace any workspace-scoped input sources that might be steering execution. The key question is whether the extension can turn a benign-looking permission set into active system interaction.

If the extension reaches into the local environment, the risk expands beyond the extension itself. A package that can initiate local commands, spawn processes, or consume workspace data has crossed from passive UI logic into an execution path that can affect the host, the developer environment, and any connected secrets or tokens.

What security teams should verify before allowing it back

Start with the artefact the user actually installed, not the source repository description. Rebuild or unpack the extension, compare its shipped files to the published manifest, and look for runtime hooks, hidden loaders, post-install scripts, or bundled dependencies that change behaviour after review. If the package pulls in workspace content, determine whether that input can influence command execution, file access, or outbound connections.

Teams should also verify whether the extension’s observed behaviour is consistent across environments. Some extensions only reveal problematic behaviour when workspace contents, user settings, or third-party resources are present. That means a clean manifest is not enough; the security test is whether the extension behaves safely under realistic deployment conditions.

For controls that emphasize verification, logging, and least privilege around execution paths, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful control reference, especially where code integrity, configuration management, and system integrity reviews need to be made operational.

Risk and Threat Considerations

Behavioural drift is attractive to attackers because it creates a review blind spot. A benign manifest can lower suspicion while the shipped extension still reaches files, commands, tokens, or other local assets. That mismatch can be used to smuggle in code execution, exfiltrate workspace data, or pivot through developer tools into broader environments.

Failure mechanism: The extension’s declared surface and its actual runtime surface diverge, so the package is trusted on the basis of incomplete or stale metadata while the executing artefact performs actions outside that trust boundary.

Impact: Users may install or retain an extension that can read sensitive files, trigger local commands, or interact with secrets and credentials without the manifest clearly disclosing that capability. In larger environments, the same pattern can scale into repeated compromise across many developer workstations.

Practitioner Guidance

What to prioritise: Treat any manifest-to-runtime mismatch as an integrity event first, not as a product defect. Quarantine the package, preserve the artefact for inspection, and decide whether the extension must be removed from all affected environments before deeper root-cause analysis.

What to verify: Confirm the exact code path that executes after install, activation, or workspace open. If the extension can launch processes, touch the filesystem, or read workspace content beyond what the manifest suggests, you have a control gap that needs remediation, not just documentation correction.

Decision rule: If the extension can initiate local commands or access sensitive workspace data in ways not clearly reflected in the published manifest, block reuse until the artefact is rebuilt, re-reviewed, and its behaviour is reproducible from a trusted source.

Practitioner takeaway: The safest assumption is that the manifest describes intent, but only the built artefact proves capability, so any behavioural drift should be handled as potential untrusted execution until proven otherwise.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that can change behaviour at runtime?
• How should security teams govern AI agents that can change behaviour based on prompt context?
• How should security teams assess AI agent behaviour beyond identity checks?
• How can security teams tell whether an extension is over-privileged?