⚠️Status: This specific issue has been resolved in the Liongard platform. There are no known defects that result in on-demand agents not appearing in the inspector configuration dropdown.
Overview 💥
This article clarifies how agent selection works when configuring inspectors in Liongard and addresses confusion stemming from an older issue where the On-Demand Agent appeared to be missing from the agent dropdown.
👉 That issue has been fully resolved and no longer exists.
Today, if an agent:
does not appear,
appears but inspections fail, or
behaves differently than expected,
the cause is almost always related to agent type, environment scope, network access, or agent status, rather than a platform defect.
This article provides explanation of:
Liongard’s two agent models
How and why agents appear in the inspector configuration dropdown
Expected behaviors (including offline agents)
When to use Global vs Single-Environment agents
How to troubleshoot agent-related inspection failures
Understanding Liongard Agent Architecture 🧑🏫
Liongard uses two distinct agent types, each designed for specific inspection scenarios.
🧠 Why This Matters
Choosing the wrong agent type is one of the most common reasons inspections fail or behave unexpectedly.
🔍 Agent Types Overview
Agent Type | Managed By | Runs Where | Primary Purpose |
On-Demand Agent | Liongard | Liongard Cloud (AWS) | Cloud & API-based systems |
Self-Managed Agent | Partner | Customer network | LAN, restricted, static-IP systems |
On-Demand Agent (Liongard-Managed) 🦁
The On-Demand Agent is the default and recommended agent for most inspections.
✅ How It Works
Runs entirely in Liongard’s cloud (AWS)
No installation, maintenance, or patching required
Automatically updated and monitored by Liongard
Appears automatically when supported by an inspector
🎯 Best Use Cases
Microsoft 365
SaaS platforms
Public APIs
External services
Any system accessible over the public internet
🌐 Networking Behavior
Uses dynamic IP addresses from AWS shared pools
Source IPs may change over time
⚠️ Important Limitation
If the system being inspected enforces IP allowlisting, the On-Demand Agent may fail because its IP addresses are not static.
In these scenarios, a Self-Managed Agent is required.
Self-Managed Agent (Partner-Managed) 💻
The Self-Managed Agent is designed for systems that cannot be inspected from the public internet.
✅ Key Characteristics
Installed and maintained by the partner
Runs inside the customer’s network
Required for internal or restricted systems
Current version: 5.1.2
Unified agent (replaces legacy Endpoint / On-Prem / Self-Hosted agents)
🔐 Common Use Cases
Active Directory
Network devices (firewalls, switches)
Hypervisors
Internal servers
Cloud services with strict IP restrictions
🧠 Network Design Requirement
One Self-Managed Agent is required per VLAN
This ensures the agent can communicate directly with systems on that network segment.
Self-Managed Agent Status Behavior (Very Important) 🚨
ℹ️ Expected Behavior
A Self-Managed Agent will still appear in the inspector dropdown even if it is offline.
However:
Inspections will not run
Inspection status will show “Agent Issues”
This is intentional behavior, allowing:
Inspectors to remain configured
Agents to resume inspections automatically when connectivity is restored
Environment Scope for Self-Managed Agents 🌎
Self-Managed Agents support environment scoping, which determines which environments they can inspect.
🔧 Scope Options Explained
Scope Type | Description | Typical Use Case |
Single Environment | Single environment scoped agents are locked to process inspections for only one specific environment. | This is the most common deployment - you typically install one agent per customer environment/network to handle all local inspections within that environment. |
Global | Global scoped agents are mainly used when you need one agent to handle inspections across multiple environments instead of being locked to just one. | The primary use case is for cloud system inspectors that require a static IP source - like when you're working with cloud services that have IP restrictions and need consistent source addresses. |
🧠 Why Global Agents Exist
Global Self-Managed Agents are designed for very specific scenarios, such as:
Cloud systems that require a static IP
MSPs managing multiple customers from a central inspection point
Replacing the legacy Self-Hosted Agent model
ℹ️ Global scope is not required for most LAN inspections
How to Assign or Change Agent Scope 🧐
Navigate to Admin → Agents
Select the Self-Managed Agent
Select Assign Environment
Choose:
Single Environment
Global
⚠️ If the agent already has inspectors assigned, those inspectors will move with the agent.
How Agent Selection Works During Inspector Configuration 🌟
When you configure an inspector, Liongard dynamically determines which agents are eligible.
🧠 The Platform Evaluates:
Inspector type
Agent type compatibility
Environment assignment
Agent scope
Agent availability
What You Should Expect to See 🙌
Scenario | Agent Behavior |
Cloud inspector (M365, SaaS) | On-Demand Agent appears |
LAN device inspection | Self-Managed Agent required |
Offline Self-Managed Agent | Appears, inspection fails |
Agent assigned to wrong environment | Does not appear in the specific environment but will appear in the assigned environment. |
IP-restricted system | On-Demand may fail |
Troubleshooting Agent-Related Issues 👨💻
Step 1️⃣ — Identify the System Type
Ask: “Is this system cloud-based or inside the customer network?”
System Type | Correct Agent |
Cloud / SaaS | On-Demand |
LAN / Internal / Endpoint | Self-Managed |
Static-IP Cloud | Self-Managed (Global) |
Step 2️⃣ — Check Agent Status
Go to Admin → Agents
You can view:
Online vs offline agents
Outdated agents
Agents awaiting configuration
Totals by agent type
Agents are separated into:
Liongard-Managed (On-Demand)
Self-Managed
Step 3️⃣ — Verify Environment Scope
Ensure the agent:
Is assigned to the correct environment
Is Global if inspecting multiple environments
Matches the inspector’s environment
Step 4️⃣ — Confirm User Permissions
Four roles can manage agents in Liongard:
Global roles (can do everything with all agents):
Global Admin
Global Environment Manager
Global System Integrators
Environment Administrators (limited scope):
Can install agents
Can only manage agents they installed themselves
Can only assign agents to environments they're assigned to
Cannot see agents from other environments
All these roles can install, delete, and assign agents to inspectors. The main difference is global roles have platform-wide access while Environment Administrators are restricted to their own environments and agents.
When to Contact Liongard Support 🚀
Contact Support after confirming:
Correct agent type
Correct environment scope
Agent connectivity
Inspector compatibility
📋 Provide the Following:
Agent name and type
Inspector name
Environment name
Agent last heartbeat time
Screenshot of agent selection dropdown
Disclaimer ⚠️
ℹ️ The original issue where the On-Demand Agent was missing from the dropdown has been fully resolved.
Any similar behavior observed today is the result of agent selection logic, scope configuration, or network access constraints, not a platform defect.
Summary 🤩
Liongard uses On-Demand and Self-Managed agents
Agent selection is intentional and rule-based
Offline Self-Managed agents still appear (by design)
Global agents exist for static-IP cloud use cases
Most issues are resolved by validating agent type, scope, and access