In whitebox cryptography the attacker is supposed to have access to every detail of the computation and the goal of this implementation is to protect the key, to -usually- avoid it is used on a classical no-whitebox implementation on a different platform.
The goal is that an attacker having access to the whole computation and intermediate values cannot achieve a bigger knowledge of the encryption key as he would have a black-box access (only input/output for all input of his choice).
The perfect way to create a whitebox implementation would be to tabulate the AES: for a given key, one takes all the possible input blocks, compute the encryption on a trusted machine and put the output on a table. In this scenario an attacker would have access only to the input/output and the computation has been done elsewhere. But, of course, this table would be ${HUGE}$ (e.g.: for the AES: $2^{128} \times 128$ bits, I don't even know how to write this quantity, but could be approximated by $2^{92}$ Terabytes). So, a typical solution is to use several lookup tables (noted as LUT) in a networked way. This allows to build an implementation in a less of a Megabyte (700k), even if this size is quite a lot in respect to a standard, no-whitebox implementation. Resume of white-box applied in AES algorithm (slides 18 - 24).
So you are not going to see the key in a whitebox implementation, the key is cut, smashed, embedded in all the tables used to compute a single encryption.
That also means that the key is not loaded somewhere during the computation but has to be embedded before shipping the implementation, and that when one needs do change/update the key, he has to ship another implementation (or on other set of tables).
