Hi,

It seems that the checkboxes “Show on card” that appear in the board view in planner for Notes and Checklist sections do not appear in Project for the Web.

Is this possible?How?

Is it considered in the Project for the Web Roadmap?

If so, when?

If not… It would be interesting in my opinion.

Regards,

Ramón

​Hi, It seems that the checkboxes “Show on card” that appear in the board view in planner for Notes and Checklist sections do not appear in Project for the Web. Is this possible?How?Is it considered in the Project for the Web Roadmap?If so, when?If not… It would be interesting in my opinion. Regards,Ramón  Read More

​

​   Read More

​

As new capabilities in Microsoft 365 Copilot enable customers to accelerate content creation like never before, it is more necessary than ever to extend traditional IT controls for content and access governance. 

SharePoint Advanced Management is a suite of features designed to help simplify data governance and hygiene in Microsoft 365, enhancing both your security posture and your Copilot experience. 

Today we’re pleased to announce several new features to help customers keep sensitive data secure and prep for generative AI by identifying overshared content, enabling AI focused access controls, and enabling easier removal of irrelevant content. 

Data entitlements and access tracking are a core principle of data governance in making data accessible only to those who need access and auditing access for evidence and control. Our new permission state report, currently in public preview, provides admins with a bird’s eye view of all site permissions across SharePoint, OneDrive, and files to help discover potentially over-permissioned content across the tenant. This empowers admins to address those sites to ensure results delivered by Copilot or search are limited only to the users who should have access to that information. 

Screenshot: permission state report

Organizations make better informed decisions when their data is safe to use, complete, and consistent. AI driven semantic matching of sites, also in public preview, is a powerful, intelligent feature that enables administrators to search through unstructured content and semantically detect patterns that align with a predefined sample. Admins can provide a list of sites with documents that are “similar”, like sales or legal, and the service will find all sites that semantically match the input, then provide a policy recommendation for the matched sites, helping achieve good governance more quickly.  

Screenshot: AI driven semantic matching of sites

Site ownership policy (rolling out in October) uses a rule-based policy engine to enable admins to automate time-consuming tasks related to content ownership management, such as maintaining the minimum number of site owners and identifying the most appropriate and accountable individuals. Effective content ownership and accountability are crucial for actions like access reviews and content certification, which help sanitize content to prevent unintended access by Copilot and reduce instances of oversharing.  

Screenshot: Site ownership policy

Ensuring that accountable groups or individuals within the organization can access, describe, protect, and control data quality is a governance fundamental. With Restricted Content Discovery (rolling out in November), administrators can configure policies to restrict search and Copilot from reasoning over select data sites, leaving the site access unchanged but preventing the site’s content from being surfaced by Copilot or organization-wide Search. This policy can be controlled granularly for Team sites, Communication sites, or any other site type. 

Identifying trusted sources and ensuring that data is being sourced from an agreed source of truth ensures accuracy and consistency in search and Copilot responses. Restricted Site Creation (rolling out in October) enables admins to restrict the creation of SharePoint sites to a specific set of users, helping mitigate content sprawl within an organization. 

Screenshot: User experience when restricted content search is enabled

Inactive SharePoint sites policy (rolling out in October) helps reduce the governance footprint at scale through supported actions such as archiving, setting content to read-only, or attestation. These actions allow customers to narrow the scope of what needs governance, minimize oversharing, and eliminate stale or irrelevant content, ultimately enhancing the quality of Copilot responses. 

One of the widely used mechanisms to share content internally with an entire organization is using the ‘Everyone except external users’ group. The new Data Access Governance report on content shared with ‘Everyone except external users’ in last 28 days (available now) assists tenant admins in identifying recently created “public” sites and content shared with this group. The report also includes integrated actions, allowing admins to initiate Access Reviews and secure content during the evaluation process which includes Copilot. 

Screenshot: Data Access Governance report on content shared with ‘Everyone except external users’

These SharePoint Advanced Management capabilities are more valuable than ever as our customers add billions of new documents daily to Microsoft 365 and seek solutions to managing content at scale throughout its lifecycle.   

Learn how to get started with these features and more at Get ready for Copilot for Microsoft 365 with SharePoint Advanced Management (SAM) – SharePoint in Microsoft 365 | Microsoft Learn. 

​Microsoft Tech Community – Latest Blogs –Read More 

Generative AI powered by Large Language Models (LLMs) has revolutionized the way we interact with technology. Through chatbots, co-pilots, and agents, AI is amplifying human productivity across sectors such as healthcare, finance, government, and cybersecurity. Microsoft’s AI platform has been at the forefront of this revolution, supporting state-of-the-art AI models, enabling organizations to differentiate with their business, by enabling developers to deploy AI applications at scale.

At Microsoft, we recognize the trust that consumers and enterprises place in our cloud platform as they integrate our AI services into their workflows. We believe all use of AI must be grounded in the principles of responsible AI – fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. Microsoft’s commitment to these principles is reflected in Azure AI’s strict data security and privacy policy, and the suite of responsible AI tools supported in Azure AI, such as fairness assessments and tools for improving interpretability of models. Whether you’re using Microsoft 365 copilot, a Copilot+ PC, or building your own copilot, you can trust that Microsoft’s responsible AI principles extend to your data as part of your AI transformation. For example, your data is never shared with other customers or used to train our foundational models.

Confidential computing is a set of hardware-based technologies that help protect data throughout its lifecycle, including when data is in use. This complements existing methods to protect data at rest on disk and in transit on the network. Confidential computing uses hardware-based Trusted Execution Environments (TEEs) to isolate workloads that process customer data from all other software running on the system, including other tenants’ workloads and even our own infrastructure and administrators. Crucially, thanks to remote attestation, users of services hosted in TEEs can verify that their data is only processed for the intended purpose.

We foresee that all cloud computing will eventually be confidential. Our vision is to transform the Azure cloud into the Azure confidential cloud, empowering customers to achieve the highest levels of privacy and security for all their workloads. Over the last decade, we have worked closely with hardware partners such as Intel, AMD, Arm and NVIDIA to integrate confidential computing into all modern hardware including CPUs and GPUs. We have taken a full stack approach across infrastructure, containers, and services. We have the most comprehensive IaaS, PaaS and developer offerings including Confidential VMs, Confidential Containers on ACI and AKS, Microsoft Azure Attestation and Azure Key Vault managed HSMs, Azure Confidential Ledger, and SQL Server Always Encrypted.

Our approach is rooted in hardware-based TEEs, in industry standards such as EAT, SCITT and TDISP which we have helped define, and in open source hardware (e.g., the Caliptra root of trust) and software (e.g. the OpenHCL paravisor for confidential VMs). In fact, as part of our Secure Future Initiative, we have committed to protect Azure’s own infrastructure and services using confidential computing.

Azure AI Confidential Inferencing

The Azure OpenAI Service team just announced the upcoming preview of confidential inferencing, our first step towards confidential AI as a service (you can sign up for the preview here). While it is already possible to build an inference service with Confidential GPU VMs (which are moving to general availability for the occasion), most application developers prefer to use model-as-a-service APIs for their convenience, scalability and cost efficiency.  Our goal with confidential inferencing is to provide those benefits with the following additional security and privacy goals:

End-to-end prompt protection. Clients submit encrypted prompts that can only be decrypted within inferencing TEEs (spanning both CPU and GPU), where they are protected from unauthorized access or tampering even by Microsoft. All intermediate services (frontends, load balancers, etc.) only see the encrypted prompts and completions.
Stateless processing. User prompts are used only for inferencing within TEEs. The prompts and completions are not stored, logged, or used for any other purpose such as debugging or training.
User anonymity. Users can remain anonymous while interacting with AI models.
Remote verifiability. Users can independently and cryptographically verify our privacy claims using evidence rooted in hardware.
Transparency. All artifacts that govern or have access to prompts and completions are recorded on a tamper-proof, verifiable transparency ledger. External auditors can review any version of these artifacts and report any vulnerability to our Microsoft Bug Bounty program.

These goals are a significant leap forward for the industry by providing verifiable technical evidence that data is only processed for the intended purposes (on top of the legal protection our data privacy policies already provides), thus greatly reducing the need for users to trust our infrastructure and operators. The hardware isolation of TEEs also makes it harder for hackers to steal data even if they compromise our infrastructure or admin accounts. Lastly, since our technical evidence is universally verifiability, developers can build AI applications that provide the same privacy guarantees to their users. Throughout the rest of this blog, we explain how Microsoft plans to implement and operationalize these confidential inferencing requirements.

How Confidential Inferencing Works

Architecture of Azure AI confidential inferencing

Architecture

Confidential inferencing provides end-to-end verifiable protection of prompts using the following building blocks:

Inference runs in Azure Confidential GPU VMs created with an integrity-protected disk image, which includes a container runtime to load the various containers required for inference.
The node agent in the VM enforces a policy over deployments that verifies the integrity and transparency of containers launched in the TEE.
An immutable, append-only transparency ledger records the container hashes and policies that have been deployed to the service, with additional auditing information when available such as pointers to container registries, SBOMs, sources, CI/CD logs, etc.
Oblivious HTTP (OHTTP) is used to encrypt the prompt from the client to the TEE, ensuring our untrusted services between the client and the TEE (TLS termination, load balancing, DoS protection, authentication, billing) only see encrypted prompts and completions.
A confidential and transparent key management service (KMS) generates and periodically rotates OHTTP keys. It releases private keys to confidential GPU VMs after verifying that they meet the transparent key release policy for confidential inferencing. Clients get the current set of OHTTP public keys and verify associated evidence that keys are managed by the trustworthy KMS before sending the encrypted request.
The client application may optionally use an OHTTP proxy outside of Azure to provide stronger unlinkability between clients and inference requests.

Attested Oblivious HTTP

The simplest way to achieve end-to-end confidentiality is for the client to encrypt each prompt with a public key that has been generated and attested by the inference TEE. Usually, this can be achieved by creating a direct transport layer security (TLS) session from the client to an inference TEE. But there are several operational constraints that make this impractical for large scale AI services. For example, efficiency and elasticity require smart layer 7 load balancing, with TLS sessions terminating in the load balancer. Therefore, we opted to use application-level encryption to protect the prompt as it travels through untrusted frontend and load balancing layers.

Oblivious HTTP (OHTTP, RFC9458) is a standard protocol that achieves this goal: a client serializes and seals the real inference request (including the prompt) with HPKE (RFC9180), a standard message sealing algorithm that uses Diffie-Hellman public shares to represent the recipient’s identity, and sends it as an encapsulated request (visible to the untrusted TLS terminator, load balancer, ingress controllers, etc.). Even though all clients use the same public key, each HPKE sealing operation generates a fresh client share, so requests are encrypted independently of each other. Requests can be served by any of the TEEs that is granted access to the corresponding private key.

To submit a confidential inferencing request, a client obtains the current HPKE public key from the KMS, along with hardware attestation evidence proving the key was securely generated and transparency evidence binding the key to the current secure key release policy of the inference service (which defines the required attestation attributes of a TEE to be granted access to the private key). Clients verify this evidence before sending their HPKE-sealed inference request with OHTTP.

Inbound requests are processed by Azure ML’s load balancers and routers, which authenticate and route them to one of the Confidential GPU VMs currently available to serve the request. Within the TEE, our OHTTP gateway decrypts the request before passing it to the main inference container. If the gateway sees a request encrypted with a key identifier it hasn’t cached yet, it must obtain the private key from the KMS. To this end, it gets an attestation token from the Microsoft Azure Attestation (MAA) service and presents it to the KMS. If the attestation token meets the key release policy bound to the key, it gets back the HPKE private key wrapped under the attested vTPM key. When the OHTTP gateway receives a completion from the inferencing containers, it encrypts the completion using a previously established HPKE context, and sends the encrypted completion to the client, which can locally decrypt it.

Azure Confidential GPU VMs

Internal architecture of confidential GPU VMs with H100 Tensor Core GPUs

In confidential inferencing, all services that require access to prompts in cleartext are hosted in Azure Confidential GPU VMs. These VMs combine SEV-SNP capabilities in 4th Generation AMD EPYC processors and confidential computing primitives in NVIDIA H100 Tensor Core GPUs to create a unified Trusted Execution Environment (TEE) across the CPU and GPU. These VMs enable deployment of high-performance AI workloads while significantly in Azure infrastructure and admins. In a Confidential GPU VM, all code and data (including keys, prompts, and completions) remains encrypted in CPU memory and when they are transferred between the CPU and GPU over the PCIe bus. The data is decrypted only within the CPU package and the on-package High-Bandwidth Memory (HBM) in the GPU, where it remains protected even from privileged access using hardware firewalls.

Azure Confidential GPU VMs support a two-phase attestation protocol. When a Confidential GPU VM starts, it boots into a layer of Microsoft-provided firmware known as the Hardware Compatibility Layer (see the recent OpenHCL blog for details). The HCL is measured by the Platform Security Processor (PSP), the hardware root of trust in the AMD EPYC processors. The measurement is included in SEV-SNP attestation reports signed by the PSP using a processor and firmware specific VCEK key. HCL implements a virtual TPM (vTPM) and captures measurements of early boot components including initrd and the kernel into the vTPM. These measurements are available in the vTPM attestation report, which can be presented along SEV-SNP attestation report to attestation services such as MAA.

When the GPU driver within the VM is loaded, it establishes trust with the GPU using SPDM based attestation and key exchange. The driver obtains an attestation report from the GPU’s hardware root-of-trust containing measurements of GPU firmware, driver micro-code, and GPU configuration. This report is signed using a per-boot attestation key rooted in a unique per-device key provisioned by NVIDIA during manufacturing. After authenticating the report, the driver and the GPU utilize keys derived from the SPDM session to encrypt all subsequent code and data transfers between the driver and the GPU.

Applications within the VM can independently attest the assigned GPU using a local GPU verifier. The verifier validates the attestation reports, checks the measurements in the report against reference integrity measurements (RIMs) obtained from NVIDIA’s RIM and OCSP services, and enables the GPU for compute offload. When the VM is destroyed or shutdown, all content in the VM’s memory is scrubbed. Similarly, all sensitive state in the GPU is scrubbed when the GPU is reset.

Hardened VM Images

Confidential inferencing will further reduce trust in service administrators by utilizing a purpose built and hardened VM image. In addition to OS and GPU driver, the VM image contains a minimal set of components required to host inference, including a hardened container runtime to run containerized workloads. The root partition in the image is integrity-protected using dm-verity, which constructs a Merkle tree over all blocks in the root partition, and stores the Merkle tree in a separate partition in the image. During boot, a PCR of the vTPM is extended with the root of this Merkle tree, and later verified by the KMS before releasing the HPKE private key. All subsequent reads from the root partition are checked against the Merkle tree. This ensures that the entire contents of the root partition are attested and any attempt to tamper with the root partition is detected.

Container Execution Policies

Much like many modern services, confidential inferencing deploys models and containerized workloads in VMs orchestrated using Kubernetes. However, this places a significant amount of trust in Kubernetes service administrators, the control plane including the API server, services such as Ingress, and cloud services such as load balancers.

Confidential inferencing reduces trust in these infrastructure services with a container execution policies that restricts the control plane actions to a precisely defined set of deployment commands. In particular, this policy defines the set of container images that can be deployed in an instance of the endpoint, along with each container’s configuration (e.g. command, environment variables, mounts, privileges). The policy is measured into a PCR of the Confidential VM’s vTPM (which is matched in the key release policy on the KMS with the expected policy hash for the deployment) and enforced by a hardened container runtime hosted within each instance. The runtime monitors commands from the Kubernetes control plane, and ensures that only commands consistent with attested policy are permitted. This prevents entities outside the TEEs to inject malicious code or configuration.

Stateless Processing

Confidential inferencing adheres to the principle of stateless processing. Our services are carefully designed to use prompts only for inferencing, return the completion to the user, and discard the prompts when inferencing is complete. The prompts (or any sensitive data derived from prompts) will not be available to any other entity outside authorized TEEs.

Confidential inferencing minimizes side-effects of inferencing by hosting containers in a sandboxed environment. For example, inferencing containers are deployed with limited privileges. All traffic to and from the inferencing containers is routed through the OHTTP gateway, which limits outbound communication to other attested services. We also mitigate side-effects on the filesystem by mounting it in read-only mode with dm-verity (though some of the models use non-persistent scratch space created as a RAM disk).

Some benign side-effects are essential for running a high performance and a reliable inferencing service. For example, our billing service requires knowledge of the size (but not the content) of the completions, health and liveness probes are required for reliability, and caching some state in the inferencing service (e.g. the attention KV) or in hardware (e.g. L3 cache) is necessary for competitive performance. All such side effects are implemented in attested and transparent code and are subject to independent review. We are also actively conducting research to understand and effectively mitigate any security risks arising through these side-effects. 

Confidential and Transparent Keying

Clients of confidential inferencing get the public HPKE keys to encrypt their inference request from a confidential and transparent key management service (KMS). The KMS ensures that private HPKE keys are securely generated, stored, periodically rotated, and released only to Azure Confidential GPU VMs hosting a transparent software stack.

The release of private HPKE keys is governed by key release policies. When a Confidential GPU VM requests a private HPKE key, it presents an attestation token issued by MAA that includes measurements of its TPM PCRs. The KMS validates this attestation token against the key release policy and wraps the private HPKE key with a wrapping key generated and only accessible by the Confidential GPU VM. Key wrapping protects the private HPKE key in transit and ensures that only attested VMs that meet the key release policy can unwrap the private key.

The KMS permits service administrators to make changes to key release policies e.g., when the Trusted Computing Base (TCB) requires servicing. However, all changes to the key release policies will be recorded in a transparency ledger. External auditors will be able to obtain a copy of the ledger, independently verify the entire history of key release policies, and hold service administrators accountable. When clients request the current public key, the KMS also returns evidence (attestation and transparency receipts) that the key was generated within and managed by the KMS, for the current key release policy. Clients of the endpoint (e.g., the OHTTP proxy) can verify this evidence before using the key for encrypting prompts.

Using a confidential KMS allows us to support complex confidential inferencing services composed of multiple micro-services, and models that require multiple nodes for inferencing. For example, an audio transcription service may consist of two micro-services, a pre-processing service that converts raw audio into a format that improve model efficiency, and a model that transcribes the resulting stream. Most language models rely on a Azure AI Content Safety service consisting of an ensemble of models to filter harmful content from prompts and completions. Each of these services can obtain service-specific HPKE keys from the KMS after attestation, and use these keys for securing all inter-service communication.

User Anonymity

In addition to protection of prompts, confidential inferencing can protect the identity of individual users of the inference service by routing their requests through an OHTTP proxy outside of Azure, and thus hide their IP addresses from Azure AI. Enterprise users can set up their own OHTTP proxy to authenticate users and inject a tenant level authentication token into the request. This allows confidential inferencing to authenticate requests and perform accounting tasks such as billing without learning about the identity of individual users.

Transparency

Confidential inferencing is hosted in Confidential VMs with a hardened and fully attested TCB. As with other software service, this TCB evolves over time due to upgrades and bug fixes. Some of these fixes may need to be applied urgently e.g., to address a zero-day vulnerability. It is impractical to wait for all users to review and approve every upgrade before it is deployed, especially for a SaaS service shared by many users.

Our solution to this problem is to allow updates to the service code at any point, as long as the update is made transparent first (as explained in our recent CACM article) by adding it to a tamper-proof, verifiable transparency ledger. This provides two critical properties: first, all users of the service are served the same code and policies, so we cannot target specific customers with bad code without being caught. Second, every version we deploy is auditable by any user or third party. Although we aim to provide source-level transparency as much as possible (using reproducible builds or attested build environments), this is not always possible (for instance, some OpenAI models use proprietary inference code). In such cases, we may have to fall back to properties of the attested sandbox (e.g. limited network and disk I/O) to prove the code doesn’t leak data. All claims registered on the ledger will be digitally signed to ensure authenticity and accountability. Incorrect claims in records can always be attributed to specific entities at Microsoft.  

When an instance of confidential inferencing requires access to private HPKE key from the KMS, it will be required to produce receipts from the ledger proving that the VM image and the container policy have been registered. Therefore, when users verify public keys from the KMS, they are guaranteed that the KMS will only release private keys to instances whose TCB is registered with the transparency ledger.

Roadmap and Resources

Confidential inferencing is a reaffirmation of Microsoft’s commitment to the Secure Future Initiative and our Responsible AI principles. It brings together state-of-the-art AI models and Azure infrastructure, with cutting edge confidential computing in Azure Confidential GPU VMs based on AMD SEV-SNP and NVIDIA H100 Tensor Core GPUs to deliver end-to-end, independently verifiable privacy.

We will continue to work closely with our hardware partners to deliver the full capabilities of confidential computing. We will make confidential inferencing more open and transparent as we expand the technology to support a broader range of models and other scenarios such as confidential Retrieval-Augmented Generation (RAG), confidential fine-tuning, and confidential model pre-training.

Learn more about the Azure  AI Confidential inferencing Preview
Sign up for the preview by filling this form
Learn about the general availability of Azure Confidential GPU VMs
Discover our full range of Azure Confidential Computing solutions here.

​Microsoft Tech Community – Latest Blogs –Read More 

Customers with the need to protect sensitive and regulated data are looking for end-to-end, verifiable data privacy, even from service providers and cloud operators. Azure’s industry-leading confidential computing (ACC) support extends existing data protection beyond encryption at rest and in transit, ensuring that data is private while in use, such as when being processed by an AI model. Customers in highly regulated industries, including the multi-national banking corporation RBC, have integrated Azure confidential computing into their own platform to garner insights while preserving customer privacy.

With the preview of Confidential inference for the Azure OpenAI Service Whisper model for speech to text transcription today, Microsoft is the first cloud provider offering confidential AI.  Confidential Whisper offers end-to-end privacy of prompts containing audio and transcribed text responses by ensuring that the prompts are decrypted only within Trusted Execution Environments (TEE) on Azure Confidential GPU virtual machines (VMs).  

These VMs offer enhanced protection of the inferencing application, prompts, responses and models both within the VM memory and when code and data is transferred to and from the GPU. Confidential AI also allows application developers to anonymize users accessing using cloud models to protect identity and from attacks targeting a user.

Read on for more details on how Confidential inferencing works, what developers need to do, and our confidential computing portfolio. 

Who Confidential Inferencing Is For

Confidential inferencing is designed for enterprise and cloud native developers building AI applications that need to process sensitive or regulated data in the cloud that must remain encrypted, even while being processed. They also require the ability to remotely measure and audit the code that processes the data to ensure it only performs its expected function and nothing else. This enables building AI applications to preserve privacy for their users and their data.

How Confidential Inferencing Works

Confidential inferencing utilizes Azure confidential virtual machines with NVIDIA H100 Tensor Core GPU, which is now generally available. These VMs use a combination of SEV-SNP technology in AMD CPUs and Confidential Computing support in H100 GPUs to ensure integrity and privacy of all code and data loaded within the VM and the protected area of GPU memory.

For example, SEV-SNP encrypts and integrity-protects the entire address space of the VM using hardware managed keys. This means that any data processed within the TEE is protected from unauthorized access or modification by any code outside the environment, including privileged Microsoft code such as our virtualization host operating system and Hyper-V hypervisor. When the VMs are paired with H100 GPU in confidential computing mode, all traffic between the VM and GPU is encrypted and integrity protected from advanced attackers.

Confidential inferencing supports Oblivious HTTP with Hybrid Public Key Encryption (HPKE) to protect user privacy and encrypt and decrypt inferencing requests and responses. Enterprises and application providers can use an Oblivious HTTP proxy to encrypt prompts, which are routed through Azure Front Door and the Azure OpenAI Service load balancer to OHTTP gateways hosted within Confidential GPU VMs in a Kubernetes cluster managed by Azure Machine Learning’s Project Forge. The Front Door and load balancers are relays, and only see the ciphertext and the identities of the client and gateway, while the gateway only sees the relay identity and the plaintext of the request. The private data remains encrypted.

OHTTP gateways obtain private HPKE keys from the KMS by producing attestation evidence in the form of a token obtained from the Microsoft Azure Attestation service. This proves that all software that runs within the VM, including the Whisper container, is attested.

After obtaining the private key, the gateway decrypts encrypted HTTP requests, and relays them to the Whisper API containers for processing. When a response is generated, the OHTTP gateway encrypts the response and sends it back to the client.

Image: Confidential inference architecture 

Confidential inferencing utilizes VM images and containers built securely and with trusted sources. A software bill of materials (SBOM) is generated at build time and signed for attestation of the software running in the TEE.

How to Integrate Confidential Inferencing

You can integrate with Confidential inferencing by hosting an application or enterprise OHTTP proxy that can obtain HPKE keys from the KMS, and use the keys for encrypting your inference data before leaving your network and decrypting the transcription that is returned. We are providing a reference implementation of such a proxy. The Whisper REST API and payload is unchanged.

There is overhead to support confidential computing, so you will see additional latency to complete a transcription request compared to standard Whisper. We are working with Nvidia to reduce this overhead in future hardware and software releases.

Our Confidential Computing Portfolio

Azure OpenAI Service Whisper is the first Azure AI Model-as-a-Service from Microsoft with confidential computing protection. As part of our long-term investment in confidential computing, we’ll continue to engage with our privacy-sensitive customers to best support their unique AI scenarios. We really want to hear from you about your use cases, application design patterns, AI scenarios, and what other models you want to see. 

If you are interested in discussing Confidential AI uses cases with us and trying out confidential inferencing with the Azure OpenAI Service Whisper model, please visit this preview sign-up page.

Resources:

Get a deep-dive on Azure AI Confidential Inferencing
Learn more about confidential VMs GA

​Microsoft Tech Community – Latest Blogs –Read More 

Today Microsoft announced the launch of Protected Materials Detection for Code, a new feature in the Azure AI Content Safety is a generative AI guardrail that can be used with generative AI applications that generate code. Previously available exclusively in Azure OpenAI Service, this advanced model can now be utilized by developers using a wide range of AI tools, enhancing the protection and detection of intellectual property (IP) in code outputs. 

How It Works 

The Protected Materials Detection for Code feature compares AI-generated code against a comprehensive database of all public GitHub repositories. If a significant portion of code matches public code, the system will flag the corresponding GitHub repository and provide a citation link, including license details. This allows developers to review the source of the matching code and ensure proper attribution or licensing. 

This model operates within Azure AI Content Safety and is designed to work without affecting the performance or experience of generating code. Developers can choose to use the content filter to block content, or annotate content, or leave the filter off. This enables developers to customize how and when code citations and licenses appear in their workflow. 

Azure OpenAI Service and Beyond 

Protected Materials Detection for Code has already been integrated into Azure OpenAI Service, where  the content filter provides citations and licensing information for code generated by OpenAI’s GPT family of models By adding this feature to Azure AI Content Safety. Microsoft is now enabling this functionality to be used by customers with other generative AI models that generate code. 

“We’re excited to offer this feature to a broader range of AI applications,” said Jinrui Shao, Product Manager for Azure AI Content Safety. “This is especially important for developers using AI to generate code, whether for internal applications or public release, as it helps ensure that any code created complies with proper licensing standards.” 

Developer Experience and Implementation 

Azure AI developers can now take advantage of this feature by simply enabling the model within the Azure AI Content Safety service. The feature is designed to integrate smoothly with existing workflows and can be used in real-time or asynchronous code generation scenarios. 

For example, when a code snippet is generated by any AI-driven code application, the system checks the code against its database and provides a detailed annotation if protected materials are detected. This annotation includes: 

Whether protected content was detected (yes or no). 

Citations for the public GitHub repositories where the code appears. 

License information for the matched code, ensuring developers know if and how they can use the code. 

Get started 

Learn more about Azure AI Content Safety 

Explore our protected material detection for code documentation  

Get started in Azure AI Studio 

​Microsoft Tech Community – Latest Blogs –Read More 

Cowritten By: @suhelp and @arishojaswi 

To receive the highest quality responses from Copilot, users have the option to allow Copilot to reference web content. Querying the web improves the quality of Copilot responses by grounding them in the latest information from the web. Throughout the process the prompt and response remain within the service boundary; the queries Copilot generates have the user and tenant identifiers removed and are sent securely to the Bing search service.  

Screenshot: Web content plugin end user toggle for Microsoft 365 Copilot

As more customers experience the benefits of web grounding, we’ve heard a strong interest in being able to see the queries Copilot generates to fetch that information from the Bing search service. Today, we’re excited to announce new features that will allow both users and admins greater visibility into Copilot generated web queries. 

Bing web search query citations for users 

Web search query citations for users (generally available in October) will include the exact web search queries derived from the user’s prompt in the linked citation section of the Copilot response, helping users understand what search queries, along with the sites searched (available today), were used to enhance the response. 

This provides users with valuable feedback as to exactly how their prompts are used to generate web queries that are sent over to Bing search. This transparency helps users with the information they need to improve prompts and use Copilot more effectively. 

To learn more about data, privacy, and security for web queries in Microsoft 365 Copilot, please refer to the Microsoft Learn article Data, privacy, and security for web queries in Microsoft 365 Copilot. 

Web search queries will be displayed in the linked citation section of the Copilot response

Audit logging and eDiscovery for Bing web search queries   

Web search query logging (generally available in Q4) will enable admins to perform search, audit, and eDiscovery on the exact web search queries Copilot derived from the user’s prompt. Admins can already perform these actions for prompts and responses and will be able to use their familiar tools to extend those actions to search queries.* 

Providing transparency into web queries supports our mission of Trustworthy AI, as customers can confirm that the information searched by Copilot is relevant and appropriate. 

Admins will be able to use the audit log to find events involving web queries. Within the CopilotInteraction audit log, there is a property AISystemPlugin.Id which can be used to identify whether a specific Copilot interaction had a query sent to Bing. If it did, then AISystemPlugin.Id will contain the value ‘BingWebSearch’.  

In order to identify all Copilot interactions where a web search query was generated, admins will first filter and export all relevant CopilotInteraction audit logs. This can be done by filtering operation = CopilotInteraction. Once the search results are exported, admind can then filter by AISystemPlugin.Id offline.  

Admins will be able to use the audit log to find events involving web queries

For eDiscovery, the Bing search query is stored in the user’s Exchange mailbox as part of the Copilot response in the form of a metadata. Admins and eDiscovery Manager can search for the prompts and responses using Copilot Activity filter in eDiscovery condition builder and view the detailed conversations including the Bing search queries. Additionally, the CopilotInteraction audit record contains a messageId which points to this response message, which can be retrieved using eDiscovery. Learn more about using eDiscovery in the Microsoft Learn article Search for and delete Microsoft Copilot for Microsoft 365 data. 

Our continuing commitment to enhancing web grounding control 

As the examples above illustrate, we’re continuing to invest in giving customers increased visibility and control over web grounding for Copilot. To learn more, please see the Microsoft Learn article How Microsoft handles generated queries.  

*Note: The specific controls will vary depending on the underlying subscription plan. 

​Microsoft Tech Community – Latest Blogs –Read More 

Would appreciate some help, please!

Column F contains current scores 1-20

Column G contains previous scores, also 1-20

I need column G to highlight whether the scores have gone up, down or stayed the same.

There’s already conditional formatting in column G (red fill for values > 12 , amber fill for 8-12 and green for <8)

I tried to use conditional formatting (format all cells based on their values) with icon sets and a formula, but excel doesn’t allow relative references for icon sets and I do need excel to compare cells within the same row, ie G2 with F2, G3 with F3, etc (ideally ignoring blank cells).

Is there any other way to do it?

​Would appreciate some help, please! Column F contains current scores 1-20Column G contains previous scores, also 1-20 I need column G to highlight whether the scores have gone up, down or stayed the same.There’s already conditional formatting in column G (red fill for values > 12 , amber fill for 8-12 and green for <8) I tried to use conditional formatting (format all cells based on their values) with icon sets and a formula, but excel doesn’t allow relative references for icon sets and I do need excel to compare cells within the same row, ie G2 with F2, G3 with F3, etc (ideally ignoring blank cells). Is there any other way to do it?  Read More

​

I need below details when i connect to my SQL Server.

DB Creation Date

Tables/Views/SPs Creation Date

Tables/Views/SPs Last used/accessed  ==> Need history of one/two years when they accessed

connecting to applications host

I want all above details in one SQL Query. 

Is that possible to get all the above details in one single query..?

​I need below details when i connect to my SQL Server. DB Creation DateTables/Views/SPs Creation DateTables/Views/SPs Last used/accessed  ==> Need history of one/two years when they accessedconnecting to applications host I want all above details in one SQL Query. Is that possible to get all the above details in one single query..?   Read More

​

I have a created a function as below

public static ICustomers[]? SanitiseCustomers(this string[]? custVals, float boxed = 0.5f)
{
List<ICustomers> customers = [];

foreach (var c in custVals)
{
customers.Add(c.Sanitize(boxed));
}

return [.. customers];
}

I want to replace the Sanitize function within the foreach loop to a different method.

I dont want to copy and paste the function and create a new one and changing Sanitize to FriendlyBox but trying to see if there is a way to switch the method name depending on the way this function is called?

​I have a created a function as below public static ICustomers[]? SanitiseCustomers(this string[]? custVals, float boxed = 0.5f)
{
List<ICustomers> customers = [];

foreach (var c in custVals)
{
customers.Add(c.Sanitize(boxed));
}

return [.. customers];
} I want to replace the Sanitize function within the foreach loop to a different method. I dont want to copy and paste the function and create a new one and changing Sanitize to FriendlyBox but trying to see if there is a way to switch the method name depending on the way this function is called?  Read More

​