What is neagent on Mac?

Last updated: 2026-08-08

What it is

neagent is an Apple-supplied host for Network Extension plug-ins on macOS. It lives at /usr/libexec/neagent, uses the code identifier com.apple.neagent, and the verified system copy is signed by Apple. It is part of macOS rather than a standalone VPN product or a third-party application.

launchd starts neagent on demand for the current user. More than one instance can exist at the same time because separate Network Extension providers may need their own host processes. The local neagent(8) documentation explicitly identifies VPN providers, content filters, and NEProvider App Extensions among the plug-ins it can host. What any particular instance does therefore depends on the extension loaded into that instance.

This distinction matters when neagent appears in a process list or network monitor. The process name identifies the host, not necessarily the software, service, or configuration responsible for the activity. A VPN provider, filtering product, DNS component, or proxy provider may be doing the actual work inside it.

A DNS proxy is a type of NEProvider, but the available Apple documentation does not guarantee that every DNS proxy is hosted by neagent across every macOS release and provider packaging method. It is safer to treat DNS proxy hosting as possible rather than universal.

Why it talks to the network

neagent should show connections only when an extension it hosts needs to communicate. The destination, protocol, and frequency are determined by that extension and its configuration. Seeing a connection under the neagent name is therefore not enough to attribute the destination to Apple.

When a Packet Tunnel VPN is active, its provider receives data from a virtual interface, encapsulates that data, and sends it to the VPN server configured by the user or organization. In that situation, traffic generated by many other applications can appear under the host responsible for the tunnel’s outer connection. The applications remain the original sources of the activity even though the tunnel provider handles the network transfer.

An enabled DNS proxy may forward system DNS queries to a conventional recursive resolver, a DoH or DoT service, or a custom proxy. Apple’s public material does not establish that all DNS proxy configurations use neagent, so the process name alone cannot prove that DNS forwarding is occurring.

A content filter’s control component may connect to its vendor’s servers to retrieve rules or policies. An App Proxy provider may connect to destination servers or to an upstream proxy. These cases can look very different in a network monitor: one extension may make occasional control connections, while another may remain busy because it is forwarding application traffic.

The practical question is not simply “Why did Apple’s neagent connect?” It is “Which enabled Network Extension is this instance hosting, and what has that extension been configured to do?”

How much traffic is normal

Apple has not published a normal traffic range for neagent, so there is no reliable number of megabytes that separates expected activity from suspicious activity. A fixed threshold would be misleading because the process can host extensions with fundamentally different jobs.

If no relevant extension is active, neagent normally has no sustained traffic and may not be running at all. An extension that handles only DNS requests or downloads filtering rules will generally produce intermittent control traffic. The exact amount and timing still depend on the provider and its configuration.

A full-tunnel VPN or proxy is different. Because it can forward traffic for other applications, the amount recorded under neagent may reach the same general scale as the combined traffic being forwarded and may remain high for as long as that activity continues. High usage in this case does not show that neagent independently chose to download something.

Claims that every byte passing through a VPN must be counted twice are not established. Some monitoring layers may expose both an application-side flow and the tunnel’s outer connection, but Apple has not published a single accounting rule for Activity Monitor and third-party traffic tools that applies to all Network Extension types. Without knowing the measurement layer, apparent duplication should remain an open possibility rather than a guaranteed explanation.

Can you turn it off

Apple does not provide a supported switch for turning off neagent itself. It is a shared, on-demand system host, so managing the specific extension is the supported way to stop the associated function.

Force-quitting or blocking an active instance can interrupt whatever it currently hosts. A VPN may disconnect. A DNS proxy may stop resolving names. Content filtering or an organization’s security policy may cease to work. The interruption may also be temporary because launchd can start neagent again when an extension requests it.

To disable a particular extension, open Apple menu > System Settings > General > Login Items & Extensions > Network Extensions, then manage the corresponding extension. To disconnect a VPN, use Apple menu > System Settings > VPN > the relevant VPN > Off. A configuration controlled by an organization may prevent the user from changing these settings.

Disabling neagent permanently is not a supported performance adjustment. Persistent activity usually indicates that an enabled VPN, content filter, DNS provider, or proxy function is using the host. Identifying and managing that specific extension preserves the distinction between an unwanted feature and the macOS process required to run it.

What people get wrong

• “neagent is a virus, cryptocurrency miner, or secret Apple uploader.” The verified /usr/libexec/neagent on the current system is Apple-signed and identifies itself as com.apple.neagent. It is a built-in Network Extension host. Its presence or network activity does not, by itself, support any of those claims.

• “High neagent traffic means the process itself is downloading data.” Large transfers may belong to a VPN or proxy provider hosted by neagent. The original trigger can be another application whose traffic is being forwarded through that provider. The host name alone does not identify the originating application or prove that Apple selected the destination.

• “Every byte through a VPN is definitely counted twice.” This has not been verified. A monitoring layer may display an inner application flow and an outer VPN connection, but Apple has not documented a universal double-counting guarantee across every extension and measurement tool.

• “Blocking neagent breaks every Network Extension installed on the Mac.” That is too broad. Blocking an instance threatens the active extension being hosted by that instance, while an extension that is not enabled is not immediately affected. Providers may also be packaged using different App Extension or System Extension approaches, so one claim cannot describe every installation.

• “Permanently disabling neagent will make the Mac faster.” neagent is started on demand. Continued activity points to a VPN, filter, DNS, or proxy function that is currently using it. The useful investigation is to identify that function and decide whether it should remain enabled; disabling the shared host does not address the configuration responsible for the work.

Seeing what it actually used

The next step is to check neagent in Bytetally’s per-process traffic view and compare its activity with the VPN, filter, DNS, or proxy extensions currently enabled. Look at when the traffic starts, how long it continues, and whether it changes when the corresponding extension is legitimately disconnected. Process totals provide evidence about scale and timing, but the neagent name alone still cannot identify the original application behind tunneled or proxied traffic.

Related processes

Common questions