Portnox Cloud adds generative AI detection to device risk scoring
The announcement boils down to two changes. Rather than requiring a separate security process for generative AI, Portnox extends its existing posture detection and access controls to this new class of applications. Administrators decide which generative AI apps are allowed and which are banned. Portnox then scores each device's risk based on what's installed on it.
Portnox names nine products in the detection list: ChatGPT, Microsoft Copilot, Claude, Google Gemini, Perplexity, DeepSeek, Cursor, Codex and Ollama. The company says it also detects "dozens" of other AI assistants, coding agents, local models and image-generation tools, and that the list grows as new tools appear. It hasn't published the full list or explained how detection works. That leaves several questions open, including how often devices are scanned, what signatures are used and how false positives are handled.
The response depends on how serious the violation is. According to the release, depending on the severity of the risk, that might mean blocking the device from the network, restricting its access to specific resources, or removing the application entirely, on both macOS and Windows. The policy covers apps that are explicitly banned and apps that simply haven't been approved. Portnox says it can respond immediately, without waiting on a security team to catch it manually.
The Microsoft Copilot entry matters most to Windows administrators. Copilot is built into Windows 11 and tied into Microsoft 365, so many organizations approve it on purpose while banning third-party assistants. The release doesn't say which Copilot client or clients it detects. Before writing any rule that affects Copilot, admins need to confirm that with Portnox.
How AgentP, Intune and Jamf feed the Portnox risk score
Portnox's documentation explains the mechanics more clearly than the release. The feature is part of Portnox Cloud risk assessment. A generative AI policy attribute detects specific assistants on a device and raises the device's risk score when it finds one that isn't approved. A separate remediation policy can kill the processes of unauthorized assistants and automatically uninstall standalone AI agent apps, with no administrator involved.
Portnox's documentation keeps two kinds of response apart. Endpoint remediation acts on the device itself by stopping processes or uninstalling software. Access enforcement happens in Portnox Cloud and its ZTNA (zero-trust network access) service. At the network level, which uses 802.1X port authentication, that can mean blocking a device entirely or moving it to a quarantine VLAN. At the application level, it can mean blocking specific apps. The documentation describes three tiers:
- Full denial blocks the device from the network or from the protected application entirely.
- Limited access confines the device to certain VLANs, such as internet-only or low-risk segments, or to low-risk applications.
- Access with warnings lets the user continue while administrators receive alerts about the device's risk level.
Settings can differ by user group, application and risk level. Portnox says some customers block any device with any risk, while others only send warnings. Once the problem is fixed and the device reconnects, Portnox Cloud checks it against policy again and restores access. For a banned AI tool, removing it should get the user back online without a help-desk ticket.
The data source is the key dependency. Portnox's own endpoint agent, AgentP, handles continuous posture checks, policy enforcement and telemetry. Organizations that don't want another agent can feed posture data from Microsoft Intune or Jamf instead. Portnox says this gives less detail than AgentP. It also says it doesn't do risk assessment with any other UEM or MDM product, although other SCEP-capable systems can still handle certificate enrollment. A shop running a different management platform without AgentP has no supported way to use this feature.
Portnox frames shadow AI as an attribution problem
Portnox argues that shadow AI is partly an identity problem as well as a data-leak problem. The documentation says an assistant installed under a user's account runs with that account's rights, including its network access, application access and stored credentials. If an agent opens sensitive files or exfiltrates data, device and network logs show only the user, with nothing to show that an assistant acted for them.
The release makes the same point in less technical language. It describes generative AI apps that increasingly act as autonomous agents, reaching local files, remote resources, and enterprise data with the same permissions as the logged-in user. Portnox CEO Denny LeCompte put the company's view bluntly: "Policy doesn't mean anything if you can't enforce it."
This is the vendor's rationale, and it explains the design. If you can't tell an agent's actions apart from the user's in the logs, one option is to keep unapproved agents off managed endpoints altogether. Portnox's controls work at that level: which software is present and what access the device gets. The documentation doesn't claim the feature reads prompts, reviews model output or tells when an agent is behaving badly.
The August "kill switch" and Microsoft Defender integration complete the design
The September feature builds on an earlier release. On August 18, 2026, Portnox announced what it called a network "kill switch" for AI agents. In that release, a new integration with Microsoft Defender joins existing integrations with CrowdStrike and SentinelOne, completing a three-partner enforcement layer. When any of those platforms reports high risk, suspicious activity or a posture change, Portnox can block, quarantine or revoke access, including an AI agent's access, according to the organization's policy.
SiliconANGLE covered the August launch separately and summed up the pitch: identity and privileged access management tools decide what an agent ought to be allowed to reach. Cutting the connection is a separate job, and the company's argument is that it can be done before an identity provider has gotten around to revoking anything. The process has three steps. One of the three endpoint platforms detects the risk. The Portnox policy engine weighs that signal against the customer's access rules in real time. Enforcement follows automatically.
Portnox presents the two features as covering different stages. The September feature finds and controls unapproved AI software on endpoints. The August feature cuts access when an AI agent that's already running looks risky. For a Microsoft shop, the combination means Defender for Endpoint signals and Intune posture data can both feed Portnox's access decisions: one reports that something is misbehaving, the other reports that something banned is installed.
Where the shadow AI controls stop: unmanaged devices, browsers and data
The feature only covers devices Portnox can see. Its documentation says risk assessment isn't possible on unmanaged devices unless they're enrolled in the organization's Intune or Jamf, or have AgentP installed and enrolled. Guests and contractors can join through a guest network, captive portal or contractor account. Those connections aren't risk-assessed, so Portnox recommends giving them minimal access. Employees on BYOD devices can install AgentP and sign in with their corporate account, after which their devices are monitored like company hardware.
The published material is about installed applications and agents. It doesn't say the feature can detect AI used in a browser, agent activity in the cloud, or corporate data pasted into an approved AI service. An employee using a banned chatbot in Edge or Chrome on a managed PC has no installed app for the detection to find. Nothing Portnox has published claims otherwise.
The same limit applies to data protection. Checking which apps are installed and restricting access is one part of AI governance. Portnox doesn't claim to provide data-loss prevention, output review, or any control over an AI provider's data retention or training. Organizations that need those controls still need other tools. Portnox hasn't published licensing, pricing, a rollout schedule or a matrix of supported versions for the feature.
What this means for Windows and Intune shops
Organizations already using Portnox with AgentP, or with Intune or Jamf posture integration, can evaluate this feature now. Everyone else should treat it as one input to a wider AI-governance decision. Before switching on automatic enforcement, write down which tools are banned and which are just unapproved. Then decide which of those should trigger a warning, a quarantine VLAN, a block or an uninstall. Automatic uninstall and process termination are the riskiest options. Pilot them with a small group before rolling them out, especially for developer tools like Cursor and Codex, which may already be part of legitimate work.
- Portnox announced detection and automatic enforcement against unapproved generative AI apps on managed Windows and macOS devices on September 23, 2026.
- Risk assessment requires AgentP or Portnox's Intune or Jamf integration. Portnox says the Intune and Jamf route gives less detail, and it doesn't support risk assessment through other UEM or MDM products.
- Enforcement options range from alerts, through limited VLAN or app access, to full network denial. Endpoint remediation can kill processes and uninstall standalone AI agent apps.
- Microsoft Copilot is on the detection list, so confirm with Portnox exactly which Copilot client it detects before writing rules that could affect a tool your organization has approved.
- Unmanaged guest and contractor devices, and browser-based AI use, fall outside what Portnox has described, so keep network segmentation and data-protection controls in place.
- The August 2026 Defender, CrowdStrike and SentinelOne integration covers the other half of the problem: cutting access for agents already running that turn risky.
Portnox's approach turns an installed AI app into a posture violation, the same way a disabled antivirus or a missing patch already is. That fits naturally into organizations that already make access decisions based on device risk. For those customers, the practical work is writing an approved-AI list precise enough to enforce automatically, starting with a decision on which Copilot and coding-agent clients stay allowed. Organizations outside that group will still need browser and data-level controls, because Portnox's published material doesn't cover either.