Skip to main content
The tool reaches a client’s own Airlock Digital server through its REST API, with the API key you save in Neo for that client, so each call is limited twice: by the REST permissions of that key’s user group in Airlock and by the agent’s permission groups below.
Automatically enabled when you configure Airlock Digital permissions in your agent workflow. No manual toggle needed.

What It Does

  • Read each computer’s enforcement agent: status, last check-in, version and policy group
  • Read policy groups and their policies: assigned allowlists, baselines and blocklists, exclusions and settings
  • Read blocked and audited executions by computer, user, file or date, and activity summaries
  • Read OTP history: which codes were granted, to which computer and user, and the files that ran under a code
  • Move computers between policy groups
  • Issue an OTP code, after a technician approves it, and revoke one
  • Look a file up by hash, read its reputation, add it to an allowlist or blocklist or remove it
  • Approve or deny exception requests users raise from a blocked computer
The agent calls the Airlock REST API through the Vendor API tool, with airlock_digital as the vendor id and the client’s PSA company id. Sandbox scripts can call Airlock Digital too, under the same permissions, except that a script cannot issue an OTP code.

Permission Groups

Every group can be Disabled, Read Only or Read/Write. Neo never sends these calls: authenticate, which reads or replaces an account’s API key; the agent installer download; agent/config, whose configuration file carries the agent’s TLS private key; and group/settings/updateall, which replaces every setting of a group at once (Neo changes each setting on its own path). Neo removes these fields from every answer: otpcode (except in the answer that issues a code, which the agent tool keeps out of the run log), agentstopcode, proxypass, password, apikey, licensekey and verificationcode, and, in the policy change history, the old and new value of a setting whose name is a credential (a stop code, a proxy password).

Access Profiles

Every group Read Only. The agent reads, and never changes anything.
Agents, OTP Codes, Exception Requests and Allowlists, Baselines & Files are Read/Write with technician approval. Everything else is Read Only.
Every group Read/Write. Allowlists, Baselines & Files, Policy Groups & Exclusions and Users, Licence & Relays require technician approval, and so do the changes below.
Every group Read/Write without approval, except the changes below, which still require technician approval.

Safety Controls

These require technician approval under every access profile, whatever the group’s own approval setting:
  • Issuing an OTP code.
  • Audit mode, script control mode and the agent stop code, which stop blocking or let a user stop the agent.
  • Removing an agent, and moving a computer to Unmanaged.
  • Deleting a policy group, an allowlist, a baseline, a blocklist or an allowlist category, and replacing a group’s configuration with another group’s.
  • Removing a hash from every allowlist, every baseline or every blocklist at once.
  • The proxy settings, which store the proxy password.
  • Setting the licence key, and any change to console users.
  • Any change that stores a credential: a password, a stop code or a licence key.