From what I understand of what you said, basically because Alice (sender) appended Bob's (receiver) address (and therefore public key) to the outputs. If he can then, sign the outputs (now considered inputs for his next transaction) with his public key, then he will be able to spend it? I was under the assumption that you can only sign with your private key?
Consider an output as a 'puzzle to be solved'.
Alice creates her transaction and ensures that the output is a puzzle only solvable by Bob.
Here is a pseudo example of a sufficient puzzle;
A signature must be provided. This signature must be verifiable by public key Y.
The only way to (feasibly) produce said signature, would be to be in possession of the private key X which corresponds to public key Y.
Alice knows Bob's public key. Or else, she knows a hash of his public key (a 1... address).
But she doesn't know his private key.
The puzzle is implemented in practice using Script opcodes.
Standard Transaction to Bitcoin address (pay-to-pubkey-hash)
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
Note that these are spread across two transactions.
scriptPubKey is part of an output, in tx 1.
scriptSig is part of an input, in tx 2. The input references the corresponding output, in tx 1.
That is to say; Alice produces scriptPubKey. Bob produces scriptSig.
Alice knows <pubKeyHash>. It's simply a decoded Bitcoin address. So she can make scriptPubKey.
What she and no-one else but Bob can do, is provide the scriptSig. Bob is the only one that can produce a valid <sig>.
Bob is the only one who can spend the output. This is equivalent to saying that he's the only one with the ability to produce the corresponding valid input.