The argument goes you can never control network access for a desktop with a software agent because agents can be hacked, and there is no way to know for certain whether one has been compromised.

In addition, reliance exclusively on agents to collect NAC data from desktops and laptops eliminates the possibility of finding out anything about devices such as IP phones that don’t support agents. No agent, no information.

But there is another way of looking at these agents. They could be considered management tools, but management tools that also add information about endpoints that is pertinent to NAC even though it might not be absolutely reliable.

So an agent could gather data essential to making a NAC decision such as whether antivirus software is running on a machine and whether critical software is patched and whether its firewall is turned on and configured properly. That data could be weighted, perhaps with skepticism because it is reported from the endpoint itself, but it could still be part of the NAC-decision equation.

The agent could also do other things, such as look for certain applications that might be running on the endpoint in violation of policy. For example, if a college wanted to bar Napster from running on its network, the agent could look for the application running, and if found, report it to the NAC policy decision point. Rules could then be enforced to, say, block the machine’s access to the network until Napster is turned off.

This is an access decision, but not on the order of assessing whether it is likely that the endpoint is infected and is therefore a risk to the network. It’s more about whether the endpoint is behaving in accordance with use policies.

Tim Greene is senior editor at Network World.