If I have a payload of e.g. 8 bits and I want to encrypt it using AES 128, I will need to add some random padding to make the plaintext 128 bits long. Does this padding affect the security of AES?
Since AES is a block cipher with 128-bit blocks, it can, by definition, process only a 128-bit entry. To turn it into a system that can encrypt and decrypt messages of arbitrary length, then you need to use a mode of operation. Each mode has its own requirements. Most will require an IV which MUST NOT be reused (if you encrypted several messages with the same key, each message needs its own specific IV), and some modes have extra requirements (e.g. in CBC, it is crucial that the IV are selected randomly, uniformly, and in a way that cannot predicted by whoever chooses the data to encrypt).
Some modes also require "padding" in case the input message length is not appropriate in some way. Some modes can process input data of arbitrary length (e.g. CTR), while others need the data to have a length that is a multiple of the block length (e.g. CBC).
Most attack models that warrant encryption may easily be turned into active attack models, in which the attacker not only wants to inspect the data, but he also may modify the data. Thus, whenever you use encryption, you normally need integrity as well. Combining encryption and a MAC is a non-trivial task, so using a mode which combines both features is highly recommended. The most standard mode that combines encryption and MAC safely is, as of early 2016, GCM.
If you do everything correctly, then there is no additional issue with the input data being short. Short data is common in, e.g., SSH connections.
Note, though, that while encryption protects the data contents, it tends to leak the data length. Depending on the kind of data that you are sending, its length might reveal a lot of information to outsiders.
Don't use random padding. Random padding cannot be checked at the decryption side, because it can be anything. Random padding gives extra power to active attackers (in SSL/TLS, see the POODLE attack, which leverages random padding in SSL 3.0). Instead, if padding is necessary, use a deterministic padding that the receiver can check. A mode that does not require padding is preferable, because it is easier to process it correctly on the decrypting side (i.e. without leaking information when an invalid message is sent).
Summary: use GCM.
However, if you need to pad your message, chances are you're doing something wrong.
First you can use CTR mode to get rid off the neccessarity to pad your messages and secondly you should use authenticated encryption (such as AES-GCM) anyways.