Interference can be destructive or non-destructive. When a principal invokes an object (thereby requesting a service) and the implementation carries out the principal's intent, the interference was non-destructive in the sense that the interference was desired.

In invoking the object, the principal may make itself vulnerable to destructive interference. When a user runs Solitaire on Windows, the Solitaire program is instantiated and given all of the user's authority. The program may delete all of the users files after publishing credit card and other sensitive information on the Internet. This type of interference is undesirable, however, generally practically unavoidable due to the way programs work on Windows (and Unix, for that matter).

The problem is that the callee has induced negative consequence for caller due to actions of the former. To not have to depend on another program (and thereby not have to add it to its tcb), it is necessary that the caller only make itself vulnerable to destructive inference in ways that can be detected and from which it can recover.

Mark Miller examines the idea of destructive interference in his PhD thesis Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.