Its normal for higher level business objects to have a wider dependency reach, these are the elements that facilitate the communication between lower level objects. The last thing you want to do is pass around a container as a dependency because you don't want your core business logic to have a dependency on a specific container (the container is a framework thing). Injecting a container would be a sign of bad design.
I didn't intend to imply you should inject an IoC container. Offhand I cannot think of an example of when that would be appropriate.
What I did intend to say is that having a wide dependency reach is a negative outcome, that is usually the result of bad design choices. That high level components have many low level dependencies is precise evidence that the dependency inversion principle has not been followed.
The entire point of the principle is to decouple high level components from low level ones and to flatten that hierarchy so that the components become peers that each own their own abstractions around dependencies.
