Before You Install an AI Tool, Verify What You Are Letting In

The first consequential decision about an AI tool may happen before anyone writes a prompt.

A colleague finds an extension that promises to remove an irritating hour of work. The name is familiar. The demonstration looks useful. Installation takes seconds. It is tempting to treat that moment as a small purchasing decision and reserve the serious questions for what the AI produces later.

I would move some of those questions earlier. What software actually arrived? Which channel delivered it? What can it reach when it starts? Who will notice if the next update changes that answer? These are operating questions for a business owner as well as technical questions for the person installing the tool.

This is not an argument against useful tools or automatic updates. It is an argument for giving software admission the same care we give a new person access to the workshop. A recognizable name can help us find the right door; it cannot establish what came through it.

Know which artifact arrived

On October 29, Cursor reported malicious versions 2.1.312 and 2.1.313 of the anthropic.claude-code extension for Windows and macOS in its extension marketplace. Its notice states that Anthropic did not develop those packages. This is a scoped incident report, not evidence that every installation carrying the name was affected.¹

Microsoft's October 30 analysis describes injected code running before ordinary extension initialization and attempting persistent host access. Successful access depended on the environment. Its report says the malicious packages were not distributed through Microsoft Visual Studio Marketplace or the official npm channel, and that Anthropic's systems were not compromised. Those reported boundaries matter as much as the headline.²

The two reports play different roles. Cursor is the marketplace operator reporting the incident; Microsoft analyzes the malicious code and cites Cursor for delivery details. They are not two entirely independent investigations of every affected machine. Recheck their current notices before making an incident-specific decision.

The wider lesson I draw is to identify an artifact rather than approve a familiar label. An artifact is the particular software being installed: the package, release or extension build, not merely the product name. The distribution route belongs beside it. Approval of one route should not silently approve a similarly named package somewhere else.

For a small business, the first useful record can be short. Name the business job, the accountable owner, the expected publisher and the approved distribution route. Ask the implementer what evidence binds the delivered file to the expected release. If that cannot be established, record the uncertainty rather than replacing it with a screenshot of a logo.

NIST's February 2022 Secure Software Development Framework, version 1.1, includes making integrity-verification information available to acquirers in PS.2.1 and acquiring and maintaining well-secured components in PW.4.1. I cite the identified edition as guidance, not a new legal requirement or a certification of this method.³

Limit what installation may reach

Authenticity and permission answer different questions. Authenticity asks whether this is the artifact we intended to receive. Permission asks what it may do here. Even genuine software can be inappropriate for a machine that holds sensitive records, reusable credentials or access to production systems.

SLSA's version 1.2 artifact-verification guidance describes checking provenance against trusted identities and expected values, including the canonical source and builder. It also states important limits: its protections do not make every build platform trustworthy or cover every way a consumer can be tricked into choosing an unintended package. Provenance needs meaningful verification; it is not a decorative attachment.⁴

My proposed Tool Admission Record separates five commitments:

1. Artifact: identify the intended software, release and publisher, with the evidence the implementer actually checked.
2. Route: name the approved distribution and update channels. A different route requires a fresh decision.
3. Reach: define the files, credentials, network destinations and actions required for this business job; note what remains outside that scope.
4. Change: assign who reviews material changes in publisher, channel, behavior, permissions or dependencies, and what response follows.
5. Recovery: name the owner who can restrict access, preserve evidence and coordinate investigation if the admitted software becomes suspect.

This is an acceptance aid, not a substitute for a security professional's assessment. Some environments need more extensive controls. A busy owner should not be expected to audit unfamiliar code alone; the owner should be able to ask the implementer for a specific answer and understand what remains unresolved.

Consider an explicitly synthetic example. A design business wants an assistant to organize draft project files. Its first rehearsal uses copies of fictional work in an approved test environment, without production secrets. The useful outcome is a correctly organized set of test files. The admission question is whether the installation and runtime can stay within the environment approved for that job.

Good output does not answer every admission question. The test may demonstrate the intended task while leaving network behavior, startup effects or shared-machine access insufficiently understood. Keep those uncertainties visible. “It worked” and “we accept this access” should remain separate statements.

Make updates a new admission decision

A Tool Admission Record should not become a reason to freeze software indefinitely. Delaying a needed security fix can introduce its own exposure. The goal is a governed update path: know who receives notices, which source supplies updates and which changes require intervention before the tool continues with its existing access.

Some checks can be automated and some decisions can be preauthorized within a documented policy. The important part is that the policy exists outside the incoming package's own claim to trust. A changed publisher, a new distribution route or a request for broader access deserves an accountable response, not a silent inheritance of yesterday's approval.

Rehearse three fictional changes with the owner and implementer. The expected package arrives through the approved channel. A similarly named package arrives through another channel. An approved tool requests access outside the agreed job. Ask what evidence is checked, what remains held and who can resolve the difference. Do not install suspicious software to make the exercise realistic.

If there is evidence of a real compromise, stop treating the situation as an admission exercise. Follow current vendor guidance and the organization's incident-response process with qualified help. Preserve relevant evidence before cleanup where the response team directs it. Removing an extension is not, by itself, proof that every consequence of earlier execution has been reversed.¹

The record does not prove a tool is harmless, identify every dependency or replace ongoing monitoring. It gives the organization something narrower and useful: a named decision about a known artifact, a defined operating scope and a way to reopen that decision when the facts change.

That is how I would turn a promising shortcut into a business capability. Verify what is arriving, bound the place where it can work, and keep the next change from borrowing trust it has not earned.