Finding Third-Party Applications by Name in the Software Catalog With AI Search

Package managers cover most software. On Windows that means winget and Windows Update, and on Linux apt, dnf, zypper, snap, and flatpak. The Software Catalog exists for everything else. That covers proprietary line-of-business tools, standalone installers, and vendor software that no repository tracks. It lives under Systems > Patch Management. A third-party application is added by typing its name into a search box, and AI resolution covers the applications that package repositories do not list.

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. An app already installed somewhere in the fleet resolves with the package id the agents 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 has the app, a fallback appears to 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 label states how the data was obtained:

• 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 resolution steps 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 resolves metadata and does not deploy software. Every entry the AI resolves lands in a needs-review state and cannot be deployed until an administrator verifies it. An AI web search locates a vendor download page quickly, and that result is not verified enough to authorize unattended 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. In both modes the output enters the script approval pipeline as a pending script. It cannot run on any agent until it is reviewed and approved, which is 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. That can be a verified download URL, a winget package id, or a hub-seeded binary. Entries with none of those are inventory records and are not deployable packages. The dashboard reports that state instead of 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. An organization can route that event, such as a new Chrome release, into a ticket, a notification, or a staged deployment. That deployment uses 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 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 source 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 main case. The AI web search locates the official vendor source and the entry lands as needs-review. Once verified, it deploys through hub-distributed installers with an approved script and is tracked for new releases via the catalog_version_update trigger.