This is normally done through what we call a "natural key view" on which you impose the constraint. If, for example, a natural key for a Receipt is the combination of the attributes ReceiptNumber and PurchaseDate, then a view is created in which their corresponding tables are joined. Then a uniqueness constraint is created on the view ensuring integrity.
Such views also come in handy when you need to determine whether an instance is known or unknown, or in other words if it has been assigned a surrogate key or not already and what that key is. For this reason the surrogate key (RE_ID) is also often included in the view, but not part of the constraint.
Of course, this depends on the database being able to impose constraints on views, which Microsoft SQL Server can do to some extent and under the right conditions. I have a feeling that 6NF is something most database vendors have given very little thought. Natural keys that are 'spread out' over several anchors may not fulfil those conditions. Say, for example, that the natural key is extended to become ReceiptNumber, PurchaseDate, and StoreNumber, where StoreNumber is an attribute of a Store anchor.
I have started to implement a way to define natural keys in the online modeling tool, but it is not completed yet, and I unfortunately currently have little time for development. For now you will have to create these views and constraints through manual labor. I hope this explains how AK-attributes are supposed to be handled.