there's an extremely common mistake made which needs to be pointed out: the clue is in the phrase "This kind of top-down thinking". the fundamental assumption is that there is a concept of "more privilege is required than before" to achieve privileged tasks. people imagine that security is hierarchical - that the further towards "the top" you get, the more access you are permitted. this is simply NOT TRUE. the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.
so, people invent new security systems, but they invent them without actual proper thought towards design, and they invent them thinking that this "top down" hierarchical approach is the only way. thus, new APIs have to be invented.
there is another way: it's called SE/Linux (and there's a variant called SE/Android). SE/Linux follows the FLASK model, which basically says that based on the current context, the current application, that a new executable is given a COMPLETELY new security context, where the new privileges have to be explicitly given. the most important implication of this model is: it absolutely does not matter how "powerful" you were in the previous context - the one that fires up the new executable; the new one is literally a completely and utterly separate security context.
to give an example: take a 5 Star General, and send him to a security base. when he gets there, standard security procedure: they take away his passport and all his credentials, and they give him a security pass (a new context). that security pass has a pre-prepared set of restricted corridors and rooms that the 5 Star General can go to. he can go to the conference room, and the bathroom. if he tries to leave without returning the security pass, he has no passport, and no papers.
this incredibly powerful security model - FLASK basically fits on top of an OS *without* interfering with it. it's particularly fascinating because it can watch which programs exec() other programs, and it can watch what APIs those programs use.... *without* needing to actually modify those programs.
basically what i'm saying is that the problem that cyanogen is trying to solve already has a way in which it can be solved, if the SE/Android team haven't already solved it. and that's because, under SE/Linux and SE/Android, you can operate both the normal "root access" system *in parallel* with SE/Linux. all you need to do is create a FLASK security context which restricts access to only those applications that *should* be accessing the restricted APIs. you don't need to modify the applications, nor do anything special to the underlying OS.