Any code in a trusted class library will be granted permissions not normally available to most application code, and hence particular care must be taken to avoid creating a weakness in security. Note that there may be classes that do not especially require special permissions that may be granted them simply by virtue of being in an assembly with code that does, in which case the same potential for trouble exists.
Any such trusted code needs to be designed so it can potentially be called by any kind of semi-trusted code on the system without exposing security holes. Protection of resources is normally safe by virtue of the stack walk - is the caller has insufficient permissions, an attempted access will be blocked - however, any time trusted code asserts permission it is taking responsibility and requires checking. Normally, the assert should only follow the necessary permission check of the caller as described above. The "window" of asserted high permission should be kept as small as possible to reduce risk of unintended exposure (but see note on performance below).
Fully trusted code is implicitly granted all other permissions, plus it is allowed to violate rules of type safety and object usage. Independent of protection of resources, any aspect of the programmatic interface that might break type safety or afford access of data not normally available to the caller could lead to a security problem.