Simple: There are no permissions. Within a method, an object may modify any variables on that object. The only way to modify another object's variables is to ask it to change them, via a message. The only way to read another object's variables is to ask it to return them, via a message. This has some peculiar consequences. For instance: an object may spoof anything it likes. It may spoof its location, so that it appears to be located in a place it is not. It may spoof its name, so it looks like something (or someone) it's not. It may refuse to change a variable. etc, etc, ad nauseum. How do we deal with these unruly objects you ask? We don't. We assume that these spoofings are going to occur, and plan around them. For instance, an object may _say_ it's in a particular location, but it will only get the 'say' messages from that room if it's listed in the room's "contents" field. An object may list another object in its contents list, but unless that object has its location field set to that object, it may be equally unsocial/unresponsive. For these reasons, the admin may choose to restrict programmer access, and/or restrict which other servers may connect (since remote objects may be operating under a different set of rules and be unruly). The admin may choose to disable programming entirely, and simply provide a rich set of classes of objects as a palette from which to build.