Deploy across a fleet
Roll TigerMole out to a whole team without touching every machine by hand. One Team key covers every seat, and Windows and Linux both support fully unattended, scripted installs — Intune, SCCM, Ansible, or your own tooling.
One key, many machines
A Team license carries as many seats as you contracted. You install with the same key everywhere — each machine consumes one seat the first time it activates, binding the seat to a machine fingerprint (v1:SHA256(machine-id | primary MAC)). There is no per-machine key to generate and no central console to pre-assign seats from: seats are claimed on first activation and released with tigermole-proxy deactivate (which every uninstaller runs automatically).
TigerMole installs per user, so size your seat count by users, not machines: a shared box where 5 people each run Claude uses 5 seats; a server where Claude runs under one service account uses 1.
Before you start
• A Team license key with enough seats for your fleet
• The installer artifacts hosted somewhere your machines can reach (an internal share, your MDM's content delivery, or the releases page) — always alongside their .sha256 files
• Outbound HTTPS to api.tigermole.com allowed from every machine (see the network section)
• Optional with Team: an X25519 audit public key (.pub) for encrypting audit files
Windows — unattended install
The Windows installer is a WiX Burn bundle (TigerMole-Setup-X.X.X.exe). It takes standard Burn silent switches, and its license and options are passed as NAME=value variables on the command line — so you can pre-inject the key and install with zero prompts. It installs per-user and needs no administrator rights.
Silent switches and variables
Silent switches (native to the Burn engine):
• /quiet — fully silent, no UI
• /passive — progress bar only, no prompts
• /norestart — suppress any reboot
• /log <path> — write the engine log
Overridable variables (pass as Name=value, not /name=value):
Variable
Default
Purpose
LicenseKey | (empty) | Your Team key — pre-injects activation so the install is prompt-free
AutoStart | 1 | Register autostart at login (per-user, no admin)
DesktopShortcut | 0 | Create a desktop shortcut
LicenseEndpoint | https://api.tigermole.com | Override only for an air-gapped/mirrored license endpoint
Example: silent install with the key pre-injected
TigerMole-Setup-X.X.X.exe /quiet /norestart `
LicenseKey="key/eyJ...IAQ==" `
AutoStart=1 `
DesktopShortcut=0
Microsoft Intune (Win32 app)
Wrap the bundle into an .intunewin and register it as a Win32 app:
Package
IntuneWinAppUtil.exe -c <folder> -s TigerMole-Setup-X.X.X.exe -o <output>
Install command
TigerMole-Setup-X.X.X.exe /quiet LicenseKey="key/eyJ...IAQ==" AutoStart=1
Uninstall command
"%LOCALAPPDATA%\TigerMole\tigermole-proxy.exe" uninstall
Detection rule
Rule type File → path %LOCALAPPDATA%\TigerMole\, file tigermole-proxy.exe, method "File or folder exists". Intune treats exit code 0 as success (non-zero as failure).
SCCM / Group Policy / any script runner
There is no fleet-specific magic: any tool that can run an EXE with arguments works. Wrap the same command in a PowerShell script that verifies the SHA-256, installs with /quiet /norestart /log, and confirms the result with tigermole-proxy doctor and tigermole-proxy license. The install is idempotent — re-running it upgrades in place.
A note on the standalone .msi
The TigerMole-X.X.X.msi is offered for MDM tooling that only ingests MSIs, but the MSI does not carry the license: its only public properties are AUTOSTART and DESKTOP_SHORTCUT. Installing the bare MSI with msiexec leaves TigerMole protection inactive until you activate separately; it does not block the AI tool. For a one-shot licensed deploy, use the .exe bundle above. If you must ship the MSI, follow it with tigermole-proxy activate <KEY> on each machine.
Linux — scripted install
There is no environment-variable activation on Linux: the binary takes the key as a positional argument to activate. So the fleet pattern is a short, deterministic script — never pipe answers into the interactive install wizard (it will hang on the license prompt with stdin closed).
Pull the key from your secrets manager / Ansible Vault into TIGERMOLE_LICENSE_KEY, then:
set -euo pipefail
sudo dpkg -i tigermole-proxy-X.X.X-amd64.deb
# Activate TigerMole protection
tigermole-proxy activate "$TIGERMOLE_LICENSE_KEY"
# Configure the supported Claude Code or Codex workflow
tigermole-proxy configure
# Optional with Team: import the audit-encryption public key
tigermole-proxy import-audit-key /path/to/team.pub
# Start the proxy
tigermole-proxy run &
For real fleets, drive that sequence from Ansible (with the key in Vault) and register a systemd user service so the proxy survives logout—enable lingering with loginctl enable-linger <user> so it starts without an interactive login.
Distributing the optional audit key (Team)
Team can encrypt audit logs or exports with your own X25519 key. The persistent audit remains limited to metadata. If you need this option, generate the pair once on a secure machine—the private key is printed to stdout and never written to disk:
tigermole-proxy keygen
Keep the private key in your vault. Push the public .pub to the machines that need encryption through the same channel as the installer, then import it during installation or later. TigerMole can be installed, activated and used without this key.
Network requirements
For license management, TigerMole contacts api.tigermole.com during activation, deactivation and the approximately 15-day background revalidation (/api/license/activate, /api/license/deactivate, /api/license/status). After activation it retains the last successful validation for up to 30 days without access to this API.
Masked functional traffic is sent directly to the provider selected by Claude Code or Codex. It does not pass through TigerMole servers.
Two things to confirm with your network team
In the interest of not overpromising, two details are not formally documented and you should validate them in your environment before a wide rollout:
• Port: activation uses https://api.tigermole.com, so allow outbound HTTPS (443) to that host. The port is implied by the scheme rather than spelled out in the product docs.
• Corporate outbound proxy: whether the license client honours your HTTPS_PROXY / NO_PROXY environment variables is not a documented guarantee. If your machines only reach the internet through a forward proxy, test activation on one machine first.
Verify each machine
After a scripted install, confirm the proxy is up, licensed and masking on any platform:
tigermole-proxy status # proxy + license + masking state
tigermole-proxy doctor # full installation health check
tigermole-proxy license # tier, seats used / max, expiry
If the license expires or becomes invalid, TigerMole disables masking and displays a warning. Claude Code and Codex continue working without protection; check the status before completing the rollout.
Need a hand rolling this out?
If you need help sizing seats, connecting TigerMole to your MDM or setting up optional audit encryption, book a demo and we will review the deployment with your IT team.