A European financial institution signs a data processing agreement that says its identity data stays in the European Union. The agreement is honoured. Then someone reads the network flows and discovers that the analytics layer calls a model endpoint outside the region, that the only supported deployment is the vendor's own cloud, and that nobody can say what happens to identity classification if that endpoint becomes unavailable.
Nothing in that story is a breach. It is the ordinary consequence of buying a product whose data residency was a legal commitment rather than an architectural property.
Where does the data plane run? Not where the tenant is, and not where the console is served from. The question is about the catalogues, the security events, the identity graph and the event store: the data. If those live in one place and the analysis runs in another, your residency is a diagram, not a boundary.
Where does inference run? Identity security now depends on models, and models run somewhere. Either they are served inside your environment, or every classification, verdict and investigation sends data across a boundary. Most vendors do not put this in the deployment guide, and most buyers do not ask, because the contract talks about storage and not about processing.
What happens when there is no accelerator available? A deployment without GPUs is the normal case in regulated environments, and in air-gapped ones it is the only case. Ask whether the product stops, which functions survive, and whether that boundary is documented before the purchase or discovered during the first incident.
The architecture that answers all three is the one where the deployment unit is the whole platform, not a tenant in someone else's cloud. The same set of containerised services runs as a managed service, inside the customer's cloud tenant, on-premises, or in an air-gapped environment, and the data plane travels with it. Catalogues, events, the graph and the event store run where the services run. Per-application database namespaces keep evidence separated by source. Collection follows the deployment, so connectors run next to the data they read rather than pulling it across a network boundary.
This is why the residency question has an architectural answer rather than a contractual one: there is no configuration in which the data sits in one jurisdiction and the analysis in another, because the analysis is a workload in the same cluster.
Most vendor discussions of AI in identity security collapse two very different workloads into one word.
The first is decision-making at scale: is this account a person or a technical identity, does this newly created account conform to a policy that exists as prose rather than as a rule, which band does this subject fall into, is this grant consistent with the purpose of the identity holding it. These are small questions asked millions of times. They are answered by small encoder models trained by the vendor, executed on ordinary processors, producing a calibrated probability rather than an opinion. Nothing about that workload needs an accelerator, which means it keeps working in a datacentre with no GPUs.
The second is generative and agentic reasoning: reconstruct what happened in an incident, correlate signals across sources, explain a verdict, draft a report. That workload needs a large language model, and a large language model needs somewhere to run: inside the cluster on hosts that have accelerators, or at an external provider if policy allows it.
Keeping the tiers apart is what makes a defensible deployment possible. The decisions that run continuously, for every identity, every day, run on hardware you already have. The reasoning that runs occasionally, on a handful of incidents, is the part that needs an accelerator, and it is also the part that can be switched off without losing the security posture of the estate.
External inference, in that model, is an option. Not a requirement, and not a hidden dependency.
The test of a deployment story is what happens at the boundary, so it is worth stating it plainly.
When no inference endpoint is available, collection continues, posture continues, identity visibility continues, behavioural detection continues, and playbook-driven response continues, all on the CPU-resident decision models. Generative investigation is unavailable, and reports fall back to the structured evidence they already hold.
The platform degrades in scope, not in integrity. That sentence is only credible because the boundary is designed and documented rather than discovered at runtime. A vendor that has never described the degraded state has almost certainly never tested it.
The same question applies with more force to autonomous agents, because an agent that reasons over identity data is also an agent that could reach it.
The architecture that holds is the one where agents have no direct access to customer data or customer networks. Each agent runs as an isolated workload inside the platform sandbox, and its only route to data is a declared set of tools exposed by the platform's tool servers, with credentials resolved at call time and never embedded in the agent. An investigation agent can read the evidence store and the graph, because those are its tools, and cannot invoke a response action its definition does not include.
On top of that execution model sit the controls that make autonomy acceptable: a per-agent tool allowlist, hard step budgets, approval or step-up gates for sensitive or irreversible actions according to a configurable autonomy level, the ability to interrupt a running task, reversible actions where the platform owns the capability, and a record of prompts, inputs, tool calls, outputs and resulting actions with the evidence behind each conclusion.
The important property is not the list. It is that the alternative, an agent holding customer credentials or reaching a database directly, is not a configuration option. You either built it that way or you did not.
The platform is a set of containerised services orchestrated by Kubernetes, and the deployment unit is the whole platform rather than a tenant in somebody else's cloud. The same set runs as a managed service, inside the customer's cloud tenant, on-premises or air-gapped, and what travels with it is everything that holds data: catalogues, security events, the identity graph and a purpose-built columnar event store that retains every event with its verbatim payload, in a local hot tier and an object-storage cold tier, with schema evolution by column promotion and point-in-time reconstruction. Per-application database namespaces keep evidence separated by source, and connectors run in the same environment as the systems they read instead of pulling data across a boundary.
Inference is a workload in the same cluster rather than a call to somebody else's endpoint. On hosts with accelerators the serving stack runs inside Kubernetes, so analysis happens where the data is and nothing has to leave the environment. The decision models are the small encoders described earlier: trained in house, executed on processor cores, used for subject classification, for telling a human account from a technical one, and for checking a newly created account against policy that exists as prose. Each produces a typed answer with a calibrated probability, and the value is stored with its confidence and the model that produced it. When the classifier service is unavailable the field stays empty instead of receiving a default, so an inference failure never becomes a fact.
Generative and agentic reasoning uses a large language model served in the same cluster, or called from an external provider where policy allows. Calling out is an option rather than a requirement, and the functions that depend on it are precisely the ones that stop when it is absent.
The agent layer is bounded by construction. Agents hold no direct access to customer data or customer networks. Each runs as a sandboxed workload whose only route to data is a declared set of tools exposed by the platform's tool servers, with credentials resolved at call time and never embedded in the agent. On top of that execution model sit a per-agent tool allowlist, hard step budgets, approval or step-up gates tied to a configurable autonomy level, the ability to interrupt a running task, reversible actions where the platform owns the capability, and a log of prompts, inputs, tool calls, outputs and resulting actions with the evidence behind each conclusion.
Deployment follows the same discipline. The front end is stateless while the stores are stateful, collectors and analytics scale horizontally with volume, and the same microservice set is deployed in every model, which is why a capability demonstrated in one deployment is the same capability in another and not a variant of it.
If the answers are architectural, you will hear them in sentences about planes, clusters and tool registries. If they are contractual, you will hear them in sentences about regions and commitments. For identity data, in a regulated European estate, that difference is the whole answer.
For more detailed information, please download the full document.
Download Resource Here
The leading Agentic AI Autopilot for autonomous identity threat detection and response (ITDR) and cloud entitlement protection.
