Traceforce for MSPs

Onboard a client and deploy Traceforce

Add the client as an organization in Traceforce, create their API credentials, and deploy the agent and browser extension through your RMM or MDM.

About 30 minutes for your first client
Agent plus browser extension
Windows and macOS
Any RMM or MDM

What you're deploying

Traceforce has two pieces, and both go on every endpoint.

The agent

Sees AI tools installed on the machine. Desktop apps, coding assistants, IDE extensions and command line tools.

The browser extension

Sees AI use in Chrome and Edge, which is where most of it happens.

On Windows, the agent and the extension go out separately: the agent as an installer, the extension as browser policy. Our script does both in one pass. On macOS, both arrive through your MDM.

Without the extension you're missing browser AI usage, whether people signed in with personal or company accounts, the connectors those browser tools are wired into, and the sensitive data findings that come out of conversation content.

The console still fills up either way, which is what makes this easy to miss. It's just showing a fraction of what's there.

Before you start

Your own Traceforce tenant, already provisioned. If you're not there yet, start at Set up Traceforce SSO.
Admin access to your RMM for Windows, or to an MDM for macOS.
Every email domain the client's users have addresses on.

Part 1

Add the client in Traceforce

This part is the same whether you're deploying to Windows, macOS or both.

Create the client organization

In your Traceforce console, click Org Access in the left menu.

Under Add organization, enter the client's Primary domain. This becomes the organization's name throughout the console, so use the one they're known by.

Add every domain they use. Use Additional domains to list any others their people have email addresses on, which is common after an acquisition or a rebrand.

Traceforce reads the domain to decide whether someone signed into an AI tool with a company account or a personal one. Leave a domain out and everyone on it counts as personal, which makes the findings wrong in a way that still looks plausible.

Then choose how the client signs in.

No sign-in

The usual choice. You manage the organization entirely from your own tenant and nobody at the client needs access. Use this for any assessment, and for any client without internal IT. You can add sign-in later if that changes.

Metadata URL or Paste XML

Use this when the client has internal IT who want their own access to the console. Set up the SAML application on their side using Set up Traceforce SSO, with one difference: don't submit the metadata URL through the form on that page, paste it into the Metadata URL field here instead.

Click Add organization. The client appears under Orgs you can access.

If you chose SAML: only users on that email domain can sign in. A guest or external account in the client's tenant won't work, because it doesn't have an address on their domain.

Switch into the client organization

Click the organization selector at the top left, the one showing your tenant name with the up and down arrows. Pick the client you just added.

A banner appears across the top reading Viewing as with the client's domain, and a Return to your org link. That banner is your confirmation you're in the right place.

Check this before every deployment. The credentials you create next belong to whichever organization you're currently in.

Create the API credentials

Go to Settings, then API Clients.

Click Create API Client, name it, and copy both values:

Client ID, a UUID
Client Secret

These two are different for every client. You can see them again any time with Show in the API Clients panel, so there's nothing to lose. It also means anyone with console access to the client's organization can read them.

Each organization allows two API clients. To replace one, create the new client, update the values in your RMM, move devices over with rotate-credentials.ps1, and delete the old client last.

Download the deployment package

Windows through our script: skip this. The script downloads the installer for you. You only need the Windows package if you deploy through Intune, or later for the two helper scripts inside it, rotate-credentials.ps1 and uninstall.ps1.

macOS: you need it. Still in Settings, click Download Packages, then Download Scanner Package. Pick darwin-arm64 for Apple Silicon Macs, and grab darwin-x86_64 as well if you support Intel Macs. For the Windows package, pick windows-x86_64. Click Download Package.

You only do this once per platform. Everything in the package is the same for every client, and only the API credentials change, so keep what you download and reuse it. Come back for a fresh copy when Traceforce ships a new version.

The download link in that dialog expires within the hour, so it can't be saved or scripted.

Part 2

Deploy to endpoints

Pick the platform you're deploying to. If the client has both, work through each one separately.

Windows Through your RMM

On Windows, one script does the whole job. It downloads the installer, installs the agent with the client's credentials, and force-installs the browser extension in Chrome and Edge. There's nothing to download from Traceforce first.

How are browser extensions managed at this client?

This decides how the extension half gets deployed. The agent half is the same either way.

Nothing manages them today

The most common case. Use the script below. It handles the agent and both browsers in one pass.

Intune, group policy, JumpCloud or another MDM

That tool overwrites whatever the script writes at its next sync, so the extension goes in that tool, alongside the rest of the client's extension policy. The agent can still go through the script. Intune and Group policy, JumpCloud or another MDM under Your tool below have the steps.

Google Workspace

Run the script with SkipExtension set to chrome. That installs the agent and covers Edge. Then add the extension to Chrome in the Google Admin console:

Go to Devices > Chrome > Apps & extensions > Users & browsers, and select the organizational unit.
Click +, then Add Chrome app or extension by ID.
Paste the Chrome extension ID below, leave it set to From the Chrome Web Store, and click Save.
Set its installation policy to Force install and save.

The browser extension

The extension values are built into the script. Chrome and Edge each have their own extension ID:

Browser	Extension ID
Chrome	`fbmlfnjlhcnjgomfibgjibecohplhmjh`
Edge	`hijndbabkmgepoggmnbmknbchklcbknn`

You only need these if an MDM, Intune, group policy or Google Workspace manages the client's extensions, if they run ThreatLocker, or to check a device.

You need two values. The same two go into every RMM.

Value	Where it came from
`ClientId`	Settings > API Clients, in the client's organization
`ClientSecret`	Same place

Get the script

One script does the whole job. It downloads the Traceforce installer, checks it's signed by Traceforce, installs the agent with the client's credentials, force-installs the browser extension in Chrome and Edge, checks its own work, and prints a result line your RMM can read.

Some RMMs take pasted text and others want a .ps1 file, so both are there.

It's safe to run more than once. Nothing is reinstalled or rewritten if it's already correct. If the client already manages browser extension policy, the script adds Traceforce to what's there rather than replacing it, and keeps a copy of the original in C:\ProgramData\PORT1.

Re-running it never changes the credentials on a machine that already has the agent. To move a device to a different client, see Deployed with the wrong client's credentials below.

Run it

Three things have to be true in any RMM:

The script runs as SYSTEM. Most RMMs do this by default, but check. Running as a normal administrator installs the agent but can't store its credentials.
The endpoint can reach port1.io. The script downloads the installer from there and picks the right build for Intel, AMD or ARM machines. If a client's network blocks it, allow https://port1.io. Or attach the MSI from the Windows package to the job, and the script uses that instead.
The two values reach the script. Your RMM does this one of three ways and the script handles all three without editing. Follow your platform below.

If the client runs ThreatLocker, set up allowlisting first. ThreatLocker blocks the installer and the deployment fails with error 1619. See If you use ThreatLocker at the foot of this section.

Keep the client secret out of anything you share. Some RMMs show script inputs in job history, so check job output before you paste it into an email or a ticket.

Your tool

NinjaOne

Store the values. Administration > Devices > Custom Fields. Create two organization-level fields, ClientId and ClientSecret. Set ClientSecret to type Secure. Fill them in per organization.

Add the script. Administration > Library > Automation > Add > New Script. Language PowerShell, Run As System.

Pass the values. Add two Script Variables with those exact names.

Datto RMM

Store the values. Sites > [site] > Settings > Variables. Add ClientId and ClientSecret. Set ClientSecret to Masked.

Add the component. Automation > Components > New Component. Category Scripts, language PowerShell.

Run it. Create a job with Execution set to Run as system account.

Note. Datto passes input variables as environment variables, which the script picks up automatically.

ConnectWise Automate

Store the values. Client-level EDFs, or script variables.

Add the script. Automation > Scripts > New Script. Use the Execute Script function with PowerShell Bypass.

Pass the values. Automate substitutes %variable% into the script text before PowerShell runs. Define ClientId and ClientSecret as script variables and assign them before the Execute Script step.

Note. Substitution is textual, so make sure values land inside quotes. It also writes the secret into the script text itself, so it can end up in job history. Check job output before you share it anywhere.

ConnectWise RMM

Store the values. Custom fields at the company level.

Add the script. Automation > Scripts > create a PowerShell script.

Pass the values. Reference your custom fields as script variables named ClientId and ClientSecret.

Note. ConnectWise RMM and Automate are separate products with different menus. If you're on Automate, use the section above.

N-able N-central

Store the values. Administration > Custom Properties. Create two at the organization level, then select them as parameters when you run the automation policy.

Add the script. Configuration > Scheduled Tasks > Script/Software Repository > Add > Scripting. Upload the .ps1.

Pass the values. N-central passes them as command-line arguments, in this order:

ClientId ClientSecret

N-able N-sight

Add the script. Use the Script Repository, then Run Script from the device view.

Pass the values. As input parameters, in this order:

ClientId ClientSecret

Note. Menus may differ from what's here.

Atera

Add the script. Admin > Scripts > Create script. File type PowerShell, Run as System.

Pass the values. Use the Arguments field, in this order:

ClientId ClientSecret

Action1

Add the script. Add it to your Script Library as a PowerShell script.

Pass the values. Add ClientId and ClientSecret as script parameters.

Run it. Use a Run Script action against the client's endpoints. Action1 runs scripts as System.

Note. If your Action1 organization enforces PowerShell script signing, sign the script before uploading.

Syncro

Store the values. Create customer custom fields for the client ID and secret, filled in per customer.

Add the script. Scripts > New Script, PowerShell.

Pass the values. Add two Script Variables named ClientId and ClientSecret. Set them to type Platform, pointing at your customer custom fields, and use type Password for the secret so it's masked. The script then picks up the right client based on which asset it runs against.

Note. Requires PowerShell 5.1 or later on the endpoint, which every supported version of Windows has.

Intune

Intune can do both halves. Deploy the agent as a Win32 app and set the extension policy in the settings catalog. You'll need the Windows package for this one (Part 1, step 04), for the .intunewin file.

Or deploy the agent from your RMM with the script, SkipExtension set to 1, and use Intune for the extension only. Then you can skip the package and the Agent steps below.

Agent. Apps > Windows > Add > Windows app (Win32). Upload the .intunewin from your package. Publisher Traceforce. Install behaviour System. Install command:

msiexec /i "<the .msi filename>" /qn /norestart CLIENT_ID="<client id>" CLIENT_SECRET="<client secret>"

Detection rule: File, path %ProgramFiles%\Traceforce, file scout.exe, method File or folder exists.

Extension. Devices > Configuration > Create > New Policy. Platform Windows 10 and later, profile type Settings catalog. Add settings, search extension management, then add both:

Google Chrome > Extensions > Extension management settings
Microsoft Edge > Extensions > Configure extension management settings. Edge labels this one differently, so searching the exact Chrome wording won't find it.

Set both toggles to Enabled. The value alone does nothing if the toggle is off. Paste the matching value into each field, then assign the profile.

Chrome:

{"fbmlfnjlhcnjgomfibgjibecohplhmjh":{"installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx","runtime_allowed_hosts":["*://*"]}}

Edge:

{"hijndbabkmgepoggmnbmknbchklcbknn":{"installation_mode":"force_installed","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx","runtime_allowed_hosts":["*://*"]}}

If either field already has a value, merge into it rather than replacing it. That single value holds every extension rule for that browser, so pasting over it removes the rest. Drop the outer braces from the Traceforce value, add a comma, and put it inside the braces already there.

Already there:
{"aaaaaaaa...":{"installation_mode":"blocked"}}

After merging, in Chrome:
{"aaaaaaaa...":{"installation_mode":"blocked"},"fbmlfnjlhcnjgomfibgjibecohplhmjh":{"installation_mode":"force_installed", ...}}

Group policy, JumpCloud or another MDM

Use this when one of those tools manages the client's browser extensions. It would overwrite anything the script writes, so the extension goes in that tool and the script installs the agent only.

Agent. Run the script from your RMM as usual, with SkipExtension set to 1. If the tool only manages one browser, set it to chrome or edge instead, and the script covers the other. No RMM? Most MDMs can run a PowerShell script as SYSTEM (JumpCloud calls these Commands), so run it from there the same way.

Extension. Add the same two values as in the Intune section above, one per browser.

Group policy: Computer Configuration > Administrative Templates > Google Chrome > Extensions > Extension management settings, and Microsoft Edge > Extensions > Configure extension management settings. You need the Chrome and Edge ADMX templates in your central store.
JumpCloud or another MDM: use its Chrome and Edge extension policy if it has one. If not, set a registry policy:
- key HKLM\SOFTWARE\Policies\Google\Chrome for Chrome, and HKLM\SOFTWARE\Policies\Microsoft\Edge for Edge
- value name ExtensionSettings, type REG_SZ
- that browser's value as the data

If the client already has a value there, merge into it the same way as in Intune.

Any other RMM

The script needs three things, and every RMM can do all three.

Run PowerShell as SYSTEM.
Reach https://port1.io from the endpoint, or attach the MSI from the Windows package to the job.
Supply the two values in one of these ways:
- as PowerShell variables named ClientId and ClientSecret
- as environment variables with those names
- as command-line arguments in this order: ClientId ClientSecret

Got it working somewhere not listed here? Send us the steps at support@port1.io and we'll add it.

Before you move on

Confirm all three:

Agent installed
Extension policy applied to Chrome
Extension policy applied to Edge

Push both browsers regardless of which one your users default to.

If you use ThreatLocker

ThreatLocker blocks msiexec from opening the Traceforce installer, so installs and auto-updates fail with error 1619. Do this before you deploy.

You could put endpoints into learning mode, but that leaves them permissive for however long it runs, and it only teaches ThreatLocker the build installed that day. Set Traceforce up properly instead. One application definition permits the whole chain and holds through future releases.

1. Build the application definition

Create an application named Traceforce and add five file rules. Each rule pairs a path with Traceforce's code signing certificate.

Full Path c:\windows\systemtemp\traceforce\*
Full Path c:\windows\installer\*
Full Path c:\program files\traceforce\*
Process Path c:\program files\traceforce\*
Full Path regex:\\appdata\\(local|locallow|roaming)\\temp

Select the certificate by subject. ThreatLocker displays it as o="traceforce, inc", l=mountain view, s=california, c=us.

The staging folder is where Traceforce drops the MSI before it installs, and that hand-off to msiexec is where the block happens. Program Files is the installed agent. The Windows Installer and AppData temp paths cover what msiexec spawns during the install.

2. Keep it off hashes

If you build these rules from the Unified Audit, ThreatLocker prefills the file hash and the path. Clear the hash box. Every condition left checked has to match, so a hash left in place permits only that exact build and breaks on the next Traceforce release.

For the same reason, use the certificate subject rather than the certificate SHA. The SHA changes when the certificate is renewed.

3. Create the permit policy

Permit the Traceforce application, then Deploy Policies.

If you manage multiple client organizations, place the policy on the Global computer group so it covers the parent and every child organization including servers. A group like Global-Workstations only reaches machines in a Workstation group and will miss anything outside it.

Order the policy above any deny policies. ThreatLocker stops at the first policy a file matches, so a deny sitting above the permit means the permit never fires and the rule still looks correct in the console.

4. Browser extension

Create a separate application definition for the Chromium extension and permit it by extension ID rather than package hash, so it survives extension updates. Add both IDs: Chrome fbmlfnjlhcnjgomfibgjibecohplhmjh and Edge hijndbabkmgepoggmnbmknbchklcbknn.

5. Verify

Stuck agents retry every 20 to 40 minutes, so a machine should pick up the new version within about an hour with no action needed. Confirm the version actually moved rather than just that the block stopped.

If it hasn't, check the Unified Audit for denies on msiexec.exe, scout.exe, chrome.exe or edge.exe, and confirm Traceforce isn't ringfenced. A permitted application can still be blocked from the network or from spawning child processes.

macOS Through your MDM

macOS needs an MDM. Full Disk Access and browser extension policy can only be granted by a configuration profile, and Apple only accepts those from an enrolled MDM. No script or command grants them, so an RMM on its own can't finish a Mac deployment.

If you already run Jamf, Intune or similar, you're set. NinjaOne includes Apple MDM now too, so Ninja partners may already have what they need.

What you'll deploy

Four pieces, all from the package you downloaded in Part 1:

File	What it does
`tf.mobileconfig`	Grants Full Disk Access and locks the agent's background items so users can't disable them
`extension.mobileconfig`	Force-installs the browser extension in Chrome and Edge
The `.pkg`	The agent itself
`install.sh`	Writes the client's credentials into the system keychain

Both profiles work on Apple Silicon and Intel, so one of each covers any fleet. The .pkg is architecture-specific, so a mixed fleet needs both downloads.

You need the same two values here, the Client ID and Client Secret from Part 1. The extension profile already carries the extension settings, so there's nothing to copy out of a text file.

Upload the two profiles

Upload tf.mobileconfig and extension.mobileconfig to your MDM as custom configuration profiles and scope them to the Macs. Every MDM accepts a .mobileconfig upload, though the menu name varies.

If Chrome is managed through Google Workspace at this client, skip extension.mobileconfig and add the extension in the Admin console instead, using the Google Workspace steps in the Windows section. Running both breaks extension management for every extension on the Mac, Traceforce included.

Deploy the package

Push the .pkg through your MDM's normal app or package workflow. For a mixed fleet, scope the Apple Silicon and Intel packages separately so each Mac gets the right one.

Run the install script

After the package lands, run install.sh with the client's Client ID and Client Secret. Jamf uses install_jamf.sh instead.

Rotating credentials later uses the same script. There's nothing separate to run.

Run them in order. The script checks for /Applications/Traceforce.app and stops if the package hasn't finished installing. If it reports the app wasn't found, wait a few seconds and run it again.

Your MDM

Jamf Pro

Profiles. Upload tf.mobileconfig and extension.mobileconfig under Configuration Profiles. Jamf signs them with its own CA. Scope to your Mac Smart Group.

Package. Upload the .pkg to your distribution point. Name them so the architecture is obvious, for example Traceforce Scout (Apple Silicon) and Traceforce Scout (Intel).

Script. Add install_jamf.sh under Settings > Computer Management > Scripts. Label Parameter 4 as Client ID and Parameter 5 as Client Secret.

Policy. Add the package, then the script set to run After. Trigger Once per computer. Scope to the same Smart Group, and fill in the two parameters there.

Note. Use install_jamf.sh, not install.sh. Jamf reserves parameters 1 through 3, so the generic script reads the wrong ones.

Intune

Profiles. Devices > Configuration > Create > New Policy. Platform macOS, profile type Templates > Custom. Upload each .mobileconfig as its own profile.

Package. Apps > macOS > Add > macOS app (PKG). Upload the .pkg.

Script. The PKG app type supports a post-install script. Put install.sh there with the two values filled in, or deploy it separately under Devices > Scripts afterwards.

Note. If you deploy the script separately, give the package time to finish first. The script stops if the app bundle isn't there yet.

NinjaOne

NinjaOne MDM covers macOS, including privacy preferences and custom payloads.

Profiles. Upload both .mobileconfig files as custom configuration profiles in your macOS MDM policy.

Package. Deploy the .pkg through Ninja's macOS software deployment.

Script. Run install.sh as a macOS script, passing Client ID and Client Secret.

Note. The Macs have to be enrolled in NinjaOne MDM, not just running the Ninja agent. The agent on its own can't deliver configuration profiles, so Full Disk Access won't be granted.

Any other MDM

The requirements are the same everywhere, and every MDM accepts a .mobileconfig upload.

Upload tf.mobileconfig and extension.mobileconfig as custom configuration profiles and scope them to the Macs
Deploy the .pkg through the MDM's package workflow
Run install.sh after the package lands, passing the Client ID and Client Secret

Using an MDM not listed here? Send us the steps at support@port1.io and we'll add it.

Before you move on

Confirm all three:

Both profiles installed on the Mac
Package deployed
Install script completed without an error

About the Configuration Profile download. The portal offers one alongside the package. It installs a root certificate for Traceforce's DLP proxy and an assessment doesn't need it. If you use it later, download it from each client's own organization, because it's generated per client and can't be shared between them.

Part 3

Confirm it worked

Check the device

Windows

The script prints a result line. A good one looks like this:

TRACEFORCE: OK agent=installed chrome=ok-written edge=ok-written warnings=0 tasks=3/3 system=True

chrome and edge show one of three values:

ok-written means the policy was just written.
ok-unchanged means it was already right.
ok-installed means the browser has installed the extension. You'll usually see this on a later run.

If warnings is above 0, read the WARN lines just above the result line.

macOS

Confirm both profiles are installed, under System Settings > General > Device Management.

Then check the browser. On Windows, open chrome://extensions and confirm TraceForce Scout is there and enabled, with the ID fbmlfnjlhcnjgomfibgjibecohplhmjh. In Edge, edge://extensions should show it with the ID hijndbabkmgepoggmnbmknbchklcbknn. On a Mac, confirm it's present and enabled in both. If it's missing, open chrome://policy or edge://policy and check that ExtensionSettings is there with status OK.

Check the console

Switch into the client organization and open Devices.

Open the All Versions dropdown and choose No Browser Extension. That list should be empty. Anything on it either didn't get the policy or hasn't checked in yet.

For a single device, the Versions column lists the browser extension separately from the agent, something like Chrome Ext 1.0.36 above Scout.

Give it time. The agent reports within minutes. The extension can take several hours to check in. Restarting the browser or rebooting speeds that up, but neither is required.

Sensitive data findings and storage

Sensitive data findings appear whether or not a storage provider is configured. You'll see what was found, in which conversation, on which device, how many times and when. The prompt content itself stays hidden, and the console says so:

Storage provider is not configured.

For an assessment, leave it alone. You don't need it, and setting it up means handling the client's sensitive data before they've decided anything.

Once a client is on Traceforce ongoing, it's worth a conversation, particularly if they're under a compliance obligation that needs a real evidence chain. Storage is what lets you log what prompts actually contained rather than only that something was found.

If you do set it up, it goes in the client's own cloud storage, not yours. Traceforce supports Amazon S3, Google Cloud Storage and Azure Blob Storage. What lands there is the client's sensitive and potentially regulated data, so it belongs in their tenant, under their control, subject to their retention.

Configured per client organization, under Settings > Storage Provider.

Keep it working

Everything above is a one-time push. On Windows we'd suggest also running the script on a schedule, daily or weekly, across the client's devices.

Browser policy doesn't repair itself, machines that were offline get picked up on the next run, and devices you deploy later are covered automatically. The script checks before it writes, so a device that's already correct costs nothing.

On macOS the MDM handles this for you. Configuration profiles reassert on their own, which is why Apple requires them in the first place.

If something isn't right

Devices appear, but no browser extension

Check chrome://policy on the device. If ExtensionSettings isn't there, the policy didn't land. On Windows, run the script again and read its output, including any WARN lines. If it's there with status OK, give it a few hours or restart the browser. On macOS, confirm the extension profile is installed and scoped to that Mac.

chrome://policy shows a schema validation error

If ExtensionSettings shows Schema validation error: Unknown property, a key under ExtensionSettings in the registry has something besides the 32-letter extension ID in its name, like a space, braces or a label. Chrome throws out the whole policy, Traceforce included. Rename the key to the bare ID or delete it, then run the script again.

Findings appear but you can't read the content

That's the storage provider, not a deployment problem. See Sensitive data findings and storage.

Nothing appears at all

The agent either didn't install or has the wrong credentials. On Windows, check C:\ProgramData\Traceforce\logs\postinstall.log. On macOS, check /var/log/install.log.

To confirm the agent is installed on Windows, run this in PowerShell. It returns the version if it's there, and nothing if it isn't.

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object DisplayName -eq 'Traceforce Scout' | Select-Object DisplayName, DisplayVersion

The script can't download the installer

The result line shows reason=msi-download-failed. The endpoint couldn't reach https://port1.io, usually because a firewall, web filter or proxy is blocking it. Allow that address, or attach the MSI from the Windows package to the job and run it again.

The script says the installer isn't signed by Traceforce

The result line shows reason=msi-signature-invalid. The script checks every installer it downloads for Traceforce's digital signature, and won't run one that doesn't have it. Email us at support@port1.io so we can look at it. Meanwhile, attach the MSI from the Windows package to the job.

Devices check in but show 0 agents and 0 MCPs

Traceforce skips the built-in Windows Administrator account. If that's the only account anyone uses on the machine, nothing gets attributed to a user and nothing reports. This is common on cloud VMs, where the admin account created with the machine is the built-in one. Create a normal local user and sign in with it once.

Custom connectors show, but built-in ones don't

Connectors built into tools like Claude and ChatGPT are found through the browser extension, using the user's signed-in session on that tool's website. The desktop app alone doesn't surface them. They'll appear once the user is signed into that tool's website in Chrome or Edge with the extension installed.

The install fails with error 1619 on Windows

That's ThreatLocker or another application control tool blocking msiexec from opening the installer. See If you use ThreatLocker in the Windows section.

The macOS install script says the app wasn't found

The package hasn't finished installing yet. Wait a few seconds and run the script again.

Reinstalling the agent

Installing the MSI over an existing agent drops its credentials. Windows treats it as a repair and discards the client ID and secret, so the device stops reporting. Uninstall fully with uninstall.ps1 from the Windows package first, then install again. Afterwards, C:\ProgramData\Traceforce\logs\postinstall.log should contain Credentials written to Credential Manager.

Our script never reinstalls over an existing agent, so this only happens when the MSI runs some other way.

Deployed with the wrong client's credentials

You can fix this in place. Re-running the deploy script keeps the credentials it finds, so on Windows, run rotate-credentials.ps1 from the Windows package (Part 1, step 04) as SYSTEM with the correct values. It needs PowerShell 5.1. On macOS, re-run install.sh with the correct values.

A 0 exit code from rotate-credentials.ps1 means the new credentials were written, not that the agent has picked them up yet. The device can take up to about 6 hours to appear in the right organization. If it still hasn't by the next day, ask PORTER or email support@port1.io.

Remove Traceforce from a client

Four steps, in this order.

Turn off the deployment job first

If you're running the script on a schedule, disable or unassign it before anything else. Otherwise the next run reinstalls everything you just removed.

Remove the browser extension policy

Windows

Delete the Traceforce subkey for each browser:

HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionSettings\fbmlfnjlhcnjgomfibgjibecohplhmjh
HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings\hijndbabkmgepoggmnbmknbchklcbknn

Delete only those, and leave the rest of ExtensionSettings alone. If that leaves ExtensionSettings empty, delete it too, since an empty one stops the browser reading any other extension policy. If the script merged into an existing policy value instead, remove just the Traceforce entry from that JSON. If an MDM or group policy holds the extension, remove it there instead.

macOS

Unassign extension.mobileconfig and tf.mobileconfig from the devices in your MDM. If you deployed the Configuration Profile with the proxy certificate, unassign that too, because the uninstall script doesn't remove it.

Removing the policy drops the extension on its own. There's nothing to uninstall by hand.

Run the uninstall script

Each platform's package has its uninstall script (Part 1, step 04). Push it through the same tool you deployed with. On Windows run uninstall.ps1 as SYSTEM. On macOS run uninstall.sh with root privileges.

Either one removes the agent, its scheduled tasks or launch daemons, its stored credentials, and the configuration it wrote into AI tooling on the machine.

Don't just uninstall the package. Traceforce writes managed settings into Claude Code, Cursor and GitHub Copilot. Remove the agent without running the uninstall script and the GitHub Copilot policy file stays behind, still blocking the user's Copilot CLI, with nothing named Traceforce left on the machine to explain why.

Exit code 3010 on Windows means a reboot is needed to finish removing a locked file. That's success, not a failure.

Unlink the organization in Traceforce

Do this last. Org Access > Orgs you can access > Remove my access.

If you unlink first, the endpoints keep running and reporting into nothing.

Found something wrong?

Menus move and platforms change. If a step doesn't match what you're seeing, or you found a better way, tell us at support@port1.io and we'll update this page.

For anything else, ask PORTER first. If PORTER can't get you there, support@port1.io reaches us directly.

v1.4 · Updated October 3, 2026

Want a hand with the first one?

We'll walk through a client deployment with you end to end. It usually takes half an hour.

Book a walkthrough

Onboard a client and deploy Traceforce

On this page

What you're deploying

The agent

The browser extension

Before you start

Add the client in Traceforce

Create the client organization

No sign-in

Metadata URL or Paste XML

Switch into the client organization

Create the API credentials

Download the deployment package

Deploy to endpoints

How are browser extensions managed at this client?

Nothing manages them today

Intune, group policy, JumpCloud or another MDM

Google Workspace

The browser extension

Get the script

Run it

Your tool

Before you move on

1. Build the application definition

2. Keep it off hashes

3. Create the permit policy

4. Browser extension

5. Verify

What you'll deploy

Upload the two profiles

Deploy the package

Run the install script

Your MDM

Before you move on

Confirm it worked

Check the device

Windows

macOS

Check the console

Sensitive data findings and storage

Keep it working

If something isn't right

Devices appear, but no browser extension

chrome://policy shows a schema validation error

Findings appear but you can't read the content

Nothing appears at all

The script can't download the installer

The script says the installer isn't signed by Traceforce

Devices check in but show 0 agents and 0 MCPs

Custom connectors show, but built-in ones don't

The install fails with error 1619 on Windows

The macOS install script says the app wasn't found

Reinstalling the agent

Deployed with the wrong client's credentials

Remove Traceforce from a client

Turn off the deployment job first

Remove the browser extension policy

Windows

macOS

Run the uninstall script

Unlink the organization in Traceforce

Found something wrong?

Want a hand with the first one?