Network Access Identity for the Machines Your AI Agents Run On
Give every agent host, IoT device and headless machine its own certificate, its own network segment and an authentication record you can hand an auditor - using the RADIUS and 802.1X your access points already support.
AI agent network identity, as IronWiFi delivers it today, means the machines your agents run on prove who they are before they join the network. Cloud PKI issues each device its own certificate over SCEP, Cloud RADIUS checks that certificate with 802.1X and EAP-TLS, RADIUS policy places the device on the VLAN or role its group allows, and authentication logs record which device connected, when and where. IronWiFi identifies the device or host, not each agent process running on it. Per-agent identity, tokens and permissions belong in your identity provider.
Agents Run on Machines. Machines Join Your Network.
Teams are putting AI agents into production faster than they can identify, limit or audit them. Whatever identity stack you use for the agents, the servers, PCs and devices they run on still connect over Wi-Fi and wired ports.
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.
Flat Networks
When an unknown or misconfigured machine lands on the same network as production systems and staff, nothing at the network layer limits what it can reach.
No Record of What Connected
Without per-device authentication, it is hard to show an auditor which machine joined which network, and when.
Directory Drift
When network access is managed apart from your directory, former users and removed groups can keep their Wi-Fi access long after they should have lost it.
Identify, Limit and Record Machines at Network Join
Built from IronWiFi capabilities you can use now - no new protocols
A Certificate per Device
Cloud PKI issues each agent host or non-human device its own X.509 certificate over SCEP, through your MDM (such as Intune or Jamf) where you have one.
802.1X and EAP-TLS Admission
Cloud RADIUS checks the device certificate before the machine gets on Wi-Fi or a wired port, so an unknown machine does not land on your network. Uses the same 802.1X standard that secures your staff devices.
Role-Based Network Placement
RADIUS policy returns VLAN or role attributes based on the device's group, so agent hosts land on their own segment instead of your production or staff network. See policy options.
Directory in Sync
Sync users and groups from Microsoft Entra ID or Okta over SCIM 2.0, or from Google Workspace with the directory connector, so network access follows the directory you already run.
Revocation
Revoke a device's certificate in Cloud PKI when a machine is retired, reassigned or suspected of compromise.
Authentication Logs
RADIUS authentication and accounting records show which device connected, when, where and to which network - network evidence you can review and export for audits.
The Network Layer of Your Non-Human Identity Stack
IronWiFi does not replace your identity provider's agent identity features. It makes sure the machines those agents run on prove who they are before they join the network.
Agent Identity and Tokens
Which agent is this, and what may it call? Handled by your identity provider or agent platform.
Runtime Controls
What is this agent allowed to do right now? Handled by agent gateways and runtime tools.
Endpoint Security
Is this machine healthy? Handled by your endpoint protection tools.
Network Access - IronWiFi
Which machine is this, which network may it join, and when did it connect? Cloud RADIUS, Cloud PKI, policy and logs.
How It Works in 4 Steps
Using the 802.1X infrastructure you already have
Connect Your Directory
Sync users and groups from Entra ID or Okta over SCIM 2.0, or from Google Workspace with the directory connector, and group the machines your agents run on.
Issue Device Certificates
Issue a certificate to each agent host and non-human device from Cloud PKI over SCEP, through your MDM where you have one.
Point Your Network at Cloud RADIUS
Configure your 802.1X access points and switches to authenticate against IronWiFi Cloud RADIUS with EAP-TLS.
Set Policy and Review Logs
Assign a VLAN or role per device group and review authentication logs. To retire an agent host, revoke the host's certificate in Cloud PKI, then check the authentication logs to confirm it no longer signs in. Revoking does not disconnect a session that is already connected.
Built on the Platform You Already Trust
Network access identity for agent hosts uses existing IronWiFi capabilities - no new infrastructure required
IronWiFi Platform
Which Machines Need Network Identity?
Any non-human device that joins your network should prove who it is
Dedicated Agent Hosts
On-premises servers, build runners and lab machines that run agents or automation unattended. Give them their own certificates and a segment away from production.
AI PCs and Shared Kiosks
Shared machines that run local AI tools. Use device certificates instead of a shared Wi-Fi password, and place them on the network their role allows.
Robots, IoT Controllers and Headless Devices
Devices with no one at the keyboard. Certificate-based IoT authentication and role-based segments keep them where they belong.
Retiring Shared Wi-Fi Passwords
Move non-human devices off shared passwords so each machine can be identified, limited and revoked on its own.
What IronWiFi Does Not Do
IronWiFi works at 802.1X, for the devices and hosts that join your network - not for the agent processes running on them. Pair it with your identity provider, runtime and endpoint tools.
- It does not authenticate individual agent processes. If several agents share one machine, they share that machine's network identity.
- It does not issue, store or rotate API keys, OAuth tokens or other agent secrets.
- It does not authorize or record what an agent does inside an application.
- It does not sync AI agent objects from your identity provider. Directory sync covers users and groups.
Extends Your Existing IronWiFi Platform
Network access identity for agent hosts uses the same Cloud RADIUS and Cloud PKI you already use for staff and devices. No new protocols - just certificates, policy and logs for another class of device.
Works With Your Existing Network Hardware
Any 802.1X-capable infrastructure - no new hardware. See the full list.
Microsoft Entra ID, Okta, Google Workspace, Intune, Jamf and the network hardware brands named on this page are trademarks of their respective owners. They are named to describe compatibility only and do not imply affiliation, endorsement or a certified integration.
Enterprise Security & Compliance
Built for organizations that take security seriously
Frequently Asked Questions
Common questions about network access identity for AI agent hosts
What is AI agent network identity?
As IronWiFi uses the term, it is network access identity for the machines AI agents run on. Each agent host or non-human device gets its own certificate, authenticates with 802.1X and EAP-TLS against RADIUS, lands on the network segment its role allows, and leaves an authentication record.
Does IronWiFi give each AI agent its own identity?
No. 802.1X and EAP-TLS authenticate a device, host or user. If several agents run on one machine, they share that machine's network identity. Per-agent identity, tokens and permissions belong in your identity provider or agent platform.
How does IronWiFi authenticate agent hosts and other non-human devices?
With certificate-based EAP-TLS. Cloud PKI issues each device an X.509 certificate over SCEP, typically through an MDM such as Intune or Jamf, and Cloud RADIUS validates it before the device joins the network.
How do I limit which network a machine can reach?
RADIUS policy assigns a VLAN or role based on the device's group, so agent hosts can be placed on their own segment, separate from production systems and staff devices.
Can I see which machines connected, and when?
Yes. RADIUS authentication and accounting logs show which device connected, when, where and to which network. They are network records, not a record of what an agent did inside an application.
Does it work with my existing network hardware?
Yes, with 802.1X-capable access points and switches, including Cisco Meraki, Aruba, Ruckus, Ubiquiti and Fortinet. See the compatible hardware list.
How does this relate to my identity provider's AI agent features?
They are separate, complementary layers. Your identity provider handles agent identities and tokens. IronWiFi handles network access for the machines those agents run on, and syncs users and groups from Entra ID or Okta over SCIM 2.0, or from Google Workspace with the directory connector. It does not sync AI agent objects.
Get Started with Network Access Identity
- Test certificate-based access on your own access points
- See IronWiFi working with your hardware
- Answers by email - no pitch deck
Free trial, set up in under 5 minutes