If you use a property to assign a list to a property member then it looks like a simple shallow assignment - it doesn't have to be a shallow copy, because properties can do anything, but if it's not then things start to seem complex.

Alternatively, if you want different semantics, you can use a method whose name indicates the intention in some way. Internally the class might wish to cache and modify the list, so the function makes a deep copy in order to avoid unexpected side-effects.

At the end of the day you have to decide on the semantics of your classes and their methods, using properties goes someway towards stating your intention in code. If the class maintains and mutates a shallow copy of the list then users need to be made aware of this: properties can hint at it, appropriately descriptive class/method names make it clearer and documentation defines it no uncertain terms.

Mutating a shallow copy of a user-provided instance when the semantics don't call for it is a sign that you're leaking implementation details. Of course, you might have to trade that off against the efficiency of making deep copies everywhere. In those cases I tend to find that it's usually possible to modify the semantics of a class to make shallow copies the natural choice; the use of immutable data structures can help in this regard too.