Latest SMT design requires Complete Visibility by Admin! Yikes!

I just finished reading, yet another Multi-Tenancy Design/Overview that claims to be secure or trusted. While I will agree that this particular design does cover Availability and some GRC  (Governance, Regulatory, and Compliance) it is severely lacking in Integrity and Confidentiality. The design even went as far as saying the cloud/virtual administrator requires “COMPLETE VISIBILITY.” I was really taken aback by those words. Why does an administrator need ‘COMPLETE VISIBILITY?’ Which leads me to the question is Integrity and Confidentiality possible within any cloud or virtual environment? Or is it purely based on TRUST?
If so this is an appalling state of virtual and cloud environment security.
This is now the second ‘Trusted Multi-Tenancy’ solution put forth and the third Secure Multi-Tenancy solution put forth. Yes I do equate Trusted with Secure when it comes to Multi-Tenancy. Why when they mean something different to all people. Security implies Availability, Integrity, and Confidentiality. Trust implies a relationship based on known quantities. These two concepts are very different, so how can I equate them? To me Trust is based on known quantities, and within the realm of security these known quantities are Confidentiality, Integrity, and Availability. Adding in GRC, is a big plus.
Virtual and Cloud environments give us Availability, we all agree to that. But can it give us Integrity and Confidentiality of the Data within the virtual and cloud environments. Security is about protecting the data. GRC is not always about security, but more about auditing that certain controls are in place, etc. So a document that adds GRC into the mix is great, but one that does not cover Integrity and Confidentiality is once more sub par.
So for Multi-Tenancy, why does an administrator need Complete Visibility, with absolutely no exceptions? They do not, this is crucial, no administrator should be able to see, modify, or delete data within the cloud or virtual environment; Nor should an administrator misconfiguration allow a tenant to see, modify, or delete data.  This is crucial to a cloud environment.  So how do we achieve this? Is it achievable?
The issue with Integrity and Confidentiality is that currently it requires either digital signatures or encryption. To do this successfully within the cloud requires processors and code that can do this fast and can scale up as well as out as data moves around within an environment or between environments. Yes we can protect data moving between environments via encrypted tunnels, but can we protect data within an environment?
There are several Integrity and Confidentiality tools available today. The list is far larger but these are interesting ones:

• Ones that encrypt bits of data before they are put into the cloud, but not enough to deter from SaaS functionality (CipherCloud)
• Ones that encrypt and digitally sign full images of data before they are placed in the cloud (many cloud backup options)
• Ones that allow you to digitally sign data before and after placing it within the cloud (Google Docs via CoSign and others).
• Once that allow you to encrypt the data while inside a VM (such as truecrypt and bitlocker) which stores keys in memory
• Ones that allow you to encrypt the data while inside a VM but store the keys in encrypted partitions and scrub memory except when the key is in use (Trend Micro Secure Cloud).
• Once that allow you to use an overlay encryption network (Apani)

So with all these technologies for Integrity and Confidentiality, what is the issue? The major issue is adoption of the tools, and that in in a fully virtualized cloud any administrator can STILL decrypt any virtual disk encrypted from within the VM, steal data, and get away with it. The solution is coming, but is not available yet and that is encrypted memory and processors that understand the encryption.
Currently, cloud and virtual environment administrators do have complete visibility! But they should not!
We need to force the administrators to use portals and other tools so that they do not touch the hosts and critical components directly except in a break glass/troubleshooting situation. This implies we need to have portals that seriously limit the current functionality of the administrator and password vaulting to ensure no one can access the consoles directly without being audited. Even with these changes we need to know we can TRUST those administrators with whom we do not have a relationship. Is there a measurement of administrative TRUST that can be used? Such as bonding?
The current batch of tools and portals are a step in the proper direction, but the Secure and Trusted Multi-Tenancy designs need to consider these options and not just ensure availability. It is not all about Availability or Compliance, but about protecting the data. Not only from the Administrator but from Administrative misconfiguration, social engineering, and hackers.
All the documents I have reviewed from CVN (Cisco, VMware, Netapp) and VCE (VMware, Cisco, EMC) as well as companies I have discussed this with and their designs are far from complete and need to consider Integrity and Confidentiality as well as availability and GRC. GRC may tell you if there was a breach, but this is after the data has been compromised.
We need to protect the data! Without the need for Administrators with Complete Visibility!