Tracking Code Provenance When Agents Paste External Logic

A pull request arrives from an automated agent. It introduces 400 lines of clean TypeScript implementing a bespoke token-bucket rate limiter with sliding-window telemetry. The unit tests pass, edge cases are covered, and the syntax matches your existing repository conventions.

Nobody on the team wrote it. When asked during review where the core arithmetic came from, nobody knows.

The code might be a direct translation of an MIT-licensed library with attribution stripped. It might be a reproduction of an AGPL-3.0 algorithm. Or it might be a novel synthesis of public forum answers. Once that logic is committed directly into your repository, traditional scanners treat it as first-party source. The origin boundary disappears, turning clean diffs into unmeasured license risk.

Post-hoc SBOM scans do not catch pasted logic

Standard software provenance pipelines rely on manifest files. Scanners inspect package-lock.json, Cargo.lock, or Go module graphs to construct a Software Bill of Materials (SBOM). These tools evaluate direct and transitive dependencies distributed as packaged archives.

Pasted code bypasses manifest inspection entirely. When an agent extracts an algorithm from an external project and commits it directly to your tree, that logic becomes vendored code without a vendor manifest.

+------------------------------------------------------------------+
| AGENT TASK: "Implement rate limiter"                             |
|                                                                  |
|   1. Pulls external logic from unverified source                 |
|   2. Inlines 400 lines into /src/lib/limiter.ts                  |
|   3. PR passes CI (no new dependencies in package.json)          |
|                                                                  |
| RESULT: License obligations dropped; zero SBOM visibility.       |
+------------------------------------------------------------------+

Static analysis scanners looking for known strings can help, but they are brittle against modified variable names, refactored control flows, or language translations. If the ingest step does not record where the bytes came from, reconstructing the license chain after the commit requires manual forensic auditing.

Cryptographic origin tagging at ingest time

The fix is structural: code origin metadata must be bound to the payload at the moment of ingestion, not audited downstream.

If an autonomous tool imports, vendors, or adapts external logic, it must emit an ingestion receipt alongside the file modifications. This receipt couples three fields:

1. Content Digest: A cryptographic hash (such as SHA-256) of the imported logic before local modifications.
2. Upstream Source URI: The canonical repository URL, release tag, or commit hash where the original logic lives.
3. Declared License: The SPDX identifier extracted directly from the upstream license manifest.

{
  "path": "src/lib/limiter.ts",
  "origin": "https://github.com/example/rate-limiter",
  "commit": "9f8a3c2e1b4d5a6f7e8c9b0a1d2e3f4a5b6c7d8e",
  "digest": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "license": "Apache-2.0",
  "ingest_timestamp": "2025-03-30T10:14:00Z"
}

By storing this metadata in a dedicated ingest manifest (or structured commit trailers), your CI harness can enforce license compliance rules automatically. If an agent pastes code with an incompatible license or omits the origin receipt entirely, the build fails before the PR merges. For more on structuring these checks in your pipeline, see our note on capturing license metadata at the build-intent gate.

How SHPBL enforces origin boundaries

SHPBL eliminates origin ambiguity by treating capability ingestion as a governed transaction rather than an unverified text paste.

Every artifact in the SHPBL catalog is model-independent, computed rather than generated, and carries a verified license chain. When an agent requests logic via MCP access or our typed SDK, the operation must pass the Build Intent gate. The gate resolves license obligations and invariant contracts in code before returning a terminal payload.

Artifact releases are sealed with published SHA-256 checksums on our root of trust, ensuring byte-for-byte reproducibility. You receive complete software ownership without runtime hallucinations or unverified third-party code slipping into your codebase untracked.

What to enforce on Monday

You do not need to rewrite your deployment pipeline to start tracking provenance:

1. Require origin trailers on automated PRs: Configure your agent prompts and ingest harnesses to append X-Source-Origin, X-Source-SHA256, and X-Source-License trailers to every pull request that introduces new utility files.
2. Reject untracked inline vendor files: Add a CI check that flags any newly added file over 100 lines that lacks a corresponding dependency entry or ingestion receipt.
3. Establish an internal provenance registry: Maintain a single JSON schema in your repository root (e.g., .provenance.json) where autonomous tools must register any imported or adapted logic before CI will execute tests. If an agent cannot specify the source and license, the code does not enter the tree.