Security teams should govern them through device identity, explicit ownership, and infrastructure-enforced communication limits. If the device cannot support an agent, policy has to move to the network edge, where allowed flows can be constrained to a small set of business-required destinations. That approach reduces blast radius without depending on unsupported tooling.
How to govern devices that cannot run endpoint agents
When an endpoint agent is impossible, governance shifts from host telemetry to control of the device as an identity-bearing asset. The practical question is not whether you can inspect the box locally, but whether you can still prove who owns it, what it is allowed to reach, and how its traffic is constrained at the network boundary.
That usually means treating the device as a known, named entity with explicit policy, then restricting its communications to approved destinations only. The fewer allowed flows, the smaller the blast radius when the device is compromised, misconfigured, or repurposed.
Why device identity and ownership matter more when the endpoint is blind
If you cannot install an agent, you lose the simplest place to enforce posture checks, local containment, and host-level detection. Zero Trust for AI Agents is useful here because the core idea transfers cleanly: verify the principal, assume breach, and remove standing trust from the connection path rather than from the host alone.
Explicit ownership is the other half of the control. A device that cannot be managed by software still needs a human or service owner, a purpose, an approved environment, and a review path for exceptions. Without that, unmanaged devices tend to become invisible bridges between trusted and untrusted zones.
Network-enforced limits are the compensating control that makes this work. Rather than trying to secure everything on the device, security teams should define a narrow allowlist of required destinations, protocols, and ports, then block everything else by default. That is especially important for devices that sit on sensitive segments, handle regulated data, or initiate outbound connections on behalf of business processes.
How to design the control plane around constrained communication
The strongest pattern is to combine identity, segmentation, and egress control. Agentic AI Security Policy Template and AI Agent Authorisation Guide both reinforce a useful governance principle: access should be explicit, scoped, and reviewable. For devices without agents, that principle has to be implemented at the network and policy layers instead of on the endpoint.
Good governance also distinguishes between business-required communication and convenience traffic. A device may need DNS, time sync, a management plane, and one or two application endpoints, but that does not justify broad internal reach. If the traffic pattern is not understood and documented, it should not be treated as approved simply because the device is operational.
For this reason, segmentation policy should be written around business function, not device class alone. Two devices of the same model may need very different access depending on where they sit, what data they touch, and whether they initiate or only receive connections. Identity-aware policy helps prevent the common failure mode where a device is trusted because it is familiar, not because it is authorized.
What teams should operationalize instead of agent telemetry
Without an endpoint agent, teams need compensating evidence from infrastructure controls. That means inventory, ownership records, configuration baselines, network flow logs, and exception tracking become the minimum operational proof that governance exists. Shadow AI and AI Agent Discovery Guide is a good example of the broader discovery mindset: if something is using network access but is not clearly governed, it is already a visibility problem.
Practically, the highest-value question is whether the device can be forced into a small and observable communication pattern. If yes, that pattern becomes your control surface. If no, the device should be treated as higher risk until the business can either replace it, isolate it further, or introduce a compensating control at a different layer.
What to verify: confirm the device has a named owner, an approved purpose, a documented allowlist, and logs that show only sanctioned destinations are reachable. If you cannot verify those four items, the device is not governed tightly enough for production use.
Decision rule: if the device can authenticate or reach sensitive services, treat it like an asset that needs explicit network privilege, not like a benign unmanaged endpoint. If it cannot be constrained at the edge, reduce its privileges, isolate it more aggressively, or remove it from the trust path.
Practitioner takeaway: when endpoint agents are unavailable, governance must become architectural. The control objective is not perfect inspection on the device, it is provable ownership plus tightly bounded network reach so compromise has little room to spread.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Resilient Communication Networks | Constrain unmanaged device flows at the trust boundary. |
| Recommendation — Restrict device communications to approved destinations and segments. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Enforce allowlisted flows when endpoint controls are unavailable. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Support device identity when the endpoint cannot host an agent. | |
| Recommendation — Enforce approved information flows at network boundaries. Authenticate devices before granting network access. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Segment and manage network paths for devices lacking endpoint agents. |
| Recommendation — Segment unmanaged devices and limit their permitted network paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Define access rules for devices by explicit policy and ownership. |
| Recommendation — Document and enforce access rules for unmanaged devices. | ||