Endpoint Management

TATER agents provide a complete Unified Endpoint Management surface - feature-parity with ManageEngine Endpoint Central across patch management, software deployment, disk encryption escrow, policy enforcement, and remote shell. Every action rides on the agent's existing AgentCommands pipeline, every mutation is audit-logged with the requesting SuperAdmin's identity, and every sensitive operation requires explicit opt-in at both the org level and the device-config level.

Live Interactive Shell

Open a persistent PowerShell / pwsh / cmd / bash / zsh session against any enrolled endpoint and type commands as if you were sitting at the keyboard. V1 transport is REST-polling pseudo-terminal - works through any firewall. V2 will add WebRTC for sub-100ms latency.

How to use it

1. Enable Live Shell for the org: Manage → Tenant Admin → Organizations → ⚙ Features → Live Interactive Shell ON.
2. Open Manage → Endpoint Fleet → Devices.
3. Find the target device, click the 💻 Shell button on its row.
4. Pick the shell (PowerShell / pwsh / cmd / bash / zsh / sh), context, and idle timeout (default 30 min, max 4h).
5. Click ▶ Start session - xterm.js loads, the agent attaches, the prompt appears.
6. Type any command. Output streams back in ~400ms chunks.
7. Click ⏹ End session to close. The session also auto-closes on idle timeout or max-session timeout.

What's recorded

Every keystroke and every byte of output is persisted server-side in a ShellTranscripts Cosmos container with 90-day retention. Replay any prior session by hitting GET /agents/shell/sessions/<sid>/transcript with SuperAdmin auth. There is no way to disable recording while keeping shell access - the audit trail is the point.

Limits

• SuperAdmin only.
• Max 64 KB per input chunk, 256 KB per output chunk (chunks are sub-second so this is rarely tight).
• Idle timeout default 30 min, hard cap 4 h.
• "Logged-in user" context is currently effective-as-agent (SYSTEM on Windows service installs) - full impersonation lands in V2.

Patch Management

The agent runs platform-native upgrade discovery (winget upgrade on Windows, brew outdated + softwareupdate -l on macOS, apt list --upgradable / dnf check-update on Linux) every 6 hours and uploads the available-update list to TATER. SuperAdmins review in Manage and queue deployments with one click.

Where to look

Manage → Endpoint Fleet → Patch Management. KPI cards show fleet-wide totals (devices reporting, total patches, critical count). Per-device table shows hostname, OS, patches, critical / important counts, and last-scan timestamp.

Deploying patches

• Upgrade all - click the green button on a device row. Queues a single winget upgrade --all / brew upgrade / apt -y upgrade command.
• Selective - click View on a device, check the patches you want, click ▶ Deploy selected.

The deployment is queued as an AgentCommand with a 30-minute timeout. Status mirrors back into the PatchDeployments shadow record as the agent reports progress.

Software Deployment

Define a package once in the org's catalog, then deploy it to up to 500 hosts in a single API call. Supports winget IDs, MSI / EXE / PKG / DEB / RPM direct-URL downloads (with optional SHA256 verification), Homebrew formulae and casks, and raw PowerShell / bash scripts as a fallback.

Catalog management

Manage → Endpoint Fleet → Software Deploy → + New package. Fill in the form:

• Name, Vendor, Platform, Installer (required)
• winget ID (e.g. Microsoft.PowerToys) - for winget installer
• Brew formula - for brew installer (cask flag for GUI apps)
• Download URL + SHA256 - for MSI / EXE / PKG / DEB / RPM
• Silent flags - override defaults (e.g. /qn /norestart)
• Script override - when installer is "script", paste a raw PS / bash script

Deploying

Click ▶ Deploy on a package row, paste hostnames (one per line, up to 500), click ▶ Deploy. Each host gets its own SoftwareDeployment record; the agent downloads (with SHA256 check if configured), runs silent install, and reports back.

BitLocker / FileVault / LUKS Escrow

The agent inventory runner captures volume protection status and recovery passwords every 6 hours. Passwords are AES-256-GCM encrypted at rest in the BitLockerKeys Cosmos container. Recovery passwords are never returned in list responses - they're masked as ••• masked •••.

Revealing a recovery key

1. Manage → Endpoint Fleet → BitLocker Keys.
2. Click View keys on a host row to see its volumes and protection status.
3. Click 🔓 Reveal on the volume you need.
4. Confirm the audit warning. A high-sensitivity entry is written to the audit log capturing your identity (OID + UPN + IP) and the volume id.
5. The cleartext password is displayed inline. It's user-selectable so you can copy/paste into the recovery flow.

Audit trail

Every reveal writes an audit entry with action=update entityType=bitlocker-key, metadata.action=reveal, and the requester's OID/UPN/via. Filter Manage → Audit & Telemetry → Activity Log → All Channels: web for bitlocker-reveal to see who's been pulling keys.

Endpoint Policies

Six policy kinds compose to cover most Endpoint-Central-style enforcement scenarios. Define each policy once with a JSON spec, then apply it to one or many devices. The API renders a platform-specific script and queues it via AgentCommands.

Apply workflow

1. Manage → Endpoint Fleet → Endpoint Policies.
2. Pick the tab (USB / App Allow / JIT Admin / Power / Browser / DNS Filter).
3. Click + New policy, fill in name + platform + spec JSON, save.
4. Click ▶ Apply on the saved policy.
5. Paste target hostnames (one per line, up to 500), click ▶ Apply.

Endpoint Profiles (Targeted Script Bundles)

Endpoint Profiles bring ScriptLogic / Desktop Authority-style desktop automation to the TATER agent. A profile is an ordered bundle of configuration elements - map a drive, deploy a printer, drop a shortcut, set a registry value, register a scheduled task, show a message, or run a raw PowerShell / bash script - gated by a composable targeting rule and applied on a chosen trigger. Where Endpoint Policies enforce a single setting (USB, DNS, JIT, etc.), a profile chains many actions into one logon-time (or startup / unlock / interval / on-demand) experience and decides, per device and per logged-in user, whether to run. The agent re-evaluates the targeting rule locally on every trigger, so a profile reacts to who is signed in and what groups they're in - not just which machine it landed on.

Anatomy of a profile

• Trigger - when the agent applies it: logon, startup, unlock, interval (re-apply every N minutes, 5-1440, default 60), or on-demand.
• Run-as - default execution context for elements: system (default) or user. Use user for anything touching HKCU, the user profile, or mapped drives. Individual elements can override the profile's run-as.
• Elements - up to 100, applied in order (low → high). Each is either a raw script element or a typed element that compiles to a platform-native script server-side: mapDrive, deployPrinter, shortcut, registryValue, scheduledTask, or message. Elements can be individually enabled / disabled and can carry their own extra targeting (AND-ed on top of the profile's).
• Targeting rule - a composable { match: "all" | "any", conditions: [...], groups: [...nested rules] } tree. Omit it (or use an empty rule) to apply to all devices.

Targeting conditions

Each condition can set negate: true to invert it, and rules nest via groups so you can express things like "(Finance device group AND Windows) OR hostname matches LAB-*". Available condition types:

Build & assign workflow

1. Manage → Endpoint Fleet → Endpoint Profiles → + New profile.
2. Name the profile, pick a trigger and default run-as (and a refresh interval if you chose interval).
3. Add elements in the order you want them to run - mix typed elements (map drive, printer, shortcut, registry, scheduled task, message) with raw scripts as needed.
4. Build the targeting rule - usually start from a device group (deployment ring) and layer on OS, user-group, or time-window conditions.
5. Save. Enabled profiles are picked up by every matching agent at its next trigger; the agent re-checks targeting locally before applying.

Preview & troubleshoot targeting

Before (or after) you ship a profile, dry-run the targeting engine against a specific device to answer "why did - or didn't - this apply?". Resolve a device context from a hostname (its device-group membership plus the latest agent-reported OS / user / IP) and the engine returns a per-rule match boolean and a step-by-step trace. You can test one ad-hoc rule, one saved profile, or all enabled profiles at once. Remember that agent-only conditions never match in this cloud preview - they are decided on the endpoint.

Roles & safety

• Viewer+ can list and read profiles and run the targeting preview; Admin+ can create, edit, and delete them.
• Every create / update / delete is audit-logged (entityType=EndpointProfile, with trigger and element count in metadata) and attributed to the requester - via=web for the GUI, via=mcp for agent-driven authoring.
• Deletes are soft (archived), so a profile can be recovered; pass an include-archived flag to surface archived profiles.
• Keep PowerShell element bodies ASCII-only for PowerShell 5.1 codepage safety.

Wake-on-LAN, Process Control, File Transfer

One-shot endpoint actions for when you don't need a full policy or live shell.

• Wake-on-LAN (POST /endpoint/wake-on-lan) - provide the target MAC plus a "peer hostname" (a known-online agent on the same LAN). The peer sends the magic UDP/9 broadcast.
• Process / service control (POST /endpoint/process-control) - kill-process / restart-service / stop-service / start-service. Lower friction than the live shell when you just need to bounce one thing.
• File push (POST /endpoint/file-push) - inline base64 file delivery, 8 MB inline cap. Writes via PowerShell [IO.File]::WriteAllBytes on Windows, base64 -d on Unix.

Self-Service Portal (My TATER)

End users submit software / JIT-admin / access / support requests from My TATER. Admins approve in Manage. Approving does not auto-execute - admins still drive the underlying action via the matching workflow (e.g., approving a software request opens up the relevant Software Deploy queue.)

End-user flow

1. Open My TATER → Self-Service.
2. Click + New request, pick a kind (Software install / JIT admin / Access request / General support).
3. Fill in the title + description. For software requests, name the package; for JIT admin, request a duration.
4. Submit. The status table shows Pending until an admin decides.

Admin flow

SuperAdmins / OrgAdmins see all pending requests across the org. Approve or deny with a decision note. Once approved, the admin manually triggers the matching action (deploy software, grant JIT admin via the Endpoint Policies → Elevation Grants flow, etc.). MCP agents can list and decide via list_self_service_requests and decide_self_service_request.

MCP Tools (Agent Surface)

External AI agents (Claude, Copilot, Cursor, etc.) can drive most endpoint-management workflows via MCP. Live Shell is intentionally not exposed - that's an interactive UI surface only, by design.

Intune Deployment (Proactive Remediations & Platform Scripts)

Beyond reading Intune compliance posture, TATER can create and assign Microsoft Intune Proactive Remediations (deviceHealthScripts) and Platform Scripts (deviceManagementScripts) directly via Microsoft Graph - scoped to the active org's tenant. The canonical surface is TATER Ops → Intune (posture KPIs, a write-consent banner, the Proactive Remediation + Platform Script lists with a Targets column that resolves each item to its assigned Entra groups, and create/assign actions). Every deployment is gated behind a What-If preview, an explicit target group (never all-devices implicitly), and an approved change request, and is fully audit-logged. The same actions are available to MCP agents, which call the exact same service layer - so the MCP can never do anything the GUI can't.

The tenant's Graph app must be granted DeviceManagementScripts.ReadWrite.All (admin-consented) before writes are allowed; reads work with DeviceManagementScripts.Read.All. Auditor+ can view posture; Admin+ can deploy.

Security Model

• Two-tier opt-in for Live Shell: per-org shellEnabled flag AND per-device liveShellEnabled config. Both must be true.
• Unbound API keys cannot upload patch inventory, BitLocker keys, shell output, etc. - the bound-org check is enforced server-side as UNBOUND_KEY 403.
• Cross-org IDOR checks on every getItem for shell sessions, software packages, BitLocker keys, deployments, policies, and self-service requests.
• BitLocker passwords AES-256-GCM encrypted in Cosmos. Decrypted only on the audited reveal endpoint.
• Audit attribution: SA actions get via=shell|patch-mgmt|sw-deploy|endpoint-policy|bitlocker-reveal|wol|process-control|file-push on the audit entry; agent updates get via=agent; MCP actions get via=mcp (or whatever actorVia the agent identifies as).
• Write-tier rate limiting (30 req/min) on every mutating endpoint.

Related

• Fleet Management - device discovery, MDE bridging, vulnerabilities
• Agent Deployment - MSI / IntuneWin / Proactive Remediation / Platform Scripts / Linux tar.gz
• MCP Setup - connect Claude / Copilot / Cursor to your TATER tenant
• My TATER for End Users - the user-side self-service surface