Before You Install the Tool: A Supply-Chain Gate for AI Agents

A developer copies one command from a directory page and adds a new tool server to an AI client. The tool promises read-only issue triage. The command downloads a package, runs an installation script, inherits the client process's environment, reads the current repository, and opens network connections. The directory entry named a useful product; it did not establish which bytes ran, who built them, which dependencies arrived, or what the process could actually reach.

That creates a concrete decision: should this exact agent tool be admitted, quarantined for investigation, or rejected? A popularity badge, recognizable publisher, clean vulnerability scan, signed artifact, or narrow tool description can contribute evidence. None alone answers the decision.

The central rule is simple: discovery is not trust, and a package name is not the unit of admission. Admit an immutable artifact together with an enforceable capability envelope, an evidence record, an owner, and an update policy. When any of those changes, the admission decision expires.

Installation joins two risk systems

An ordinary library becomes part of an application's software supply chain. An agent tool also becomes part of an authority chain. It can influence model context, receive sensitive arguments, return untrusted instructions, contact other systems, and sometimes execute a side effect. A local server may additionally run as code under the same operating-system identity as the AI client.

This is why the admission question has two independent axes:

1. Artifact trust: Is this the intended artifact from the intended source and build process, without unexplained substitution?
2. Runtime authority: If the artifact is genuine, what files, processes, networks, credentials, data, and business actions can it reach?

A genuine malicious release passes an origin check. A well-intentioned tool with excessive filesystem access fails an authority check. A safe source commit built through a compromised or unexpected pipeline fails an artifact check. A robust gate must examine both axes without allowing one to compensate for the other.

Our tool-permission guide begins after a capability exists and asks how each call should be authorized. This guide addresses the earlier question: whether that capability should enter the environment at all.

What the sources establish—and where judgment begins

Several standards provide useful parts of the answer, but none certifies an agent tool as safe.

The final July 2026 NIST SP 1326 due-diligence guide describes supplier assessment through provenance, resilience, foundational cyber practices, supply-chain tiers, and ownership or influence. The broader NIST SP 800-161 Rev. 1 treats supply-chain risk across acquisition, deployment, maintenance, and disposal—not only at purchase. NIST SP 800-218 gives producers and purchasers a common vocabulary for secure development practices. These are general software and supplier controls; they do not inspect an MCP schema or decide an agent's permissible egress.

ZharfAI's analysis is to combine that supply-chain evidence with a separately enforced capability envelope. Provenance answers where an artifact came from. Behavioral quarantine tests what it attempts. Runtime policy limits what it can do. Operational ownership determines how it is updated, disabled, and investigated. The admission record connects all four.

Define the admitted object precisely

Do not approve “the calendar tool,” “version 4,” or a floating container tag. Record a resolvable object:

• canonical source repository and supplier identity;
• exact source revision, release tag, package version, and artifact digest;
• registry or distribution channel and package coordinates;
• entry command, arguments, working directory, and installation scripts;
• direct and resolved dependencies, including native binaries and downloaded models;
• build platform, build type, external parameters, and available attestations;
• declared tools, resources, prompts, schemas, and transport;
• requested filesystem, process, network, secret, and downstream-service access;
• review owner, admission decision, exceptions, expiry, and emergency disable path.

The digest is the identity used at execution. Names and versions remain search aids. If a bootstrap command resolves a different package tomorrow, the previous decision must not silently authorize it. Prefer an internal catalog that maps a human-friendly tool name to an approved digest and a policy bundle.

This admission object complements the wider AI release passport. The release passport names the production assembly; the tool record supplies the evidence and limits for one especially powerful component.

Verify provenance against expectations

Provenance is useful only when it is verified against a policy. The approved SLSA 1.2 artifact-verification guidance calls for checking the attestation signature, matching the statement subject to the artifact digest, recognizing the predicate type, evaluating the builder identity, and comparing the canonical source and external build parameters with expectations. It also states important limits: even Build Level 3 assumes the selected build platform is trustworthy, and recursive dependency evidence may be incomplete.

GitHub artifact attestations can link an artifact to its workflow, repository, commit, and build event. GitHub explicitly warns that an attestation is not a guarantee that the artifact is secure. Sigstore's verification guidance shows that verification must check the artifact digest and the expected certificate identity and issuer, not merely the existence of a signature. npm provenance similarly links a package to source and build instructions while warning that provenance does not prove an absence of malicious code.

Turn those limits into gate behavior:

• Reject a signature whose identity, issuer, artifact subject, or canonical repository is not expected.
• Treat an unverifiable artifact as unknown, not “probably official.”
• Do not let a provenance badge replace code, dependency, or behavior review.
• Record which properties were actually verified; do not collapse them into one green shield.
• Verify again at download or deployment time so registry or transit compromise is not outside the control.

Where no strong provenance exists, a low-risk tool may still enter quarantine for evaluation. That is a risk exception with tighter limits and an expiry—not equivalent assurance.

Build an enforceable capability envelope

A tool description is input to review, never the enforcement boundary. Describe the smallest environment in which the intended use still works:

Enforce this outside the model and, where practical, outside the tool process: sandbox policy, read-only mounts, explicit directory grants, a brokered credential, egress proxy, downstream authorization, resource quotas, and independent logs. The model cannot grant an undeclared directory or destination merely because the tool requests it persuasively.

The envelope should also say what failure looks like. A denied file read, new domain, child process, schema expansion, or scope request is a policy event. It should stop or quarantine the execution rather than become an automatic permission prompt that users learn to approve.

Quarantine before trust

Quarantine is an instrumented environment, not a waiting room. Give it synthetic data, canary secrets that confer no real access, no production identity, and no route to private networks. Capture the resolved artifact, process tree, filesystem reads and writes, DNS and network attempts, spawned commands, tool-list changes, resource use, and output sent back to the model.

Test the intended path and adversarial variations:

• empty, oversized, malformed, and instruction-bearing inputs;
• symlink and path traversal attempts;
• redirected URLs, rebinding, private addresses, and cloud metadata targets;
• missing credentials, partial downstream failure, timeout, cancellation, and retry;
• poisoned tool output and content that asks the model to broaden authority;
• update, downgrade, dependency replacement, and offline execution;
• concurrent calls and cumulative data or action budgets.

The official MCP security best-practices guide makes the local risk concrete: a local MCP server is downloaded code that may execute with client privileges, and it recommends explicit consent, sandboxing, restricted filesystem and network access, and exact command visibility. The same guide covers malicious authorization URLs, server-side request forgery, token audience failures, and broad scopes. These are not remote edge cases; they are admission tests.

Passing quarantine does not prove future safety. It establishes that the tested artifact behaved within the tested envelope under stated cases. Preserve that bounded claim.

A worked example: an issue-triage server

A team wants an MCP server to summarize new repository issues, find duplicates, and propose labels. The first request is deliberately read-only.

The acquisition lane resolves the package to one digest, links it to the canonical repository, verifies the publisher and build attestation, records dependencies and install scripts, and stores the artifact internally. Review finds that the package's default start command reads the entire current directory and sends optional telemetry to a second domain. Neither behavior is necessary.

The team does not approve the defaults. In quarantine it mounts no repository files, permits egress only to the repository API, disables telemetry, blocks subprocesses, and injects a short-lived read-only token through a broker. The server can read issue metadata and return label suggestions. It cannot change labels, run workflows, read source code, or retain issue bodies.

The decision is admit with limits, bound to the digest and envelope. A later release adds a run_workflow tool and contacts a new analytics host. Even if the version is signed by the same publisher, the catalog diff and egress attempt invalidate the prior admission. The new artifact returns to quarantine. Write access would require a separate capability, downstream authorization, a specific approval rule, and new evidence.

This separation follows the same logic as short-lived credential brokering: the tool receives only the authority needed for the current task, after policy evaluation, rather than inheriting a standing secret.

Decide: reject, quarantine, or admit

Use explicit outcomes instead of a vague score:

Higher consequence raises the evidence floor. A read-only tool over public data may be acceptable with a pinned artifact and strong isolation even when its supplier is small. A tool that can read private source, touch production, move money, or communicate externally should require stronger source and build evidence, independent review, narrower downstream controls, and a rehearsed revocation path. Popularity does not reduce consequence.

Supplier due diligence still matters: maintainer identity, governance, release protection, security contact, response history, dependency policy, business continuity, data handling, and acquisition risk. The broader AI vendor dossier provides that procurement view. Keep supplier evidence distinct from artifact verification and runtime observation so reviewers can see exactly what is known.

Make updates new admissions

Floating versions turn one review into indefinite authorization for future code. Pin by digest and let an update service—not the production agent—discover new releases. For every candidate, compare:

• source repository, publisher, signer, issuer, builder, and build parameters;
• dependency graph, lockfile, install scripts, native binaries, and licenses;
• declared tools, schemas, annotations, scopes, and transports;
• filesystem, process, network, telemetry, retention, and subprocessor behavior;
• test results, vulnerabilities, accepted exceptions, and supplier advisories.

Classify changes. A documentation-only release may need evidence refresh but no behavioral campaign. A dependency, entrypoint, tool schema, scope, network, or credential change returns to quarantine. An unexplained provenance change fails closed.

Keep the previous known-good artifact available, but do not confuse rollback with safety. If a supplier signing identity, build platform, or shared dependency is compromised, multiple versions may be affected. The emergency control must disable the capability or revoke its identity independently of deployment.

Measure whether the gate works

Useful measures expose uncontrolled authority rather than celebrate review volume:

• percentage of running tools bound to an immutable digest;
• percentage with verified artifact subject, expected publisher, canonical source, and trusted builder;
• unreviewed install scripts, native binaries, and transitive dependencies;
• observed filesystem and egress attempts outside the declared envelope;
• catalog, schema, scope, and destination changes per update;
• high-consequence tools without external downstream authorization;
• expired exceptions and overdue evidence refreshes;
• time from a bad advisory or behavior signal to quarantine, credential revocation, and blocked execution;
• percentage of decisions reconstructable from artifact, policy, test, and owner records.

A high rejection rate may reveal weak discovery sources or an impractical policy. A zero-rejection rate may mean the gate is ceremonial. Review both false positives and escaped authority with security, platform, and business owners.

The agent-tool admission gate

Before enabling a tool outside quarantine, require affirmative answers:

• Is the exact executable artifact identified by digest and stored through a controlled channel?
• Do publisher, signer, issuer, source repository, builder, and build parameters match written expectations?
• Have dependencies, install behavior, native code, and known vulnerabilities been reviewed at the consequence-appropriate depth?
• Is the smallest useful filesystem, process, network, identity, data, action, and output envelope documented and enforced externally?
• Did the exact artifact pass intended, adversarial, failure, and update tests without unexplained reach?
• Are credentials short-lived, audience-bound, hidden from model context, and independently revocable?
• Will any material artifact, dependency, schema, scope, destination, or supplier change trigger re-admission?
• Can an owner disable the tool, identify affected runs, preserve evidence, and restore a known business state?
• Is the decision one of reject, quarantine, or admit with limits, with an expiry and named exception owner?

The goal is not to prove that a tool contains no defect or malicious path. That claim is unavailable for complex software. The goal is a smaller, defensible statement: the organization knows which artifact it is running, has evidence about where it came from, has observed how it behaves, and has made undeclared authority technically unavailable. Install the evidence and the boundary together—or do not install the tool.

Source notes — reviewed August 21, 2026

• NIST SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide — final July 2026 guidance for supplier and product due-diligence assessment components.
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices — lifecycle C-SCRM guidance for acquiring, deploying, maintaining, and retiring products and services.
• NIST SP 800-218: Secure Software Development Framework 1.1 — secure-development practice vocabulary usable by producers, purchasers, and consumers.
• SLSA 1.2: Verifying artifacts — approved guidance for verifying provenance signatures, artifact subjects, builder identity, source expectations, parameters, and dependencies.
• MCP Security Best Practices, protocol version 2026-07-28 — official risks and mitigations for local execution, consent, sandboxing, SSRF, token handling, and scope minimization.
• GitHub: Artifact attestations — build-provenance features and the explicit limitation that attestation does not guarantee secure code.
• Sigstore: Verifying signatures — artifact-digest, certificate-identity, issuer, signature, and attestation verification guidance.
• npm: Generating provenance statements — registry provenance mechanics and their documented limits.