SHORT VERSION:
Intel's Management Engine, or Active Management Technology, depending on where you look is a low-level subsystem that's attached to every Intel chip produced after 2008 (I believe). It runs whenever the chip is powered (even if the computer itself is switched off), and it's purpose is to 'provide trust' that the processor isn't compromised. It's completely invisible to the user, but has complete access to the processor as well as access to power up or down the machine, interfere with the boot process, send/receive TCP network traffic through it's own independent MAC forwarded by the network adapter and run arbitrary code locally. Efforts to dump it's code and understand it's workings, potentially leading to an exploit are underway but due to the way the core firmware is compressed and obfuscated, as well as peripheral functions being stored on ROM chips, makes progress very difficult.
When it's exploited, if it hasn't been already, every machine running a recent Intel chip will be outfitted with a rootkit that can't be disabled (breaking or disabling the ME coprocessor forces the computer to shut down on a timer). Don't think switching to AMD will make much of a difference either... They have a very similar system (TrustZone) that's implemented via an on-chip ARM coprocessor.
TECHNICAL:
The AMT unit itself is a separate on-chip coprocessor that has several supporting components such as ROM and RAM for firmware and temporary data storage as well as a 'DMA engine' that allows it unfettered access to memory in use by the user-installed operating system, meaning it can potentially subvert the program flow of Windows, Lunix or whatever OS you're using without any warning or indication. It also has it's own simple TCP stack which has been demonstrated to be insecure in the past; it has a hardcoded MAC address different to the standard NIC and is essentially able to relay through the NIC to forward requests to the internet or LAN. The ME engine itself is composed of the core firmware which is compressed, encrypted and obfuscated, only decoded on the fly to run commands, and modules and components stored on ROM chips, which cannot be dumped or accessed directly.
The original purpose of the AMT was to provide trust for the CPU itself; you may compile applications from source because you want to be able to see what it does before you 'trust' it enough to compile, but you then also need to be able to trust the compiler that builds it, and dependencies that get linked in and anything that runs below the application, ie. the operating system, drivers used and the like. You can continually move down the chain, checking source or watching applications' behaviour to verify they're working as advertised, but once you get to hardware, specifically the processor in this case, it's a black box - there's no way to directly view the source, so the only way to 'trust' that it's not compromised is through a third-party that can verify such. This begs the question of how you can verify that the third-party is trustworthy - you can't. One of it's popular uses now is to facilitate remote installations and administration functionality on behalf of sysadmins.
OTHER:
It would surprise me if some of the betabet agencies don't already have access to this - it may have even be among the exploits stolen from the NSA's archives, but hasn't been released because whoever released them publicly knew of it's value. Much of the system's code is stored on ROM chips and untouchable; it cannot be reflashed or updated meaning that if an exploit exists in it, there is nothing users can do to protect themselves - they'd literally need to buy a new processor once Intel gets around to patching or rewriting the AMT codebase.
Manufacturers have ostensibly worked with NSA contractors in the past, specifically in the case of harrdrive firmware exploits used to cache and transmit data - without co-operation from the major harddrive manufacturers, such an exploit would take years to develop per manufacturer, and there are around 10 of them.
COUNTERMEASURES:
At the moment, there's very little that can be done to mitigate your risk of being exploited because even if no exploit exists today, it will. Disabling the AMT platform causes the computer to shut down after a countdown, but it's been observed that if chunks of the WMT's firmware are erased or overwritten, it stays in the 'running' state but stops responding
You may be able to sniff TCP data to/from the platform by enhancementing by MAC address, but I'm not sure how possible it is to mask those requests.