In part one of this little series I introduced TasmanianDevil, a standalone, offline PII detection and de-identification engine for .NET. We saw it on its own - detecting and validating PII, anonymizing it with a range of operators, the reversible encrypt/decrypt round-trip, structured JSON and CSV redaction, and the optional multilingual NER add-on.

That engine is useful anywhere, but the place I built it for is AI agents. In this part I will wire it into Microsoft Agent Framework (MAF) agents through AgentGuard, so PII is handled automatically around the agent - on the way in, on the way out, and in the results that come back from tool calls.

A few months ago I introduced AgentGuard, a library for declarative guardrails and safety controls for .NET AI agents. One of the rules it shipped with from day one was PII redaction, but back then it was a fairly basic, regex-only affair - good enough to scrub an email address or a credit card number, but not much more. Since then I have rebuilt that part of the library from the ground up into a proper, offline PII detection and de-identification engine, and it has grown enough that it no longer makes sense to keep it locked inside AgentGuard.

As of the 0.10.0 release, the PII engine lives in its own standalone, brand-neutral library called TasmanianDevil - framework-agnostic, no dependency on AgentGuard, usable anywhere you have a string you would rather not leak. AgentGuard now consumes it like any other NuGet package.

This is the first of a two-part series. In this part I will walk through TasmanianDevil on its own - detection, anonymization, the reversible round-trip, structured data, and the optional multilingual NER. In part two I will wire it into Microsoft Agent Framework (MAF) agents, where it really comes into its own.

This post continues a series on hybrid architectures that combine local Small Language Models (SLMs) with cloud Large Language Models (LLMs). We have already looked at the Minions pattern, which offloads bulk text extraction to a local model to reduce cloud API costs, and the SLM-default, LLM-fallback pattern, where a local model handles the majority of queries and only escalates to the cloud when confidence is low. Today we look at a third pattern: Chain of Agents (CoA), introduced in the paper “Chain of Agents: Large Language Models Collaborating on Long-Context Tasks” by Wang et al. (2024). Where the previous patterns were primarily motivated by cost, CoA is motivated by a different challenge - what happens when your document is simply too long to fit into any model’s context window?

Some years (wow, time flies!) ago I wrote a quantum computing book titled “Introduction to Quantum Computing with Q# and QDK” (I guess it’s difficult to miss too, since its cover still sits in the sidebar of this blog…). Even though a ton of things have changed in QDK since than, I have been maintaining the source code throughout the years - most importantly, porting everything to QDK 1.0.

Today I would like to share yet another update: the samples are now also available as Jupyter notebooks.

As AI agents become more common in .NET applications, the question of how to keep them safe and well-behaved keeps coming up. Prompt injection, PII leakage, topic drift, tool call abuse - these are all problems that every team building with agents ends up having to deal with, often by hand-rolling ad-hoc checks. Python developers have had libraries like NeMo Guardrails and Guardrails AI to help with this for a while now, but the .NET side has been largely left to fend for itself.

Today I would like to introduce AgentGuard, a library I have been working on to fill that gap - composable, declarative guardrails and safety controls for .NET AI agents.

Over the last few years, I have dedicated a lot of space on this blog to the topic of Post-Quantum Cryptography (PQC). Today, we will peek into the TLS 1.3 handshake.

While hybrid mode TLS is the pragmatic choice for today’s internet, understanding how to construct a fully quantum-safe connection is critical for preparing for the deprecation of classical algorithms.

In this post, we are going to explore a “pure” PQC TLS stack: Post-Quantum Key Exchange, with Post-Quantum Authentication. We will configure an ASP.NET Core application running on Linux to use ML-DSA-65 for authentication and ML-KEM-768 for key exchange.

Recently, I dedicated quite a lot of room on this blog to the topic of running Phi locally. This time, I want to focus on a different aspect of adopting small language models like Phi - fine-tuning them. I already covered local fine-tuning in the past, so today we are going to do this with Azure Machine Learning (Azure ML).

Azure ML is a comprehensive cloud service for accelerating and managing the machine learning project lifecycle. While local fine-tuning is great, moving to Azure ML makes a lot of sense when you need to scale, and/or when you want to experience the Nvidia GPUs without investing in hardware.

We are going to do LoRA fine-tuning of a Phi-4 model, and then deploy it to a managed batch endpoint for inference.

Following the initial introduction of (Maybe) LibOQS.NET a few months ago, the post-quantum cryptography landscape has continued to move rapidly. To keep pace with these developments, the library has undergone significant updates to provide broader algorithm support and deeper integration with the underlying native tooling.

Today marks the release of version 0.3.0, a major milestone that brings the wrapper up to date with liboqs 0.15.0. This release is more than just a version bump; it exposes pretty much all of the liboqs algorithms to .NET developers and adds support for signature context strings, as well as the ability to perform deterministic (derandomized) KEM operations.

In the world of quantum computing, generating true randomness is one of the most fundamental applications. But how do we know that a sequence of numbers is truly random and generated by a quantum process, rather than by a classical simulation or a pre-determined list?

In this post, we will explore a protocol to generate high-quality random numbers using a quantum computer, based on the recent paper Certified randomness amplification by dynamically probing remote random quantum states (Liu et al, arXiv:2511.03686, 2025). We will implement the core of this protocol using Q# for the quantum kernel and Python for the orchestration and verification, and then run it on a Q# simulator.