Real-world scenarios for table with DENY SELECT and GRANT [INSERT/UPDATE/DELETE] What is real-world scenarios for this type of permissions?

May be it is generally not valid, and made by mistake?

Should this kind of permissions be avoided (or prohibited)?
There is one simple enough scenario where I could see permissions being REVOKEd/DENYed for SELECT and GRANTing INSERT/UPDATE/DELETE makes sense.

Suppose one works for an institution wheire confidentiality is crucial and any large scale publication and/or loss of user data would be disastrous. Say, a bank or a medical insurance company?

You take the agents who answer calls for these institutions.

You allow the customer to key in their details (account number).

Then, the first thing the agent sees are the security questions (mother's maiden name, first pet's name, &amp;c.).

These questions being answered correctly, the system allows the agent to see the record of that person and that person only.

Then, the agent is allowed to UPDATE or DELETE that account (change of address, cancellation of account). An INSERT wouldn't be a problem either (new account - no risk).

This way, an agent can only see one person's account details at a time and cannot SELECT large quantities of data for potential download/malicious release for criminal/blackmail/"hacking" purposes.

My girlfriend's sister is a manager in a telecenter for a large bank and the large-scale release of data is their biggest nightmare. I discussed this with her (me from a database perspective and her from a banking one). She couldn't release details of their system, so it was like 20 questions, but the clear impression I was given is that something like this was in place.