eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent Tool Supply Chains — Artifact Provenance, Verification and Admission

—

by

eduKate Asia

An AI tool connector should not be admitted into a live workflow merely because it has a familiar name, a working download link or a plausible description. Its executable package, dependency chain, signing identity, build origin and declared permissions need to match an approved expectation. Tool-supply-chain integrity is the discipline of establishing which code and configuration will execute, who supplied it, how it was built, what it can access and what changes require another review. A signature or hash can detect some alterations, but it does not prove the tool is safe, truthful or appropriate for the request.

The most useful practical rule is to separate release verification from runtime authority. Before deployment, verify the exact artifact digest and expected publisher or builder, inspect dependencies, constrain tool descriptions and test the tool in isolation. After deployment, allow only approved operations with the right identity, network destinations and data scopes, then inspect actual effects. This guide follows a fictional four-connector release with twenty-four material checks, calculates why twenty-two passed checks do not equal four approved connectors, examines misleading signatures and gives an executable-style review plan without distributing harmful code. These ideas protect today’s agents; artificial superintelligence is hypothetical, not a product whose integrity can already be certified.

Continue from the How Super Intelligence Works library. Agent protocols and tasks describes communication contracts; identity and delegation addresses permissions; and change control addresses deployment discipline. This article addresses a different question: can we establish which third-party executable tool we are actually trusting? All numerical data here is invented as a worked teaching packet.

Choose a learning route

  • Developer integrating external plugins or tools? Read the trust map, manifest and admission rules first.
  • Security reviewer? Focus on publisher identity, dependency provenance and runtime boundaries.
  • Operator facing a suspicious release? Follow the containment and diagnosis sections.
  • Student or team learning risk analysis? Solve the four-connector case, then try the transfer problem.

Contents

1. Why an agent tool is part of a supply chain

An assistant may treat a tool as a simple function: give it an argument and receive a result. In reality, the execution path can include an SDK, a packaged server, dependencies, installation scripts, container images, credentials, remote APIs, build infrastructure and a registry that serves updates. Any one of those elements can change the program that eventually sees private inputs or acts on a business system. Even a read-only-looking tool may have network access or write temporary data somewhere the user did not expect.

A supply-chain problem differs from a prompt-injection problem, though they can meet. Prompt injection happens when untrusted text attempts to redirect model behaviour. A compromised tool package can execute code with host privileges regardless of whether the model interprets the tool description correctly. Conversely, a legitimate, correctly signed tool can return malicious instructions in its data. One control validates software origin; another treats tool results as untrusted content and restricts subsequent actions. The engineering design needs both.

The relevant security question is not “is this package popular?” but “is this exact version, from this expected source and build process, suitable for this explicitly authorised capability?” A legitimate vendor might release a breaking change or accidentally ship a vulnerable dependency. A registry might serve different bytes under a mutable tag. A developer might choose an unofficial mirror with a confusingly similar name. A configuration file might grant wildcard network access long after an experiment ends. None of those is fixed by asking the model to be more careful.

Threats include accidental dependency drift, malicious package substitution, build-process tampering, compromised publisher accounts, installer scripts with unexpected side effects and remote tools whose behaviour changes without an artifact update. Write these possibilities into a threat model with explicit boundaries and realistic detection paths. Keep the scope defensive: inventory and verify what your organisation chooses to run, rather than experimenting with exploit payloads on someone else’s infrastructure.

2. Map five trust boundaries

Boundary one is discovery: how did the team learn this tool existed, and does the published name map to a verified publisher and documentation? Boundary two is distribution: what artifact was downloaded, through which repository or registry, and what digest identifies its exact bytes? Boundary three is construction: which build platform, source revision and declared materials produced those bytes? Boundary four is installation: what scripts or package managers execute during deployment, and which dependencies are pulled in? Boundary five is runtime: what authority, network destinations and data can the admitted tool reach?

Draw the boundary map before discussing signatures. A signature can help connect the artifact to a known identity under a configured trust root, but it does not describe every action performed by an installer, prove the entire build environment was uncompromised or limit a running process. Provenance is evidence about a build; permission policies govern execution. Consider each missing link separately. A tool can pass one boundary and still fail the final admission decision.

Some connectors are remote services, not downloadable binaries. In that case the client package may be pinned and signed while server-side code changes behind an API. Add provider identity, contractual change notification, versioned API semantics, data handling and runtime observations to the review. “Verified client artifact” should never be presented as proof of a remote supplier’s entire infrastructure. The admission contract must describe the boundary of verification honestly.

Ownership also matters. Who is allowed to add a new publisher root of trust? Who accepts new destinations, new data categories and a major-version upgrade? Who can remove a compromised connector quickly? A team that has no independent answer may be allowing a tool marketplace or a model-generated suggestion to govern production authority. Give those decisions to accountable people and controlled deployment processes.

3. An admission manifest for tools

An admission manifest is a simple, reviewable declaration of the expected tool. Include the logical name, internal owner, version, immutable artifact digest, approved publisher or signer identity, expected build identity, source repository or release reference, dependent components, supported operations, minimum privileges, allowed network destinations, permitted data categories, resource limits, maintenance contact and a rollback reference. It should also name the verification policy version and exactly what result allows deployment.

Use a digest rather than relying on a floating label such as “latest” to identify a specific release. The digest must be checked against the retrieved artifact through a trusted mechanism; writing a hash into the same untrusted text file and trusting it blindly achieves little. Record which signing identity and issuer are expected, not merely that a signature exists. If a publisher changes identity, obtain a separately verified authorisation for that change rather than automatically trusting whichever identity happens to sign the new artifact.

Map direct and transitive dependencies. A top-level connector may be built from six named material units, one of which is a helper library updated independently. An inventory of only the top-level package leaves a blind spot. A software bill of materials can improve visibility, but its existence does not establish absence of vulnerabilities or guarantee completeness. Verify critical dependency versions, hashes and origins according to consequence, and record uncertainty when a supplier does not expose the necessary evidence.

The manifest should also contain a runtime contract. A “read learning calendar” tool must not be allowed to receive a payment credential just because both applications use the same agent process. A “summarise a PDF” tool should not gain arbitrary filesystem or internet access by default. Enforce least privilege in the tool host, network policies, access grants and human approval rules. A model’s tool-selection prompt is helpful routing information but not a reliable security boundary.

4. Verify bytes, identity and build origin

The SLSA build track describes successive levels of evidence about how software is built, while its build provenance model records how an artifact was produced. The security value comes from checking provenance against an expected trust policy, not simply possessing a provenance file. Do not confuse build provenance with a claim that the program’s behaviour is harmless or that all dependencies are benign.

The Sigstore Cosign verification documentation describes checking a signed artifact and, in identity-based flows, the expected certificate identity and issuer. The verifier must know what identity it trusts in advance. Otherwise it can mistakenly accept an artifact signed by a perfectly valid but unrelated actor. Verified signature, correct artifact digest, recognised issuer, intended signer and approved release all need to agree with the manifest.

Separate integrity checks from source checks. A digest comparison tells you the bytes match an expected value. A signature check links signed data to a key or identity under a trust configuration. A provenance check tests assertions about build origins and materials. Dependency analysis and security testing investigate additional risk. Human or automated admission policy decides whether all evidence is sufficient for this use case. Skipping any layer should be a documented risk decision, not a silent green check.

If verification fails, stop admission and preserve a small record: expected digest, observed digest, expected signer, observed identity, build reference and the policy check that rejected it. Do not execute an untrusted installer to see if the failure was harmless. Ask the supplier for a corrected release or change in declared trust relationship through a separate, authenticated review. A successful repair should produce fresh evidence, not a manually edited status flag.

5. Review capabilities, not just packages

A correctly signed tool can be unsuitable because it can read wider datasets, send material to a new destination, mutate records without user approval or return untrusted instructions disguised as policy. Review tool descriptions and command schemas as untrusted third-party interface text. Bind them to an approved capability set with parameter validation, destination restrictions, explicit side-effect classification and independent checks on requested operations. Test both valid and denied requests under a least-privileged service identity.

Distinguish a tool’s advertised operation from what the executable can physically do. A function called search_library may have a process-level token that also permits deletion. If its runtime is compromised or its configuration drifts, the descriptive name offers no protection. Grant the execution identity only what the business contract requires and constrain paths, endpoints and transaction size. On every sensitive call, compare the proposed action with the original user mandate and current approval state.

Include negative tests. The admitted connector should refuse an out-of-scope account, a malformed identifier, an unapproved write and an attempt to send confidential data to an unknown endpoint. A tool that returns a plausible answer but silently calls another service is not passing. Keep test data fabricated and avoid using live student or customer records during screening. After rollout, telemetry should reveal new destinations, changed permissions, unusual volume and unexpected error patterns.

For wider secure-development context, NIST SP 800-218, Secure Software Development Framework Version 1.1, sets out practices to reduce software-vulnerability risk. As of October 2026 NIST lists a proposed revision, but it is not the same thing as a final replacement. A high-quality integration combines producer practice, verified distribution, runtime restriction and observability rather than treating any one certificate as a full security warranty.

6. Worked laboratory: four connector releases

The fictional North Harbour Study Archive is considering four new connector releases: Atlas for calendar reads, Birch for catalogue search, Cedar for citation export and Delta for support-ticket triage. Each release has six material units in the team’s teaching manifest: the connector artifact, its declared build result and four dependencies. That creates four × six = twenty-four artifact or material checks. This is a simplified educational inventory, not a claim that every real connector has exactly four dependencies or that all materials receive the same type of proof.

Atlas passes all six checks and its negative capability tests. Birch passes five; its remaining dependency’s retrieved digest does not match the pinned expectation. Cedar also passes five and has a different digest mismatch in an included library. Delta passes four, but one material was built by a different builder identity than policy allows and another dependency lacks the required origin record. The team does not install Birch, Cedar or Delta merely because most checks are green. The rule is that all admission-critical evidence for a release must pass, with any exceptions approved through a specific risk decision.

The reviewers contact the authenticated maintainers through known support channels. Birch and Cedar receive corrected artifacts together with release records that match the original approved expectations. The new bytes are independently downloaded and verified rather than blessing the previous mismatches. Their negative runtime tests also pass. Delta still has the unexpected builder identity and missing material provenance; no approved exception covers either one. Delta remains quarantined. Nothing about Atlas’s successful verification confers trust on Delta, even if the same agent would call both.

The admission ledger records the exact reason and evidence for each decision. Atlas: six material checks passed, capability gates passed, admitted. Birch: five initially passed, corrected digest reverified, admitted under a new artifact reference. Cedar: five initially passed, corrected material independently checked, admitted. Delta: four material checks passed, two unresolved blockers, not admitted. Dates, source revision, policy version, reviewer and artifact digest are part of the stored evidence. The ledger retains no executable secrets.

  • Atlas: 6 of 6 material checks passed initially — admitted.
  • Birch: 5 of 6 passed; one digest mismatch corrected and independently reverified — admitted only after correction.
  • Cedar: 5 of 6 passed; one different digest mismatch corrected and independently reverified — admitted only after correction.
  • Delta: 4 of 6 passed; unexpected builder and missing dependency origin remain — blocked.
  • Before correction: 6 + 5 + 5 + 4 = 20 of 24 material checks passed.
  • After two verified corrections: 20 + 2 = 22 of 24 checks passed; three of four connectors can be admitted.

Notice the review has two orthogonal questions. Material verification is about what was supplied and whether it matches the approved origin evidence. Capability testing is about what the installed tool can do with its permissions. A connector can have perfect package provenance and still fail a security test because its default policy allows access to every student record. The team only admits a release when both dimensions satisfy its risk policy. There is no mathematical trick that converts a high average material pass rate into permission for a failing connector.

7. Check the 24-artifact arithmetic

Calculate the initial material pass fraction: 20 ÷ 24 = 0.833333…, or approximately 83.3%. After two independent corrections it is 22 ÷ 24 = 0.916666…, or approximately 91.7%. That is an increase of two material checks or about 8.3 percentage points. The denominator is checks, not vulnerabilities, vendor trust scores, probabilities of compromise or tool releases. It says nothing about whether the unresolved failures are serious. In this packet, they are admission blockers.

Connector-level admission has its own denominator. Three of four releases meet every required gate, so 3 ÷ 4 = 75% are deployable under this fictional policy. It would be wrong to report “91.7% of agents are safe” simply because 22 of 24 checks passed. Two failures are concentrated in one connector that is entirely blocked. A stronger question is whether any prohibited capability can enter production. If the answer is no, a hold may represent the security control working exactly as intended.

Suppose a manager suggests ignoring the remaining two checks because Delta’s feature is urgent. The implicit assertion is that a successful four-of-six record provides acceptable trust. But the missing builder identity and origin evidence may prevent the team from establishing which code was actually produced and from where. Those are not interchangeable with low-risk documentation typos. A quantified exception would need its own threat analysis, scope reduction, monitoring, expiry and accountable acceptance; a numerical average cannot authorise it.

One more accounting trap is to count repair attempts as new material units. Birch’s original mismatched dependency and its corrected replacement are two observations about one required position in the manifest, not two separate requirements that make the denominator twenty-five. If both observations are retained for audit, the verification history can have more events while the final decision still evaluates twenty-four required slots. Keep evidence-event counts, required gate counts and deployable-release counts separate.

8. Runtime safeguards after admission

Admission is not the end of verification. A connector may be safe to install but capable of causing harm when it receives a broad credential or untrusted text from another tool. Run it under a least-privileged identity; restrict filesystem locations, network destinations, data categories, operation verbs and output size; and prevent remote content from becoming a source of instructions. Where the platform supports isolation, use meaningful sandboxing and egress controls. A model prompt saying “do not misuse tools” is not a substitute.

Maintain an immutable reference to the admitted artifact in deployment configuration. Automatic upgrades from a floating tag should go through the same release gate before receiving production authority. If a transitive dependency changes, determine whether the deployed executable has changed. A signing ceremony for an earlier artifact does not authenticate a different digest that appears tomorrow. Review important configuration differences such as tool command schemas, allowed endpoints and permissions alongside code changes.

For write-capable tools, require an application-level action contract: identify the user’s intended result, validate arguments, recheck current authority, classify the side effect and obtain independent readback. Idempotency keys help prevent accidental repeats, but they do not solve permission abuse or malicious tool output. A tool that edits a calendar should not also grant itself access to payment records. Test explicit denials and keep the trust boundaries measurable.

Observe the deployed tool by verified version label, operation type, data class and destination. Unusual outbound traffic, sudden increases in denied operations, changed response fields or missing audit events are reasons to investigate. Interpret anomalies carefully: a legitimate service outage may cause retries, and a maliciously changed tool might intentionally imitate ordinary traffic. Runtime telemetry informs a human-owned response; it cannot retroactively prove a build was trustworthy.

Remote service connectors require extra caution. Even if a client binary remains pinned, the external service can change validation logic or response content. Define allowed API versions, stable response schemas, service ownership and escalation paths. Treat responses as potentially untrusted data and verify important facts against authoritative sources. If a provider cannot promise deterministic behaviour or expose sufficient evidence, narrow the tool’s permissions and the consequences of automatic action.

9. Investigation and containment

Imagine Delta somehow appears in a staging environment after a deployment script bypassed the admission gate. Do not immediately copy every staging token or diagnostic file into a public incident channel. First restrict its network and credential access, stop consequential work, preserve the verified artifacts and deployment configuration, and determine which operations actually ran. Compare the observed digest, installer history and runtime logs against the approved manifest. The point is to establish scope without making the containment process another leakage path.

If a production connector is suspected of being substituted, identify its exact deployed artifact and reachable data. Pause write operations as needed, revoke compromised credentials, isolate the workload, and seek an approved, independently verified previous release. Reconciliation of external side effects is separate from replacing code: a tool may already have sent messages or changed records. Query those systems of record, document what is known and hold uncertainty open rather than declaring recovery because a clean container starts.

A good incident record distinguishes suspected cause, verified observation and residual unknowns. “A digest differed from policy” is an observation. “An attacker changed the package” is a hypothesis until supported by evidence. A signature that verifies under an unexpected identity is not necessarily forged; it might be a legitimate release using a new builder, but the trust policy still requires an independent decision before admission. Calibrated language avoids both unwarranted reassurance and unsupported accusations.

After containment, improve the gate. Identify whether the bypass was due to missing verification, overly permissive deployment credentials, a floating package tag, an incomplete dependency list or an unaudited exception. Write a regression test that would have prevented this exact failure, then test with a harmless deliberately mismatched artifact in an isolated environment. The aim is to repair the control path, not only to remove one suspicious package.

10. Diagnose and repair common failures

Failure A: a package digest changes although its semantic version label is unchanged. The registry tag may be mutable, an artifact may have been rebuilt or a mirror may be inconsistent. Do not automatically update the approved digest to the new value. Retrieve the expected release details through a trusted route, compare build provenance and request a formal update if needed. A legitimate rebuild is still a different artifact requiring validation.

Failure B: a signature is valid, but its certificate identity differs from the allowed publisher. The cryptography may be working correctly while the policy check fails. Confirm the expected identity from an independent authority, reject the release until a new publisher is authorised, and retest both signature and identity. Never switch verification to “accept any signer” for convenience; that defeats the reason to use identity-based signing.

Failure C: the connector passes static package checks but requests access to a new remote endpoint. The build could be authentic while its configuration or dependencies changed the operating boundary. Compare network allowlists and permitted destinations, examine the change request, deny unauthorised egress and retest. Origin integrity cannot substitute for least privilege. Similarly, a benign tool description cannot authorise a hidden write capability.

Failure D: a software bill of materials lists dependencies but one entry lacks a verifiable origin. A list of names is helpful inventory, not full provenance. Determine whether the gap is material to the approved threat model, obtain additional evidence or hold the connector. If a formal exception is accepted, record why, who authorised it, its duration and compensating restrictions. A workaround should never be concealed in a generated assurance summary.

Failure E: a rollback to an earlier signed package restores connectivity but repeats an external operation. The artifact fix addressed software identity, not transaction idempotency. Reconcile side effects before replay, use stable intention IDs, revalidate user approval and make “unknown result” a supported state. Coordinate with incident response and disaster recovery when a tool release may have affected both the code and the data it manipulated.

11. Transfer exercise and worked solution

A youth-science club needs three connectors for a laboratory diary, a reading catalogue and a volunteer sign-up system. Each has four admission-critical checks: pinned artifact digest, expected signer, approved origin record and least-privileged runtime destination. The diary connector passes all four. The catalogue connector passes all four. The sign-up connector passes two, but its builder identity is unexpected and its new runtime policy permits outbound requests to a destination the club has not approved. Ten of twelve checks pass. How many connectors can the club deploy, and how should it handle the problematic release?

Solution: 10 ÷ 12 ≈ 83.3% of required checks pass across the packet, but only two of three connectors pass every gate. The deployable fraction is 2 ÷ 3 ≈ 66.7%. The sign-up release stays held. Confirm the builder change through a known, independent identity channel; independently verify any corrected provenance; refuse the unapproved destination until the club’s data-handling and permission review explicitly accepts it. Correcting the signer evidence alone does not make the extra outbound destination safe.

Now change the setting: instead of an installed package, the sign-up system becomes an externally hosted service, and the club receives only a verified client library. The client’s signature cannot prove the remote server’s implementation or data retention. Adjust the admission contract to verify the client artifact while limiting its accessible data, naming the service operator, restricting API methods, checking returned state and documenting what cannot be verified inside the provider. The method transfers because it follows the true trust boundary, not an assumption that every tool lives in one container.

A further extension asks the student to prioritise controls under a limited budget. If only one new check can be automated this week, choose based on probable consequence and existing gaps, not on which percentage improves most. A reproducible digest verification gate may protect every package update; a new denial test may protect the highest-risk write tool. Defend the choice with the trust map and a concrete counterexample, then schedule the remaining control rather than calling the deployment safe forever.

12. Limits, governance and uncertainty

A software-supply-chain attestation gives bounded evidence about an artifact and its creation. It cannot by itself prove absence of vulnerabilities, privacy compliance, source truthfulness, non-malicious dependencies or safe downstream decisions. Reproducible builds can be helpful evidence but depend on controlled inputs and appropriate verification. Signed software can still contain mistakes or intentionally harmful features from a trusted publisher. Treat assurances as properties with explicit scope and test conditions.

Complexity brings costs: large dependency graphs, frequent releases, hard-to-verify remote services, key rotations for signing identities, incomplete metadata and compatibility pressures. Teams need an owner for trust roots and exception approval, an update cadence, a rollback path and a fast revocation mechanism. They also need a way to tell users when a service is held because evidence is missing. An honest hold can be more responsible than a polished but unjustified claim of safety.

The human lesson is that provenance and authority are related but separate. Knowing where an artifact came from is not the same as allowing it access to a learner’s personal records. Verify the source, constrain the capability and independently inspect the result. These are engineering measures available now. They should not be marketed as proof of presently existing artificial superintelligence or as a substitute for organisational accountability.

Frequently asked questions

Is a signed tool automatically safe?

No. A valid signature can link bytes to a signing identity under a configured trust root. It does not establish that the signer’s design is secure, that the executable is appropriate for a sensitive task, or that the runtime has the right permissions.

Why verify a digest if the registry already names a version?

Versions and tags may be mutable or ambiguous. A digest identifies exact bytes for comparison with an approved expectation. The expected digest must come from a trustworthy source rather than from whichever package was downloaded.

Is an SBOM a guarantee that every dependency is harmless?

No. It is an inventory aid and may be incomplete. It supports questions about components, versions and exposure, but security depends on provenance, testing, update practice and controls around the running system.

What if the connector is only a remote API?

Verify the local client and credentials that you control, and separately assess the remote service’s identity, contract, data boundaries and observable behaviour. Do not claim insight into inaccessible server internals.

Should we disable everything if one connector fails verification?

Not necessarily. Isolate the affected connector, classify shared dependencies and credentials, and continue unrelated approved services if their risk remains acceptable. The response should follow an impact assessment rather than a blanket or cosmetic action.

What evidence should an auditor receive?

A versioned manifest, expected and observed artifact identities, signature and provenance verification results, dependency evidence, permission tests, documented exceptions and deployment readback. The audit should include what remains unknown.

Original standards and further reading

Reader pathways

Next, read safe change control for phased release gates, chaos testing for controlled failure experiments and incident response for containment. The How X Works hub and Gold Standard of Education connect the practical idea to learning, careers and society: verify where something comes from, test what it is allowed to do and keep a clear route to stop when evidence fails.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading