Skip to main content
Each call carries an API path, an HTTP method, and — where the endpoint needs them — query parameters, a request body, and headers from the vendor’s allowlist. Neo adds the base URL and the authentication, so the agent never handles the credentials, and a header outside the allowlist is rejected. A vendor the agent’s permissions do not cover is rejected before any HTTP call.
Automatically enabled when you configure permissions for any of the covered vendors in your agent workflow. No manual toggle needed — and it never appears as a separate tool to configure.
The agent’s instructions list the vendors your permissions enable, with a line on what each one covers. The endpoint tables, request shapes, and each vendor’s quirks live in that vendor’s skill, which the agent must load before its first call to the vendor.

​
What It Does

  • Calls the vendor’s REST API directly — reads and (where permitted) writes
  • Routes each call through the vendor’s own permission groups, exactly as the former per-vendor tools did
  • Applies the vendor’s approval rules: operations a vendor always gates (Huntress host isolation, ThreatLocker software approvals and policy edits, AutoElevate elevation decisions, BeyondTrust EPM JIT request decisions and computer removal, SentinelOne agent uninstall and decommission, CIPP device wipe, retire and deletion, ScalePad ControlMap and Backup Radar writes, Domotz collector and Organization deletion, SaaS Alerts response actions and rule-trigger approve, reject and manual remediation, Datto EDR quarantine restore and delete, response actions, exclusions and policy changes, Mimecast held-mail releases, permits, policy changes, remediations and sending email, WatchGuard FireCloud allow exceptions, policy, VPN, certificate and template changes, disabling global exceptions, deployments, protection uninstalls, security configuration moves, undoing a containment, operator changes, deallocations and orders, Sophos allowed item, exclusion and local site changes, taking a category out of TLS decryption, block removals, turning the MDR threat feed off or to log only, lifting an isolation, turning Adaptive Attack Protection off, policy settings that turn protection off or allow, runtime detection rules turned off, web filtering profiles and DNS Protection policies that allow, endpoint deletes, device software changes, turning Tamper Protection off or regenerating its password, authorizing a PUA, releasing an email with its sender allowed, phone wipes and unenrolls, creating or deleting the Intercept X for Mobile auto-enrollment or rotating its connection code, setting iOS auto-enrollment on a device group, mailbox removals, S/MIME changes, firewall deletes, admin, role and token changes, and tenant and product changes, TP-Link Omada customer and site deletion, backup restores, device forgets, admin, role, SSO and two-factor changes, and writes that set a secret (a password, key, PIN, token or SNMP community), OpenText Secure Cloud admin and role changes, endpoint keycode changes, endpoint uninstalls and deactivations, site suspensions and deactivations, and product cancellations, the Zabbix writes listed under “Changes that always ask a technician” in Connecting Zabbix, the Cisco Meraki writes listed under “Changes that always ask a technician” in Connecting Cisco Meraki, the Duo writes listed under “Safety Controls” in Duo API) still require technician approval regardless of automation level

​
Covered Vendors

​
Permissions & Billing

Each vendor keeps its own permission groups in the agent’s settings — enabling one vendor never grants another. On a scheduled or chat agent each call prices by what it did (Tool credit costs), and usage reporting keeps the per-vendor split.