正如 cmets 所指定的，您不执行任何 CLR 程序集。这些与文件系统隔离，并与SQL Server 中的任何其他类型的对象一样保持不变。
事实上，这就是让 CLR 对象如此巧妙的原因。它们与您希望操作的任何其他函数、过程、表一样存在。
现在，既然您在此论坛上发布了有关权限的帖子，请从数据库管理员的角度了解 CLR 是自定义的，因此本质上是不安全的。这是不安全的，因为归根结底，您的专业知识和知识深度是一个限制因素，超出了 SQL Server 的正常预期操作。
CLR 权限的最大因素取决于它是否需要来自 SQL Server 的外部资源。从安全的角度来看，它是UNSAFE，句号。
请注意，有三个策略决定您的安全级别：MACHINE、USER 和 HOST 策略。
确定授予程序集权限的安全策略在三个不同的地方定义：
机器策略：这是对在安装了 SQL Server 的机器上运行的所有托管代码有效的策略。
用户策略：这是对进程托管的托管代码有效的策略。对于 SQL Server，用户策略特定于运行 SQL Server 服务的 Windows 帐户。
主机策略：这是由 CLR 的主机（在本例中为 SQL Server）设置的策略，对该主机中运行的托管代码有效。
CLR Integration Code Access Security
这些是分开的，其中一个可能是您被拒绝特权的原因。
CLR 使用 .NET Framework 中的代码访问安全 (CAS)，不再支持将其作为安全边界。
clr enabled configuration | Microsoft Docs
1) 无论如何都向您的团队请求访问权限，而无需进行任何更改，并且忽略有关安全性如何变化的任何警告。
2) 在确定 CLR 对系统实际构成何种风险后请求访问。
3) 更改您的 CLR 以在仍然支持 CAS 的情况下在适当的安全级别下运行。
4) 请求一个替代方案，将这个对象的要求封装在远离常规、不合格用户的地方，以便正确的帐户在您的常规帐户没有访问权限的情况下运行它。
第一种选择是懒惰的人所做的。不要偷懒。做一些研究，学习，从他们的角度理解你需要什么。也许这无论如何都是不可行的。
第二个选项基本上是这样的：阅读并了解文档所说的内容，这样您就可以更有说服力地满足您的需求。对于您的开发团队来说，这绝对是他们阅读文档的必要条件。链接见帖子末尾。
第三个选项可能不可行，但也许在第二步/与 DBA 交谈之后，您可能会确定 CLR 无论如何都被压倒了。唯一的问题是，在 SQL Server 2017 中，所有 CLR 代码都将被视为 UNSAFE，因为 Microsoft 正在取消对常规安全性的支持。 因此，如果这不会造成阻塞问题，请做出相应的计划。
第四个选项意味着您可以让 DBA 使用与实际运行脚本的LOGIN/USER 不同的服务帐户/合格用户。优点是封装可以让您得到您想要的，并且仍然保持您需要的高标准的安全性。这两个缺点取决于 CLR 和您的需求，以及 DBA 帮助您开发正确代码的意愿。
无论您是经验丰富的 CLR 资深人士还是新手，文档确实是您了解可以或不应该要求什么的最佳方式。
来源
开发者必读