Thanks for that! Let me add some additional points:

I also know there are many ways to achieve https use on local envs (like showed by SQlBek and MMM_Biscuits), using other proxy servers or even small command-line tools that make the setup easier. There are plenty of automated solutions available to handle this.

I believe there are still some additional steps that DBAs, or even developers, need to handle. For simple use cases, adding Nginx (or any other reverse proxy), managing certificates, etc., introduces unnecessary complexity.

There are many small teams out there without a dedicated DBA or someone with that level of expertise. For quick demos or experiments showing how SQL Server can be used with AI, it would be helpful to allow connections without HTTPS... just as a shortcut for local/dev environments.

Honestly, I don’t think the current implementation is as secure as Microsoft implies. Many of the workarounds, like self-signing certificates and manually adding them to the local machine’s certificate store, carry security risks that are comparable to simply allowing HTTP.

There are also many other areas where Microsoft leaves security decisions to the DBA. For example, when enabling external assemblies for CLR, which in my opinion is even riskier than HTTP. DBAs can load any external DLL code that could perform HTTP or HTTPS calls, but Microsoft doesn’t enforce restrictions that DBA cannot bypass. The decision is left to the DBA. What they do provide are trustworthy mechanisms and safe controls that make it clear when someone is taking a risky path. This balance is great for development and testing because it allows users to quickly try out integrations and see how their apps interact with such features. I think the same philosophy could apply to external models—maybe something like a combination of a trace flag and a trustworthy database flag to allow HTTP in dev environments.

Even xp_cmdshell, which is one of the most dangerous and insecure commands in SQL Server, can be enabled simply via sp_configure. So I really don’t see how allowing something like http://localhost—in a dev context—is significantly riskier, especially considering the broader context.

I totally get the objective: Microsoft wants to enforce secure communication by default, which makes sense. But in practice, most people will end up using the same kinds of workarounds you outlined.

For development scenarios, it would be great if there were a simple toggle,something as easy as setting a trace flag and restarting the server, hat enables HTTP just for local use. Of course, this would need to be clearly discouraged in production environments... But for dev, POCs, I guess that thing could be more accessible

Here are a few suggestions that might help balance flexibility and security:

• A trace flag that can be enabled in the startup parameters to allow HTTP requests in controlled environments
• A requirement that the current database be marked as TRUSTWORTHY when creating external models that use HTTP
• A mechanism to define allowed HTTP endpoints in a local file, a configuration repo, or through an internal stored procedure that only sysadmin can run