Active Directory. Okta. Entra ID. RADIUS. Most identity systems were built around people and the devices people use. AI agents add a different kind of actor: software that runs unattended, around the clock, on servers, laptops, AI PCs, kiosks and headless devices.
Security teams are now being asked three questions about those agents. Can we identify them? Can we limit what they reach? Can we show afterwards what happened? Most of the answers live in the application layer: your identity provider, your agent platform, runtime controls and endpoint security. This post covers the part the network can honestly answer, and the part it can't.
Two Halves of the Problem
Agent identity products from identity providers treat each agent as its own directory object, with its own credentials and policy on the calls it makes. That is application-layer identity, and it is where per-agent permissions belong.
Network access control works one layer down. It decides which machines get onto Wi-Fi or a wired port, and which segment they land on. It does not see agent processes. An individual Internet-Draft submitted to the IETF in July 2026, draft-shang-agent-network-admission (a work in progress, not a standard), makes the same point: EAP and EAP-TLS commonly authenticate a device, host, user or supplicant, which is not enough to tell apart several agents that share one host.
Both halves matter. An agent with valid tokens still runs on a machine, and that machine still joins your network.
Where the Network Layer Helps
At the moment a machine connects, the network can do five useful things for agent hosts and other non-human devices.
1. Replace Shared Passwords on Non-Human Devices
A shared Wi-Fi password on an agent host, kiosk or IoT controller can't be tied to one machine, and you can't cut off one machine without re-keying every device that uses it. Per-device certificates from Cloud PKI, issued over SCEP through your MDM where you have one, give each machine its own credential that can be revoked on its own.
2. Identify Machines at Network Join
With 802.1X and EAP-TLS, the RADIUS server checks the device certificate before the machine gets on the network. A machine without a valid certificate does not get on.
3. Limit Where Each Machine Lands
RADIUS policy can return VLAN or role attributes based on the device's group. Agent hosts can sit on their own segment, separate from production systems and staff devices, using policy rules rather than a flat network.
4. Keep a Record of What Connected
RADIUS authentication and accounting records show which device connected, when, where and to which network. That is useful audit evidence, but it is network evidence: it does not show what an agent did inside an application.
5. Keep Access in Step With Your Directory
When network access follows the directory, a user who is deactivated in Okta over SCIM is disabled in IronWiFi. Deactivating a user in your directory does not revoke a host's certificate or disconnect a session that is already connected, and it may not stop the host from signing in again. Certificate revocation, device removal and session disconnect are separate admin steps. IronWiFi syncs users and groups from Microsoft Entra ID and Okta over SCIM 2.0, and from Google Workspace with a directory connector. Suspending or deleting a user in Google Workspace does not currently disable them in IronWiFi, and it doesn't revoke certificates or end a live session. Confirm the user is disabled in IronWiFi, use Disable & Revoke Certs, and check the authentication logs before treating WiFi access as cut off.
What the Network Layer Cannot Do
IronWiFi works at 802.1X, for the devices and hosts that join your network - not for the agent processes running on them. Network access control, including IronWiFi, cannot authenticate individual agent processes on a shared machine, issue or store API keys and tokens, or govern what an agent does inside an application. If several agents run on one laptop, they share that laptop's network identity. Pair network access control with your identity provider, runtime controls and endpoint security.
A Practical Pattern for Agent Hosts
Five Steps Worth Taking Now
- Separate dedicated agent hosts. Give on-premises servers, build runners and lab machines that run agents their own device certificates and their own group in your directory.
- Give them their own segment. Place that group on its own VLAN or role, away from production and staff networks.
- Retire shared passwords. Move AI PCs, kiosks and headless devices from shared Wi-Fi passwords to device certificates.
- Revoke when machines change. Revoke certificates when a machine is retired, reassigned or suspected of compromise.
- Keep the logs. Review and export authentication logs as part of your audit evidence.
| Layer | Question It Answers | Typical Owner |
|---|---|---|
| Agent identity and tokens | Which agent is this, and what may it call? | Identity provider or agent platform |
| Runtime controls | What is this agent allowed to do right now? | Agent gateway or runtime tools |
| Endpoint security | Is this machine healthy? | Endpoint protection |
| Network access | Which machine is this, which network may it join, and when did it connect? | RADIUS and PKI, such as IronWiFi Cloud RADIUS and Cloud PKI |
Getting Started
You do not need a new protocol to start. The 802.1X infrastructure most organizations already run is enough.
- List the machines. Write down the servers, runners, AI PCs, kiosks and headless devices your agents run on, and who owns each one.
- Issue device certificates. Enroll each machine for a certificate over SCEP, through your MDM where you have one.
- Point your network at RADIUS. Configure your 802.1X access points and switches for EAP-TLS and place agent hosts on their own segment.
- Review and revoke. Check authentication logs regularly and revoke certificates when machines change hands.
Put Agent Hosts on Certificate-Based Network Access
IronWiFi provides Cloud RADIUS and Cloud PKI on one platform, with directory sync from Entra ID, Okta and Google Workspace, and works with the 802.1X access points you already run.
Start Free Trial Network Access for Agent Hosts Have Questions?Active Directory, Microsoft Entra ID, Okta, Google Workspace and other product names mentioned here are trademarks of their respective owners. They are named for identification only and do not imply affiliation, endorsement or a certified integration.
Daniel Konecny
Blog Writer, IronWiFi
Daniel writes about enterprise WiFi authentication and identity security at IronWiFi. With deep expertise in RADIUS, 802.1X, and cloud infrastructure, he covers practical network security for IT teams managing thousands of devices.
About the author