Semantic Kernel中OpenAPI函数执行参数的安全改进探讨

背景介绍

在.NET生态系统中，Semantic Kernel作为一个强大的AI集成框架，提供了OpenAPI函数执行功能。开发者可以通过OpenApiFunctionExecutionParameters类来配置API操作的执行参数。当前实现中，该类提供了一个OperationsToExclude属性，允许开发者排除特定的API操作。

现有设计的问题分析

当前基于"排除列表"的设计存在一个经典的安全隐患：默认情况下，所有未被明确排除的API操作都会被包含进来。这种"默认允许"的模式在安全领域被认为是反模式，因为它可能导致：

1. 安全风险：当API接口扩展时，新添加的接口如果没有被及时加入排除列表，就会自动暴露
2. 维护困难：随着API规模增长，开发者需要不断更新排除列表来保持安全性
3. 意图不明确：大多数情况下，开发者其实更清楚他们需要哪些API，而不是不需要哪些

改进建议

建议将当前的"排除列表"模式改为"包含列表"模式，即：

1. 引入OperationsToInclude属性替代或补充现有的OperationsToExclude
2. 如果两者同时存在，包含列表应具有更高优先级
3. 当两者都未定义时，可以保持向后兼容性，包含所有API操作

这种改进将带来以下优势：

• 更安全的默认行为：只有明确允许的API才会被暴露
• 更清晰的开发意图：开发者明确声明他们需要的功能
• 更好的可维护性：API扩展不会意外暴露新功能

技术实现考量

在实现这一改进时，需要考虑：

1. 向后兼容性：如何处理现有使用OperationsToExclude的代码
2. 性能影响：包含列表的检查是否会影响性能
3. 错误处理：当包含列表中指定了不存在的操作时的行为
4. 文档更新：需要同步更新相关文档和示例

当前进展

Semantic Kernel团队已经开始向这个方向改进，引入了OperationSelectionPredicate机制。这个谓词可以根据操作ID、路径、方法和描述来包含或排除操作，提供了更灵活的过滤能力。虽然这个谓词尚未集成到OpenApiFunctionExecutionParameters中，但代表了框架未来的发展方向。

最佳实践建议

对于当前需要安全地使用OpenAPI功能的开发者，可以：

1. 使用OperationSelectionPredicate实现自定义过滤逻辑
2. 如果必须使用OperationsToExclude，确保定期审查和更新排除列表
3. 考虑手动编辑API规范资源作为临时解决方案，但要注意其维护成本

总结

将OpenAPI函数执行参数从"排除列表"改为"包含列表"的设计，不仅更符合安全最佳实践，也能更好地表达开发者的真实意图。这一改进将使Semantic Kernel在API集成方面更加安全和可靠，特别是在企业级应用中。开发者应关注框架在这方面的更新，以便及时采用更安全的设计模式。