You can look at this website.
There is no way for your AS/400 to know what process on a remote system is contacting any server. The telnet server only knows what comes across the telnet port, and every telnet client will send sockets data according to the telnet RFCs.
However, there are telnet, TN5250 and TN5250E (technically there are also 3270 protocols that can be accepted) standards such that additional data may be sent by more sophisticated clients. Note that the more sophisticated clients can also be configured to send only the data elements of the lower standards. E.g., a client capable of TN5250E might only connect as TN5250.
IOW, if you want to restrict to a specific TN5250E client such as PComm from iSeries Access, the best you are likely to do is to refuse connections for every client request that is configured to (or perhaps capable of) sending only basic telnet or TN5250 connection requests. In that case, simple Windows telnet could be rejected simply because it didn’t send a complex enough set of connection parameters.
Thorough reading of the telnet, TN5250 and TN5250E RFCs will tell you what each may send. This telnet article also references numerous related telnet RFCs.
The really serious trick is in having an isolated test environment. It is risky to have a test exit program that will return an Accept/Reject indication when you are uncertain how to react to all of the various parameter combinations. If the exit program says to Accept, then the session will be allowed regardless of correct password for example. (Or any password at all.) If you feel uncertain that your exit program correctly handles all request options, it is strongly recommended not to keep it active.