I'm a little late on this, and I agree that you should point the blamethrower at the application's developers and I'd put my concerns in writing and get someone with political power to understand the risks, but I hope to give you some more options.
If I were really stuck, I would look into creating a trigger for the LOGON event. In the trigger, I would find a way to discriminate between what I'll call a "legitimate" logon and an "illegitimate" logon and stop the illegitimate ones from completing. Legitimate logons would be users connecting to the proper database with the proper application, plus any administrative logins, job logins, etc. that you might need. I'd be very careful when writing this, since it seems like a good way to lock yourself out of the server. BOL says that LOGON TRIGGERS are available in SQL 2008, I'm pretty sure that they are available in Express.
The problem with this tactic is that you might find yourself playing "whack-a-mole", where you exclude Excel and Access, then someone figures out how to write a quick vb.net application that lets them get in, then you block that, then someone modifies the connection string to change the application name, etc. The more knowledgeable your users are, the more difficult this would be to stop them. If you've got developers, they might see it as a challenge. I'd say that anyone who is aggressively trying to find a way around security controls, even if those controls aren't perfect) is a problem. (If I lock the screen door on my home, it's pretty obvious that I don't want anyone to come in. If someone uses a pocket knife to slash the screen and step in, they have certainly done something wrong.)
Another thing to do is to simply run a query on the DMVs to find users who are not playing by the rules. You can get user, host and application name information from the system DMVs. If you run the query periodically (once a minute or so) and save the results in a table, you can have a look every day (or week) and then go rap the bad actors on the knuckles. Or have HR do it.
Another thing to try is, if you have anything that looks for and reports on long-running queries, you can look for "weird" queries. I actually caught someone doing something once, while reviewing logs for problem queries. Often, inexperienced users that are poking around will run inefficient queries that either read a lot of data or cause long-duration blocks. Sometimes, if the application has a certain, definite "style" to the way it write queries, you can pick out queries that are written by someone (or something) else. IOW, to use a very contrived example, there is a big difference between:
select * from salary where employee = "me"
and
select * from salary order by salary_amount
To sum up: Fixing the application would be best. Preventing logins might be OK. Trying to find violators after-the-fact might be all you can do.
