Из статьи "Microsoft SQL Server 7.0. Контрольная по безопасности", опубликованной в Компрессе не помню, когда.

"...Однако, как бы то ни было, пользователю придется давать права на хранимые процедуры, скажем на ту же spChangeBalance. Конечно, по-хорошему он должен вызывать ее только изнутри приложения сугубо для тех счетов и сумм, которые получаются по ходу бизнес-логики, но... Но представим себе, что продвинутый пользователь Саша, купив на Горбушке диск с SQL Server, поставил себе на рабочую станцию Query Analyzer, запустил запрос типа exec spChangeBalance @Sum=$1000000, @Account=<Подставной счет в оффшоре>, далее каждый домысливает сам. Спрашивается, а) что будет в этом случае с DBA и б) как быть, чтобы этого не было?
Оставим первый вопрос как риторический и рассмотрим следующий кусочек кода:
revoke all from [Cаша]
exec sp_addapprole @rolename=’AppRole1’, @password='abc'
grant execute on spChangeBalance to ‘AppRole1’
Cымитируем работу приложения (исходный код пользователю, естественно, неизвестен и недоступен):
exec sp_setapprole @rolename=’AppRole1’, @password={Encrypt N'abc'}, @Encrypt='ODBC'
exec spChangeBalance …
Процедура вызывается и отрабатывает. Теперь откроем Query Analyzer, Microsoft Query, Access или любую другую программу, позволяющую послать на SQL Server интерактивный запрос, зарегистрируемся на нем под логином Саши и попробуем вызвать spChangeBalance. Вызов не сработает.
Это пример действия прикладной роли. Прикладные роли в SQL Server 7.0 ограничивают возможности пользователей по доступу к данным рамками конкретного приложения. Таким образом, даже если продвинутый пользователь Саша догадается, что изменение остатка по счету производится хранимой процедурой spChangeBalance, он все равно не сможет ей воспользоваться, когда захочет, вне жестко заданного сценария. Прикладные роли действуют не постоянно, а во время пользовательской сессии. Они защищены паролем, так как это единственный способ авторизации (в них нет четко приписанных логинов, потому что они могут быть активизированы из любого приложения. Следовательно, приложение должно само проверить пользователя, прежде чем включать ему прикладную роль. При активизации приложением прикладной роли в текущей БД все права и роли, соответствовавшие контексту безопасности пользователя, перестают быть действительными (кроме роли public). К другим БД можно обращаться из текущей с использованием полных имен объектов (обращения будут идти от имени guest). При смене текущей БД (явная команда USE) действие прикладной роли прекращается."

Я вообще не знаю, что такое Delphi, но думаю, что из него (а также из VС++, Java, etc.) это делается абсолютно аналогично засылкой на сервер команды sp_setapprole. Вообще идеальный вариант, когда у Вас все оформлено в виде компонент (хоть на VBScript и XML - за ради Бога) и компонентам в СОМ+ прописаны роли, которые можно затем один в один отобразить на прикладные роли SQL Server'a.