The Software Catalog: Third-Party App Management with AI Search

Package managers cover most software: winget and Windows Update on Windows, apt, dnf, zypper, snap, and flatpak on Linux. The Software Catalog exists for everything else: proprietary line-of-business tools, standalone installers, and vendor software that no repository tracks. It lives under Systems > Patch Management, and its defining feature is that you can find any third-party application by typing its name into a search box, with AI filling the gaps that package repositories leave.

This post documents how the search works, what the AI does and does not do, and the verification gates between an AI-resolved catalog entry and software actually running on an endpoint.

Searching for an app by name

The catalog's add flow starts with a search box. Type an application name ("Google Chrome", "7-Zip", "Notepad++") and the search runs against two sources at once: the public winget catalog, and the organization's own Linux fleet inventory (so an app already installed somewhere in the fleet resolves with the package id agents actually observed). A match prefills the catalog entry with the package id, publisher, and version metadata, and installs can route through the native package manager.

When neither source knows the app, a fallback appears: search the web for the official download. That runs an AI web search which locates the vendor's official site and extracts the download URL, current version, publisher, and silent-install arguments. Every entry records where its data came from, and the source labels are deliberately blunt about trustworthiness:

• winget_manifest: read from the community-maintained winget manifest on GitHub. No AI involved.
• web_search: found via a grounded web search. The URL should be verified.
• ai_web_search: found by the AI reading vendor pages. The URL should be verified.
• ai_memory: the model answered from its training data without a live search. Treated as the least reliable source.

Two bulk actions apply the same machinery across the whole catalog: "Scan for PM" matches name-only entries against winget and the Linux package managers with no AI involved, and "Resolve remaining with AI" runs the AI resolution over whatever is left. AI resolution consumes AI quota like any other AI feature; package-manager matching does not.

What the AI cannot do

The AI finds metadata. It does not deploy software. Every entry the AI resolves lands in a needs-review state and cannot be deployed until an administrator verifies it. This is deliberate: an AI web search is the right tool for locating a vendor download page in seconds, and the wrong thing to trust unattended with code execution across a fleet.

Verification continues past the review step. Before any downloaded installer executes on an agent, it is checked for EV code signing via Authenticode (WinVerifyTrust) and a SHA-256 match anchored in the version manifest. A file that fails either check is deleted and the deployment aborts. There is no bypass prompt; overriding a failed check requires an explicit policy change.

Install scripts and approval

Each catalog entry can generate an install script through a "Draft install script" action, in one of two modes: a deterministic template, or an AI draft that accounts for the entry's silent-install arguments and platform. Either way the output enters the script approval pipeline as a pending script; it cannot run on any agent until it is reviewed and approved, the same gate every script in the platform passes through.

Distribution and installation

Verified installers can be seeded onto Distribution Servers, agents that act as LAN-local file hubs, so a 200 MB installer crosses the WAN once rather than once per endpoint. Installation requires an install source: a verified download URL, a winget package id, or a hub-seeded binary. Entries with none of those are inventory records, not deployable packages, and the dashboard says so rather than failing at install time.

Version tracking and automations

Catalog entries track their vendor's release source. When a new version of a tracked app is detected, the catalog_version_update automation trigger fires, so an organization can route "Chrome shipped a new version" into a ticket, a notification, or a staged deployment through the same ring-and-verify pipeline used for OS patching, where post-patch health checks draw on the kernel event stream.

Keys and cost

The AI web search runs on the workspace's AI key: your own key if configured (BYOK), otherwise the platform allowance. No separate search API key is required. winget manifest and Linux inventory lookups involve no AI at all and only need outbound access to GitHub. On OpenAI or Azure keys, where the Anthropic web-search tool is unavailable, resolution falls back to model memory or an optional Brave Search key, with the source label downgraded accordingly.

Frequently asked questions

Can ET Ducky search for any third-party app with AI?

Yes. The Software Catalog's search box takes any application name. winget and the organization's Linux fleet inventory answer first; for apps neither tracks, an AI web search finds the official vendor download, version, and metadata. AI-resolved entries are marked needs-review and cannot deploy until verified.

Does the AI download and install applications automatically?

No. AI resolution fills in catalog metadata only. Deployment requires administrator verification, a fail-closed installer check (EV code signing and a SHA-256 manifest match, with failures deleted and aborted), and an approved install script.

What happens when an app is not in winget or a Linux repository?

That is the catalog's core case. The AI web search locates the official vendor source, the entry lands as needs-review, and once verified it deploys through hub-distributed installers with an approved script and is tracked for new releases via the catalog_version_update trigger.