Inloggen Gratis voor altijd Get started

MSP Tools

Your RMM already makes API calls.
Clavitor makes them safe.

Your technicians use Datto, N-able, and ConnectWise every day. Every script, every automation, every scheduled task needs credentials. Today they're in script variables, custom fields, or a shared vault everyone can read. The Clavitor proxy and CLI change that without changing your workflows.

The proxy pattern for RMM

Set HTTPS_PROXY on the endpoint and your existing scripts work unchanged. The proxy intercepts outbound HTTPS requests, resolves clavitor:// references in headers, and injects the real credential. Your script never sees the secret. Your RMM console never logs it.

# On the managed endpoint — one-time setup
$env:HTTPS_PROXY = "http://localhost:1983"

# Your existing automation scripts work unchanged
# The proxy resolves clavitor:// references in request headers
Invoke-RestMethod -Uri "https://api.openai.com/v1/models" `
  -Headers @{ Authorization = "Bearer clavitor://OpenAI/key" }

PowerShell

PowerShell is the MSP's daily language. Both the CLI and the proxy work natively.

CLI — single values

# Resolve, use, scrub — the credential lives for one statement
$cred = clavitor-cli get "Client-Acme/VPN" --field password
Add-VpnConnection -Name "Acme" -ServerAddress "vpn.acme.com" -AuthenticationMethod MSChapv2
$secure = ConvertTo-SecureString $cred -AsPlainText -Force
Set-VpnConnectionUsernamePassword -ConnectionName "Acme" -Password $secure
Remove-Variable cred, secure

Render — config templates

# Template with clavitor:// references (safe to store in your RMM)
clavitor-cli render monitoring-config.json | `
  Set-Content -Path "C:\ProgramData\Monitor\config.json"

Proxy — transparent injection

$env:HTTPS_PROXY = "http://localhost:1983"

# Every Invoke-RestMethod and Invoke-WebRequest now resolves clavitor://
Invoke-RestMethod -Uri "https://api.datto.com/v1/devices" `
  -Headers @{ Authorization = "Bearer clavitor://Datto API/key" }

Atera

Atera substitutes custom-field placeholders into script parameters at run time, using the {[Atera.<level>.CustomField.<name>]} syntax. Pass the Clavitor token to a one-time install script as a parameter; later scripts shell out to the CLI on the endpoint.

Install via IT Automation profile

In the Atera script library, create an Install Clavitor PowerShell script with one parameter. In the IT Automation profile that runs it, invoke with the customer-level field placeholder:

Install-Clavitor.ps1 -Token "{[Atera.Customer.CustomField.ClavitorToken]}"

Atera substitutes the value before the agent reads its arg list. The script:

param([Parameter(Mandatory)][string]$Token)
$Token | clavitor-cli init
Remove-Variable Token

Resolve credentials at runtime

Once the endpoint is enrolled, every later Atera script reads credentials from the vault — Atera holds the token slot only:

$pass = clavitor-cli get "Client-Acme/SQL Server" --field password
$secure = ConvertTo-SecureString $pass -AsPlainText -Force
Invoke-Sqlcmd -ServerInstance "sql.acme.local" `
  -Credential (New-Object PSCredential("sa", $secure)) -Query "SELECT 1"
Remove-Variable pass, secure

ConnectWise Automate

Automate substitutes Extra Data Field (EDF) macros into script step arguments using the {%^el:FieldName^%} syntax (computer-level EDF). The CLI installs via an Automate script that downloads the binary and invokes a PowerShell step with the token passed as a parameter — the EDF value is replaced before the script step executes.

Automate script: install

In the Automate script editor, create the script with two steps:

Step 1  File Download from LTShare       clavitor-cli.exe → %windir%\Temp\
Step 2  Shell Execute (PowerShell)       Install-Clavitor.ps1 -Token "{%^el:ClavitorToken^%}"

The {%^el:ClavitorToken^%} macro is replaced with the computer-level EDF value before the PowerShell step runs. Keep tokens under 255 characters to stay inside LabReplace's substitution limit. The script itself:

# Install-Clavitor.ps1
param([Parameter(Mandatory)][string]$Token)
$Token | clavitor-cli init
Remove-Variable Token

Automate script: rotate a domain credential

Subsequent scripts read from the vault and write a status back to the EDF for dashboarding:

$cred = clavitor-cli get "Client-Delta/Domain Admin" --field password
$secure = ConvertTo-SecureString $cred -AsPlainText -Force
Reset-ComputerMachinePassword `
  -Credential (New-Object PSCredential("administrator", $secure))
# Push timestamp back to EDF "LastRotation" via Automate's ExtraData Set Value step
Write-Output (Get-Date -Format o)
Remove-Variable cred, secure

Datto RMM

Datto RMM exposes site and global variables to PowerShell components as environment variables with the $env: prefix; user-defined fields (UDFs) are exposed as $env:UDF_1 through $env:UDF_30. One component installs the CLI; everything afterwards reads from the vault.

Component: install and initialize

Define a site variable ClavitorToken in the Datto console — it surfaces inside the component as $env:ClavitorToken:

# Datto RMM component: bootstrap Clavitor CLI
# Site variable "ClavitorToken" → $env:ClavitorToken at runtime
$env:ClavitorToken | clavitor-cli init

Component: API monitor via the proxy

Subsequent components write clavitor:// references in request headers — the proxy resolves them on the host. The credential never enters the script's memory or Datto's logs:

# Scheduled monitor — runs every 15 minutes
$env:HTTPS_PROXY = "http://localhost:1983"
$response = Invoke-RestMethod -Uri "https://api.client.com/v1/status" `
  -Headers @{ Authorization = "Bearer clavitor://Client-Bravo/Monitoring API" }

# Push a status code back into UDF_5 for the Datto dashboard
New-ItemProperty -Path "HKLM:\SOFTWARE\CentraStage" `
  -Name "Custom5" -Value $response.status -Force | Out-Null

Kaseya VSA

VSA agent procedures substitute #variable# macros into PowerShell arguments at run time, then execute the script via the executePowershell step family (executePowerShell64BitSystem, etc.). A Custom Field on the agent record holds the Clavitor token; the procedure passes it to init through stdin.

Agent procedure: install

Add an agent Custom Field ClavitorToken (Audit → Edit Profile → Custom Fields), then build a procedure with two steps:

Step 1  Get File from VSA Server     clavitor-cli.exe → C:\Program Files\Clavitor\
Step 2  Execute PowerShell (64 Sys)  "C:\Program Files\Clavitor\clavitor-cli.exe init" \
                                     stdin = "#vAgentConfiguration.ClavitorToken#"

The #vAgentConfiguration.ClavitorToken# macro is replaced with the Custom Field value before VSA executes the command — the token does not appear in VSA's procedure history.

Agent procedure: rotate a privileged credential

Once initialized, any later procedure reads from the vault:

# Executed via executePowerShell64BitSystem
$cred = clavitor-cli get "Client-Hotel/Local Admin" --field password
$secure = ConvertTo-SecureString $cred -AsPlainText -Force
Set-LocalUser -Name "Administrator" -Password $secure
Remove-Variable cred, secure

N-able N-central

The unit of automation is an AMP (Automation Manager Policy) — a PowerShell-based policy built in Automation Manager. Custom Properties at the organization, customer, or site level can be passed to a Run PowerShell Script object as Input Parameters.

AMP: install with Custom Property as input

Add a Custom Property ClavitorToken at the customer level (Administration → Custom Properties). In Automation Manager, create an AMP whose Run PowerShell Script object binds the Input Parameter Token to that Custom Property. The script:

param([Parameter(Mandatory)][string]$Token)
$Token | clavitor-cli init
Remove-Variable Token

The Custom Property value flows in as $Token. It never appears in the AMP's exported XML or in N-central's audit log.

Script Repository: fetch a credential at runtime

For ad-hoc scripts pushed via the Script Repository (Configuration → Repository → Scripts/Software), the endpoint is already initialized — the script just calls the CLI:

$dbPass = clavitor-cli get "Client-Bcme/SQL Server" --field password
$secure = ConvertTo-SecureString $dbPass -AsPlainText -Force
Invoke-Sqlcmd -ServerInstance "sql.bcme.com" `
  -Credential (New-Object PSCredential("sa", $secure)) -Query "SELECT 1"
Remove-Variable dbPass, secure

N-able N-sight

N-sight (formerly SolarWinds RMM) runs the same Automation Manager engine as N-central, plus a Script Manager for .ps1, AMP, batch, and other script types. The pattern mirrors N-central: AMP with an Input Parameter for the token, then everything else resolves at runtime.

Script Manager: install via Automated Task

Upload an Install-Clavitor.ps1 to Settings → Script Manager with a parameter for the token. Attach it as an Automated Task on the endpoint; pass the token as a script argument from the device-level setting:

param([Parameter(Mandatory)][string]$Token)
$Token | clavitor-cli init
Remove-Variable Token

Automated Task: scheduled backup with vault credentials

Once initialized, scheduled tasks pull credentials from the vault. Any standard output up to 255 characters surfaces back to the N-sight dashboard:

$pass = clavitor-cli get "Client-India/SQL Backup" --field password
$secure = ConvertTo-SecureString $pass -AsPlainText -Force
Backup-SqlDatabase -ServerInstance "sql.india.com" -Database "AppDB" `
  -Credential (New-Object PSCredential("backup-svc", $secure))
Write-Output "backup OK $(Get-Date -Format o)"
Remove-Variable pass, secure

NinjaOne

NinjaOne scripts running on the endpoint can read and write custom fields through built-in cmdlets: Ninja-Property-Get <name> returns the value, Ninja-Property-Set <name> <value> writes it back. Store the Clavitor token in an organization custom field (type Secure so it is write-only from the console); the install script reads it once.

Install script: read token from custom field

In Administration → Library → Custom Fields, add an organization field clavitorToken of type Secure. Then run an install script:

$token = Ninja-Property-Get clavitorToken
$token | clavitor-cli init
Remove-Variable token

Custom Action: API call through the proxy

Once installed, automations call external APIs via the proxy — the credential is never copied into a script variable:

$env:HTTPS_PROXY = "http://localhost:1983"
$response = Invoke-RestMethod -Uri "https://api.client-echo.com/v1/status" `
  -Headers @{ Authorization = "Bearer clavitor://Client-Echo/Monitoring API" }

# Push the result back to a device custom field for dashboarding
Ninja-Property-Set lastApiStatus $response.status

Syncro

Syncro exposes asset custom fields and tags as Platform script variables using the {{asset_custom_field_<name>}} double-curly syntax. Define a script variable of type Platform and bind it to the field — Syncro substitutes the value into a PowerShell parameter at script-run time.

Syncro script: install

Create an asset custom field clavitor_token. In the script editor, declare a variable Token of type Platform bound to {{asset_custom_field_clavitor_token}}; pass it to a PowerShell parameter in the script body:

param([Parameter(Mandatory)][string]$Token)
$Token | clavitor-cli init
Remove-Variable Token

The Quick Help panel at the bottom of every Syncro script editor lists every available platform variable for the asset, customer, and ticket context.

Syncro script: connect VPN with vault credentials

After install, scripts and Automated Remediations resolve credentials from the vault and use them directly:

$pass = clavitor-cli get "Client-Golf/VPN" --field password
$secure = ConvertTo-SecureString $pass -AsPlainText -Force
Add-VpnConnection -Name "Golf" -ServerAddress "vpn.golf.com" `
  -AuthenticationMethod MSChapv2 -Force
Set-VpnConnectionUsernamePassword -ConnectionName "Golf" -Password $secure
# Write status back to asset for Syncro dashboard
Rmm-Alert -Category "vpn-status" -Body "Golf connected $(Get-Date -Format o)"
Remove-Variable pass, secure

Why this matters for MSPs

Every RMM platform stores credentials somewhere — custom properties, site variables, extra data fields, script parameters. Every technician with console access can see them. Every breach of your RMM console exposes every client's credentials.

Clavitor moves the credentials out of the RMM. The RMM stores only the agent token (one per client). The token grants scoped access to that client's vault. A breach of your RMM console exposes tokens, not credentials — and each token is IP-whitelisted to the endpoint it was deployed on.

Scoped per client

Each client vault has its own agent token. Technician access is controlled by scope, not by "who can log into the RMM console."

Audited per script

Every credential access is logged — which script, which endpoint, which credential, when. Your clients can see the audit trail. You can prove who accessed what.

Revoked in one click

Client leaves? Revoke their agent token. Every endpoint stops resolving credentials immediately. No passwords to rotate, no custom properties to clear across 200 machines.

Stop storing credentials in your RMM.

One CLI. Every client. Every credential scoped, audited, and revocable.