This is just what you would expect would eventually happen with AMT. Frankly it should be possible to physically disconnect a jumper on the motherboard that completely PHYSICALLY disables things like AMT.
There is an undocumented pin which, when properly pulled {up|down} on startup, a.k.a. strapped, causes the ME to bypass its internal boot ROM and read from an external bus.
It is used internally to develop the ME and its firmware. It may not continue working after the OEM blows the last e-fuses -- it may be necessary to start from chips in the "partially fused" state that Intel ships out to OEMs.
A sufficiently motivated attacker, knowing it exists, could find it and exploit it. A sufficiently motivated defense, knowing it exists, could find it and use it to (re)gain control over their ME firmware.
The attackers have an advantage right now: currently deployed ME firmware is vulnerable. I'd like the defense to have all relevant information at their disposal.
> An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs
This appears to imply an "exploit $site-backend -> provision AMT -> be vulnerable to network/local attack (for provisioned AMT) -> get AMT system privileges" route.