Network access control answered a question that mattered in the era of laptops and printers: is this device allowed on this network, and if so, where? Admit it, assign it a segment, move on. The decision was made once, at connection time, about a device that would then do roughly what devices do.
AI agents break every assumption in that sentence.
Why agents need a different kind of NAC
An agent is admitted to the network like a device, but it does not behave like one. It holds credentials. It calls tools that reach into systems a device would never touch. It moves between resources by design — reading from one, writing to another, sending to a third — which, from a network perspective, looks exactly like lateral movement. And its behaviour is not fixed at connection time: it is determined by its instructions and by the content it reads, both of which can change minute to minute.
A NAC decision made once, at admission, cannot govern an actor whose intent changes continuously. The decision has to be made per action.
The remote workforce is an agent vector
There is a second reason the device-centric model is breaking. In a remote-only organisation, nobody has physically seen the worker on the other end of the VPN. The identity that authenticated this morning may be the employee, the employee plus a fleet of agents operating with their credentials, an agent operating alone, or a deepfake who passed the interview. From the network's point of view they all look like an authorised device on an authorised segment.
Network access control for AI has to assume that any authenticated session may contain an agent, and govern what that session can reach per action rather than per login. Establishing whether the human is real and unassisted is ScreenComply's job; governing what acts on the network under that identity is Monolith's.
Monolith as the access-control layer for agents
Identity-bound, not device-bound. Each agent is admitted as a named identity with a responsible owner and an explicitly stated authority, not as an anonymous process on an allowed host.
Per-action authorisation. Every tool call that reaches the network — a query, a write, a connection, a send — is checked against identity, scope, resource and current policy before it executes. The check happens at the execution boundary, outside the model, where instructions in the agent's context cannot alter it.
Segmentation that follows the task. Agents are confined to the network resources their authorised task requires. A support agent reading tickets cannot reach the finance segment because nothing in its scope includes it, and no prompt can add it.
Egress control. Destination allow-lists, export limits and content checks apply to every outbound path the agent could use — tools, messages, uploads, raw network. An agent cannot turn a newly connected tool into an unauthorised exit for data.
Delegation caps. Child agents and connected tools inherit no more network reach than the authorising parent task permits, so a chain of agents cannot accumulate access none of them was granted.
Fail closed. If the policy service is unreachable, privileged network actions stop. An agent does not get to proceed unchecked because the thing checking it is down.
No connection without attestation. A session is not admitted on credentials alone. The endpoint must qualify on a trusted compute layer first: measured boot, a verified host image, an attested runtime. A credential presented from an unqualified or unattested machine gets no connection at all, whether the credential belongs to a person or an agent.
Administrative control is part of the perimeter. Domain names, registrars, DNS and certificate authorities are where an attacker takes an organisation over without touching a single host. Monolith treats these administrative settings as assets to inventory, monitor and defend: registrar lock, DNS change detection, certificate issuance monitoring and MFA on every administrative console are controls it validates, not assumptions it makes.
Detecting the agent that reaches too far
Enforcement prevents; detection catches what enforcement did not anticipate. Monolith baselines each agent's network behaviour — which segments, which services, what volume, which destinations — and re-baselines continuously, because in an environment where agents, tools and data sources are onboarded constantly, what was normal last week is not normal this week. Divergence from purpose, not just divergence from history, is the finding. An agent that begins reaching resources outside its authorised pattern is contained the way a compromised host would be: isolated, credentials revoked, egress blocked, with the full chain of evidence recorded.
Why this cannot be a prompt
The tempting shortcut is to tell the agent which networks it may and may not touch. That is a content filter, and it fails the moment the agent reads something that tells it otherwise. Network access control for AI has to be enforced by something the agent cannot reason its way past — a policy boundary outside the model, backed by network namespaces and allow-lists, and recorded in a store the agent cannot edit. That is the difference between a guideline and a control.
Frequently asked questions
How is NAC for AI different from zero-trust networking?
Zero trust supplies the principle — never trust, always verify, per request. NAC for AI applies it to a class of actor that zero-trust tooling was not designed around: one that holds delegated authority, calls tools, spawns sub-agents and can be influenced by content. Monolith adds agent identity, per-action authorisation and delegation caps on top of a zero-trust foundation.
Can an agent be restricted to specific systems?
Yes. Authority is stated per agent as explicit tools, resources, actions and duration. Network reach follows from that: an agent can only connect to what its authorised task requires, and the restriction is enforced at the execution boundary rather than in the prompt.
What stops an agent from exfiltrating data through a tool?
Egress control applies to every outbound path — tool calls, messages, uploads and raw network — with destination allow-lists, export limits and content checks. A new connector does not create a new exit; it inherits the same egress policy.
What happens if the policy enforcement service fails?
Privileged network actions fail closed: they stop rather than proceeding unchecked. People regain control through an independent administrative path, and the outage is recorded.
Does this work for third-party agents, not just ours?
Yes. External agents — a customer's, a vendor's, a partner's — are admitted as identities with stated authority, or treated as untrusted and limited by default. The same per-action authorisation and egress control apply regardless of who operates the agent.