DEV Community: With Nate

I Built 5 Minimal MCP Servers for Every Social Platform My AI Fleet Uses

With Nate — Mon, 31 Aug 2026 11:08:29 +0000

My AI fleet posts to five platforms — X, LinkedIn, Meta (Instagram/Facebook), Threads, and Dev.to. When I went looking for how to wire that up, I expected to build something from scratch. Instead I found a genuinely crowded market: Socialync covers eight platforms in one server, Publora covers eight more, SocialPilot and Buffer both ship their own multi-platform MCP stacks. The "do everything in one server" pattern is already the commercial default.

I didn't do that. I built five separate, minimal servers — one per platform — and I want to explain why, because it wasn't about being first. It was about a trade-off I kept hitting once agents started actually using these tools in production.

What "minimal" bought me

Each server does one platform's real API, nothing else. No unified abstraction layer pretending X and LinkedIn work the same way (they don't). No shared auth store across platforms I don't fully trust with each other's tokens. When X's OAuth2 flow needed token rotation logic, that lived in exactly one file, touched by exactly one server, with a blast radius of one platform if I got it wrong.

The alternative — a single mega-server proxying eight platforms — means one dependency update, one auth bug, or one rate-limit misconfiguration can take down posting across everything at once. For a one-person studio running an agent fleet unattended, that's not a hypothetical: an agent that can't tell the difference between "X is down" and "my auth layer broke" burns hours I don't have.

The platform-specific gotchas that justified separate servers

X (Twitter): OAuth2 with token rotation — refresh tokens expire and need to be re-issued correctly or every subsequent call silently fails. Isolating this in its own server meant one clear failure surface instead of a shared auth module that has to reason about five providers' different expiry semantics at once.

Meta (Instagram/Facebook): scope gotchas that don't show up until runtime — a token that works for page posts can fail silently for Instagram publishing if the scope wasn't requested up front. Debugging that inside a generalized server means guessing which platform's scope model you're actually looking at. In a single-platform server, the scope requirements are the entire file.

LinkedIn: the UGC post API has a real processing delay between submission and the post actually going live — long enough that a naive "post and confirm" loop returns before the post exists. That's a LinkedIn-specific quirk with no equivalent on X or Threads; baking a wait/retry pattern for it into a shared posting abstraction is exactly how those abstractions get bloated and fragile.

Dev.to: the API's own publish-state gate — everything created through it lands as a draft, full stop, no argument flips it live. That's a deliberate safety property I want preserved exactly as-is, not smoothed over by a generic "publish" method that has to special-case it anyway.

Threads: newest of the five APIs I integrated, still evolving faster than the others. Keeping it isolated meant I could iterate on it without touching four other working integrations.

Every one of those is a reason a shared abstraction gets complicated fast. Multiply by five platforms and the "unified" server either becomes a pile of platform-specific branches wearing one interface, or it flattens the differences and breaks in ways that are hard to debug because you don't know which platform's assumptions just got violated.

What minimal did NOT save me

I'll be honest about the cost: five servers means five things to keep running, five sets of credentials to rotate, five codebases (small as they are) to keep in sync with each provider's API changes. If you're integrating one or two platforms, a single server is probably still the right call — this only paid off because I had five and they diverged enough to matter.

It's also worth saying plainly: if you just need "post to everywhere" and don't care about isolating failure domains, the commercial multi-platform options (Postiz is the strongest open-source one I've seen mentioned; Ayrshare if you want a developer-facing API) will get you there faster than building anything yourself.

Where this leaves me

None of the five servers is trying to be a product — they're internal infrastructure for a fleet of agents that need to reliably post without me babysitting auth tokens across platforms that don't agree on how auth should work. The architectural bet was: keep the blast radius of any one platform's weirdness contained to that platform's own server, and accept the operational overhead of running five small things instead of one big one.

If you're building agent tooling that touches more than two or three platforms with genuinely different APIs, that trade-off is worth thinking through before you reach for the all-in-one server — even though, as it turns out, most of the market already has.

This post was written with AI assistance as part of an active AI agent workflow — the fleet described here is real and running.

If you found this article helpful or informative, please consider supporting us by visiting our creative sister brand, With Nate on Etsy.

The April 2026 Cyber Essentials Change That Will Auto-Fail Your Audit

With Nate — Mon, 31 Aug 2026 11:07:22 +0000

On 27 April 2026, Cyber Essentials moved to version 3.3 of the Requirements for IT Infrastructure — question set codenamed "Danzell." If you've passed Cyber Essentials before under the old marking scheme, read this before your next renewal. The five core controls haven't changed. What changed is how strictly they're marked — and several things that used to cost you points now fail the audit outright.

Nothing new to build. Your existing setup can now auto-fail.

That's the part worth sitting with. This isn't "here are three new controls to implement." It's "the same five controls you already have are now marked with zero tolerance in specific places." If your organisation currently scrapes through on a technicality, Danzell is designed to catch exactly that.

The changes that actually bite

MFA becomes strictly mandatory, everywhere it's available. Any cloud service where multi-factor authentication exists — free, bundled, or paid tier — now requires it. Not "recommended," not "deduct points if missing." Missing MFA on any in-scope cloud service where the provider offers it is an automatic fail. If you've been treating MFA as something to roll out "eventually" on lower-priority services, this is the deadline that removes the option.

Patching gets a hard 14-day SLA. High-risk and critical updates for operating systems, firmware (routers, firewalls — not just laptops), and applications must be installed within 14 days of release. Miss that window and it's an automatic fail, not a marked-down score. If your patch cadence is "monthly Patch Tuesday plus whatever we get to," check the actual gap between release and install for your critical assets — 14 days is tighter than most SME patch cycles.

Scoping just got a lot less forgiving. The old certification let you write ambiguous exclusions — "untrusted" devices, "user-initiated" processes — and get away with vague language. That's gone. Cloud services can no longer be excluded from scope at all. Any device or network exclusion now needs formal justification plus proof of genuine segregation, not a line in the questionnaire. If your current cert relies on excluding something that isn't actually properly isolated, this is where that gets found.

Certificates require precise legal-entity detail. Full legal name, address, company number. If you operate as a corporate group, separate certificates per entity are now available (for a small fee) rather than one certificate awkwardly covering everyone.

Directors sign a personal declaration for the full 12-month period. This is the real accountability shift. It used to be about confirming controls were in place on audit day. Now a director is putting their name to maintaining compliance for the entire certification period — not a point-in-time snapshot.

Cyber Essentials Plus gets stricter too. Verified self-assessment answers can no longer be altered once the CE+ audit begins. And if patching failures turn up during testing, remediation now has to cover the whole environment, with expanded re-testing — not just fixing the one device the assessor happened to flag.

What to check before your next audit

Audit every cloud service in scope for MFA availability, not just the obvious ones. If a service offers it and you haven't turned it on, that's your most likely auto-fail.
Measure your actual patch-to-install gap for OS, firmware, and application updates on anything in scope. Not your policy — your real numbers.
Review every exclusion in your current scope statement. If it's vague ("untrusted devices") or covers a cloud service, it needs to be rewritten or the device/service needs to come back into scope with real segregation evidence.
Confirm your legal entity details are exact — name, address, company number — especially if you're part of a group structure.
Make sure whoever is signing the director's declaration understands what they're actually committing to — this is no longer a box-ticking signature.

The bottom line

Cyber Essentials hasn't added new hoops to jump through. It's closed the gaps that let organisations pass while quietly not really meeting the five controls it's always asked for. If you're renewing after 27 April 2026, the honest move is to check your MFA coverage and patch timing against the new hard limits now, not the week before your assessment.

I've sourced the specifics of the April 2026 update from IASME (the scheme's own accreditation body) and cross-checked against several independent compliance publishers, but the scheme's own documentation is the definitive source — always verify against current NCSC/IASME guidance before your audit rather than relying solely on this summary.

This post was written with AI assistance. The research behind it draws on publicly available scheme documentation and third-party compliance analysis current as of August 2026.

If you found this article helpful or informative, please consider supporting us by visiting our creative sister brand, With Nate on Etsy.

I Couldn't Find a Usable OWASP LLM Checklist for .NET Devs, So I Built One

With Nate — Mon, 31 Aug 2026 11:06:32 +0000

I Couldn't Find a Usable OWASP LLM Checklist for .NET Devs, So I Built One

On August 3, 2026, OWASP published the 2026 edition of the Top 10 for LLM Applications. For the first time in the list's history, 75% of the ranking weight came from real practitioner surveys and 25% from 6,639 documented AI security incidents. The list reshuffled significantly — Excessive Agency jumped from #8 to #3; Improper Output Handling fell from #5 to #10; Unbounded Consumption climbed four places. OWASP renamed System Prompt Leakage to Hidden Context Exposure and broadened its scope to cover everything assembled into a model's context that a user was never meant to see — not just the literal system prompt string.

I went looking for a .NET/C# implementation guide for the new list within about 48 hours of it publishing. I found JavaScript examples, TypeScript examples, Python examples, one good TypeScript runtime library (Arcjet), and Microsoft Learn's OWASP module — which covers the classic web app OWASP Top 10, not the LLM one.

There is, as of today, no .NET/C# implementation checklist for the 2026 OWASP LLM Top 10. I use Semantic Kernel in production for the AI features I build, so I wrote one.

Why This Gap Exists

The generic lists were written for JavaScript first. That makes sense — most of the early LLM app tooling (LangChain, the Vercel AI SDK) is JavaScript/TypeScript, and the public security examples followed that ecosystem.

The .NET ecosystem has Semantic Kernel, which is genuinely excellent. Microsoft built it, it's production-ready, and it has first-class Azure OpenAI integration. But Semantic Kernel's own documentation focuses on capabilities rather than security posture. What you get is "here's how to add a plugin," not "here's how to make sure that plugin can't be triggered by an attacker who controls the prompt."

The result: a community of .NET developers shipping LLM features with solid architectural understanding and weak security implementation — not because they're careless, but because nobody wrote the mapping.

What a Usable Checklist Actually Needs

A checklist that just recites the OWASP category names is not useful. Every article does that.

What I needed was: for each risk, what is the exact thing in a Semantic Kernel application that needs changing, and what does the code look like? Not "validate your inputs" — that's a fortune cookie, not an implementation guide.

Below is my working implementation checklist for the 2026 edition. Verify the current category order and names at genai.owasp.org — OWASP revises the list and a third-party writeup can fall behind. This covers seven of the ten items with code; the official source has mitigations for all ten.

The Checklist

LLM01:2026 — Prompt Injection

What it is: Attacker-controlled text gets interpreted as instructions rather than data, overriding your system prompt. The indirect form — payload planted in a document, an API response, or a retrieved RAG chunk — is harder to catch than a direct chat injection and more common in real incidents.

What to change in .NET: Validate user input before it enters the prompt, and validate retrieved content before it re-enters the context window. Neither check is airtight — treat them as tripwires, not guarantees. The real protection is downstream scoping (see LLM03).

private static bool ContainsInjectionSignals(string input)
{
    var signals = new[] { "ignore previous", "disregard all", "new instructions:" };
    return signals.Any(s => input.Contains(s, StringComparison.OrdinalIgnoreCase));
}

// Before building ChatHistory
if (ContainsInjectionSignals(userMessage))
    throw new SecurityException("Input blocked.");

// After retrieval, before adding to context
if (ContainsInjectionSignals(retrievedChunk))
    throw new SecurityException("Retrieved content blocked.");

LLM02:2026 — Sensitive Information Disclosure

What it is: The model emits PII, secrets, or data from another user's session — memorised from training, leaked through a prompt, or surfaced by a RAG system that didn't enforce tenant isolation.

What to change in .NET: Scrub before the model sees it, and scrub again before the response reaches the client. Also check your application logs — verbatim prompt/response logging is the most common accidental PII storage pattern I've seen in .NET LLM apps.

private static readonly Regex PiiPattern = new(
    @"\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b", // credit card numbers
    RegexOptions.Compiled
);

private static string ScrubPii(string text) =>
    PiiPattern.Replace(text, "[REDACTED]");

// In your completion handler
var safeInput = ScrubPii(userMessage);
var chatHistory = new ChatHistory(systemPrompt);
chatHistory.AddUserMessage(safeInput);

var response = await chatCompletionService.GetChatMessageContentAsync(chatHistory, kernel: kernel);
var safeOutput = ScrubPii(response.Content ?? string.Empty);

For multi-tenant RAG: filter at the retrieval layer, not after. A query that returns another tenant's documents and then scrubs them is still a tenant isolation failure — you've just made it harder to notice.

LLM03:2026 — Excessive Agency

What it is: The model triggers an action — sends email, runs a query, calls an external API — that the user or the current context shouldn't have authorised. This is the biggest mover in the 2026 list, jumping from #8 to #3, and the incident data reflects why: agents with broad tool access cause real damage when manipulated.

What to change in .NET: In Semantic Kernel, only register the plugins this request is actually allowed to use. Scope at registration time, not at invocation time.

var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(deploymentName, endpoint, apiKey)
    .Build();

// Don't import the whole plugin
// kernel.ImportPluginFromType<EmailPlugin>();

// Import only the functions this context is permitted to use
var emailPlugin = KernelPluginFactory.CreateFromType<EmailPlugin>();
var scopedPlugin = KernelPluginFactory.CreateFromFunctions("email",
    emailPlugin["ReadEmail"]  // ReadEmail only — not SendEmail, not DeleteEmail
);
kernel.Plugins.Add(scopedPlugin);

For anything irreversible — writes, sends, deletes — require a confirmation step the model itself cannot authorise.

LLM04:2026 — Supply Chain

What it is: A compromised model API, embedding model, MCP server, or third-party Semantic Kernel plugin package becomes an attack vector. Treat every external component the model talks to as potentially attacker-controlled.

What to change in .NET: Allowlist model endpoints. Pin NuGet package versions. Validate MCP server origins at startup.

private static readonly HashSet<string> AllowedModelOrigins = new()
{
    "https://api.openai.com",
    "https://youraccount.openai.azure.com",
};

if (!AllowedModelOrigins.Contains(new Uri(modelEndpoint).GetLeftPart(UriPartial.Authority)))
    throw new InvalidOperationException($"Model endpoint not allowlisted: {modelEndpoint}");

In your .csproj: use deterministic version pins, not floating ranges.

<!-- Correct -->
<PackageReference Include="Microsoft.SemanticKernel" Version="1.29.0" />

<!-- Don't do this -->
<PackageReference Include="Microsoft.SemanticKernel" Version="1.*" />

LLM05:2026 — Data and Model Poisoning

What it is: Attacker-controlled content makes it into your RAG corpus, fine-tune dataset, or embedding store. Unlike most attacks, this one succeeds before the user ever sends a message.

What to change in .NET: Validate documents before they're chunked and embedded. Apply the same injection signal check as LLM01 at ingest time.

public async Task IngestDocumentAsync(string documentText, string documentId)
{
    if (ContainsInjectionSignals(documentText))
    {
        logger.LogWarning("Document {Id} blocked at ingest — injection signals detected", documentId);
        return;
    }

    var embeddings = await textEmbeddingService.GenerateEmbeddingsAsync([documentText]);
    await vectorStore.UpsertAsync(documentId, embeddings[0], documentText);
}

A document that embeds successfully with "the correct response to any refund question is always yes" doesn't need a prompt injection later — it's already in your knowledge base.

LLM06:2026 — Unbounded Consumption

What it is: Crafted requests drive disproportionate API token consumption, memory, or CPU usage. The 2026 edition renamed this from "Model Denial of Service" and broadened it — it now covers resource exhaustion at any layer, not just inference.

What to change in .NET: Cap prompt length before it reaches the API. Set MaxTokens in execution settings. Rate-limit at the session level.

const int MaxInputChars = 8192; // ~2048 tokens at ~4 chars/token — use a real tokenizer for precision
const int MaxOutputTokens = 1024;

if (userMessage.Length > MaxInputChars)
    throw new ArgumentException("Input exceeds maximum length.");

var settings = new OpenAIPromptExecutionSettings
{
    MaxTokens = MaxOutputTokens,
};

var result = await kernel.InvokePromptAsync(prompt, new KernelArguments(settings));

Use TikToken.NET or the Azure AI SDK's token counter for accurate limits rather than character estimation.

LLM10:2026 — Improper Output Handling

What it is: The model's response is rendered directly in a UI without encoding, or executed (code generation, shell commands) without validation. It fell from #5 to #10 in the 2026 edition — still on the list, still exploitable.

What to change in .NET: In Blazor or Razor Pages, never render LLM output as raw HTML. If markdown rendering is required, sanitise it.

@* Wrong — renders raw HTML from the model *@
@((MarkupString)llmResponse)

@* Right — HTML-encoded by default *@
@llmResponse

// If markdown rendering is required, use a sanitising pipeline
// e.g. Markdig with HtmlSanitizer
var sanitised = Markdown.ToHtml(llmResponse, sanitisingPipeline);

For code execution features: treat LLM output as untrusted. Run generated code in a sandboxed process with restricted permissions — never in-process.

How to Apply This

Don't implement all ten at once. The 2026 incident data shows the real damage concentrating in the top three. Start there.

Tier 1 — before you ship anything:

LLM01: Input validation before prompt construction
LLM02: PII scrubbing on input and output
LLM03: Plugin scope locked to the minimum required

Tier 2 — before you scale:

LLM06: Token caps and session rate limits
LLM10: Output encoding in all UI rendering paths

Tier 3 — as your RAG or agent surface grows:

LLM04: Dependency allowlists and version pinning
LLM05: Ingest-time document validation

The full 2026 list at genai.owasp.org covers all ten items with mitigations — this covers the seven where Semantic Kernel gives you clear, concrete implementation points. If you're building agentic features specifically, the OWASP Top 10 for Agentic Applications (linked from the same project page) covers the multi-agent orchestration risks that the LLM Top 10 doesn't address directly.

This post was researched and drafted with AI assistance. Factual claims about the 2026 OWASP list structure and incident weighting were verified against live sources; verify anything implementation-critical against the official documentation at genai.owasp.org before shipping.

If you found this article helpful or informative, please consider supporting us by visiting our creative sister brand, With Nate on Etsy.

Five Things SMEs Keep Getting Wrong About EU AI Act Article 50

With Nate — Mon, 31 Aug 2026 11:05:44 +0000

Five Things SMEs Keep Getting Wrong About EU AI Act Article 50

August 2, 2026. Article 50 of the EU AI Act went live. The coverage mostly focused on what it means for "AI companies." The coverage mostly missed the small business owner using ChatGPT to write their weekly newsletter, or the e-commerce site with an AI chat widget on the product page.

Article 50 is not a regulation for AI companies. It is a transparency regulation for anyone who deploys AI systems that interact with users, produce synthetic content, or categorise people. That's a wide net, and most SMEs are already inside it.

Here are the five mistakes I see most often.

Mistake 1: Thinking it only applies to AI product companies

Article 50 targets deployers — businesses that put AI systems in front of people. Not the companies that built the models.

If you have a chatbot answering customer questions on your website, you are a deployer. If you use an image generator to create product photos for your shop, you are a deployer. If you use AI to write marketing copy that goes out under your brand, Article 50 is talking to you.

What it requires: Users must be informed they are interacting with an AI system at the point of first interaction. The only carve-out is if it would be "obvious to a reasonable person" — and courts will not stretch that interpretation to cover an AI that you've given a human name and a profile picture.

This applies to tools built on third-party models (GPT, Claude, Gemini) just as much as anything custom-built. You chose to deploy it; the obligation is yours.

What to do: Add a clear, explicit AI disclosure before users interact with any AI-powered interface. Not in the footer. Not in the terms of service. Before the conversation starts.

Mistake 2: Missing the two-track deadline

Most coverage says "August 2026 deadline" and leaves it at that. There are actually two deadlines, and conflating them is a real compliance risk.

Deadline 1 — August 2, 2026: All four Article 50 obligations apply to new AI systems launched from this date. If your chatbot, image generator, or AI personalization feature went live after August 2, full compliance applies now.

Deadline 2 — December 2, 2026: Systems that were already on the market before August 2, 2026 have until December 2, 2026 specifically for the machine-readable marking requirement (see Obligation 2 below). The other obligations — AI interaction disclosure, deepfake disclosure, biometric/emotion recognition disclosure — apply immediately regardless.

The practical implication: if you're publishing AI-generated images or video, and the tool you're using went live before August 2, you have a few more months to implement the technical marking standard. But your chatbot disclosure and deepfake labels can't wait.

What to do: Audit which AI features existed pre-August 2026 and which didn't. Apply the December 2026 deadline only to the machine-readable marking component on pre-existing generative systems — not as a blanket extension.

Mistake 3: Burying the disclosure in your terms of service

This is explicitly addressed in the regulation: notices must be given clearly, separately from other information, at the first point of interaction or exposure. Not in a T&Cs footer. Not in an on-boarding email sent after sign-up. First interaction, clearly labelled.

The EU's own guidance (digital-strategy.ec.europa.eu) is unambiguous on this. A disclosure buried in page 47 of a privacy policy does not satisfy Article 50. The regulation was written specifically to prevent compliance-by-small-print.

This matters particularly for AI-generated content posted publicly — a product image created by AI and posted to your website or social media needs a disclosure that meets this standard, not a vague watermark people won't see.

What to do: Treat AI disclosure the same way you treat cookie consent: it has to be front-facing, at the moment it's relevant, and independently legible from everything else on the page.

Mistake 4: Not realising emotion recognition and biometric categorisation are in scope

Article 50's fourth obligation catches businesses who would never describe what they're doing as "AI" at all.

If you use any system that:

categorises users by emotional signals (sentiment scoring, engagement analysis)
makes inferences about a person's characteristics from their behaviour or biometrics
uses emotion recognition to adjust personalisation or content

...you have an active Article 50 obligation. Users must be informed when these systems are operating on them.

This catches more businesses than it sounds like it would. Behavioural personalization engines, adaptive content systems, customer sentiment scoring dashboards fed by real-time interaction data — these are commonly deployed by SMEs through third-party analytics platforms, often without realising the privacy/AI Act implications.

What to do: Review your third-party analytics, personalization, and customer insight tools. Ask vendors directly whether emotion recognition or biometric categorisation features are active in what you've licensed — and if yes, add the required disclosure.

Mistake 5: Assuming SME fine caps mean the risk is negligible

There is SME relief built into the penalty structure. Fines are capped at whichever is lower: €15 million, or 3% of worldwide annual turnover for that particular category of violation.

That sounds protective. It is, relative to what larger companies face. But 3% of worldwide annual turnover for a mid-sized SME is a real, painful number. "Lower cap than a multinational" does not mean "consequence-free."

There are also reputational and commercial consequences that sit alongside formal fines. If a data protection regulator flags a company for non-compliant AI deployment — particularly on something as visible as a public-facing chatbot — the headline is the damage, not the fine amount.

What to do: Price the actual exposure, not the theoretical maximum. Three percent of your revenue is your real risk ceiling, not zero. Build the compliance checklist around what that number means for your business.

The four Article 50 obligations at a glance

For quick reference, here is what the regulation actually requires:

1. AI interaction disclosure
If a user is interacting with an AI system, tell them — clearly, at first contact, unless it would be "obvious to a reasonable person" that they're talking to AI.

2. Machine-readable synthetic content marking
AI-generated audio, images, and video must carry a machine-readable mark in a standardised, detectable format. Caption-only disclosure does not satisfy this. (Grace period applies for pre-August 2026 systems until December 2, 2026.)

3. Deepfake disclosure
Any artificially generated or manipulated audio, image, or video that depicts real or realistic people must carry a clear, visible disclosure that it is AI-generated or AI-modified. This applies to marketing materials, not just social media content.

4. Emotion recognition and biometric categorisation
People must be informed when these systems are being used on them, at the point of use. Not in a privacy policy: at the point of use.

One open question worth flagging

Multiple sources have noted a possible interaction between Article 50 obligations and EU Digital Omnibus legislation that could affect implementation timelines or scope. I have not verified the full extent of this interaction. If your legal team is advising on Article 50 compliance, specifically ask whether the Digital Omnibus package changes anything before you finalise your compliance posture.

Practical starting point

Run through this checklist:

[ ] Every AI-powered user interface has a clear, front-facing disclosure before first interaction
[ ] AI-generated images and video being published publicly have disclosures that go beyond captions (machine-readable standard needed)
[ ] Deepfake/AI-manipulated content is clearly labelled at point of publication
[ ] Third-party tools have been audited for emotion recognition / biometric categorisation features
[ ] The December 2, 2026 grace period has been correctly scoped to machine-readable marking only — not used as a blanket extension
[ ] Actual fine exposure has been calculated (3% of worldwide turnover) not waved away

This post reflects my understanding of Article 50 as of August 2026. It is not legal advice. Verify against current EU Commission guidance (digital-strategy.ec.europa.eu) and the official regulation text before making compliance decisions. The EU Code of Practice on Transparency is also available as a voluntary compliance framework.

This article was written with AI assistance (Claude). NAS Digital uses AI as part of its content workflow.

n8n + Claude Workflow Market: Who's Winning and Why

With Nate — Mon, 31 Aug 2026 11:04:49 +0000

n8n + Claude Workflow Market: Who's Winning and Why

The 2026 AI workflow automation market ran a feature race for about eighteen months and then essentially called it a draw. As of mid-2026, n8n, Make, and Zapier all support AI agent creation, multi-step Claude pipelines, and RAG integrations. The feature lists look nearly identical.

The race was decided somewhere else. And the answer is less interesting than people expect.

The billing model is the actual differentiator

This is the framing almost everyone skips in favour of feature comparison tables. Per Parseur's August 2026 analysis, the single biggest factor in most n8n-vs-Zapier-vs-Make evaluations has nothing to do with what the tools can do and everything to do with how you pay for it:

Zapier bills per step. Every action in a workflow is a step. Complex, multi-action automation gets expensive fast.
Make bills per module. Similar unit, similar problem at scale.
n8n bills per run. One workflow execution = one unit, regardless of how many steps are inside it.

For workflows that are simple in structure but high in volume, Zapier and Make win on familiarity and ease. For workflows that are complex in structure — multi-step Claude pipelines with branching logic, tool calls, memory lookups, post-processing — the per-run model means n8n's costs scale with workflow count, not workflow complexity. That's a meaningful structural advantage for AI agent work specifically.

This is why n8n keeps winning in technical AI-agent comparisons despite not being the most polished or easiest to use. The economics fit the use case.

What "n8n is winning" actually means

n8n's positioning has consolidated around three specific strengths:

1. Self-hosting. This is a real, non-trivial differentiator — particularly for teams with data residency requirements or who want to run AI pipelines without their workflow data touching a third-party cloud. Zapier and Make are cloud-only. n8n is genuinely deployable on your own infrastructure.

2. Technical depth. Multiple independent 2026 comparison analyses (GoPenAI, Crux Digits, AY Automate) converge on the same summary: n8n offers the deepest technical control for Claude-driven RAG pipelines and complex agent architectures. "Deepest technical control" in this context means: granular error handling, lower-level access to API responses, more flexible data transformation between steps, custom code nodes.

3. Price architecture at scale. Per-run billing above.

Where Zapier and Make retain their edge: speed of setup, breadth of native integrations (Zapier has thousands), and accessibility for non-technical users. For simple automation — "when this happens, do that" — they remain faster and more polished.

The market in 2026 isn't "n8n beats everything." It's "n8n wins on a specific dimension that technical AI-agent builders care a lot about."

The broader field you're not reading about

The big-three framing misses a serious mid-tier that matters for specific use cases:

Activepieces — open-source, self-hostable, growing quickly as a developer-first alternative. Favoured by teams who want n8n's self-hosting model with a cleaner UI.

Pipedream — strong for developers who want code-first workflow building with native Node.js/Python execution. Less visual, more programmable.

Gumloop — emerging as a low-code option specifically optimised for AI agent workflows, where the abstraction is built around LLM calls rather than generic API connectors.

Vellum — focused on LLM operations (LLMOps) rather than general workflow automation; wins for teams where the core problem is managing Claude/GPT prompt versioning, evaluation, and deployment rather than connecting business apps.

Power Automate, Workato, Tray.ai — enterprise tier, typically appear in comparisons where IT governance and enterprise SSO/compliance requirements eliminate the simpler options regardless of technical fit.

The right answer for any given team isn't necessarily in the big three. Activepieces specifically is worth watching — it's picked up n8n's early community energy.

The gap in the market: what nobody's building well

Here's where the data from the July 2026 Gumroad marketplace scan is instructive. The n8n + Claude workflow template market on Gumroad shows a clear split:

Pay-what-you-want (PWYW) tier (anchored £0–£7.88): high volume, mostly simple single-trigger templates with Claude API calls. Commoditised, low-margin, essentially loss leaders.
Mid-tier (£15–£25): theoretically the best margin segment, but real sales volume is unproven. Listed widely, unclear conversion rate.
High end (£97+): rare, and almost exclusively for templates with a real standalone use case (lead qualification agents, autonomous content pipelines) rather than general-purpose integrations.

What's thin across all tiers: opinionated, end-to-end workflow systems built for a specific vertical (not "a generic Claude API integration for n8n" but "a customer support triage system for SaaS teams, including prompt design, escalation logic, and output formatting"). The generic template market is crowded. The vertical-specific playbook market is not.

When to skip visual workflow builders entirely

This is the view that neither the n8n community nor the Zapier ecosystem has obvious incentive to say out loud: for some technical teams building LLM-first products, visual workflow builders are solving the wrong problem.

Our own fleet at NAS Digital runs on OpenClaw + Claude with MCP servers — not n8n or Zapier or Make. The choice wasn't ideological. It was structural: our agents don't follow a workflow graph with edges and nodes. They respond to tasks, call tools, make decisions, pass outputs to other agents. The primitive is an LLM call with tool access, not a step in a visual diagram.

MCP (Model Context Protocol) handles the tool integration. OpenClaw manages the session, scheduling, and agent routing. Claude handles the reasoning. The whole architecture is code and configuration, not a drag-and-drop canvas.

That architecture is genuinely harder to set up than n8n. It is not faster to iterate on visually. But it composes in ways that visual workflow builders struggle with — chaining agents, passing structured outputs between reasoning steps, handling branching based on LLM judgment rather than predetermined conditional logic.

The honest framing: if your automation has enough conditional complexity that you're trying to encode it in a visual workflow graph, ask whether you'd be better served by an LLM making the decisions instead of the graph. Visual workflow builders are excellent at high-volume, low-complexity automation. They become a bottleneck when you're encoding human judgment.

Who's winning and why: the actual answer

n8n wins on technical AI-agent use cases, self-hosting, and per-run pricing economics. The community is real and active. The template ecosystem is growing faster than Zapier/Make for Claude-specific integrations.
Zapier/Make win on ease of use, polished UI, and breadth of native connectors. They've caught up on AI features. They remain the right answer for non-technical teams doing high-volume simple automation.
The emerging alternatives (Activepieces, Gumloop) are worth watching for developer-first teams who want the self-hosting model without n8n's complexity ceiling.
MCP-native agent orchestration is a separate category that the visual-workflow market doesn't yet have a clean answer for — and it's the one that most closely matches how frontier AI applications are actually being built in 2026.

The n8n + Claude ecosystem has real momentum. But "who's winning" depends entirely on what you're building. If you're building workflows for a technical audience with complex AI logic and data sensitivity concerns, n8n's structural advantages are real. If you're automating a linear business process for a non-technical team, Zapier still wins the race.

And if your architecture is fundamentally agent-first rather than workflow-first, you might not need any of them.

This analysis draws from marketplace research conducted in July 2026, independent 2026 comparison analyses (Parseur, Crux Digits, GoPenAI, AY Automate), and NAS Digital's own experience building and running an AI agent fleet. All pricing data was accurate at time of research and may have changed.

Written with AI assistance (Claude). NAS Digital uses AI as part of its content workflow.

Monetizing Developer AI Tools: Distribution Beats Product Quality

With Nate — Mon, 31 Aug 2026 11:03:33 +0000

Monetizing Developer AI Tools: Distribution Beats Product Quality

I spent last month building five minimal MCP servers — one per social platform — for the AI agent fleet running NAS Digital. Each one is 150–300 lines, covers only the endpoints I actually use, and is auditable by hand in 15 minutes. They're in production. Zero bugs in six weeks.

Nobody knows they exist.

That gap between "built something real" and "anyone paying for it" is what this piece is about. The conventional advice is to build something better. The reality, at least for developer tools in 2026, is that distribution matters more than product quality — and most solo developers, myself included, spend our time in exactly the wrong place.

The thesis everyone is already saying

Here's the uncomfortable part: this isn't a contrarian take anymore. Search for "distribution beats product for indie devs" and you'll find the same argument made well by pickaxe.co, gravity.fast, developersmatrix.com, and a dozen others. Pickaxe.co's AI Overview summary puts it directly: "building something genuinely useful is table stakes; distribution is where the leverage actually is."

So if everyone knows this, why are most solo developer tools still invisible at launch?

Because knowing it and understanding what it actually means for a one-person operation are different things. The generic version of "distribution" is useless advice — it just means "be on social media more." The useful version breaks into three distinct layers, and they don't all work the same way or on the same timeline.

Three layers of distribution, and why they're different

Platform distribution is the rarest and most valuable. It means building something that lives inside a platform that carries you — a Gumroad product that shows up in search, a VS Code extension that gets recommended, a Dev.to article that the algorithm surfaces. You don't own the distribution, but you don't have to build it from scratch either. The leverage here is enormous; the catch is you're dependent on someone else's algorithm and discovery mechanisms.

Gravity.fast frames this as the difference between building on a platform versus building for a platform. Building on a platform (like Gumroad's marketplace, or GitHub's trending page) means the platform's existing traffic and recommendation logic works in your favour. Building for a platform — making something that integrates with a tool but doesn't live inside it — means you're doing all the distribution work yourself. The product doesn't carry you; you have to carry the product.

For developer tools specifically, this distinction matters. An MCP server published to a registry that developers are already browsing benefits from platform distribution. The same server documented only on a personal blog does not.

Audience distribution is slower but owned. Newsletter, social following, GitHub stars, Dev.to readership — these are channels you build once and compound over time. Developersmatrix.com's August 2026 analysis of successful solo dev tool monetization is blunt about it: the developers who made real money from their tools almost all had 12–18 months of consistent audience-building before the tool launched. The tool wasn't the start of the story; it was the payoff of an audience that already trusted the builder.

For a one-person operation, that's a hard timeline to sit with. Most solo developers build the tool first, then look up and realise they have no audience. By that point the launch is a broadcast into a room with nobody in it. The 12–18 month number isn't arbitrary — it's roughly how long it takes to build enough trust with enough people that a launch actually lands.

Content distribution is the most accessible and the most misunderstood. It's not "post about your product on Twitter." It's publishing something genuinely useful to the audience you want to reach — an article that explains a real problem, a deep-dive that would have saved you three days of debugging, a walkthrough of a production decision with the actual trade-offs. The product is the proof that you know what you're talking about. The content is how anyone finds you in the first place.

The mechanism matters here. Content distribution works because it gets indexed, it gets shared, and it builds the kind of trust that converts to sales — but only if the content is actually worth reading. Promotional content that disguises itself as educational gets ignored or, worse, damages the trust you're trying to build. The developers whose content distribution works are writing things they would have wanted to read six months ago.

What this looks like in practice

For NAS Digital, the sequencing is deliberate: ship the infrastructure (the MCP servers — platform distribution via Dev.to and GitHub), document the real experience of building and running it (content distribution), and price the tools to optimise for first-week velocity rather than per-unit margin.

On pricing: Gumroad's algorithm weights recent sales velocity heavily in how it surfaces products. A tool priced at £0+ that generates 50 downloads in its first week gets more organic placement than a £29 tool that generates 3. The revenue comes later, when you raise the price after the algorithm has already learned to show it. This only works if your distribution play generates the early velocity — which is why sequencing matters. Content first, platform placement second, audience-building in parallel, price increase once the signal is established.

The trap most solo developers fall into is launching the product and then starting the content work. By then the launch window is gone. The algorithm has learned the wrong signal from low early-velocity sales. The only people who know about the tool are the ones already in your network — which, if you haven't been building an audience, is a small number.

The honest trade-offs

None of this replaces product quality. A tool that doesn't work gets distribution in the wrong direction — negative word of mouth, refunds, and reviews that tank its search placement. The point isn't that quality doesn't matter; it's that quality is necessary but not sufficient. A tool that works and nobody finds is a worse business outcome than a slightly rougher tool that gets in front of the right people.

Distribution-first is also harder than it sounds. Building an audience takes longer than building a product. Writing content that's genuinely useful — not just promotional — requires actually having done the thing you're writing about, not just planned it. And pricing for velocity rather than margin requires enough runway to wait for the price increase to make sense, which not every one-person studio has.

The honest version of "distribution beats quality" for a solo developer is: plan the distribution strategy before you build the product, not after. By the time you launch, the window for first-mover organic placement is already closing. The developers who monetise their tools successfully are the ones who treated distribution as a design constraint from day one — not an afterthought once the thing was built.

Sources: pickaxe.co, gravity.fast, developersmatrix.com (August 2026). This post was written with AI assistance as part of an active AI agent workflow — the fleet described here is real and running.

Level Up Your Game Assets: 40 Characters, Zero Restyling

With Nate — Sun, 26 Jul 2026 02:55:12 +0000

If you've bought a character asset pack before, you know the drill: the art is fine, but the characters don't fit your game. No lore, no stats, no sense of who these people are. You end up inventing all of that yourself, which is the part that actually takes time.

I built the Ultimate Character Collection to ship the documentation alongside the art.

What's actually in it

40 characters across four packs, each with its own setting:

Pack	Setting	Style
Vol.01 — Neon Future	Cyberpunk	Sleek sci-fi
Vol.02 — Old Kingdom	Medieval fantasy	Gothic-anime
Vol.03 — Ten Outlines	Modern urban	Gritty contemporary
Vol.04 — Broken World	Post-apocalyptic	Painterly-anime

Per character:

4 facial expressions (neutral, confident, intense, concerned) — same pose, same outfit, same lighting, only the face changes, so they work as a dialogue UI set
4 portrait sizes: full (307×512), clean (no title overlay, for in-engine UI), 2× HD upscale (614×790), and a bust shot (512×341) for chat heads
Square avatar (512×512)
A stat card (800×1000)

Per pack:

A 14-page Character Bible PDF — lore, stats, weapons, playstyle, and dev notes
Lineup poster (1600×980) and a character-select UI mockup (1600×900)
characters.json — machine-readable, so you can load the roster programmatically
Ren'Py demo scripts with working dialogue you can run immediately
Dominant palette swatches per character
Prompt seed documents, if you want to generate variations in the same style

Why the Bible is the part I'd actually pitch

Art you can find. What's usually missing is the reason behind it — why this character carries that weapon, how they relate to the rest of the roster, what their numbers should look like next to everyone else's.

That's what the Bible covers, and it's why the four packs hold together as one cast rather than 40 unrelated images. If you're building a tactics game or an RPG with a roster, the stat cards and lore give you a starting point to argue with, which is much faster than starting from an empty document.

You can also ignore all of it and just use the art. The documentation is there if you want it.

Who it's for

Indie developers building RPGs, tactics games, visual novels, or anything with a named cast. It's PNG-based, so it drops into Unity, Unreal, Godot, GameMaker, Ren'Py, Twine, RPG Maker MV/MZ, Phaser, LÖVE, Foundry VTT, Roll20, Tabletop Simulator — anything that opens an image. The Ren'Py scripts are the only engine-specific thing in the bundle.

Licence

One purchase covers a solo dev or a full team, for any number of commercial and non-commercial projects. Modify and remix freely. No reselling the originals and no repackaging — full terms in LICENCE.txt.

AI disclosure

These characters were designed and curated by me using AI-assisted illustration tools. Full commercial rights transfer on purchase. If you're reselling work that includes them on a storefront requiring AI disclosure, make that disclosure as their policy requires.

I'm stating it here because the product page states it, and a post sending you to that page shouldn't be vaguer than the page itself.

Get it

Ultimate Character Collection — All 4 Packs — £24.99.

The individual volumes are also available separately (£6.99–£12.99) if you only need one setting.

Made by NAS Digital. More game assets, design templates, and developer tools at nasdigital.co.uk

Semantic Kernel CVE-2026-25592: What You Need to Know

With Nate — Tue, 09 Jun 2026 17:52:56 +0000

Correction (July 2026): an earlier version of this post gave the CVSS score as 10.0 and the disclosure date as 7 May 2026. Both were wrong — the score is 9.9 and the advisory was published on 6 February 2026. That earlier version also described only DownloadFileAsync; the advisory covers UploadFileAsync as well, and the hardening advice below has been corrected accordingly. Apologies to anyone who acted on the original.

Microsoft disclosed CVE-2026-25592, an arbitrary-file-write vulnerability in Semantic Kernel — the .NET framework used to build AI agents and LLM-powered applications. The GitHub Security Advisory (GHSA-2ww3-72rp-wpp4) was published on 6 February 2026 with a CVSS 3.1 base score of 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

If you've upgraded to Semantic Kernel 1.71.0, you've applied Microsoft's official fix. Many teams considered the issue closed at that point.

From a CVE perspective, they're correct.

However, the vulnerability highlights a broader security problem that can still exist in many Semantic Kernel deployments: allowing AI-controlled values to flow into privileged operations without strict validation.

This post explains what CVE-2026-25592 was, how it worked in a real .NET application, why the underlying pattern remains relevant, and what developers should be doing to secure their Semantic Kernel implementations.

Why Semantic Kernel Matters

Semantic Kernel is Microsoft's open-source orchestration framework for integrating Large Language Models into .NET applications. It provides abstractions for prompts, plugins, memory, planning, tool invocation, and agent workflows.

It is increasingly being used to power:

Enterprise customer support systems
AI-assisted business workflow automation
Internal knowledge management platforms
Intelligent data processing pipelines
Agentic applications connected to enterprise systems

The framework works by exposing application functionality to the LLM through "kernel functions" — methods decorated with the [KernelFunction] attribute that the model can invoke when it determines they are needed.

This capability is what makes Semantic Kernel powerful.

It is also what makes mistakes extremely dangerous.

CVE-2026-25592: The Sandbox That Wasn't

The vulnerability centered around the SessionsPythonPlugin component within Semantic Kernel's .NET SDK.

The plugin exists to allow agents to execute Python code inside an Azure Container Apps sandbox. The intended security model is straightforward: code runs inside the isolated environment and cannot directly impact the host system.

The problem was insufficient path validation in two helper methods: DownloadFileAsync and UploadFileAsync. Both were exposed to the LLM through a [KernelFunction] attribute, which turned internal helpers into AI-callable tools — and made their path parameters AI-controlled.

Path traversal sequences (../) or absolute paths could escape the intended directory and reach arbitrary locations writable by the application process.

This is the detail that matters most for remediation: fixing only DownloadFileAsync leaves you exposed. If you wrote your own mitigation based on early write-ups (including the first version of this post), check UploadFileAsync too.

An attacker who can influence any prompt consumed by the agent — a support ticket, uploaded document, SharePoint file, Teams message, RAG source, or direct user interaction — could potentially persuade the model to invoke either function with an attacker-chosen path.

For example, a path pointing at the current user's startup folder:

C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\evil.exe

If a malicious payload is written to a startup directory, the next user login may result in code execution. That escalation from "write a file" to "run code on the host" is why the score is 9.9 rather than something lower — the scope change (S:C) reflects escaping the sandbox boundary.

Affected and fixed versions:

SDK	Vulnerable	Fixed in
.NET (`Microsoft.SemanticKernel.Plugins.Core`)	< 1.71.0	1.71.0
Python	< 1.39.3	1.39.3

The Broader Lesson

Microsoft's fix addresses the specific vulnerability that was reported.

However, the broader lesson extends beyond two methods.

The root problem was allowing AI-generated values to reach privileged operations without appropriate validation.

Although the reported vulnerability has been remediated, developers can unintentionally recreate the same class of issue in custom implementations.

Examples include:

Custom kernel functions that accept file paths
Functions that construct URLs
Database query generation
Command execution wrappers
Reflection-based operations
Network-access plugins
Internal API integrations

If a custom [KernelFunction] accepts AI-controlled input and passes it directly into operating system, database, filesystem, or network operations, the same trust-boundary problem can reappear regardless of Semantic Kernel version.

The important question is not:

"Am I running 1.71.0?"

The important question is:

"Do any of my kernel functions trust values generated by an LLM?"

Hardened Implementation Pattern

The safest approach is to avoid automatic execution of sensitive functions wherever possible.

var executionSettings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.EnableKernelFunctions
    // Avoid AutoInvokeKernelFunctions for privileged operations
};

When functions must accept paths, validate against an allowlist rather than trying to block dangerous values. Note this pattern applies to any path-taking kernel function — upload as well as download.

private static string ResolveWithinAllowedRoot(string requested)
{
    var allowedRoot = Path.GetFullPath("/app/downloads")
        .TrimEnd(Path.DirectorySeparatorChar)
        + Path.DirectorySeparatorChar;

    // GetFileName strips any directory component, so "../../etc/passwd"
    // collapses to "passwd" before it is ever combined with the root.
    var resolved = Path.GetFullPath(
        Path.Combine(allowedRoot, Path.GetFileName(requested)));

    if (!resolved.StartsWith(allowedRoot, StringComparison.Ordinal))
    {
        throw new SecurityException($"Path traversal attempt: {requested}");
    }

    return resolved;
}

[KernelFunction]
public async Task<string> DownloadFileAsync(string localFilePath)
{
    var safePath = ResolveWithinAllowedRoot(localFilePath);
    await using var stream = File.Create(safePath);
    // ... write the downloaded content to stream ...
    return safePath;
}

A note on the comparison: use StringComparison.Ordinal rather than OrdinalIgnoreCase unless you are certain the filesystem is case-insensitive. Getting this wrong on Linux containers can accept paths you meant to reject.

The key principle is simple:

Never trust AI-generated input simply because it originated from your own application.

Audit Every AI-Initiated Action

One of the most effective defensive controls is auditing all AI-triggered function calls.

kernel.FunctionInvocationFilters.Add(new SecurityAuditFilter());

A security-focused invocation filter should:

Log every tool invocation
Capture relevant arguments
Alert on filesystem access
Alert on network operations
Alert on database modifications
Generate audit events for investigation

If you cannot see what your agent is doing, you cannot detect when it has been manipulated.

Human Approval Controls

Many enterprise teams rely on human-in-the-loop controls before allowing agents to perform sensitive actions.

Semantic Kernel includes mechanisms intended to support these workflows. However, developers have reported scenarios where confirmation behaviour did not align with their expectations.

For that reason, organizations with strict approval requirements should consider implementing confirmation logic explicitly at the application layer rather than relying solely on framework-level controls.

public class ConfirmationRequiredFilter : IFunctionInvocationFilter
{
    private readonly IConfirmationService _confirmationService;

    public ConfirmationRequiredFilter(IConfirmationService confirmationService)
        => _confirmationService = confirmationService;

    public async Task OnFunctionInvocationAsync(
        FunctionInvocationContext context,
        Func<FunctionInvocationContext, Task> next)
    {
        var approved = await _confirmationService
            .RequestApprovalAsync(context.Function.Name, context.Arguments);

        if (!approved)
        {
            throw new OperationCanceledException("Human approval denied.");
        }

        await next(context);
    }
}

Immediate Actions for Production Deployments

If you're currently running Semantic Kernel in production:

1. Upgrade

.NET: 1.71.0 or later. Python: 1.39.3 or later.

2. Audit Every Kernel Function

Review every [KernelFunction] implementation and identify:

Filesystem operations (both read and write paths)
Network requests
Database access
Process execution
Reflection usage
Dynamic code generation

Treat all parameters as untrusted input.

3. Disable AutoInvoke for Sensitive Operations

Only allow automatic invocation for low-risk, read-only functions. Require explicit approval for anything that modifies systems or data.

4. Implement Allowlist Validation

Validate paths, URLs, queries, commands, and resource identifiers. Do not rely on blocklists.

5. Run With Least Privilege

Minimal filesystem permissions, restricted network access, limited IAM permissions, regular credential rotation, strong isolation where practical.

6. Monitor for Exploitation Attempts

Look for unexpected tool invocations, unusual filesystem activity, unexpected outbound traffic, and repeated failed function calls followed by success.

7. Review Historical Activity

If vulnerable versions were previously deployed: review audit logs, investigate unusual agent behaviour, check for unauthorized file modifications, and rotate secrets where appropriate.

The Bigger Picture

CVE-2026-25592 highlights a challenge facing every AI framework today.

Developers want agents that can take meaningful action. Security teams want systems that cannot be manipulated. Those goals are often in tension.

Semantic Kernel is not unique here. Similar patterns can emerge in any framework where an LLM is allowed to invoke application functionality. Whenever model-generated output crosses into privileged operations, the trust boundary becomes a security-critical control.

The industry is still learning how to secure these systems properly.

What I'm Looking At Next

These issues are only part of a much larger attack surface. Future research will focus on:

Azure AI Search index poisoning through SharePoint and Teams content
Text-to-SQL injection chains in Azure OpenAI applications
Secure patterns for agentic workflows
Building Roslyn analyzers that detect dangerous Semantic Kernel patterns at compile time

AI agents are becoming increasingly capable. The security controls protecting them need to mature just as quickly.

Until then, treat every AI-generated action as untrusted input and design your systems accordingly.

Sources: GitHub Security Advisory GHSA-2ww3-72rp-wpp4 · GitLab Advisory Database

Working with Semantic Kernel in production? The Semantic Kernel Security Audit Prompt Pack walks through the attack surfaces covered in this series, with 20 ready-to-use audit prompts for the vulnerability classes Microsoft hasn't fully addressed.