Windows enterprise install

Install AgentKeeper Runtime on managed Windows devices. The Windows package installs one runtime service, one per-device credential flow, the MCP gateway binary, and the supported IDE hook helpers.

Use Intune as a Windows app (Win32), or deploy the same package with GPO, SCCM, Workspace ONE, or another software distribution tool.

Requirements

• Windows 10 or Windows 11 Pro, Enterprise, or Education.
• An x64 or ARM64 device. The same IntuneWin contains native binaries for both architectures.
• Administrator, LocalSystem, or equivalent elevated install rights.
• The device is enrolled in Intune and appears under Devices > All devices.
• The enrolling user has an Intune license and is allowed to enroll Windows devices.
• AgentKeeper org ID and scoped Enterprise Installer token.
• HTTPS egress to the AgentKeeper app origin used by your tenant.
• A small device group you can inspect before assigning the installer broadly.

Enroll a test device

Skip this section when the target device is already enrolled in Intune.

AgentKeeper supports Microsoft Entra automatic enrollment, Windows Autopilot, and manual Company Portal enrollment. Use your organization's normal Entra enrollment path when one is already configured. Automatic MDM enrollment is convenient, but it is not required for a small manual test. Microsoft Entra ID P1 or P2 is not required for Windows user enrollment. On an existing Windows VM or PC:

1. Sign in to Windows with a local administrator account. Company Portal enrollment of an already-configured Windows device fails with You don't have the right privileges when the Windows account is not a local administrator.
2. Install Company Portal from Microsoft Store.
3. Open Company Portal and sign in with the Intune-licensed work account.
4. Follow Set up this device until Company Portal shows the device can access company resources.
5. In the Intune admin center, open Devices > All devices and confirm the device appears before creating the AgentKeeper assignment.

If Entra automatic enrollment is already enabled, continue using it; the AgentKeeper package and assignment are unchanged. Do not configure Automatic Enrollment > MDM user scope only to run this manual test. The Automatic MDM enrollment is available only for Microsoft Entra ID Premium subscribers message applies to automatic enrollment, not the Company Portal flow above. Prefer Company Portal over the Enroll only in device management path; the Company Portal flow does not ask the user to type a generic MDM discovery URL.

Microsoft documents the Windows enrollment choices and the local-administrator requirement for Company Portal enrollment.

Create the AgentKeeper token

1. In AgentKeeper, open Settings > Access > API keys.
2. Under Enterprise Installer tokens, choose Windows / Intune.
3. Enter a display name and a deployment ID, such as windows-production-rollout and intune-windows.
4. Select the surfaces the assignment will install. Choose All seven IDEs for -IdeTargets all or a multi-IDE subset; choose a single surface only when the command installs that one target.
5. Create the token and copy both the organization ID and one-time enrollment token. The full token is not shown again.

Copy the token's Deployment ID from Deployment scope into -MdmDeploymentId, including capitalization and punctuation. Do not use the token's display Name. For example, for a token named windows-production-rollout with deployment ID intune-windows, use -MdmDeploymentId "intune-windows".

Treat the token as a scoped secret: Intune administrators who can edit the app can read its install command.

Download

Use the production feed only after its version metadata reports artifact_status: signed-release and release_channel: production, and keep that version and checksum with the Intune change record:

• Promoted Windows IntuneWin
• Version metadata
• Checksums

Download the matching source ZIP too. Normal Intune deployments upload the promoted .intunewin as the app package and upload detect.ps1 extracted from that exact source ZIP as the custom detection script. Do not reuse a detector from another package version.

An .intunewin is an encrypted content container, not a complete Intune app definition. Uploading it does not populate the install command, uninstall command, requirements, detection rule, restart behavior, or assignments. Enter the values below in the Intune wizard.

A package produced by the signing workflow is a signed validation candidate. Signing alone does not publish or approve it for production. Keep that candidate in a test device group until its exact workflow run, commit, and hashes pass the release evidence gates and the reviewed production feed points to those same bytes.

What gets installed

Supported IDE targets are Claude Code, Cursor, Windsurf, GitHub Copilot CLI, Codex, Gemini CLI, and Google Antigravity. Use -IdeTargets all for the normal installer path, a comma-separated list for selected targets, or -IdeTargets none for runtime-only validation.

The installer writes one canonical all-IDE runtime hook and points each selected non-Claude integration at it. Claude Code uses the runtime's dedicated Claude and SessionStart forwarders. Managed config placement is:

The %USERPROFILE% Antigravity path means the persisted target developer profile, not the LocalSystem profile used by Intune Management Extension. Antigravity is the only selected Windows surface that requires a target SID and mounted profile. The machine-wide Copilot policy hook applies to Copilot CLI; the VS Code Copilot extension is not used to infer CLI presence or hook placement.

Claude Code's configuration reference documents Windows file-based managed settings under C:\Program Files\ClaudeCode\. AgentKeeper structurally merges its hook entries into the base managed-settings.json; it does not place them in C:\ProgramData\ClaudeCode, managed-settings.d, or the developer's user settings. %USERPROFILE%\.claude\settings.json is legacy cleanup only, and AgentKeeper removes its older entries there only after the machine-managed repair has succeeded and been verified.

AgentKeeper does not change Windows permissions on IDE-managed configuration directories or files. Existing permissions are preserved, and paths created during installation inherit the permissions of their parent directory. AgentKeeper continues to protect its own runtime, credential, state, and hook-forwarder files under C:\ProgramData\AgentKeeper and C:\Program Files\AgentKeeper.

When any machine-scoped hook is selected, the built-in Windows Users group receives read/execute access to the canonical hook and read access to its non-secret configuration and scoped per-device credential. This includes mixed all installs: Antigravity still uses its resolved target profile, but the system hooks remain readable by Builtin Users rather than being restricted to that one SID. Hooks can write only the four precreated diagnostics last-runtime-hook.json, last-evaluate.json, last-checkin.json, and last-activity.json. The Activity marker is updated only after the API explicitly acknowledges a persisted Activity row; a self-test, deduplicated event, disabled pass logging, or later transport failure cannot replace that proof. The State directory grants traversal without inherited permissions or create/delete/rename rights; the protected device key and all other state children remain SYSTEM/Administrators-only. An Antigravity-only install grants the same narrow file-level access only to the resolved target SID. The installer removes the recursive Modify ACL used by older validation packages. If that legacy write grant is present, it stops the old service, discards the exposed local key, credential, and enrollment state, then uses the current MDM token to enroll again and replace the prior device credential.

Intune settings

In the Microsoft Intune admin center, open Apps > All apps > Create, select Windows app (Win32), and upload agentkeeper-runtime-windows-latest.intunewin.

Do not put Microsoft Graph credentials, broad API keys, or per-device machine IDs in the install command. AgentKeeper derives machine identity locally, exchanges the MDM enrollment token for a per-device credential, and stores that credential with OS protection.

The default all install includes Antigravity and therefore must resolve exactly one Windows developer account, SID, and mounted profile from an explicit target or strong active-session evidence. It persists that target for Antigravity install, detection, remediation, status, and uninstall. If no unique strong target exists, the install fails without writing to a guessed profile. Any selection that omits Antigravity is machine-managed and does not require an interactive user, including a Claude Code-only selection.

App information

Use AgentKeeper Runtime for the name and RAD Security, Inc. for the publisher. Description, category, owner, information URL, privacy URL, and logo are optional. The package can show only limited source-file information; the portal fields are expected to require manual entry.

Program

1. Set Installer type to Command line.
2. Paste the install and uninstall commands from Commands. Replace every placeholder in the install command before continuing.
3. Leave Installation time required at 60 minutes.
4. Set Allow available uninstall to No.
5. Set Install behavior to System. Do not select User: the Intune Management Extension must install the service as LocalSystem even when no developer is signed in.
6. Set Device restart behavior to No specific action and keep the default return-code mappings. AgentKeeper does not require a Windows restart.

The installer is silent and does not open a setup window. Intune can still display its own download, install, or restart notifications. To suppress those, edit the Required assignment and set End user notifications to Hide all toast notifications.

Requirements

Select both x64 and ARM64. Do not create a separate Windows ARM app: the installer detects the endpoint architecture and installs the matching native runtime and gateway binaries. Choose the minimum Windows release permitted by your organization and leave the optional disk, memory, processor, and CPU rules empty.

Detection rules

1. Set Rules format to Use a custom detection script.
2. Upload detect.ps1 extracted from the source ZIP that matches the uploaded .intunewin.
3. Set Run script as 32-bit process on 64-bit clients to No.
4. Leave Enforce script signature check at No unless the target devices already trust the RAD Security signing chain through your Intune, WDAC, or App Control policy.

For normal installation and upgrades, use the package-matched custom detection script and do not enter a detection command. Intune marks the app installed only when the custom script exits 0, writes an installed message to standard output, and writes nothing to standard error. Emergency uninstall of an earlier package version uses a separate Intune Remediations package and does not change this Win32 app detection rule.

Dependencies and supersedence

For a first deployment, add no dependencies and no supersedence relationship. AgentKeeper carries its own runtime, native gateway, and PowerShell helpers in the package.

To upgrade without uninstalling, update the Win32 app with the new .intunewin and its matching detect.ps1. If your change process requires a second app, supersede the previous AgentKeeper app with Uninstall previous version set to No. The installer performs an in-place service and hook repair. Never reuse the previous version's detector.

Assignments

For an automatic silent install, assign the app as Required to a device group. Available for enrolled devices only lists the app in Company Portal and waits for the user to choose Install.

For a new test group:

1. In Intune, open Groups > All groups > New group.
2. Create an assigned Security group, such as AgentKeeper Intune Test.
3. Open the group, choose Members > Add members, and add the enrolled Windows device.
4. Return to the AgentKeeper app's Assignments step and add the group under Required.
5. Set availability and installation deadline to As soon as possible. Choose Hide all toast notifications when the test must be fully silent.

Review the app and create it. A device being visible in Intune is not by itself an assignment; the device must be a member of a group included under Required.

Commands

Replace the angle-bracketed values in the install command. Copy MdmDeploymentId exactly from the token's Deployment scope value; do not use the token's display name. Use all, none, or a comma-separated IDE list for IdeTargets.

Install

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 -ApiUrl "https://www.agentkeeper.dev" -OrgId "<org_id>" -MdmToken "<mdm_enrollment_token>" -MdmDeploymentId "intune-windows" -IdeTargets "all"

Custom detection script

In Detection rules, select Use a custom detection script and upload detect.ps1 from the source ZIP that matches the assigned .intunewin. Set Run script as 32-bit process on 64-bit clients to No. Do not paste a PowerShell command into the detection rule.

The package generator embeds that package's exact immutable version directly in detect.ps1. On every upgrade, replace the .intunewin and re-upload the new matching detect.ps1; an older detector will intentionally report the new runtime as not installed.

IDE remediation

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\agentkeeper-windows-ide-remediate.ps1 -IdeTargets all

Status

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\agentkeeper-windows-status-current.ps1 -SelfTest

Uninstall

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\uninstall.ps1

Do not add -IdeTargets all to the normal uninstall command. The current package records the exact successful install target set and reuses it for safe cleanup. Explicit target arguments are support overrides for an unavailable or damaged install marker.

Do not use agentkeeper-windows-ide-hooks.ps1 as the first-install command. It is a legacy helper and requires either an existing per-device credential or a separately configured fleet API key.

Install command values

The universal source package already contains the reviewed amd64 and arm64 gateway executables. Their exact hashes are bound into package metadata, and a signed candidate signs and validates those embedded bytes before installation. The customer install command must not pass GatewayArtifactPath, GatewaySha256, or a different gateway release tag.

The installer derives identity in this order:

Network

Allow these destinations before broad assignment:

The universal Windows installer does not download the gateway at endpoint install time. Its signed, architecture-specific gateway binary is carried inside the .intunewin source and verified again immediately before replacement.

Sync and monitor Intune

The Intune Management Extension checks for new Win32 app assignments on its own schedule, so the install does not necessarily begin when the portal assignment is saved. To request an immediate device check-in:

1. On Windows, open Company Portal > Settings > Sync; or open Settings > Accounts > Access work or school, select the managed account, choose Info, then Sync.
2. In Intune, open Apps > All apps > AgentKeeper Runtime > Device install status and refresh.

Common intermediate states are expected:

If enrollment fails, confirm that you created a Windows / Intune Enterprise Installer token, copied its exact Deployment ID into -MdmDeploymentId, and requested only surfaces selected for that token.

Microsoft documents that the Intune Management Extension normally checks hourly and also checks after its service or the device restarts. A Windows restart should be a troubleshooting fallback, not part of the AgentKeeper installation procedure. See Win32 app management and manually sync a Windows device.

When installation fails, inspect these paths from an elevated PowerShell session:

Get-Content "$env:ProgramData\AgentKeeper\Logs\agentkeeper-intune-install.log" -Tail 200
Get-ChildItem "$env:ProgramData\AgentKeeper\Support\intune-install-failure-*.zip"
Get-Content "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" -Tail 200

The AgentKeeper failure ZIP and log are redacted, but still contain customer environment evidence. Share them only through an approved support channel.

Validate

Run these from elevated PowerShell on a test device:

Get-Service AgentKeeperRuntime
& "C:\Program Files\AgentKeeper\agentkeeper.exe" status --json
& "C:\Program Files\AgentKeeper\agentkeeper.exe" doctor
& "C:\Program Files\AgentKeeper\agentkeeper.exe" heartbeat --json
Test-Path "C:\Program Files\AgentKeeper\agentkeeper-mcp-gateway.exe"

Then restart the selected AI agent and generate one harmless action. The device is ready when all of these are true:

• The service is running and set to Automatic.
• Status shows a valid per-device credential and a successful policy fetch.
• The gateway binary is present.
• The canonical all-IDE hook exists at C:\ProgramData\AgentKeeper\agentkeeper-ide-hook.ps1, and the dedicated Claude forwarders exist when Claude Code is selected.
• Claude Code's AgentKeeper hooks are structurally present in C:\Program Files\ClaudeCode\managed-settings.json; C:\ProgramData\ClaudeCode and managed-settings.d are not used.
• Machine-managed configs exist at their system locations, and the Antigravity config exists in the persisted developer profile when selected.
• AgentKeeper Activity shows one fresh runtime event from the selected AI agent.
• A controlled BLOCK test works on a supported pre-execution path.

Self-test and heartbeat prove local runtime reachability. They do not replace live IDE evidence.

restart_required: true in AgentKeeper status does not request a Windows reboot. Fully quit and reopen the selected AI agent, start a new session, and run one harmless tool action so its managed hooks can report live preflight evidence. Intune can already report the package as Installed while this live-event step is still pending.

Repair is ownership-scoped: it may update only the AgentKeeper-owned hook object or marked block and must preserve unrelated customer hooks and settings. If a selected JSON or TOML config is malformed, the helper preserves the file, reports it noncompliant, and exits nonzero. Repairing the file manually and rerunning remediation is safer than allowing an installer to replace customer configuration. A selected hook repair failure also fails the unified install; do not treat a partial Win32 result as healthy.

Standard Windows users have read-only access to Logs, Support, and RuntimePackage, so local diagnostics and support bundles can be collected without elevation. Runtime credentials, device keys, enrollment state, and installer control records remain protected from standard-user access. IDE-managed configuration files keep their existing Windows permissions.

When Antigravity is selected for a domain-backed Windows profile, pass -TargetUser DOMAIN\user or -TargetUserUpn user@company.com if the active developer profile is not unambiguous. The installer persists the resolved SID/profile, so later Antigravity status, detection, remediation, and uninstall use the same target state. Enrollment revalidates that canonical pair against the local Windows ProfileList; a cached domain profile remains valid when the domain controller is temporarily unavailable, while any available account translation must still agree. If the profile root is not mounted, have the developer sign in once and retry the installation. Claude Code and the other machine-managed surfaces do not require this profile resolution.

WDAC readiness

If the device enforces Windows Defender Application Control, App Control for Business, or PowerShell constrained language mode, validate trust before broad assignment.

Run these checks on a device with the same WDAC/App Control policy as the target fleet:

Get-AuthenticodeSignature "C:\Program Files\AgentKeeper\agentkeeper.exe"
Get-AuthenticodeSignature "C:\Program Files\AgentKeeper\agentkeeper-mcp-gateway.exe"
$ExecutionContext.SessionState.LanguageMode
& "C:\Program Files\AgentKeeper\agentkeeper.exe" doctor

The release workflow rejects a signer that does not match its configured approved publisher subject or thumbprint. signed: true in metadata still does not prove the customer's WDAC policy trusts that publisher, hash, path, or script execution path, and it does not mean the validation candidate was promoted to the production feed.

Uninstall

Use the packaged uninstall.ps1 command above. It removes AgentKeeper-owned hook blocks from Claude Code's machine-managed base file and the other selected configs, unregisters AgentKeeperRuntime, removes agentkeeper.exe and agentkeeper-mcp-gateway.exe, and preserves unrelated customer hook configuration. If a trusted persisted target identifies an older %USERPROFILE%\.claude\settings.json, the helper removes only AgentKeeper's legacy entries there after handling the managed file.

The same script can be run manually. Download the source ZIP that matches the installed release, extract it, open 64-bit Windows PowerShell as Administrator in the extracted folder, and run:

& "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File .\uninstall.ps1

Keep uninstall.ps1 and the other extracted package files together. The .intunewin file is an Intune content container and cannot be used as the script working directory.

Emergency uninstall of an earlier package version

Use an Intune Remediations script package when a Win32 Uninstall assignment reports the app absent but AgentKeeper remains on the endpoint. Remediations require a supported Windows/Intune license; see Microsoft's Remediations prerequisites.

First remove the affected device group from every AgentKeeper Required or Available for enrolled devices assignment so the app is not reinstalled. Do not change the Win32 app's normal detection rule. Then:

1. Extract the current promoted AgentKeeper Windows source ZIP.
2. In Intune, open Devices > Manage devices > Scripts and remediations and select Create script package.
3. Enter a name such as AgentKeeper emergency uninstall.
4. Upload emergency-uninstall-detect.ps1 as the Detection script.
5. Upload uninstall.ps1 as the Remediation script.
6. Set Run this script using the logged-on credentials to No.
7. Set Enforce script signature check to No, unless the AgentKeeper signing certificate is already trusted by the device policy.
8. Set Run script in 64-bit PowerShell to Yes.
9. Assign the script package only to the affected device group and use a one-time schedule. You can also select an affected device and use Run remediation after the package has been created.
10. Review the remediation device status, then confirm that the service and binaries are absent:

Get-Service AgentKeeperRuntime -ErrorAction SilentlyContinue
Test-Path "C:\Program Files\AgentKeeper\agentkeeper.exe"
Test-Path "C:\Program Files\AgentKeeper\agentkeeper-mcp-gateway.exe"

Get-Service should return no service and both Test-Path commands should return False.

Remove the emergency remediation assignment after every targeted device reports success. Before assigning AgentKeeper as Required again, confirm that the Win32 app still uses the package-matched detect.ps1 custom detection script.

If you already have a legacy Windows script assignment, keep its scope fixed until this package passes validation on the same device group. See legacy MDM script migration for the transition sequence.