It is certainly reasonable for interfaces to specify that implementations don't do "a thing". This pattern can be seen in C, C++, and Fortran a lot. You will often see things called a precondition(before), postcondition(after), and rarely pericondition (what happens while the function/class runs). This has been further expanded upon in languages that actually implement language constructs in the form of contracts. Often you will see pre and post conditions on a C++ template function, which defines what can and can't be used inside of it, what properties the template must have (generics in java), etc, despite there being no way to enforce it (without very hard template meta programming that is).
In your case however, I'm not sure that the entire class need be immutable, or if only your function should be immutable instead of the entire class.
In your situation, instead of providing documentation defined constraints, you might be able to define a class that will contain the data you don't want to be accessed (assuming you even know what that is) that only implements accessors (which could all be final) and have that class implement the interface (or provide abstract method) for "execute". You couldn't guarantee immutability across the whole class, but you could enforce it on a subset of values you know about. You could also use the final keyword in the same abstract class to achieve a similar effect (but it might be harder to accomplish)
In other languages (like C++) even without contracts you can force a function to be "const" which means that it doesn't modify the calling class. Java makes such things particularly difficult to accomplish.