Единственное возможное, и часто осуществляемое решение, это размещение дополнительных мониторов управления доступом на прикладном уровне. Это сделано в языке сценариев веб-броузеров Javaи в VBA, имеющемся в Word for Windows. Преимущество заключается в том, что о синтаксическом анализе позаботится приложение, которое также уверено в собственной объектной модели. Это наиболее оптимальный способ применения мониторов управления доступом.
Сразу становится очевидна одна проблема: механизм безопасности уязвим для атак со стороны прикладного уровня. Поэтому мониторы должны быть ограждены защитой ядра от модифицирующих атак. Security Information Modification (SIM) Policy, разработанная для нашей GFAC-системы, может быть использована для защиты мониторов от неавторизованного изменения. Политика SIM [LaPadula 1995] использует ACI-атрибут data-type с двумя вероятными значениями, "si" и "NIL", точно также, как и system role для пользователя. Если типом запроса доступа процесса к данным является si, в режиме использующем изменение данных, то согласно SIM-политике доступ будет предоставлен только в том случае, если владельцем процесса является "security officer". Следовательно, мониторы в программном окружении должны иметь для атрибута data-type значение si, так они обретут защиту со стороны ядра от манипуляций.
Мы хотели бы немного отойти от темы и упомянуть использование 'сертификатов' в защите приложений. Обычно предлагается составлять сертификаты как аутентификацию для аплетов, таких как Java-аплет, объектов ActiveX или макросов VBA, для уверенности в безопасности этих аплетов. Однако, сами-по-себе сертификаты ничего не решают. Они повышают доверительный уровень аплета, идентифицируя сверх разумных пределов его происхождение. то не защищает аплет от внесения в него злонамеренного кода составителем сертификата.