What an AI Security Gate Should Check in 2026

The first half of this article covered how the buying decision is actually made: the five stages, the three evaluation layers, and the residency traps sitting in vendor documentation. This half covers what the gate should be checking for, and why a gate designed in 2024 now checks for the wrong things.

Every external factual claim carries an inline reference to a primary source. A note on verification method, and a list of the claims that could not be confirmed, appears at the end.

Part 6. The threat model the assurance market does not cover#

None of the certificates above tell you whether the system will be manipulated through its own inputs. For that you need the threat-side artefacts, which cost nothing and require no vendor cooperation.

OWASP, 2026 editions#

The GenAI Security Project published a 2026 edition of the LLM Top 10 on 3 August 2026, describing it as developed by hundreds of AI security experts with research grounded in thousands of real-world AI security incidents, and mapped to NIST, MITRE ATLAS, CWE and the OWASP Top 10 for Agentic Applications.

The methodology shift is the part worth acting on: this is the first edition to blend practitioner voting with empirical incident data, which pushed categories with high real-world frequency up the list relative to expert perception. Two categories that moved up, excessive agency and unbounded consumption, are consequences of agentic deployment rather than model behaviour as such.

I am deliberately not reproducing the numbered 2026 list here. Secondary coverage disagrees on the ordering of items four through ten, and I could not extract the authoritative list from the OWASP landing page. The category names are stable across sources; if you need ranks, read the source report.

Separately, the Top 10 for Agentic Applications 2026 was published in December 2025 by the project’s Agentic Security Initiative, covering goal hijacking, tool misuse, identity and privilege abuse, agentic supply chain, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. If you assess agents against the LLM Top 10 alone, you miss most of that list.

MITRE ATLAS, and why it got much more useful#

ATLAS is the ATT&CK-equivalent knowledge base for adversary behaviour against AI systems. Its public release history shows the pace: a lateral-movement tactic, technique-maturity grading, agent-focused techniques covering service API abuse, sandbox evasion and credential harvesting, and case studies covering MCP server exploitation, all added across late 2025 and 2026.

The change with the most direct procurement relevance is the May 2026 structural overhaul, which tags techniques by platform, predictive AI, generative AI, agentic AI, enterprise. You can now scope an ATLAS-based threat model to the class of system a vendor is selling and hand them a filtered technique list rather than the whole matrix. That turns ATLAS from a research reference into something you can attach to an RFP.

The honest caveat, from NIST#

NIST’s adversarial machine learning taxonomy contains the sentence that should govern expectations: there are no information-theoretic security proofs for the widely used ML algorithms in modern AI systems, and available mitigations are empirical and limited in nature, adopted because they appear to work in practice rather than because they provide guarantees (NIST AI 100-2e2025).

That is a reason to design for containment rather than prevention, and to be sceptical of any vendor claiming their filter solves prompt injection.

What NIST has and has not shipped#

Final and citable: AI RMF 1.0 (January 2023), the Generative AI Profile, AI 600-1 (July 2024), and AI 100-2e2025 (March 2025).

Not shipped: the announced AI RMF revision, for which no draft has been published; and the control overlays for securing AI systems, where the COSAiS project page shows only an August 2025 concept paper and a January 2026 annotated outline for the predictive-AI use case, explicitly framed as a discussion draft feeding a future initial public draft. No overlay, including the planned single-agent and multi-agent overlays, has been released even as a formal draft. The Cyber AI Profile (IR 8596) exists as a preliminary draft from December 2025.

So when a vendor says their AI controls are “NIST-aligned,” the only security-specific NIST artefact available to align to is a taxonomy of attacks. The control overlays are not there yet.

Part 7. The supply chain nobody inspected#

Model artefacts are executable dependencies with weaker inspection than any other dependency class in the estate.

Serialisation is code execution#

Pickle deserialisation executes opcodes as they are read, which is why truncated and corrupted files defeat static scanners: the payload runs before the parse fails. Researchers documented malicious models carrying reverse shells on a major public hub in early 2024 (JFrog), and in early 2025 a technique storing models with non-standard compression so the loader would still process them while the scanner could not parse them (ReversingLabs).

Scanners are themselves attack surface: four CVEs in the widely used pickle scanner were disclosed in March 2025, covering static-analysis bypass, extension-based detection gaps, and ZIP-metadata manipulations that crash or evade the scanner while leaving the file loadable. The hub’s own documentation is direct about the limits, stating that pickle scanning is not foolproof and that safety determination remains the user’s responsibility (Hugging Face, pickle security).

“Safe” formats are not automatically safe. The Keras chain: arbitrary code execution via model loading, then a bypass of that fix reusing internal library functions (CVE-2025-8747), then a separate issue where safe mode is silently ignored for legacy file formats (CVE-2025-9905). Three CVEs against a mechanism whose purpose was to be the safe path.

Safetensors does remove the code-execution vector, an independent audit found no critical flaw leading to arbitrary code execution, but not architectural backdoors, poisoned weights or behavioural compromise. That hub scanning has since added detection for architectural backdoors in saved model graphs is evidence the threat class survives the format change (Hugging Face, six months of model scanning).

Namespace reuse: dependency confusion, for models#

Deleting an account on a public hub frees the Author/ModelName namespace for re-registration. Researchers demonstrated end-to-end remote code execution against two major cloud AI model catalogues by re-registering orphaned namespaces, and found large numbers of public repositories hard-coding vulnerable references (Unit 42).

The mitigation is unglamorous and effective: pin by commit hash rather than tag or bare name, clone approved models into an internal registry, and treat model references as dependencies subject to policy, including references buried in default arguments.

Signing exists; verification largely does not#

Sigstore’s model-signing reached v1.0 in April 2025, and the OpenSSF Model Signing (OMS) specification defines a detached signature carrying a manifest of every model file by hash, supporting bare keys, X.509 chains, keyless flows and hardware security modules. NVIDIA signs its published models on its own hub using OMS.

The gap is on the demand side: the largest public hub’s security documentation covers malware, pickle and secrets scanning, tokens, 2FA and commit signing, but not native model-signature verification. Signing is available; verification is out-of-band and publisher-by-publisher.

AI-BOM has the same shape of gap. CycloneDX supports ML-BOM and AIBOM as distinct inventory types, and SPDX 3.0 defines an AI profile with a rich property set. Both are mature as specifications. But the SPDX AI properties are oriented to transparency, ethics and energy consumption; there is no signature, no hash manifest and no cryptographic parent-model pointer. The integrity layer is model signing, not the bill of materials, and verifying fine-tune lineage remains unsolved, because signing signs files, not ancestry.

Open weights: the risk concentrates in the long tail#

The scale data is instructive: a major hub’s spring 2026 ecosystem report describes millions of public models against an extremely skewed download distribution, a small head of heavily used models and a very long tail with minimal usage, alongside a falling industry-affiliated share of downloads and a rising share from independent developers.

Two things catch enterprises out. Licence risk is a contract-lifecycle problem, not a one-time review: community licences are not OSI open source, impose attribution and derivative-naming obligations that propagate, set monthly-active-user thresholds above which a separate licence must be requested, and, critically, incorporate acceptable use policies by reference, so the restriction set can change without the licence text changing (Llama licence; Gemma terms).

And behavioural safety varies enormously between open-weight models, with multi-turn as the gap: a black-box assessment of eight open-weight models found multi-turn jailbreak success rates far above single-turn, with the largest gaps in models from capability-prioritising labs and flatter profiles in safety-tuned ones (Cisco AI Defense; preprint). If your evaluation suite is single-turn, it is measuring the wrong thing.

Part 8. Retrieval: every query is an implicit access request#

That framing comes from AWS’s AI Security Framework, and it is the right mental model. The moment you put retrieval in front of a model, you have built a second authorization system, and it is usually weaker than the one beside it.

The canonical risk list is OWASP’s vector and embedding weaknesses category: unauthorized access and leakage through insufficiently controlled embeddings; cross-context leakage where multiple user classes share a vector database; embedding inversion, where source text is recovered from stored embeddings; poisoning; and behaviour alteration through retrieval. Prescribed mitigations are permission-aware vector stores, strict logical partitioning, trusted-source validation, immutable retrieval logs and classification-driven tagging.

What the platforms deliver is thinner than most architects assume.

Azure AI Search. Security filters are generally available, but they are a technique rather than a service feature: the application resolves identity itself. The three richer mechanisms (POSIX-like ACL and RBAC scopes, Purview sensitivity labels, and SharePoint ACL inheritance) are all preview, under the 2026-05-01-preview API. And the documentation states the limitation plainly: permission changes in the source system “are only reflected in search results after that metadata is synchronized to the index through the source-specific mechanism, for example, a subsequent indexer run, a push-API update, or a Purview-driven refresh.” SharePoint permissions inherited from a parent scope require an explicit resync (Microsoft Learn, document-level access overview). A revoked permission is not a revoked retrieval until the index catches up.

Bedrock Knowledge Bases. Multi-tenant isolation is achieved through storage hierarchy plus metadata tags and query-time metadata filters, and AWS states that developers must implement the filtering in application code, warning that failure to enforce appropriate metadata-based filtering could result in unauthorized access to sensitive documents (AWS, multi-tenancy in RAG applications). Filtering is not automatically enforced.

Microsoft 365 Copilot enforces that it can only reference content the user is authorized to access, requires specific usage rights where encryption applies, and inherits the highest-priority sensitivity label from source material (Microsoft Learn, architecture, data protection and auditing).

The contrast is instructive. One platform enforces access control inside the retrieval service at query time, with a synchronisation-lag caveat and much of it in preview. Another pushes enforcement up into application code with an explicit warning about the consequences of getting it wrong. Neither is a permission-inheritance guarantee. Both are the customer’s problem on every query path.

This is why “we inherit the permissions of the source system” is a claim to test rather than accept. The usual failure is not malice, it is an index built once with a service account that had broad read access, and never reconciled again.

Part 9. Agents, and why they lengthen every assessment#

The protocol matured faster than the ecosystem#

The Model Context Protocol’s authorization model has hardened substantially. In the current revision, 2026-07-28, the authorization specification requires that MCP servers “MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728)” and clients “MUST use” it for authorization server discovery; that clients “MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707,” with the resource parameter required in both authorization and token requests, identifying the target server by canonical URI, and sent “regardless of whether authorization servers support it”; that servers “MUST validate that access tokens were issued specifically for them as the intended audience,” “MUST only accept tokens that are valid for use with their own resources,” and “MUST NOT accept or transit any other tokens.” Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, and issuer validation per RFC 9207 is required of clients, with the specification noting that a future revision is expected to upgrade server inclusion of iss from SHOULD to MUST.

That is a serious authorization specification. The structural caveat is in the same document: “Authorization is OPTIONAL for MCP implementations.” HTTP transports SHOULD conform; STDIO transports SHOULD NOT follow the specification and instead retrieve credentials from the environment.

So the protocol has closed most protocol-level holes. Nearly every incident in the public record is an implementation or ecosystem failure, with the STDIO transport question as the contested exception.

The public incident record#

The documented attack classes are enumerated in the OWASP MCP Security Cheat Sheet: tool poisoning through malicious instructions hidden in tool descriptions, parameter schemas or return values; rug pulls where a server alters tool definitions after approval; tool shadowing, where one server’s poisoned description changes how the agent uses another trusted server’s tools; confused deputy, where the server executes with its own broad privileges rather than the requesting user’s; data exfiltration through legitimate-looking tool calls; sandbox escapes; supply chain compromise of server packages; and message tampering or replay.

The CVE record from 2025 into 2026 covers most of that list in practice, including unauthenticated remote code execution in developer tooling, command injection through an attacker-controlled authorization endpoint in a widely downloaded proxy package, sandbox escape and symlink bypass in a reference filesystem server, cross-tenant data exposure in a commercial integration, a trojanised package that silently copied outbound email to an attacker, and path traversal in a hosting platform that leaked infrastructure credentials (compiled timeline with CVE references).

The most consequential disclosure for a buyer came in April 2026, when researchers published a cluster of CVEs arising from unsafe defaults in the standard I/O transport, where configuration flows directly to command execution, affecting widely used agent frameworks and IDE integrations, and the vendor position was reported as treating the behaviour as expected rather than a design flaw (The Hacker News). That judgement aside, its practical meaning for a deployer is unambiguous: the risk is permanently yours to manage.

Ecosystem-scale exposure counts circulate for MCP, numbers of publicly accessible unauthenticated servers, and of vulnerable instances. The ones I found trace to a single research organisation; attribute them if you use them, and do not treat them as independently established.

Identity is the actual bottleneck#

Authentication for agents is close to solved; delegation is the open problem. Workload identity is mature (SPIFFE/SPIRE); token binding exists (DPoP, RFC 9449); one-hop delegation is workable through OAuth token exchange with actor claims; revocation has a mechanism (CAEP); portable credentials have a foundation in W3C decentralised identifiers and verifiable credentials.

Multi-hop delegation has nothing production-grade. When agent A invokes agent B which calls tool C on behalf of human D, there is no widely deployed way to carry, constrain and verify that chain of authority, which is the shape of every interesting agentic architecture.

Standards work is underway. The OpenID Foundation’s AuthZEN working group approved two drafts in June 2026: a profile for MCP tool authorization, and an Access Request and Approval Profile that treats “policy cannot yet authorize this action because approvals, consent, attestations or delegated authority are outstanding” as a first-class protocol state rather than an error (OpenID Foundation). CSA has published an agentic IAM approach built on decentralised identifiers, just-in-time task-scoped credentials and an agent naming service (CSA).

Be precise about status when citing these. The agent-identity work at the IETF consists of individual Internet-Drafts without working-group adoption, not standards, and not yet working-group items.

Human-in-the-loop is a control with a well-documented failure mode#

Every agentic design review lands on the same mitigation: put a human in the loop for consequential actions. The evidence on how that fails is better than the AI industry’s own literature suggests, because the human-factors work predates AI.

The EDPS TechDispatch #2/2025 on human oversight of automated decision-making (23 September 2025) catalogues the failure modes: automation bias; “quasi-automation,” where a decision-support system effectively makes the decision despite nominal human approval; operators lacking meaningful authority to override; interface design that limits timely intervention; inadequate training and cognitive overload; and organisational misalignment where operators prioritise throughput over fairness.

The most counterintuitive finding deserves quoting: “When clinicians were provided with incorrect ML recommendations accompanied by explanations that were limited yet easily interpretable, there was a significant decrease in treatment selection accuracy.” Explainability, deployed naively, can make oversight worse.

Its countermeasures are organisational rather than technical: stable working conditions and sufficient review time, training on system limitations, interpretable systems and clear interfaces, and, the one most often skipped, auditing and strategic sampling to verify that oversight is actually happening, alongside the four-eyes principle and “institutionalised distrust” frameworks that assume reviewers will err.

This connects to the supply chain story. Agent CLI tools ship flags that disable approval prompts, and in a 2025 npm supply chain compromise the malware’s novel step was to invoke already-installed AI CLI tools with exactly those flags to enumerate and steal filesystem contents (Wiz analysis). Those flags exist because approval fatigue is real. Attackers found them faster than governance did.

The design patterns that actually contain the problem#

The most useful applied research here is Design Patterns for Securing LLM Agents against Prompt Injections. Its core principle: once an agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger consequential actions. Its six patterns, action-selector, plan-then-execute, LLM map-reduce, dual LLM, code-then-execute and context-minimisation, are all ways of ensuring the component that sees untrusted data is not the component that holds authority. The paper is also candid that a model-level fix is not coming, noting that designing models inherently resistant to attacks that elicit arbitrary outputs is extremely challenging, and that adversarial examples in computer vision remain open after more than a decade.

Microsoft’s published posture says the same thing in vendor language, prevention through hardened system prompts and spotlighting of untrusted text, detection through classifier-based Prompt Shields, and impact mitigation through data governance and human approval for consequential operations, followed by the admission that even with the best current mechanisms, some injections may evade these defences, which is precisely why the architecture must ensure success does not translate into impact (Microsoft MSRC).

Part 10. Five incidents that should change what your gate asks#

Assessment questions are best derived from things that actually happened.

Zero-click exfiltration from a productivity assistant (2025). A vulnerability in a major enterprise AI assistant allowed instructions hidden in ordinary content to trigger data exfiltration with no user interaction, using a returned reference whose URL carried data out on load; it was fixed server-side (CVE-2025-32711 write-up). Gate question: when your product renders model output, what can that output cause the client to fetch?

Server-side exfiltration from a research agent (2025). Indirect prompt injection hidden in email HTML caused a deep-research agent to exfiltrate data, with the exfiltration occurring inside the provider’s cloud, leaving no trace on the user’s machine and bypassing endpoint controls, and generalising across the agent’s connectors (The Hacker News; The Record). Gate question: where does the agent’s egress originate, and which of the buyer’s controls can see it?

The first reported AI-orchestrated espionage campaign (2025). A model vendor’s own published investigation described a state-linked actor using an agentic coding tool across reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting and exfiltration, with the AI executing the large majority of tactical operations and humans intervening at escalation points, and guardrails bypassed through role-play in which operators claimed to be conducting authorised penetration testing (Anthropic report). Gate question: what does your abuse detection do when the attacker’s cover story is a legitimate security use case?

A build-system compromise that weaponised installed AI tooling (2025). A CI misconfiguration allowed code injection through a crafted pull request title, leading to a stolen publishing token and trojanised packages; the malware then invoked AI CLI tools already present on developer machines, with approval prompts disabled, to enumerate and exfiltrate secrets (Wiz; The Hacker News). Gate question: which AI tools are installed on your engineers’ machines, with what standing authority?

An autonomous agent breaching a major AI platform’s production estate (July 2026). Per the platform’s own disclosure, the intrusion “started where AI platforms are uniquely exposed: the data-processing pipeline”, a malicious dataset exploiting “two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration)”, and escalated through code execution on processing workers, node-level access, credential harvesting and lateral movement into multiple internal clusters. It was, in the platform’s words, “driven, end to end, by an autonomous AI agent system,” executing “many thousands of individual actions across a swarm of short-lived sandboxes” with more than 17,000 recorded events over a weekend. Access reached “a limited set of internal datasets and to several credentials used by our services”; there was no evidence of tampering with public models, datasets or Spaces, and the software supply chain was verified clean (Hugging Face disclosure). Gate question: is your data-ingestion path treated as an execution surface, and can your detection correlate thousands of individually low-value events?

A note on that last one: earlier commentary attributed the agent to a specific vendor’s internal capability evaluation and described a different initial vector. The platform’s own disclosure does not identify the operator, and I have described only what the primary disclosure states.

Part 11. What you still build yourself#

The single most useful thing a buyer can tell a vendor: after selection, the vendor supplies the model and a set of primitives. The enterprise around it is the buyer’s to build, and it is the larger share of the work.

The gateway. A single enforcement point that every application calls instead of calling a provider. It owns identity mapping, data-loss prevention, quota, routing and telemetry. It is also why a vendor can be swapped in weeks rather than quarters, because model selection becomes a routing decision instead of an application change. It costs latency, and it becomes a tier-zero service the day it goes live, which means multi-region availability work that was probably not in the original budget.

Organisation-specific data controls. Generic sensitive-data detection is table stakes and insufficient. The hard cases are internal identifier formats, cross-turn leakage where the sensitive value appeared two messages ago, and false positives on legitimate business language. These rule sets grow monotonically and become a maintenance burden nobody owns by default.

Injection and jailbreak detection. Vendor filters are largely opaque and produce a score you cannot interrogate. Layering your own helps and does not solve it, which is the explicit position of both Microsoft’s MSRC and NIST’s taxonomy. Treat it as a control that reduces risk, and design so that a successful injection does not reach authority.

Identity and model access brokering. Mapping enterprise groups to permitted models, enforcing per-team consumption limits, brokering keys. The failure modes are unglamorous: policy sprawl as teams multiply, race conditions in distributed quota checks, and the discovery that key revocation is not graceful unless it was designed to be.

Model intake. The layer most organisations are missing entirely: an internal registry, hash-pinned references (Unit 42’s mitigation), mandatory safe serialisation formats, signature verification where a publisher provides one, licence and acceptable-use review with a re-review trigger, and an independent behavioural red-team before approval.

Logging that supports forensics. Security operations needs to see enough to detect exfiltration; privacy obligations say sensitive data should not sit in general-purpose logs. The workable answer is two streams: redacted telemetry for monitoring, and a separately encrypted break-glass store for investigation. Agreement takes longer with privacy and legal than the build takes with engineering.

Agent tool governance. Platforms increasingly offer tool allowlisting and approval hooks, but the governance content is yours: which tools are high risk, which require human approval, how tool arguments are validated against injection, how agent memory is isolated, and how you avoid handing an agent the requesting human’s full permission set, the last being explicitly recommended against in AWS’s framework, which argues for scoped least-privilege agent credentials instead.

Evaluation. No vendor evaluation suite substitutes for one built on your own data and failure definitions, wired into the release process so a model upgrade cannot ship if quality regresses. Its weakness is staleness. And per the open-weight research, if your suite is single-turn it understates your exposure substantially.

Part 12. What vendors give you after selection, and where they stop#

This part is observation rather than documented fact, and should be read that way.

The pre-sales and deployment phase is generous. Providers field strong technical teams for large accounts, and their character differs: some are infrastructure-led and will help you build reference architecture; some are research-led, small, and will pair with you on prompting, evaluation design and safety tuning. The consistent pattern is that these engagements are time-boxed, and the drop-off afterwards is real.

What continues: model deprecation notices, cost optimisation advice, roadmap briefings, and a support relationship whose responsiveness tracks your spend tier. What does not: embedded engineering. When a model version changes and your prompts regress, that is your problem. When you have an injection incident, you run the forensics.

Plan for it explicitly. The operating model you need in month twelve is not the one you had in month two, and the knowledge from the embedded phase evaporates unless somebody is made responsible for writing it down before the team leaves.

Part 13. Production is where decisions get revisited#

The decision does not end at selection. In production, it gets paused, moved and reassigned, rarely for reasons about model quality:

A control assumption turns out wrong under real traffic: most often data crossing a boundary the design said it would not, which, given the residency and tenancy subtleties covered in the first half, is the most common single cause.
Operational economics shift. At volume, cost and log-retention behaviour start to dominate.
The evaluation suite did not represent production. Documents were longer, messier or differently structured than the test set.
A workload moves toward dedicated capacity and predictable tail latency, because a customer-facing experience has an SLA that on-demand capacity cannot reliably meet. Sometimes that means accepting a weaker control posture on a lower-sensitivity workload and compensating elsewhere, a legitimate risk decision made explicitly, not a lapse.

Which is why no single provider wins everything, and why third-party concentration risk policy would not permit it even if one could. Multi-model is not indecision. It is the design, and the gateway is what makes it affordable.

Part 14. Where isolation is heading#

This is the one area where the technical ceiling is rising rather than the paperwork thickening.

Confidential computing for AI is real at the infrastructure layer and thin at the managed-service layer. Confidential VMs pairing CPU trusted execution environments with GPU confidential computing are generally available on Azure with NVIDIA H100, and NVIDIA documents confidential computing across its recent GPU architectures with a remote attestation service. Google has shipped open-source prompt encryption SDKs establishing attested sessions for end-to-end encryption of prompts and responses during inference, alongside third-party attestation verification for its confidential compute environment.

Confidential managed model inference is largely still preview: Azure’s AI confidential inferencing remains a preview offering, so an enterprise wanting attested inference today generally runs its own model inside a confidential VM rather than consuming a managed endpoint.

AWS takes a different posture, stating that “there is no mechanism for any AWS operator to access an Amazon EC2 instance based on the Nitro System or to access data that customers send to a machine learning (ML) accelerator or GPU,” and offering attested isolated enclaves (AWS confidential computing). That is a design claim about operator access backed by the platform architecture, rather than a customer-verifiable hardware attestation of a GPU trusted execution environment. Both postures are defensible; they are not the same claim, and an assessment should not treat them as interchangeable.

The benchmark for what “verifiable” can mean is Apple’s published architecture: stateless computation with cryptographic erasure, no privileged runtime access, non-targetability, and verifiable transparency through an append-only log of production code measurements with images published for inspection (Private Cloud Compute). In mid-2026 that architecture was extended to run on third-party cloud infrastructure, combining GPU confidential computing, CPU trusted execution, a hardware ledger for supply-chain integrity and dual roots of trust from independent vendors.

Whatever you think of the vendor, that is the standard: attested confidential inference as a published, third-party-inspectable architecture that survives running on someone else’s hardware. It is the existence proof that “trust us” is not the only available answer.

Part 15. The short version#

For buyers. Separate kill gates from scored controls from compensable gaps, and be explicit about which is which. Read vendor documentation at higher resolution than your questionnaire, residency, tenancy and retention are configuration flags, not product properties. Treat model artefacts as executable dependencies with an intake process. Assume prompt injection succeeds and design so success does not reach authority. And recognise that your assurance artefacts do not cover the model layer; you are closing that gap yourself whether or not you have admitted it.

For vendors. You are not scored on an average. You are checked against a small number of disqualifiers, then assessed on how cheaply the buyer can operate you, then asked what you cannot do. Honesty at the third step is worth more than polish at the first. Bring a security architect to the architecture call, not the third call. And know that your real competitor is the platform the buyer already approved.

For everyone. Re-check the assumptions. Several architectural constraints that shaped 2024’s decisions are no longer constraints; several differentiators people still route on have become table stakes; the regulatory deadlines most compliance decks cite have moved by binding instrument; and the threat model has expanded from “the model says something wrong” to “the model acts on something hostile.”

Verification note#

Every external factual claim above carries an inline link to the source it rests on. Sources were selected in this order of preference: the primary document itself (regulation text, standards body, vendor documentation, the affected organisation’s own disclosure), then reputable secondary analysis where a primary source is paywalled or unreachable.

I re-verified the following directly against primary sources, quoting where the exact wording matters: Regulation (EU) 2026/1744 title, date and entry into force; the current MCP protocol revision and the normative authorization requirements, including that authorization is OPTIONAL; the Bedrock cross-region inference residency wording; the Azure AI Search GA-versus-preview split and the index-synchronisation limitation; NIST COSAiS publication status; the EDPS TechDispatch failure modes and the finding on explanations and overreliance; OpenAI’s data-controls page; and the Hugging Face July 2026 incident disclosure.

Claims I could not fully verify, and how I handled them:

The OWASP 2026 LLM Top 10 ordering. The landing page does not enumerate the list, and secondary coverage disagrees on items four through ten. I removed the numbered list and describe the methodology shift instead.
The Transparency Code of Practice signatory count. Reported in secondary coverage; I could not find a Commission register. Flagged inline as indicative.
MCP ecosystem exposure counts. Single-origin research. Flagged inline and attributed.
The July 2026 platform intrusion. Earlier commentary attributed the agent to a named vendor’s internal evaluation and described a different initial access vector and a longer escalation chain. The platform’s own disclosure does not identify the operator. I rewrote the passage to match the primary disclosure only, and noted the discrepancy.

Product capabilities, standards status and regulatory dates are as of August 2026. This space moves fast enough that anything here should be re-checked against the linked source before being relied on.

Written in a personal capacity. Nothing here represents the views of any employer, and no confidential information, vendor evaluation in progress, or commercial term is disclosed.

I write about AI/ML security and threat modeling, the grounded version, read from the research rather than the marketing. If that’s your thing, subscribe to the newsletter.