There is an issue with validation token transactions to prevent token injection or leakage.
The issue is related to 'multi-eval' token transactions, that is, when in the same transaction there are both token and non-token vouts. An example of such transaction is on the picture below.

To prevent token injection or leakage we need to validate token transactions by comparing total token amounts of inputs to amount of outputs (more information is here: 'Fake tokens' problem description).

The issue with such validation in those multi-eval transactions is that we cannot just look into vouts and tell if this vout is token or non-token, because vouts' scriptPubKey value is hashed. So to select and validate token vouts we need to recreate test vouts (with the pubkeys and eval code which we put in the opret) and if that test vout is equal to a vout in the validated tx, we pick that vout as token's. If we do just that way there is a possibility of token injection to any token cc addresses for which we have not put pubkeys into the opret. This is again shown in the diagram below:

As we cannot look into vouts (as they are hashed) we cannot prevent creating such 'fake' vouts. Therefore, we should prevent using these 'fake' vouts as UTXO when one adds token inputs for vins of a spending transaction. For this, we should again check token vouts with the use of those pubkeys in the opret.

So one more time, to spend any token uxto you SHOULD NOT simply add them as tx vins. You SHOULD validate them with the use of pubkeys stored in the transaction's opret (the transaction to which those uxto belong). This is exactly what the function AddTokenCCInputs() does! And if you are implementing your own add token inputs function you may use IsTokenvout() function to check whether token inputs you are picking are correct.