Environment Variables Inventory

For every managed machine, Athena inventories the environment variables defined on that machine — their name, value, and scope. This lets you answer configuration questions across the fleet from the console instead of logging on to each device: what does PATH look like on a given server, is a HTTPS_PROXY set, where does JAVA_HOME point, or which machines still carry a stale variable left behind by an old install.

This is read-only discovery. Athena reports the environment variables each machine already has; it does not create, change, or delete them. To set or remove a variable on an endpoint, run a remote command or a deployment that performs the change on the machine.

What's collected#

For each machine, Athena records every environment variable it can read, and for each one the following:

Field	Meaning
Variable Name	The name of the variable — for example `PATH`, `TEMP`, `JAVA_HOME`, `HTTP_PROXY`.
Value	The variable's value as read from the machine — for example the directory list in `PATH` or the URL in a proxy variable.
Scope	Where the variable is defined. See Scope & platform coverage below.

Scope & platform coverage#

Environment variables are collected on both Windows and Linux endpoints, using each operating system's native facilities. The Scope value tells you where a variable comes from, and it differs by platform:

Scope	Platform	Meaning
`System`	Windows	Machine-wide variables that apply to every account on the computer.
`User`	Windows	Variables defined for the user profile under which the agent reads them.
`Process`	Linux	The environment the agent process itself runs with — the effective, resolved set of variables in force for the agent's service context.

On Windows, both machine-wide (System) and per-user (User) variables are reported, and the list is ordered by scope and then by name so related variables sit together. On Linux, the agent reports its own resolved process environment as scope Process.

What "value" reflects. The recorded value is what the operating system reports at collection time. A variable that is set differently for an interactive login shell than for the machine or service context can therefore read differently than what a signed-in user sees in their own session — this record describes the machine's configured and effective variables, not an individual user's live shell.

What it's good for#

Application configuration audits — confirm that variables such as JAVA_HOME, PYTHONPATH, or NODE_PATH point where you expect across a group of servers.
Proxy & connectivity checks — verify that HTTP_PROXY, HTTPS_PROXY, and NO_PROXY are set correctly (or absent) on the machines that need them, which is especially useful on air-gapped or restricted networks.
PATH review — inspect what is on a machine's PATH when troubleshooting a program that resolves to the wrong binary.
Cleanup after migrations — spot stale variables left behind by software that has since been removed.

Where to see it#

Open a machine from the Agents list, then in the agent detail view's left-hand navigation choose Environment Vars. The section lists the variables in a table with three columns — Variable Name, Value, and Scope.

A search box above the table filters as you type and matches on both the variable name and its value, so you can type PROXY to find every proxy-related variable, or paste part of a path to find which variable contains it.

Like the rest of inventory, the values reflect the machine's last successful collection on its regular reporting cadence rather than a live query at open time. For the wider inventory surface and refresh behaviour, see Inventory.

Scope note. Environment variables are a per-machine inventory field, viewed on a machine's detail view. They are not currently one of the fields you can build a dynamic collection, an automatic tag, or a report-builder column from. If you need a fleet-wide rule (for example, "flag any machine missing the expected HTTPS_PROXY"), evaluate it on the endpoint with a compliance rule or a custom scan and surface the answer through the scan results — which you can then use in collections, tagging, and reports like any other collected field.

Reading it over the API#

Environment variables are part of an agent's full inventory. Fetch the complete inventory document and read the environmentVariables array:

# Fetch the full inventory for one agent, then inspect environment variables
$headers = @{ Authorization = "Bearer $token" }

$inv = Invoke-RestMethod `
  -Uri "https://athena.example.com:8443/api/agents/$agentId/inventory" `
  -Headers $headers `
  -SkipCertificateCheck

# List every environment variable with its scope
$inv.data.environmentVariables |
  Select-Object scope, name, value | Sort-Object scope, name

# Just the value of PATH
($inv.data.environmentVariables | Where-Object name -eq 'PATH').value

You can also retrieve the same document with the PowerShell module and read the EnvironmentVariables property directly:

$inv = Get-AthenaAgentInventory -AgentId $agentId
$inv.EnvironmentVariables | Where-Object Name -like '*PROXY*'

Each element of environmentVariables carries name, value, and scope. Reading inventory requires the Helpdesk role or higher. The environmentVariables array is empty or absent when a machine has not yet reported this data. For the full inventory surface and the PowerShell module used to script against the server, see Inventory and the PowerShell Module reference.