This went out first to Arcane Scrolls subscribers.

A new choice of castle gate

Microsoft shipped a new choice of castle gate this week. The AI Gateway tier of Azure API Management entered public preview on 27 July: a fully managed gateway in front of models from Microsoft Foundry, AWS Bedrock, Google Vertex AI, OpenAI and Anthropic, plus federated MCP servers and more than 1,400 connector-backed tools. Policies are JSON rather than policy XML, so you can manage them as code and enforce them fleet-wide with Azure Policy. Azure AI Content Safety and token quotas attach per asset, and token metrics come out on OpenTelemetry conventions, so cost attribution and anomaly detection across five providers finally run off the same telemetry.

The governance gain is real. Provider keys leave application code entirely; the gateway holds backend credentials and supports API key, OAuth client credentials, managed identity and mTLS.

Runtime access keys are gateway-scoped, though: one key reaches every model and every tool behind the gate. A skeleton key to the kingdom. Issue one key per application and environment, and grant least privilege deliberately, because the platform does not do it for you yet. Developers can take the OAuth 2.0 route instead. The preview covers two regions, East US 2 and Sweden Central, with no published pricing. Pilot it now, but put nothing regulated behind it this quarter.

The quieter item: check your token cache keys

The quieter item requires more thought. Microsoft published its case for Toolboxes, now GA in Foundry, with a potential failure mode within ‘hand-rolled’ on-behalf-of authentication: a mis-partitioned token cache. Get the cache key wrong and one user’s downstream API access leaks to another user, or another tenant, silently. No error. No log line. A reportable incident waiting in code that looks like it works. If you have hand-rolled delegation anywhere, check this week that every token cache key includes both user and tenant. Highest severity-per-effort fix on the board.

Defaults that write the session down

The Agent Framework Harness shipped in Python and .NET on 22 July, and the default settings have a good security story: tool approval gates, chat history persisted after every individual model call, OpenTelemetry built in. Agents built on it produce an auditable, replayable record by construction - the DM asking “are you sure?” before the barbarian pulls the lever, with the whole session written down. One survey this year put over half of production agents at zero security oversight or logging. Defaults are how that number moves.

Before you upgrade, read the list of features that have been gated. Background agents, file access, automatic looping and shell tooling all sit behind opt-in warnings. Experiment today but hold off on production until the warning labels come off.

Two dates for the diary

One deadline for the diary: Foundry retires visual Workflows on 1 December 2026. The designer goes; exported YAML definitions keep running as hosted agents. Export your YAML now - copy those workflows as if they’re the character sheet from a treasured campaign! Then decide per workflow whether it moves to Agent Framework or Logic Apps. Pro Tip: While you’re looking at this, give the model retirement schedule an owner.

Stability AI image models retire in Foundry on 31 July [today!], and a retired model returns HTTP 410 - Gone, don’t roll a saving throw…

We have a new podcast episode out on Monday 3rd August 2026 with Bruno Lecoq of BEMO - find it on Apple Podcasts, or via securing.quest.

The problem: agents everywhere, governance nowhere

Agents might seem like magic, but most are orchestration loops - a language model receives prompts and tool definitions, selects an action, and returns a structured response. Once you see the loop clearly, there are many places you can track, limit, or audit actions so your agents do what you expect.

The challenge is that many organisations are building agents in more than one place, and with appropriate controls, that’s fine. Those using Copilot Studio or custom GPTs have different needs from those using Microsoft Foundry, and in a multicloud world, agents also live outside the Microsoft ecosystem - perhaps on Google Vertex AI or AWS Bedrock. On top of the agents themselves, there’s the supporting infrastructure - the tools, the MCP servers, and the data sources that agents can access or that get injected as context.

Framing the risks

Two OWASP frameworks help us think about these risks: the LLM Top 10 2025 and the newer Top 10 for Agentic Applications 2026. The LLM Top 10 covers foundational model risks - prompt injection, sensitive information disclosure, supply chain vulnerabilities. The Agentic Top 10 extends this to autonomous systems that plan, delegate, and act across tools and other agents. Together, they give us a shared language for the risks we need to govern.

Four risks thread through everything that follows:

If the core risk is that agents call APIs or use tools that might delete files or update databases in ways you don’t expect - excessive agency (LLM06) in OWASP terms - then you need to govern that traffic. That means a single place to validate agent identity (ASI03), scan for prompt injection, enforce rate limiting to prevent runaway loops or cost spikes (LLM10), and add observability so you can see what’s happening.

Many agents across many systems means heavy traffic and a mix of protocols - including agent-to-agent communication that may lack consistent validation (ASI07). How do we manage all of this and standardise - perhaps even create a single pane of glass for governing it?

Enter Azure API Management

APIM has been the developer workhorse for API governance for years. Its ‘AI Gateway’ capabilities position it as the central hub for your enterprise AI backends, creating a single chokepoint where all agentic traffic converges. It covers three governance surfaces: models (LLM endpoints), tools (MCP servers and function calls), and agents (autonomous identities acting on behalf of users).

Architecture: APIM AI Gateway in the agentic stack

The AI Gateway is a set of capabilities built into APIM - a service that processes 3 trillion requests monthly. It sits between your agents and your backends, providing a consistent governance layer across Foundry model deployments, MCP servers, A2A agent endpoints, data and vector stores, content safety services, monitoring through Application Insights, and third-party LLM providers like Google and Amazon.

If you’re using Microsoft Foundry, the AI Gateway integration auto-provisions a Basic v2 APIM instance with a free tier included (see API Management Pricing for current details). You can configure it in the Foundry portal under Operate > Admin > AI Gateway, with governance surfaces for models (TPM rate limits per project), agents (registration and throttling), and tools (MCP governance and discovery). For production workloads, Standard v2 or Premium v2 is recommended - see the pricing page for costs by tier.

Note - If you already have a ‘traditional’ APIM instance, it won’t be detected in the Foundry Admin portal. You’ll need to create a new one as an AI gateway.

Token rate limiting and cost governance

Maps to: OWASP LLM10 - Unbounded Consumption

APIM gives you two token governance policies - azure-openai-token-limit for Azure OpenAI backends, and llm-token-limit for everything else including third-party models and Azure AI Model Inference. Both let you set tokens-per-minute limits for burst control and token quotas over longer periods for hard budget caps. You can configure these in the Foundry Admin portal or directly as APIM policies.

The feature worth knowing about is estimate-prompt-tokens. APIM can pre-calculate how many tokens a request will consume before it reaches the backend. If it’s over your limit, the request gets rejected at the gateway - no backend tokens consumed, no cost incurred. Pair that with token metrics flowing into Application Insights and you get cost control and visibility from the same layer. When an agent gets stuck in a loop, you’ll see the token spike in your dashboard before it hits your invoice.

Note - Token estimates and actual token emission can still vary.

Prompt shielding and content safety

Maps to: OWASP LLM01 - Prompt Injection, ASI01 - Agent Goal Hijack

APIM integrates with Azure AI Content Safety to moderate prompts at the gateway. Out of the box, it checks four harm categories (hate, sexual, self-harm, violence) with independent severity thresholds. Content that trips a threshold gets a 403 before it ever reaches your model.

The more interesting capability for agentic workloads is prompt shielding. This detects both direct injection (jailbreaks, role-play attacks, encoding tricks) and indirect injection - hidden instructions embedded in documents or web content that the agent processes. That second category is the one that catches people out. Your agent summarises a customer’s PDF and the PDF contains a hidden instruction to exfiltrate data. Prompt shielding catches that at the gateway before the model sees it.

You can also extend scanning to model outputs, giving you bidirectional protection. If the model generates something it shouldn’t, it gets blocked on the way out. Custom blocklists let you add organisation-specific terms on top. You’ll need an Azure AI Content Safety resource, a backend entity in APIM pointing to it, and the APIM managed identity with the Cognitive Services User role - quick to set up if you’re already running APIM.

Semantic caching

Maps to: cost and latency reduction, supports LLM10 mitigation

Semantic caching lets APIM vectorise incoming prompts and check them against previously cached responses in Azure Managed Redis. If someone asks a question that’s semantically close enough to one that’s already been answered, the cached response comes back with no backend call. Cached responses typically return in under 200ms - often more than 10x faster than a full LLM call, and at zero token cost.

The threshold matters here. Microsoft recommends starting strict (0.05) and loosening cautiously - go above 0.2 and you risk returning responses that don’t actually match the question. In practice, stripping system prompts before embedding improves hit rates without sacrificing accuracy, since the system prompt is usually identical across requests and just adds noise to the similarity comparison.

One infrastructure note: you need Azure Managed Redis with the RediSearch module enabled at creation time. It can’t be added later, so plan for it upfront.

Governing MCP tools

Maps to: OWASP LLM06 - Excessive Agency, ASI02 - Tool Misuse

APIM’s MCP server support (currently in preview) works in two ways. You can expose any existing REST API as an MCP server directly from the portal - APIM wraps it and generates the MCP endpoint, no custom MCP code required. Or you can proxy external MCP servers built with any framework, applying the same authentication, rate limiting, and content safety policies to all proxied traffic. Either way, your agents get tools through a governed pipe.

The governance layer is where this gets practical. Agents never hold backend tokens directly - APIM manages OAuth credentials on their behalf. JWT validation, rate limiting, IP filtering, and audit logging all apply at the gateway. Azure API Center (mcp.azure.com) acts as your enterprise MCP registry, so you can configure it as a private registry for VS Code agent mode and GitHub Copilot. That means you control which tools your agents can even discover, not just which ones they can call.

The remote-mcp-apim-functions-python sample is a good starting point - it implements the MCP Authorisation specification with OAuth 2.0/PKCE via Entra ID.

Agent identity with Microsoft Entra Agent ID

Maps to: OWASP ASI03 - Identity and Privilege Abuse, ASI10 - Rogue Agents

If agents are acting autonomously across your systems, they need identities you can govern. The instinct is to reuse existing app registrations or service principals, but agents aren’t traditional applications - they make decisions, delegate to other agents, and act on behalf of users. Microsoft Entra Agent ID (currently in preview) treats them as what they are: a distinct identity type.

The model is built around accountability. You define blueprints for each agent type, then create agent identities from those blueprints with unique IDs and limited permissions by default. Every agent has a sponsor - a human user who’s accountable for it. If that person leaves the organisation, sponsorship transfers to their manager automatically. No orphaned agents silently running with nobody responsible. The Agent Registry gives you centralised visibility across all deployed agents, including those outside the Microsoft ecosystem.

APIM plugs into this directly. You can authenticate agents at the gateway, enforce per-agent rate limits, and apply conditional access policies before anything hits your backends. Agents can’t sign in to Entra ID sign-in pages, can’t join dynamic groups, and tokens are bounded within the agent’s tenant - so if an agent identity is compromised, the blast radius is contained by design.

This is the practical answer to two of the OWASP risks we flagged earlier. Limited-by-default permissions and sponsor accountability address the credential scoping gaps in ASI03. The centralised registry and tenant-bounded tokens give you the visibility to catch rogue agents (ASI10) before they drift.

OWASP risk mapping

The following table shows how APIM’s AI Gateway capabilities map to the two OWASP frameworks. APIM is transport-layer governance - the chokepoint where you enforce auth, rate limiting, content safety, and observability. It does that well. But it doesn’t inspect function-calling payloads, doesn’t orchestrate agent workflows, and has limited reach into model-level risks like data poisoning or embedding weaknesses. You still need complementary controls at the model, application, and data layers. APIM is a strong foundation, not the whole house.

Getting the policy order right

When you combine all these controls into a single APIM policy, the sequence matters - requests that fail early never reach later stages, which protects both your backends and your budget.

Think of inbound processing as a series of gates, where each one reduces what hits the next. Authenticate first - unauthenticated requests never reach content safety. Content safety comes second - a prompt injection caught here never burns your rate limit tokens. Cache lookup sits before rate limiting, so a cached response doesn’t count against your quota. Then rate limiting, emit metrics, routing, and finally backend auth using managed identity. By the time a request actually reaches your backend, it’s authenticated, safe, within quota, logged, and routed - in that order.

The AI-Gateway labs repo includes a complete annotated production policy template you can use as a starting point.

Getting started

Everything described in this post is deployable via Bicep. If you’re using agentic coding tools like Claude Code or GitHub Copilot, the Azure CLI is quick and scriptable for iterating. But from an IaC perspective, you’ll want proper templates. Four repos are worth bookmarking, depending on where you’re starting from.

• Azure-Samples/AI-Gateway - The flagship. 30+ Jupyter notebook labs covering load balancing, rate limiting, auth, MCP, and agentic orchestration. Also includes an enterprise AI Gateway e-Book. Start here if you want to understand the full picture.
• Azure-Samples/apim-genai-gateway-toolkit - Accelerator with an OpenAI API Simulator for cost-free testing and Locust load tests. Demonstrates PTU spillover, request prioritisation, and lowest-latency routing. Start here if you want to test without spending.
• Azure-Samples/apim-lbpool-openai-quickstart - Minimal Bicep quickstart. A Basic v2 instance with two Azure OpenAI backends in a native pool. Start here if you just want to learn the pool feature without the complexity.
• Azure/apim-landing-zone-accelerator - Cloud Adoption Framework-aligned enterprise architecture, including a GenAI Gateway workload scenario with private endpoints and opinionated policies. Available in both Bicep and Terraform. Start here if you’re deploying at enterprise scale.

Conclusion

APIM is already the control plane where models, tools, and agents converge. If you’re already running it, you don’t need new infrastructure - you have new policies to configure. There’s a wealth of other policies and configuration available in APIM that apply to AI and non-AI API’s alike. Give them a go!

The GA capabilities handle transport-level risks today: token limiting, content safety, semantic caching, and backend pools. The preview features - MCP governance, agent identity, and Foundry integration - address the agentic risks that OWASP formalised in December 2025 and are being hardened for regulated workloads. Preview features may change before reaching general availability. You’ll still need controls at the model, application, and data layers, but starting with auth, rate limiting, content safety, and observability will take you a long way - extending your existing AppSec investment rather than replacing it.

Get started with the AI-Gateway labs, use the production policy template and Bicep templates to codify your governance baseline, and build from there. Josh and Chris will also be at Scottish Summit 2026 running a workshop on APIM and AI Gateways in multi-cloud scenarios if you want hands-on support.

Appendix: Feature maturity

Preview features are subject to change and may have different terms of use. The table below reflects status as of February 2026.

While there are specific vulnerabilities and attacks related to applications built with AI - including language models both large (LLMs) and small (SLMs), as well as multi-modal models suitable for audio, video and images - the development of Agentic Systems and more traditional machine learning approaches demands we think of security for AI as additive, rather than security in a parallel universe. What has been done before should be reviewed, not removed.

Machine-learning isn’t new, and neither are the concepts surrounding AI systems. What is new is the significantly reduced barriers to implementing the latest AI technologies within the systems we are building today. If we think of security for AI as additive, have you already applied best practices to the systems you’ve deployed?

For example, API management - is your MCP server gated? Without this, your identity and authentication may all be for naught whilst an adversary makes calls to your APIs without ever seeing your login page, potentially exfiltrating data and significantly increasing your cloud spend.

All this said, AI Applications are still new applications. What’s more, through both AI code generation and the demand for AI agents, there are more and more ‘apps’ than ever.

The most secure AI applications will implement a multidisciplinary approach, as with many aspects of AI, particularly those more novel elements of a modern AI application. As noted by Microsoft and OpenAI ahead of the launch of GPT-5 family of models, the team was made up of not only AI and Security teams, but numerous lines of business, bringing the consumers of AI products closer to the notion of secure & responsible AI.

AI Applications as Applications

AI - Artificial Intelligence - is generally used to refer to the ability for computers to take on tasks that previously only humans could do. Over time, other definitions have appeared, like “Artificial General Intelligence” or AGI, for computers to think like we do - or even in ways that are superior to us.

The reality today is that AI systems are composite applications - complex webs of code that bring together data, automation, and business logic. Some forms of AI might be simple call and response tasks, and others might use goal-seeking logic to form agents, or webs of agents.

Getting more specific, these composite applications can include open-source libraries, closed source logic, or calls out to managed services, including data ingestion pipelines, machine learning model training and storage, inference endpoints to run models, or feedback and retraining loops. On top of that, we still have traditional user interfaces including the web, desktop / mobile applications, or digital conversational channels like SMS or WhatsApp.

If we can agree that AI (today, at least) is implemented as a composite application, then we can look at existing standards for application security. ISO/IEC 27034 describes three pillars of application security.

Translating AppSec Principles to AI

If you have a set of baseline controls for your Secure Software Development Lifecycle, particularly if you’ve been using them for a while, you should absolutely start with that!

What you may find is that the controls can broadly remain the same, but the focus will shift. Looking for a good place to start? You may see the data and information protection more heavily weighted than many apps, as well as your logging, monitoring & auditing controls, and API management.

You’ll find some scenarios where the control is the same, but the implementation is completely new. For example, Input Validation is hugely important to AI apps, for much the same reasons, but the way you implement it must change or in many cases expand. From writing regular expressions for a field, to creating prompt shields to filter content in a brave new fuzzy world and defining whether this takes place before a model has a chance to review the user input, or after.

Let’s explore the other controls you may be familiar with and what they translate into in your AI Application:

Of course, all of this depends on the details of your solution, and who is consuming your solution.

The AI-Specific Amplifiers

So, if AI is additive, once we have extended and applied traditional AppSec approaches, what are those AI-specific amplifiers we need to consider?

New primitives are required for complex AI applications that weren’t required in older application architectures - including agent identity, prompt inspection at runtime, and policy-driven tool access.

This is because we have new risk dimensions. When you use a closed-source model, or an open model where only model weights are provided, you have a potential risk of data poisoning; has the model been trained to respond erratically to certain prompts, potentially allowing attackers to exfiltrate data, and other forms of adversarial manipulation.

We also have to consider how our systems may inadvertently replicate or introduce bias or produce unfair outcomes; not just at development, but over time as data the system processes continues to increase.

Importantly though, whilst these specific challenges are new, each can be mapped back to existing AppSec control categories, such as validation, confidentiality, integrity, and accountability.

How might we implement these controls to our AI Application - particularly when developing on Foundry?

As Microsoft MVPs, we will focus our examples assuming you’re developing on Microsoft Foundry, but these controls are applicable to all the major hyperscalers.

Design

Foundry Models and Model Leaderboards - Meet Secure by Design controls with up-to-date benchmarking from Microsoft. With the ‘Safety’ scoring, review attack success rates against each model.

GitHub MCP Server - MCP Servers are usually associated with security risk, not mitigation, but the GitHub MCP Server is accessible from most development platforms, including Azure AI Foundry. Leverage GitHub Advanced Security features including examining security findings, review Dependabot alerts, analyse code patterns, and get codebase insights.

Build

Grounding reduces hallucinations and improves response quality, impacting the data validation control. Ground models on enterprise data with Foundry IQ & Azure AI Search and for anything else, consider grounding with Bing Search to verify data on the web.

Secure Storage and Access to enterprise storage data via Azure Key Vault with Azure Storage, and even synthetic data generation via Microsoft Foundry, helping control data poisoning and the inappropriate use of personal or confidential data.

Evaluations across Agents, Models and Datasets on Microsoft Foundry, including AI Red Teaming agent & the open source PyRIT framework.

Implement Microsoft Foundry Guardrails via both prompt & response filters for a variety of undesired content, such as direct/indirect prompt injection PII leakage, custom blocklists of prohibited phrases, and potential intellectual property violations.

Identity and Access Management - Each Foundry project comes with a Managed Identity allowing for Entra ID integration natively. Need more depth? Govern at the agent level and create Entra Agent Identities and leverage integration with Agent 365. Just don’t take a key-based AI application into production.

Run

Integrate Foundry with the power of Microsoft Defender for AI Services, the wider Defender for Cloud family for AI app security posture management and workload protection, surfacing alerts and violations into Defender for Cloud & Sentinel. Integrate Microsoft Purview to implement wide-reaching Data Loss Prevention policies and govern AI access to documents and files. Integrate Microsoft Foundry Evaluations into CI/CD pipelines on Azure DevOps or GitHub Actions, to enable continuous evaluations each time you ship.

Operational Reality: Embedding in DevSecOps / MLOps

You don’t rebuild your pipeline - you augment it with AI-specific security controls at the appropriate stages. MLOps isn’t a separate discipline - it’s DevSecOps extended with model and data artefacts.

The “Extra Layer” Philosophy

Focusing on this “Extra Layer” philosophy, traditional CI/CD gates (code quality, vulnerability scanning, dependency checks) remain mandatory. What’s added is a new set of artefacts to be secured, across the stages of build and run.

Most of the time, you’ll likely be using an off the shelf model from a third party; sometimes you will be fine-tuning that model further for your use case. For this reason, we’ll talk about Model Refinement - encompassing model selection & context engineering, custom training, and fine-tuning.

Pre-Model Refinement

Add new AI artefacts to your pipeline, tracking either model versions used or model weights used; training datasets; prompt templates; and MCP Server configurations. Version control and signing apply equally to models as they do to container images. Just as you scan dependencies with Dependabot, you must verify model provenance and scan training data for injection attacks. For example, Microsoft partners with HiddenLayer to scan models deployed through Azure AI Foundry. CodeQL scans for vulnerabilities; Copilot Autofix suggests remediation.

Post-Model Refinement

Security validation intensifies after model selection or fine-tuning - this is where theoretical vulnerabilities can become practical attack vectors. Three critical security checks define this stage: training data scanning, model signature verification, and MCP server validation.

Data scanning - After selecting a model, or fine-tuning, it’s important to review for prompt injection attacks beyond simple pattern matching. Modern injection techniques embed subtle manipulations within seemingly legitimate training examples - customer service datasets might contain hidden instructions to reveal sensitive data when triggered by specific phrases.

Model Verification - At each stage, each model artefact requires a complete chain of custody. Verify that deployed weights match exactly what your training pipeline produced, confirm no backdoors were injected during storage or transfer, and validate behaviour aligns with previously tested specifications.

MCP Server Supply Chain - You wouldn’t upload your core systems of record to other random API endpoints, and an MCP server is no different. If you don’t control the underlying system, then you don’t ultimately know how the data you submit is being used. Consider swapping out PII for token substitutions, and re-inserting PII after processing. These servers bridge models to external tools and data, so use the same supply chain scrutiny you’d use for critical dependencies: verify server implementation authenticity, ask how vendors you might rely on manage their own software supply chain, and ensure configurations haven’t been modified to redirect queries to malicious endpoints. A single compromised MCP server can cascade through your entire AI system. Regular audits must validate not just the servers but their communication patterns - confirming authorised connections only and preventing data leakage through side channels.

Pre-Deployment

Adversarial testing must systematically attempt to break your AI system before real attackers can. Run red team exercises targeting prompt injections, jailbreak attempts, and context manipulation attacks. Validate that AI Content Safety policies work under pressure, not just ideal conditions. Stress test every endpoint with malformed inputs, oversized payloads, and extraction attempts.

Model Consistency validates that updated models maintain predictable behaviour across versions. As models evolve, identical inputs can produce different outputs, breaking downstream dependencies. Implement automated validation comparing new versions against baseline responses. When drift exceeds thresholds, trigger automated rollback or flag for human intervention to adjust prompts and context. Track response quality metrics, semantic similarity scores, and edge case handling. Some providers deprecate older models, forcing prompt adjustment rather than rollback - your consistency framework must accommodate both scenarios.

API Gating - Your API management layer must gate all model endpoints without exception - a single unprotected endpoint can compromise everything.

Test the model. Validate behaviour. Secure the endpoints.

Deployment and Runtime

Prompt Protection - Runtime protection requires active defence mechanisms that respond to threats as they occur. In Azure, Prompt Shield acts as your first line of defence, analysing incoming requests and blocking injection attempts before they reach your model. This real-time filtering catches both obvious attacks and sophisticated attempts that use encoding tricks or context manipulation.

Security as Code - Apply the same infrastructure-as-code rigour you apply to cloud resources. Define your AI security configurations in version-controlled files, treating them like Terraform modules with full change tracking and approval workflows. When incidents occur, you can roll back problematic changes instantly. More importantly, you can replicate security configurations across environments, ensuring development, staging, and production maintain consistent protection levels.

Runtime Operations - DevSecOps principles extend to runtime AI operations through three key mechanisms. First, runtime-to-code traceability connects production incidents directly to source code - when Prompt Shield detects injection attempts, tools like AI Foundry Control Plane trigger alerts in the GitHub repository containing the vulnerable template, enabling rapid fixes. Second, agent identity requires new security primitives, whether just-in-time access tokens or first-class identity systems like Microsoft Entra Agent ID. Third, agent governance demands centralised registries (using open-source indexes or Agent 365) to track every agent with API access, enforce unique identities, log all actions, and require human verification for destructive operations like deletions or significant data modifications. This prevents shadow AI agents just as you prevent shadow IT.

It’s all DevSecOps

AI-specific monitoring extends traditional approaches, and these techniques allow you to track model drift, prompt injection attempts, data exfiltration patterns, and unexpected tool usage.

Measure AI-specific KPIs: prompt rejection rate, model version consistency, MCP server authentication failures, agent policy violations - but integrate telemetry into existing SIEM/SOAR platforms - don’t create separate dashboards.

Convergence, Not Reinvention

So, where can you take this from here? Our suggestion is to integrate AI controls into and extend your Application Security Posture Management (ASPM) to include the idiosyncrasies that the rapid development of new AI protocols and architectural patterns are introducing. Your AI Security Roadmap starts on Monday!

“The future of AI assurance isn’t a new branch of security - it’s the next version of AppSec, compiled for machine learning.”

For example, ASPM will need to include your upgrade approach for language models (LLMs or SLMs) that your organisation relies upon. Will upgrades to those models cause the same inputs to give the same expected outputs?

How about your Model Context Protocol (MCP) servers? Do you know the underlying software supply chain for those MCPs? Are they hosted by actors that you trust now, and will continue to trust for the future? Can your MCPs exfiltrate confidential data, from API keys to financial reporting?

Where does your data come from for your AI systems? Is the data both up to date, and is it free of potential prompt injections, or malicious/sloppy instructions that could cause a vulnerability or an outbound network connection?

These are taking traditional areas of ASPM such as application data privacy and compliance, application misconfiguration management, or an inventory of applications - and extending them to be fit for purpose in today’s world. We suggest you measure your maturity and then introduce new controls to account for this additional threat surface. Failing to adapt to AI isn’t an option - not because the technology is magical, but because your employees will otherwise engage in using Shadow AI, such as ChatGPT or Claude on their own mobile phone. Work to enable people, and security will follow. Block, and the castle will fall.

How can you get started?

Remember: Your existing security team already has 80% of the skills needed. The remaining 20% is understanding how AI changes the threat surface - not learning entirely new disciplines. Start where you are, use what you have, do what you can.

Leverage your cloud provider’s AI security tools; and inventory all AI touchpoints in your organisation - including shadow AI usage through personal accounts.

Review your ISO27034 implementation as-is, and review where AI specific controls, such as those we’ve described, can be applied.

More information

Here’s a downloadable cheat sheet you can use to review the latest ISO27034 controls you might want to apply on the Microsoft stack, and a downloadable framework for implementing ISO27034 and OWASP Top10 LLM to your Microsoft AI Application.

Welcome, traveller. You’ve entered the Library – the heart of Securing the Realm, where we chronicle our adventures across cybersecurity, Azure, and AI.

What Awaits Inside

Among these shelves you’ll uncover:

• Technical Deep Dives – explorations of Azure, AI models, and secure architectures
• Quest Chronicles – stories from real-world projects and the battles fought along the way
• Spell Books – hands-on guides and tutorials to sharpen your craft
• Arcane Knowledge – insights into the technologies shaping tomorrow’s defences

Why We Write

Securing the Realm began with a simple idea: learning should feel like an adventure. By blending fantasy storytelling with technical precision, we make complex topics accessible and memorable – a map through the ever-shifting lands of digital transformation and security.

Whether you’re reforging cloud defences, taming AI agents, or building trust in your kingdom’s data, this Library is your guide.

Join the Quest

Return often. The story grows with each chapter.

• Visit the Tower for talks and videos
• Explore the Forge for open-source creations
• Subscribe to Arcane Scrolls for updates from the Realm

The gates are open. The torches are lit. Adventure awaits. 🏰✨