From WYSIWYG to WYGIWYN: securing software that agents build to order

For thirty years the promise of software was WYSIWYG: What You See Is What You Get. You saw the product in a window, a box or a download page, and what you got was the same thing everyone else got. That era is ending. The new promise is WYGIWYN, What You Get Is What You Need: a coding agent reads your task, picks the packages, the model, the skills and the connectors, writes the glue, and hands you an application assembled for your team and nobody else. My argument in this post is simple. When every build is made to order, the supply chain becomes unique per build, "known good" stops being something we can share, and security has to move to the evidence of what each build actually contains and does.

This post is for heads of AppSec, platform leads and CISOs who have watched coding agents become the default way their engineers work. You will get a model for why the old controls thin out, eight controls that hold up when every build is different, and how each one works in Safeguard today. Where a control is a general practice rather than a Safeguard feature, I say so.

The short version

• WYSIWYG security relied on sameness. Millions of teams ran the same release of the same package, so one advisory or one patch protected everyone at once.
• WYGIWYN breaks the sameness. Agents choose dependencies, models, skills and MCP connectors per task, and generate the code between them. Two teams asking for "the same" service get different trees, call paths and tools.
• The attacks have already moved there. The nx compromise of 26 August 2025 shipped a payload that drove local AI command-line tools with their permission checks switched off. The Shai-Hulud worm compromised over 500 npm packages in September 2025, per CISA. In the first 28 days of October 2026, GitHub's advisory database published 913 malware advisories for npm and 168 for PyPI.
• So the unit of security becomes the build. Each build needs its own SBOM and AI-BOM, verifiable provenance, static reachability for what is actually called, a policy gate in CI, a package firewall in front of installs, explicit permission modes for the agents doing the work, and fixes that arrive as pull requests your own CI tests.
• Shared intelligence still matters, as an input. Advisories, exploit data and hardened components feed the per-build decision. They no longer make it for you.

What WYSIWYG quietly gave security

WYSIWYG started as a description of editors: the document on screen matched the document on paper. It became a fair description of how software was distributed. A product was a fixed thing. A library was a fixed thing. Version 2.17.1 of a logging library was byte for byte the same file in a bank, a game studio and a hospital.

That sameness was the hidden foundation of most of the security tools we still use. A CVE record that says "versions below X are affected" was true for everyone holding that version, and "upgrade to X" was the same fix for everyone. One researcher fuzzing a popular parser protected every user of it; the cost of knowing was paid once and shared. "Known good" was a social fact: fifty million downloads and no incident was a crude form of review, and it mostly worked. And a pull request that added a dependency was written by a person who chose it and read by another who could ask why.

None of this was perfect, and Log4Shell showed how slowly "upgrade to X" travels. But the model held because we protected mostly the same things, used in mostly the same ways.

What WYGIWYN means in practice

The phrase I keep coming back to is "assembled to order". A modern coding agent does not hand you a product. It hands you a build, and the build is the result of dozens of choices it made on your behalf.

The adoption numbers are no longer a forecast. The Stack Overflow Developer Survey 2026 reports that "the overwhelming majority of respondents now use coding assistants and agents daily (73%)", and names Claude Code (66%) and GitHub Copilot (59%) as the leading coding agents among respondents (accessed 29 October 2026). Two years ago Google's chief executive said on the company's Q3 2024 earnings call, on 29 October 2024, that "more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers." GitHub's Octoverse report, published 28 October 2025, counted more than one million pull requests created by its coding agent between May and September 2025, and 1.1 million public repositories using an LLM SDK.

The survey also has the most useful line for security: 48% of respondents say they trust AI "when they can easily validate the answers." That is this post's thesis in one result. Agents will be trusted where their output can be checked cheaply, and the security job is to make that check cheap for every build.

The anatomy of a build assembled to order

Here is what an agent actually assembles when someone asks it to "add a summarisation endpoint that reads tickets from our tracker":

Every row is a supply chain input, and under WYGIWYN all of them are chosen quickly, per task, often by software.

Why "known good" stops being a shared property

There are three separate reasons, and it helps to keep them apart because each one calls for a different control.

1. The combinations are new every time

Even with only popular packages, an agent combines them differently per task, pins whatever versions it remembers, and writes different code between them. A library flaw matters only if your code reaches the vulnerable function, and under WYGIWYN the code that decides that is rewritten with every change. A finding that was unreachable last Tuesday can be reachable after this morning's prompt.

2. The agent's choices create names nobody vetted

Language models suggest packages that do not exist. The most thorough study I know, "We Have a Package for You!" by Spracklen and colleagues (USENIX Security 2025, arXiv 2406.10279), generated 576,000 code samples and found that on average at least 5.2% of the packages suggested by commercial models and 21.7% of those suggested by open source models were hallucinated, with 205,474 unique hallucinated package names. Each of those names is a registration an attacker can make. Popularity tells you nothing about a package that was published last night precisely because an agent keeps asking for it.

3. New ingredient types have no shared registry of trust

There is a CVE system for packages. There is nothing comparable, yet, for a skill folder copied from a forum, a rules file in a repository, or an MCP server someone added to their agent's configuration on a Friday. The MCP specification lets a server advertise any set of tools through tools/list and lets a client call them through tools/call. Each tool is a capability the agent can try to use. Nobody downloads your engineer's particular combination of servers fifty million times, so nobody else's experience vouches for it.

The incidents already reflect this

You do not have to take the argument on theory. The last fourteen months of incidents read like a list of WYGIWYN failure modes.

nx, 26 August 2025. Malicious versions of nx and several @nx packages were published to npm after attackers abused a GitHub Actions workflow injection to obtain the project's npm token. Nx's advisory (GHSA-cxm3-wv7p-598c) puts the exposure window on the evening of 26 August, ending with npm's removal of the affected versions at 10:44 PM EDT. The postinstall script scanned the file system, collected credentials and posted them to new public GitHub repositories under the victim's own account. The detail that should change how you think about agents: the script carried a prompt that cast the AI tool as a "file-search agent", and per Wiz's analysis it invoked locally installed AI command-line tools (Claude, Gemini and Q are named) with the flags --dangerously-skip-permissions, --yolo and --trust-all-tools to do its reconnaissance. Wiz reported more than a thousand valid GitHub tokens leaked in the first phase. The advisory itself makes a point every platform team should copy into a runbook: "Transitive dependencies, AI agents, editors, other editor extensions, other scripts" can all trigger an install without a person typing npm install.

Shai-Hulud, September 2025. CISA's alert of 23 September 2025 described a self-replicating worm that "has compromised over 500 packages", harvested GitHub tokens and cloud keys, and used the stolen npm credentials to inject itself into other packages the victim maintained. CISA's first recommendation was a dependency review of everything built on npm, including nested dependencies and cached copies in artifact repositories.

Spring 2026. Red Hat's bulletin RHSB-2026-001, first published on 1 April 2026, "Multiple supply chain compromises of open source projects", lists compromises affecting BerriAI LiteLLM, Aqua Security Trivy, Checkmarx KICS, Telnyx, Axios and various npm packages. Two things stand out. LiteLLM is a gateway that sits between applications and model providers, and Trivy and KICS are security scanners. The tools we add to make AI and supply chains safer are themselves supply chain inputs.

October 2026, the background rate. As of 29 October 2026, GitHub's advisory database listed 913 malware advisories for npm published between 1 and 28 October 2026, covering 840 distinct package names, and 168 for PyPI, covering 168 packages. I counted those myself from GitHub's public malware advisory listings, filtered by type, ecosystem and publication date. Most reach few machines, but all are names an agent could be talked into installing.

OpenCode Console, 16 to 19 October 2026. The Hacker News reported on 19 October that an intruder reached a legacy system at OpenCode on the night of 16 October, which may have exposed third party model provider keys that users had saved in OpenCode Console, the company's optional hosted service. OpenCode said 1.4% of Console users were affected and told them to revoke and replace their keys. Its co-founder stressed that this was "the OpenCode Console, not OpenCode itself", and the report gives OpenCode's position that keys stored locally by the CLI and desktop apps were not part of the breach. OpenCode had not confirmed that any key was copied or used. I include it for a narrow reason: the services around a coding agent, and the provider keys they hold, are part of the build's supply chain too.

None of these incidents needed a novel exploit. They needed a build process that would accept whatever showed up, and an agent or a script with enough permission to act on it.

The principle: secure the build, not the brand

If the supply chain is unique per build, the evidence has to be unique per build too. That is the whole shift. Under WYSIWYG we asked "is this package known to be good?" Under WYGIWYN the useful questions are about this build, today:

1. What exactly went into it, including the AI parts?
2. Where did each piece come from, and can that be verified?
3. Which of the known flaws in those pieces does our code actually reach?
4. Does this build meet our policy, decided by a machine in CI rather than by a reviewer's memory?
5. What was allowed to install during the build, and what was refused?
6. What was the agent that wrote it allowed to do while it worked?
7. When something needs fixing, does the fix arrive as a change our own pipeline tests?

Here is the concession. Per-build evidence costs compute and attention, and most of what an agent picks is still the popular packages everyone uses. CVE records, CISA KEV, EPSS and curated hardened components remain the best inputs we have. What changes is their role: they used to be the verdict, and now they feed a verdict computed for each build. The rest of this post is the eight controls that make that routine.

Control 1: an SBOM for every build, not every release

Why WYGIWYN needs it. When an agent can change the dependency tree in a single commit, a quarterly SBOM is a historical document. You need the inventory of the build you are about to ship.

What Safeguard ships. The Safeguard CLI builds an SBOM from source trees, lock files, container images and existing SBOMs. It reads CycloneDX JSON and XML (1.4, 1.5 and 1.6) and SPDX JSON, tag-value and RDF (2.2 and 2.3), and writes CycloneDX, SPDX, CSV, custom JSON, SARIF and JUnit XML. In CI, one step runs safeguard ci scan, and each push becomes a new version of its Safeguard project, named after the branch and commit (for example main-a1b2c3d). That naming matters more than it looks. It means "what was in the build that went out on Thursday" is a lookup, not an investigation.

A local scan, for a developer checking what the agent just added:

# Build an SBOM and match it locally; results stay on the machine
safeguard scan --dir . --output out/

# Read an SBOM produced elsewhere (format detected automatically)
safeguard scan --sbom sbom.json

Commit lock files, which give the real tree at exact versions. The SCA docs list the supported ecosystems.

safeguard scan reports and never fails on findings; gating is a separate decision, covered in control 5. Keeping inventory and verdict apart is deliberate: the agent can see the inventory without arguing with the verdict.

Control 2: an AI-BOM next to the SBOM

Why WYGIWYN needs it. A classic SBOM lists packages. It does not tell you which model a service calls, which SDK it uses to call it, which prompt templates ship with it, or which MCP servers its configuration wires in. In an agent-built application, those are often the most consequential choices in the build.

What Safeguard ships. AI-BOM discovery inventories AI assets across three surfaces:

Vector databases are inventoried as vector stores, and agent definitions as agents. The assets for a product are assembled into an AI-BOM, a tenant and organization scoped snapshot of your AI footprint at a point in time. CycloneDX has a machine learning BOM format for exactly this kind of record, described on its ML-BOM capability page, and our earlier post comparing AI-BOM specifications goes through the formats.

WYGIWYN also needs an inventory of the agents themselves, since each build was assembled by one running on someone's laptop. Safeguard's AI agent discovery is switched on per organisation (ask your Safeguard contact to enable it; your administrator then turns it on, and each person allows it on their own computer). It reads each supported agent's own configuration folders on the computer, as the signed-in person and never as an administrator, and reports agents, versions, permission settings, MCP servers, skills and plugins (each with a hash of its definition), local models, credentials by name only, and session activity. Results appear under Assets, Inventory, Asset discovery, with tabs for agents, models, skills and plugins, MCP servers and devices.

The part I am proudest of is the consent step. Each person can see exactly what would leave their machine before agreeing to it:

safeguard aidr collect status    # organization setting, my choice, last delivery
safeguard aidr collect show      # print what the next run would send; nothing is sent
safeguard aidr collect on        # read the notice and allow it

Environment and header values for MCP servers are never read, only their names. You learn that a server is configured with a variable called DATABASE_URL without anyone seeing the value. Our post on agent identity in Safeguard explains how to read which agent holds what access.

Control 3: provenance and signing you can verify

Why WYGIWYN needs it. When nobody chose a component on purpose, the question "who built this, from which source, and can I prove it?" is the only trust signal left that does not depend on popularity. The nx attack is the cautionary tale: the malicious versions were published with a stolen token, outside the project's normal release pipeline. A consumer who required build provenance tied to the project's own workflow would have had a reason to refuse them. In its postmortem, Nx moved all its packages to npm's Trusted Publisher mechanism and required 2FA for publishing.

What Safeguard ships. Every component in an SBOM gets a Safeguard Component Attestation Level (SCAL), a 0 to 5 rating of how trustworthy its origin and build process are, where lower is better. The attestation docs describe the steps: fetch attestations from registries and transparency logs, validate that what each attestation claims matches the component, and assign a level from what survives. Recognised evidence includes SLSA provenance, in-toto attestations and package signatures (PGP signatures, package manager signatures and publisher certificates).

SCAL feeds the component Risk Score, where attestation and provenance together outweigh package health, behavioural signals and history combined. Under WYGIWYN, "where did this come from and can you prove it" is worth more than "has anything bad happened yet".

On your own side, sign what you build. Generating SLSA provenance and publishing through your registry's trusted publishing route are general practices, not Safeguard features, and among the cheapest improvements a team can make this quarter. Our post on what npm provenance statements prove and what they don't is a good starting point.

Control 4: static reachability for what is actually called

Why WYGIWYN needs it. More dependencies, chosen faster, means more matched CVEs and a queue nobody can read. The answer is to rank by whether this build's code actually calls the vulnerable function.

What Safeguard ships. Safeguard's reachability analysis is static: it reads your code and its dependency graph and determines whether there is a call path from your code into the vulnerable function or path. It does not use runtime data to decide reachability, and I think that is the right default for agent-built software, because static analysis can run on the build before it ships, on every pull request, while the code is still changing. Two rules keep it honest:

• When the analyser cannot decide, for example because of reflection, dynamic dispatch or native code, the finding is classified as unknown and treated as potentially reachable. It is never hidden.
• Unreachable CVE findings drop to the backlog band of the priority score rather than disappearing, so you can still see them.

Reachability is then combined with exploitation evidence (CISA KEV and FIRST EPSS) and business context into one ranked queue. The post on inside Safeguard's reachability engine covers the architecture.

The WYGIWYN twist is timing. Generated code changes with every prompt, so a finding that was safely unreachable can become reachable when an agent adds a convenience wrapper. Treat reachability as a property of the build, not of the package.

Control 5: policy gates in CI, evaluated per build

Why WYGIWYN needs it. A human reviewer cannot hold an organization's dependency, license and provenance rules in their head while reading a two thousand line pull request an agent wrote in four minutes. A policy has to be code, and the decision has to happen in the pipeline, every time.

What Safeguard ships. Policies and gates are defined in the platform and evaluated against each scanned build. In CI you have two routes, and they call the same thing.

The CLI route:

# Scan this build, wait for the result, fail the job if any gate is not Passed or Warning
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on-gate all

# Scan on the runner instead of letting Safeguard clone the repository
SAFEGUARD_API_KEY=... safeguard ci scan --local --wait --fail-on-gate all

--fail-on-gate takes a gate's name, its id, or all, and fails the step when the gate is not Passed or Warning. --fail-on critical is a blunter severity threshold for dependency vulnerabilities, and a sensible first week. The default mode clones the repository, which is also what lets it run SAST; --local scans the checkout on the runner and sends only results. The CI/CD integration docs list templates for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines.

The API route, for pipelines that would rather not install a binary, is the CI scan API: start a scan with POST /api/v1/ci/scans against https://api.safeguard.sh/scm, read the result with GET /api/v1/ci/scans/{id}, and read the gate outcomes from its /gates path, authenticated with an sg_sk_ key. It is the one customer REST API, and it is deliberately narrow: start a scan, read the verdict.

What should a WYGIWYN gate check? My starting set:

Safeguard can also draft policies from plain English. Review what it drafts before you enforce it, as you would any generated code.

Control 6: a package firewall in front of every install

Why WYGIWYN needs it. The nx advisory said it plainly: agents, editors and extensions install packages without a person deciding to. The hallucination study says agents will ask for names that do not exist. And the October 2026 count says hundreds of malicious packages are published every month. A scan after install is too late for a package whose postinstall script has already run.

What Safeguard ships. Package Firewall is an install-time proxy that fronts npm and pip. It blocks malicious, typosquatted and dependency-confusion packages before they reach a laptop, a CI runner or a build. Because it sits on the fetch path, it sees transitive fetches too, with no separate lockfile parsing step. It has three outcomes (allow, warn, block) plus two modes that make rollout safe: audit mode records what would have happened without blocking anything, and quarantine mode holds a flagged package for review instead of installing or hard-blocking it. Every decision other than allow becomes a dependency finding with the ecosystem, package, version and the rule that fired.

# Start a local or CI proxy in audit mode
safeguard pkgfw start --mode audit --port 8899

# One-shot check of a single version, printed as JSON; exits 1 on block
safeguard pkgfw check --ecosystem npm --name left-pad --version 1.3.0

The proxy serves ecosystem-prefixed paths, /npm/ for npm and /pypi/ for pip. Point npm's registry setting and pip's index-url at those paths, replace the public index rather than adding to it, and re-key CI caches so every package is fetched through the proxy at least once. A bare package path with no ecosystem prefix returns 404 by design. The Package Firewall docs and our post on Package Firewall for dependencies cover the full rollout.

For agent workflows, run safeguard pkgfw check over the lockfile diff in a pull request check, so a newly suggested package is evaluated before anyone runs the install. And close the side door (a general practice): if runners can reach public registries directly, one stray --registry flag in a generated script bypasses the proxy, so block direct registry access for build jobs where your network allows it.

Control 7: explicit permission modes for coding agents

Why WYGIWYN needs it. This is the control the nx payload aimed at. It did not exploit the AI tools. It ran them with their permission checks switched off, because that was one flag away. An agent's permission mode is part of the build's supply chain: it decides what could have happened while the code was being written.

Permission modes should be explicit, chosen per context, and boring, not a slider you nudge up when you are in a hurry.

What Safeguard ships. The Safeguard CLI agent has six permission modes. They are separate modes, not a ladder, and the right one depends on where the agent runs:

Shift+Tab cycles through the modes in an interactive session, and --permission-mode (or -a) selects one at start-up. Older names are still accepted: ask means supervised, auto means guarded (not autonomous), and yolo means autonomous. The design choice I want to point out is in the last row. The dangerous mode exists, because sometimes you want an agent to run unattended in a disposable environment, but it is refused outside a sandbox unless you pass a flag whose name tells you exactly what you are doing.

# An unattended job in CI: only pre-approved actions run
safeguard exec --permission-mode strict "summarise the critical findings in this repository"

MCP connectors get their own setting, separate from the session modes. safeguard mcp add --approval-mode ask|allow|deny sets how calls to that server's tools are treated, and the default is ask. On the server side, Safeguard's own MCP server starts each new workspace with a small default set of read-only tools; every other tool is off until an administrator enables it, and tool gating fails safe to that small set if resolution cannot complete.

For other vendors' agents the switches are theirs, but the principle holds: inventory the modes in use (control 2 shows you) and treat any "skip all permission checks" flag as sandbox-only. Our post on Claude Code security posture works through one agent in detail.

Control 8: fixes as pull requests your own CI tests

Why WYGIWYN needs it. If builds are made to order, fixes have to be too. "Upgrade to X" implies a different change in every repository. A ticket puts that work back on a person; a pull request does the work and leaves the decision with the team.

What Safeguard ships. When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version. Your own CI runs your tests on that pull request, and your branch protection decides what merges. Safeguard does not run the tests itself in this path, and I think that is correct: your pipeline is the only thing that knows what "working" means for your build.

The details are deliberately plain, so the pull requests are easy to recognise and audit:

• Commits are authored by safeguard-autofix[bot]; the pull request comes from your connected source control account.
• Branches are named devtasks/Safeguard-SH- followed by the task id, and carry the labels safeguard-sh, security and automated-remediation.
• Upgrades are classed as compatible, minor or major, and major upgrades are flagged as possibly breaking.
• For npm, the pull request also rewrites the lockfile.
• Auto-merge is a separate switch under Settings, Automation, and it is off by default. Your team decides what, if anything, merges without a human.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

A per-build checklist you can adopt this month

If you take one thing from this post, take this list. Each item is something you can check for the next build that goes out, not a maturity model for next year.

1. Inventory the agents. Turn on agent discovery for a pilot group, have each person run safeguard aidr collect show first, and look at which permission modes, MCP servers and skills are actually in use.
2. Pick permission modes per context and write them down. Supervised or plan on laptops by default, edits or guarded where a team has a policy, strict for CI, autonomous only in sandboxes.
3. Put Package Firewall in audit mode in front of npm and pip. Route CI first, then laptops. Read a week of audit decisions before you block anything.
4. Run safeguard ci scan on every push. Start with --wait --fail-on critical so nobody is surprised, then move to --fail-on-gate with the gate set above.
5. Turn on AI-BOM discovery for your products. Make a new model provider or MCP server in a product an owner's decision.
6. Require provenance where you can. Gate production products on SCAL, and publish your own packages through your registry's trusted publishing route.
7. Let reachability order the work. Read the reachable, KEV and high EPSS findings first; leave the backlog band for scheduled clean-up.
8. Accept fixes as pull requests. Let your CI decide whether they pass. Keep auto-merge off until you have watched a month of them.

Frequently asked questions

What does WYGIWYN stand for?

WYGIWYN stands for What You Get Is What You Need. It is a play on WYSIWYG, What You See Is What You Get. I use it to describe software that coding agents assemble to order for a specific team and task, so that every build is different, as opposed to packaged software that everyone shares.

What is the difference between an SBOM and an AI-BOM?

An SBOM lists software components: packages, versions, licenses and their relationships. An AI-BOM lists the AI parts of a product: models and model files, AI SDKs, prompt templates, notebooks, MCP server configuration, inference endpoints and vector stores. Agent-built applications need both, because the most consequential choices (which provider, which tools) do not show up in a package list.

What does Package Firewall block?

Package Firewall is an install-time proxy for npm and pip. It blocks malicious, typosquatted and dependency-confusion packages before they install, including transitive fetches. Audit mode lets you see what it would block before you enforce anything, and quarantine mode holds a flagged package for review.

Which permission mode should a coding agent use in CI?

Strict. In CI there is nobody to answer a prompt, so only pre-approved actions should run and everything else should be denied. Autonomous mode is for sandboxes, and the Safeguard CLI refuses it outside a sandbox unless you pass --dangerously-skip-permissions.

Does Safeguard merge fixes automatically?

Not unless you turn it on. Safeguard opens the fix pull request and your own CI runs your tests on it. Auto-merge is a separate switch and it is off by default.

Is shared vulnerability intelligence still useful in the WYGIWYN era?

Yes, as an input. CVE records, CISA KEV, EPSS and free lookups such as Gold Open Source are still the best sources of what is known. What changes is that the decision about a specific build has to combine that knowledge with what the build contains, what its code calls and how it was made.

The implication

WYSIWYG let us secure software by securing the things everyone shared. That model is not coming back. When an agent can assemble exactly what a team needs in minutes, nobody will choose the generic thing instead.

So the evidence has to be as particular as the software. Every build should be able to say what it contains, where each piece came from, what its code calls, which policy it passed, what was refused at install, what its authoring agent was allowed to do, and whether its fixes passed your own CI. None of that is exotic. It is the discipline we always wanted, at a finer granularity.

The survey line I quoted earlier is the hopeful part. People trust AI where its output is easy to validate. Our job, as an industry, is to make every build easy to validate. If you want to see how Safeguard does that on your own repositories, the CLI documentation is the place to start, and plans are listed at safeguard.sh/pricing.

Sources

All accessed 29 October 2026 unless stated.

• Stack Overflow, Developer Survey 2026: AI.
• Google, Q3 2024 earnings call remarks, 29 October 2024.
• GitHub, Octoverse 2025, published 28 October 2025.
• Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025.
• Nx, security advisory GHSA-cxm3-wv7p-598c and s1ngularity postmortem.
• Wiz Research, s1ngularity supply chain attack analysis.
• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem, 23 September 2025.
• Red Hat, RHSB-2026-001: Multiple supply chain compromises of open source projects.
• The Hacker News, OpenCode Console breach may have exposed OpenAI, Anthropic and Google API keys, 19 October 2026.
• GitHub Advisory Database API, malware advisories for npm and PyPI, counted 29 October 2026.
• CycloneDX, ML-BOM capability.
• SLSA, Provenance specification v1.0.
• Model Context Protocol, Tools specification (2025-06-18).