The boundary
Shadow AI, a CASB, or your own models: which exposure are you managing?
AI-SPM is not the same problem as every other AI security challenge. Before you scope the work, it helps to be precise about which surface you are actually governing.
01
The tools your teams adopt without telling you
Every enterprise has them: AI writing assistants, code completion tools, document summarisers, research agents, adopted by individual teams without a procurement or security review. These unsanctioned AI tools create a data-leakage surface. The exposure here is primarily about what your people send out, not about what you host.
02
What a CASB sees, and what it does not
A Cloud Access Security Broker sees traffic to third-party SaaS AI applications. It can tell you that someone in your finance team is uploading documents to an external AI service. What it cannot see is the model you fine-tuned on customer data last quarter, the inference endpoint your product team exposed without authentication, or the training dataset sitting in a storage bucket with overly permissive access. That gap, the AI you own and operate, is the subject of this page.
03
The models you deploy yourself
Your own models are the core of AI-SPM. That means every model version running in production, the access rights attached to each inference endpoint, the training data each model consumed and where that data currently lives, and the configuration state of the infrastructure serving it. No third-party vendor maps this for you automatically. It requires deliberate inventory work against your own estate. This is what AI-SPM covers: a documented, ranked, continuously reviewed picture of the AI surface you are responsible for.
The exposure your people create with unsanctioned AI tools your teams adopt is a different problem, with different controls and a different playbook. This page covers the AI you own and operate.
The data sources
What can you actually inventory on Cloudflare?
Six data sources, spread across four Cloudflare product families: AI, application security, Cloudflare One, and log retention. Each one shows a different layer of the estate you already own.
AI Gateway: every model call, logged
AI Gateway sits in front of your model calls and logs the prompt, the model response, the provider, the timestamp, the request status, token usage, cost, duration and the client user agent. That log is the evidence layer of a posture review: without it you are reasoning about your AI surface from memory.
One thing it does not give you on its own is attribution to a named user or service account. That has to be designed into how your applications call the gateway, and it is worth deciding before you need it in an investigation.
Workers AI: inference on Cloudflare's network
Workers AI runs inference on serverless GPUs on Cloudflare's network, from a curated catalogue of open-source models, with private custom models available on request. So the posture question is not where the hardware sits, it is which model version your code invokes, with what configuration, and reachable by whom.
A model wired in for a proof of concept may still be running a version that has since been superseded, with the access rights set for that test.
API Shield: the endpoints your models expose, and which ones lack authentication
Every inference endpoint is an API. API Shield gives you endpoint management and schema validation, so you can catalogue the endpoints sitting in front of your models and see where live traffic diverges from the contract you published.
It also assesses authentication posture: once session identifiers are configured, it scans successful requests daily and labels the endpoints where authentication is missing from all of them, and separately those where some requests carry an identifier and some do not.
For an inventory, that is the answer to the question that matters most, which of your model endpoints are being reached without authentication.
Two conditions apply: the labelling only covers endpoints that return successful responses, so an endpoint answering nothing but errors gets no label, and the feature is available to Enterprise customers with an API Shield subscription.
Zero Trust: who reaches your AI consoles
Model management interfaces, training pipeline dashboards and configuration consoles are high-value targets. Cloudflare Zero Trust controls who can reach them, enforces identity verification before access is granted, and logs every session.
In a posture review this layer tells you whether access to your AI control plane is still restricted to the population it was scoped for, or whether it has drifted since deployment.
Prompt inspection and DLP: what reaches the model
Three layers inspect what moves through your AI applications, and they do not cover the same ground.
AI Security for Apps, built into the WAF, scans incoming prompts on the endpoints you label as LLM endpoints and detects personally identifiable information, prompt injection attempts and unsafe topics.
AI Gateway DLP works in both directions: it inspects the text of request and response bodies as they pass through the gateway, using the same detection profiles as Cloudflare One's DLP, and it can pass, flag or block.
Guardrails screens the same two directions for safety, on the prompt before the model and on the response before it reaches the user.
Two operational points are worth knowing early rather than late: DLP policies are set per gateway with no per-request bypass, and on streaming responses the full response has to arrive before DLP can evaluate it, which costs latency.
Workers Logpush: a trail long enough to audit
Posture management is not a one-time audit. Compliance review, incident investigation and trend analysis all depend on how far back the record goes.
AI Gateway logs export through Workers Logpush, which needs the Workers Paid plan, logging switched on for the gateway, and an RSA key pair: Cloudflare encrypts each log with a per-log key and you decrypt with your private key, so managing that key is part of the retention design rather than an afterthought.
Then compare the window you actually keep against the one your framework expects. Weeks of history against a requirement for months of evidence is a gap, and it is one of the checks in the next section.
Two of these sources reach past the inventory. What the prompts carry and where that content ends up is a data question, treated in training data and prompt content. The web layer in front of an inference endpoint is protected like any other, which is the applications that expose your models.
The regulatory hook
Which obligations put your AI inventory on the hook?
An AI inventory is not optional when regulators ask for documented risk management. Three frameworks are directly relevant to enterprises operating in EMEA and the Gulf.
NIS2
NIS2 imposes risk management obligations on operators of essential and important services. Those obligations include asset documentation, the identification of high-risk systems, and logging requirements sufficient to support incident investigation and regulatory reporting. An AI model processing operational data for a critical service is an asset that belongs in that documentation. If you cannot produce a current inventory of your AI systems and their access controls, you cannot demonstrate NIS2 compliance in a meaningful way.
The EU AI Act
The EU AI Act introduces technical documentation and logging requirements for high-risk AI systems. Operators of high-risk systems must maintain records of the system's design, training data, performance characteristics and access controls. That is an AI inventory requirement by another name.
Gulf and GCC sector frameworks
Sector frameworks across the Gulf place AI governance inside broader operational risk management obligations rather than in a separate regime. For clients operating across EMEA and GCC, the inventory question is rarely optional: it is a matter of when the regulator asks, not whether.
See our NIS2 obligations page for the full operational picture. No section of this page constitutes legal advice. Regulatory obligations vary by sector, jurisdiction and system classification. Engage qualified legal counsel for your specific situation.
Before you sign
What should you check before you call your AI posture managed?
A posture is only as current as its last review. These are the five questions your inventory needs to answer before you can claim your AI surface is under governance.
01
Which models are running in production, and since when
You need a current list of every model version in production, the date it was deployed and the team responsible for it. Models deployed for a proof of concept and never formally decommissioned are a common source of unmanaged exposure. If you cannot produce this list in under an hour, your inventory is not operational.
02
Who can call your inference endpoints
Every inference endpoint has an access control state. The question is whether that state is intentional and current. Service accounts created for a pilot, API keys shared across teams, endpoints left open during a migration: these are the gaps that posture management is designed to surface.
03
What data trained your models, and where it lives
Training data provenance is a posture question as much as a data governance one. If a model was trained on a dataset that included customer PII, that fact needs to be documented, the data's current location needs to be known, and access to it needs to be controlled. Without that documentation, you cannot assess the blast radius of a model compromise.
04
Are your API keys rotated, and how often
A static, long-lived API key is a finding in its own right. Key rotation cadence should be defined, enforced and logged. If your answer to this question is "we rotate them when we remember to", that is a finding.
05
Are your logs retained long enough for an audit
Regulatory frameworks and internal incident response requirements both depend on log retention. If your AI Gateway logs are retained for 30 days but your compliance framework requires 12 months of evidence, there is a gap. Workers Logpush addresses this, but only if it is configured and verified.
Brixio's Metryx tool automates the configuration assessment against your live Cloudflare environment, DNS, TLS, WAF and rule posture, which is the foundation the AI controls above are deployed on. It does not inspect your models, your endpoints or your training data. To see where your current configuration stands, run a Cloudflare configuration audit.
Not sure what your Cloudflare setup actually covers?
Metryx assesses your live Cloudflare configuration against a structured baseline, DNS, TLS, WAF mode and rule posture, and maps each gap to a fix. It measures the foundation your AI controls run on; the model inventory and the posture review run on top of it.
Run an express audit- Free access, no commitment
- Read-only Cloudflare token
- No configuration required
- Downloadable audit report to share internally
- Run as many audits as you want, on as many zones as you want
Your entry point
Where do you start, depending on where you are?
The right entry point depends on the state of your current inventory. Three scenarios cover most of what we see.
01
No inventory at all
The first step is a read-only configuration audit: no changes, no disruption to delivery, just a structured read of what is currently running and what it exposes. This gives you the baseline from which every subsequent posture decision is made. Start with a Cloudflare configuration audit to get that baseline in place.
02
An inventory that is already stale
An inventory that was accurate six months ago and has not been updated since is almost as dangerous as no inventory. Every model deployment, every new integration, every access control change since that last review is an undocumented gap. The fix here is not another one-off audit but an automated review cadence that runs continuously and flags drift as it happens. We configure that cadence as part of our managed posture service.
03
An inventory and controls, but no governance review
Some teams have done the technical work, they have a model list, they have API Shield configured, they have Logpush running, but they have never run a governance review to ask whether the controls in place are appropriate for the risk level of each system. That is a different kind of gap, and it requires a structured workshop rather than a technical audit. Contact us to scope a governance review.
The rollout
How do you roll out AI posture management without freezing delivery?
The four-phase approach below is how we deploy AI-SPM for enterprise clients without disrupting the engineering teams building on AI at the same time.
Phase 1
Read-only inventory
We map everything: models, endpoints, access controls, data paths, log retention state. Nothing is changed in this phase. The output is a structured inventory document and a gap list ranked by exposure level. Engineering teams continue to ship; we observe and record.
Phase 2
Risk ranking
Not every gap is equally urgent. In phase two, we apply a risk ranking to the inventory: which endpoints are publicly reachable without authentication, which models process regulated data, which API keys have not been rotated in over a year. We prioritise by exposure concentration, not by the volume of findings. A single unauthenticated inference endpoint serving a model trained on customer data outranks fifty low-severity configuration notes.
Phase 3
Progressive control enforcement
We close the highest-ranked risks first, validate that each control is working as intended, and move to the next tier. This phase is deliberately staged: no bulk changes, no big-bang enforcement that breaks integrations. Each control is tested in a non-production context before it is applied to production traffic. Engineering teams are informed of each change before it goes live.
Phase 4
Continuous review
Every new model deployment triggers a posture check. Every new inference endpoint is catalogued before it goes to production. Every access control change is logged and reviewed against the baseline. This is the operational state we aim to reach: posture management as a continuous process, not a periodic audit.
Day to day
How does Brixio run AI posture management day to day?
24/7 follow-the-sun coverage
- Our operational model covers EMEA, APAC and GCC time zones without handoff gaps
- A new model deployed at 02:00 in Singapore, or a posture alert firing on a Friday evening in Riyadh, gets the same structured response process
- Coverage is continuous and the escalation path is the same regardless of when an issue surfaces
A named, certified team
- Brixio is an Authorized Cloudflare Service Delivery Partner (ASDP), an authorisation held at company level
- The engineers staffed on each engagement hold individual Cloudflare certifications
- You have a named point of contact
- The engineers who ran your initial posture review are the same engineers who respond to posture alerts and conduct your quarterly reviews
- International-level expertise for clients with complex multi-region deployments, including custom solutions that go beyond native Cloudflare capabilities where the use case requires it
SLA and tuning cadence
- A defined response SLA for posture alerts, with escalation thresholds agreed at onboarding
- Posture reviews run on a cadence agreed in advance
- New model deployments are gated through a posture check before they reach production
- A deployment that does not pass the check does not go live until the gap is documented and either remediated or formally accepted as a risk
Integrated with the rest of the stack
- Model endpoint access sits on the same Zero Trust control plane as your human access policies
- AI Gateway logs are exported to your SIEM through Workers Logpush, with the retention window you need for an audit
- Each new model or integration is reviewed before it reaches production, against the same baseline as the rest
This runs on Brixio's standing security posture
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
certified data handling
450+
delivered projects in regulated industries
4 hubs
Luxembourg · Paris · Dubai · Singapore, follow-the-sun
The umbrella over all of it is AI security with Cloudflare. Talk to an expert to scope this against your own environment.
Where it stops
What AI posture management on Cloudflare does not cover.
Be precise about scope. AI-SPM on Cloudflare addresses the security posture of the AI systems you operate. It does not do the following.
Model quality, bias and hallucination audits
Whether a model produces accurate, fair or reliable outputs is a data science and product function. Posture management tells you whether the model is secured, not whether it is good. These are separate disciplines and should not be conflated.
Replacing a data governance board
Posture management surfaces risk. It does not make policy. Decisions about what data a model may be trained on, what outputs may be shared externally, and what retention rules apply to training datasets require a governance function with organisational authority. We provide the evidence; your governance board makes the decisions.
What happens inside a third-party provider's model
If you call an external model API, OpenAI, Anthropic, Cohere or any other, you cannot inventory what happens inside that provider's infrastructure. You can log what you send and what you receive via AI Gateway. You cannot audit the provider's model weights, training data or access controls. That boundary is fixed.
Unsanctioned tools your teams adopt
If a team member is using an AI tool that was never approved or deployed by your organisation, that is a shadow AI detection problem. It requires a different set of controls, CASB-style traffic inspection and policy enforcement at the identity layer, and a different operational playbook.