Are you utilizing the standard AE Kiosk or the legacy Lockdown? If you utilize the true AE kiosk mode I believe the recent button may in fact get hidden or disabled. 

If you don't want to use the AE Kiosk then you could plausibly remap the Recent button to something else using Zebra MX.

http://techdocs.zebra.com/mx/keymappingmgr/

I am using the SOTI Features Kiosk Mode. I assume that is what you are calling the legacy Lockdown. Not sure what AE Kiosk is then. 

As far as the button being hidden or disabled, the button is printed on the glass. It appears that SOTI has remapped the button because when you hit it, the recent apps popup for a second and then MobiControl redisplays the Kiosk.

If you have this option selected in the Advanced settings of the lockdown then it is using the original SOTI (and/or legacy) lockdown launcher which tries to remap the Home and Recents buttons. If you leave that unchecked an AE managed device will use the native Kiosk mode which is a feature of AE (ie. not SOTI specific). The native Kiosk mode will probably offer the level of restriction that you're looking for but it has other side effects, like disabling the Home button as well. This is why I suggested the alternative of continuing to use the SOTI lockdown (Activity Suppression mode), an assumption that I have made based on your description, in conjunction with an MX configuration to remap the Recents button to something else.

Yes. We are using Activity Suppression as we want to be able to show the device Status Bar.

Whether or not a kiosk lockdown can be made secure enough depends not just on the few options of the kiosk-mode profile configuration, but also on many other factors such as the UI design of a particular device, the MDM API supported by the device agent, how some functions are implemented in the device firmware, the UI of the apps defined in the kiosk items, the background services on the device, etc.   In addition, status bar, quick-launch side-bars, hardware/software keys, multi-screen, etc. can also create loopholes, and different measures are usually needed to cover them, though this is NOT always possible. Thus, some device models are inherently not suitable for use to implement a secure kiosk.   Even worse, a secure implementation may become insecure after a firmware upgrade if the upgrade create new loophole(s). Stringent tests are thus needed before each firmware upgrade.  

These are reasons why many of my customers requiring a really secure kiosk mode implementation needs consultation with my company on EACH device model to see if all the potential loopholes can be identified and removed. 

In your case that your supervisor found some end-user can make phone calls or send text messages on some device, the simplest solution is to use applicable feature-control and/or application-run-control profile payload(s) to disallow such activities on the device.