Manage an AI desktop app like any software with access to company data: pin an approved version range, pace updates through rings, enforce settings centrally, inventory installed versions, and make removal and deprovisioning explicit. Ask the vendor how updates are signed, how fast critical fixes ship, and which settings an admin can lock.
Why updates are a bigger question for desktop AI
AI desktop apps change fast. New tools, new connectors and new permissions arrive through updates. A version bump can quietly add a capability that your review never covered. At the same time, delayed updates leave known flaws in place. You need a policy for both sides.
A simple update policy
| Ring | Who | Pace |
|---|---|---|
| Test | Security and IT volunteers | Same day as release |
| Early | A small group of power users | After a few days without issues |
| General | Everyone approved | After a defined soak period |
| Hold | Anyone with a blocker | Pinned until resolved |
Critical security fixes should skip the soak period. Decide in advance who can approve that, and how fast.
Read release notes before each ring. You are looking for new permissions, new network destinations, and changed defaults. If the vendor does not publish notes, ask for them, and treat unannounced changes as a risk.
Enforcing settings
A policy that lives in a document drifts. Ask whether the vendor supports settings that an administrator can set and lock through your device management tool, so users cannot loosen them. Typical candidates:
- Which connectors and tool servers are allowed
- Whether file generation or scheduled tasks are enabled
- Command and folder permissions
- Telemetry and logging options
- Whether sign in must use your identity provider
Check the order of precedence too. If a user setting can override an admin setting, the lock is a suggestion.
Update integrity
Ask how the update arrives and how the app trusts it. Look for signed installers and signed update metadata, and for a way to verify a download yourself, such as a published checksum. The update framework project describes an approach for securing software update systems against compromised servers and rollback attacks, and is a useful reference for what to ask about. You do not need to design this, only to hear a coherent answer.
Inventory and removal
You cannot manage what you cannot see. Confirm that your endpoint tooling reports the app name and version, and set an alert for versions outside your approved range. For removal, write down the steps: uninstall the app, clear local caches and tokens, revoke the user's account and any tokens issued to connectors. Test them once on a spare machine.
When someone leaves, deprovisioning in the identity provider should end the desktop session. Verify that, since cached sessions sometimes outlive account removal.
Questions for the vendor
- How are updates delivered, signed and verified?
- Can admins pause or pin versions?
- What is the typical time from a reported critical flaw to a fix?
- Which settings can be enforced and locked centrally?
- Is there a changelog that lists permission and default changes?
- How does the app behave after account deprovisioning?
For Safeguard's own desktop options, the install guide for macOS is a practical example of what clear instructions look like.
A worked example: a bad Tuesday
A vendor ships a desktop update on Tuesday morning. The release notes mention a new connector feature and a security fix. Your auto update setting pushes it to 300 laptops by noon. By afternoon, a team notices the assistant can now reach a service it could not reach before, because the new feature is on by default.
Nothing malicious happened. But the permission set changed under a review that approved the older version. With rings in place, the update would have reached ten volunteers first. They would have spotted the new connector, you would have turned it off by policy, and the general release would have gone out with the setting locked.
Step by step: set up update management
- Inventory. Confirm your endpoint tool reports the app and version on every device.
- Define the approved range. For example, the current version and the one before it.
- Create rings. Test, early, general, hold.
- Read notes. Assign someone to read release notes before each ring and flag permission or default changes.
- Lock settings. Enforce the settings you reviewed so a new feature does not switch on by itself.
- Set a fast path. Define who can approve a same day rollout for a critical security fix.
- Alert on drift. Flag devices on versions outside the range.
- Test removal. Practice uninstalling the app and clearing caches and tokens on a spare machine.
| Situation | Response |
|---|---|
| Routine release | Roll through rings over about a week |
| Critical security fix | Same day to all, after a quick smoke test |
| New feature that changes permissions | Hold at early ring until reviewed |
| Release breaks something | Pin the previous version, notify the vendor |
Why pinning matters
Ask whether the app can be pinned to a version, and for how long the vendor supports an older one. If the vendor only supports the latest, you cannot hold a release, and your ring plan becomes a delay of days at best. That is a finding for your scorecard.
Checking authenticity
Verify that installers and updates come from the vendor and are signed. Where a checksum is published, compare it before installing on managed devices. A short internal procedure for this makes it routine rather than heroic, and pairs well with the guide to verifying a checksum before installing a desktop app.
Try it yourself
Click through it at your own pace, or open it full screen. Watch what the assistant is allowed to reach once a tool connection is configured.
Quick check
Should we turn on auto update for everyone?
Auto update is fine if you can pace it with rings and have release notes. Without that, pin versions and update on a schedule.
What if the vendor offers no central settings?
Then rely on device permissions and a short approved user list, and raise it as a gap in your review.
How often should we review the approved version range?
Monthly is a reasonable start. Review sooner after a vendor security notice or a major release.
Sources
Last reviewed: 19 October 2026.
