AI Security Data Sovereignty: On-Prem vs. SaaS Evaluation Architectures
Compare on-prem and SaaS architectures for AI security tools - data sovereignty, CLOUD Act exposure, and questions to ask before you choose.
Rushali
2026 State of Agentic AI Security
How ready is your organization to secure AI agents?
3 quick questions. See how you compare to other security leaders.
In June 2025, a commission of the French Senate requested a commitment from Microsoft France's director of public and legal affairs, who pledged to assure on oath that the data of French citizens would never be transferred to the US authorities without being approved by French authorities. His response: "I can't promise it, but I can assure you that I'll do everything I can. The data was stored in EU Data Centers. This did not affect the answer.
Now ask the same question about an AI security platform that reads your prompts, tool calls, and MCP traffic so it can do its work. AI security data sovereignty is a question of control, at three levels: the location of the data, the ownership of the keys, and the control of the runtime, and the jurisdiction that can force access to the data. This guide explains the differences, identifies where each of these architecture approaches fails, and provides you with the questions that will let you know if the data is actually flowing or if it's just a contractual promise.
What Data Sovereignty Actually Means for AI Security Tools in 2026
In recent years, the term "sovereignty" in a procurement questionnaire referred to choosing a region from a drop-down menu for the questionnaire. In most of the past decade, "sovereignty" in a procurement questionnaire implied selecting a region from a drop-down menu. That's the answer to where data is stored. It does not tell who can read it, who can be ordered to give it to someone, who runs the system that processes it. For AI security data sovereignty, these are key questions because the unit's protected is the live stream of AI traffic the tool monitors.
Beyond Data Residency: Three Practical Layers: Data, Control, and Legal
The physical location of the stored bytes is only one aspect of data residency. Sovereignty is broader. The cleanest working definition is to divide it into three operational layers: a data layer (prompts, completions, embeddings, logs), a control layer (keys, model endpoints, and the orchestration runtime), and a legal layer (the jurisdiction that binds the company that owns any of those things). If they all live in one perimeter that you really control, then you have a sovereign workload.
These layers contain the following when the workload is not a chatbot, but an AI security tool:
Layer | What it covers for an AI security tool | Question that tests it |
|---|---|---|
Data | Raw prompts and completions, MCP tools/call arguments and results, red-team transcripts, guardrail verdict logs, discovered agent and tool inventories | Where is each of these stored, cached, or processed, even for a few seconds? |
Control | Encryption keys, the runtime that inspects traffic, detection rule and model updates, admin and support access | Who can decrypt, who can push code into the inspection path, and who can log in? |
Legal | The contracting entity, its parent company, its sub-processors (including any LLM provider it calls) | Which courts can compel any of those parties to produce your data? |
One of the typical failure scenarios: An EU bank purchases an AI security SaaS from a US-based company and sticks it in a Frankfurt region. Data layer resides. The Control Layer is run by the vendor. The legal parent is the US parent. No, that deployment has residency, not sovereignty, and the difference only becomes apparent when the question is posed by the French Senate.
Transient processing counts. If you don't write anything to disk or write something that should not be saved to disk and a prompt passes through another region in a vendor's inference cluster, it's out of your perimeter for 200 milliseconds. GDPR applies to processing, not storage, so telling someone “we don't store it” does not constitute a “it never leaves” response.
Architectural Exclusivity vs. Legal Exclusivity
All vendors will say that their data is secure. The helpful question is what sort of protection it is. They come in two varieties, and they break in different ways.
A Vendor Promising Not to Reuse Your Data (Legal)
Legal exclusivity is a promise: a data processing agreement, a no-training clause, a promise of 30 days’ retention, Standard Contractual Clauses. These limit the options that the vendor has. They do not limit the court or government's ability to direct the vendor to perform and do not prevent an attacker, if he reaches the vendor's storage, from doing so.
The recent case of The New York Times v. Microsoft and OpenAI is the most obvious of the recent examples. A federal magistrate judge issued an order on May 13, 2025, to OpenAI to preserve and separate all output log data that may be deleted, even deleted conversations. OpenAI's ability to delete was genuine, and it challenged the order. It still needed to meet the requirements. The requirement to continue preserving new logs was removed on 26 September 2025; however, any new logs already preserved remained preserved.
Contracts still matter. They establish limits of purpose, breach notification, rights of audit, and who pays if it all goes wrong. They simply can't stop the data existing in someone else's hands; however, they can be used as a remedy afterward. An analysis of sovereign AI governance states: "Contracts do not replace statutes".
A Vendor Never Holding a Usable Copy of Your Data at All (Architectural)
If a vendor claims to be an architectural expert, then he or she cannot give you the expertise. Custody is the basis for most cross-border disclosure orders in law. For instance, the US CLOUD Act applies to data that is "in the possession, custody or control" of the provider. If the data is not held by the company, in its custody or control, there is no obligation to disclose, as eucrim points out. When inspection is performed in your environment, keys are stored in your KMS or HSM, and the vendor is only responsible for providing you with metadata that you approve of, then the answer is: "we will resist.
Most sovereignty content doesn't get into the details of security tools: inspection relies on plaintext. A prompt injection cannot be detected by a guardrail that doesn't recognize the prompt. A red teaming engine will not score an agent's response without parsing it. Thus, if you choose to use customer-managed encryption keys on data at rest in a vendor's SaaS, you don't have architectural exclusivity. The service still decrypts your traffic in memory, on its infrastructure, to accomplish the work. AI security tools' architectural exclusivity is determined by the location of the process that reads the payload. Does not, by itself, mean key custody alone.
A good way to test any vendor: If your company today gets a legitimate and valid legal order from us as a tenant tomorrow, what can you actually produce? An answer of the "configuration and aggregate metadata" type is for architectural exclusivity. An answer beginning with "we would challenge it" is legal exclusivity.
Why This Matters More for an AI Security Tool Specifically
The majority of SaaS products slice into your data. A CRM is a tool that displays customer records; a ticketing tool is a tool that displays tickets. An AI security platform is designed to monitor the most valuable traffic your AI systems produce, since it's where the attacks are going to happen. This alters the risk calculation.
The Tool Sees Your Prompts, Tool Calls, and Agent Traffic: It's Not Just Storing Metadata
The tool should be capable of parsing full payloads to detect tool poisoning, prompt injection (through tool output) or LLM context pollution (leaking into LLM context). When an agent requests a customer's information via a single MCP tool call, the following is what appears on the wire:
Response includes the billing history and support notes. The request shows the names of the internal tools and their schemas. Times by each agent, each session, each day. An AI security tool that scans this stream also holds:
System prompts, sometimes used to include business rules and escalation logic.
Tool schemas which are mapping your internal API surface.
Red-team transcripts, with the prompts that succeeded in jailbreaking your agents. That's a pre-prepared attack plan for your own systems!
Teams expect agents to pass tokens/keys through tool arguments more frequently than they actually do.
This material builds up in the logging layer. Wiz Research discovered in January 2025 an unauthenticated and open DeepSeek ClickHouse database, revealing more than a million lines of log data, such as chat history and plaintext API secrets. No one at DeepSeek wanted to post prompts. Unlocked store with accumulated logs. If any security tool for AI is designed to store payloads, it will create the same type of store, which raises the question: whose perimeter is it at?
An AI-SPM or AIDR Platform's Own Deployment Model Becomes Part of Your Attack Surface
To function, AI security posture management (AI-SPM) and AI detection and response (AIDR) tools must have privileged access. A posture tool stores read roles in your cloud accounts and Azure API tokens for Bedrock, Azure AI, or Vertex. Each agent call has an inline guardrail. If those components are running as SaaS, then the credentials are in the vendor's environment, and if the vendor is compromised, you're compromised.
This is no theoretical scenario for security vendors. In August 2025, attackers accessed Salesforce environments of over 700 organizations, such as Cloudflare, Zscaler, and Palo Alto Networks, using stolen OAuth tokens from Salesloft's Drift integration. There was no direct exploitation of any customer system. The attackers took over the trust of one integration. It is just such an integration with a SaaS AI security platform that stores tokens for your model providers and MCP servers, and SaaS vendors gather many customers' crown jewels under a single corporate perimeter.
There's also an available size aspect. Vendor-hosted inline guardrails are an imperative fail-open or fail-closed situation when the vendor is out of service. If it fails open, your agents are running without protection. A failure equals no agents. Threat model the security tool as you would any privileged third party, including credentials, update channel, egress paths, and failure mode.
Where SaaS AI Security Tools Break Down for Regulated Teams
There are lots of teams out there for which SaaS is the correct solution. It is the fastest, most up-to-date, and gets operational work off your hands. The on-prem vs SaaS AI security debate is only as clear as it will be in a regulated setting, and in those reviews there are three failure points that are repeated.
The CLOUD Act and Foreign Jurisdiction Exposure
The CLOUD Act, enacted on March 23, 2018, introduced new provisions in the U.S. criminal code known as 18 U.S.C. § 2713, which mandate that U.S. providers maintain or provide data stored in or controlled by them "regardless of whether such data is located within or outside the United States. Providers can only be moved to quash in “narrow circumstances” – the request must be directed at a non-U.S. person, and the conflict must be against a “qualifying foreign government” that has a “quoting foreign government” with the U.S. (eucrim).
When a company is the corporate parent, it is the company that is exposed to the CLOUD Act, not the data center. A vendor whose headquarters are located in the USA is exposed even if all the servers are in Frankfurt. The same argument is equally true of any vendor whose parent is based in a jurisdiction that has extraterritorial production powers.
This poses a direct conflict for EU controllers. GDPR Article 48 says third-country judgments or administrative decisions requiring a transfer are only recognized when based on an international agreement such as a mutual legal assistance treaty. According to EDPB's draft Guidelines 02/2024 on Article 48, such decisions "must not be recognized or enforced in the EU/EEA without an international agreement that stipulates this. In July 2025, the EU-US Data Privacy Framework withstood its inaugural legal test as the General Court quashed the motion in the case of Latombe on 3 September 2025, though the case has been appealed before the Court of Justice. In fact, there is a transfer basis today. It's still undergoing litigation to see if it will hold.
Audit Trails That End at the Vendor Boundary
The EU AI Act imposes many obligations on high-risk AI, with a focus on the logs. Article 12 mandates automatic record-keeping, and Article 26(6) states that the deployers are obliged to maintain "automatically generated logs" for "a period appropriate to the intended purpose," which is "of at least 6 months". DORA gives financial entities audit rights to critical ICT providers.
Audit trail continuity is the ability to track a single event from the agent to the gateway to the verdict to the action taken, and there is no break in the trail. The chain is split at the vendor boundary with SaaS. It is possible to display the output of the vendor's console. It is not possible to independently demonstrate which member of vendor staff accessed your tenant, whether traffic was processed in a different region during a capacity event, or which sub-processors touched a particular prompt. Cross-region routing during a peak load period is a design feature used during periods of heavy traffic and doesn't show up for the customer unless the vendor logs and exposes it.
If you do use SaaS, close as many of the holes as possible: stream raw events to your own SIEM system in near real-time, not just periodic exports; require access logs from the vendor side, identifying who accessed what, when, and why; and get retention per data store, in writing.
Shared Infrastructure and Multi-Tenant Risk
A multi-tenant SaaS separates customers logically; typically this is done by appending a tenant identifier to each row, queue message, and cache key. That isolation is only as secure as the authorization check that is used to secure it. A missing tenant filter in one of your internal APIs is a cross-tenant broken object-level authorization bug, and that is what your AI security tool should be looking for in your own APIs.
AI security tools also bring an additional common element: the models they employ for detection. An LLM is utilized as a classifier or judge in many platforms. If that model is API-based (a third-party), then your prompts are sent to another sub-processor who is in another jurisdiction. A tool can operate in a sovereign cloud and "still break the chain with prompts to a model provider in another country," as one guide for regulated buyers states. Ask which models the detection pipeline calls and where they run.
Where On-Prem and Self-Hosted Introduce Their Own Trade-Offs
Self-hosting places the three sovereignty layers within your perimeter. It also carries any other operational issues that the vendor had to deal with before, and may even subtly alter which product you are purchasing.
Operational Burden and Total Cost of Ownership
The license is the smallest part of the total cost of ownership (TCO) of a self-hosted AI security platform. The higher expense items are:
If local LLMs are used for detection, then GPUs are required to compute for inspection if there is a high volume of agent traffic.
Under the AI Act, there is a minimum storage requirement of 6 months, and longer for high-risk deployers under the sector rules, for log storage, while if they are kept, they are sized for full payloads.
Upgrade labor. Cast.ai estimates that at 10 releases a month, it takes up to 1 SRE-day per month for a comparable category, Kubernetes optimization tooling, in self-hosted installs, in addition to high-availability work and disaster recovery work.
Status of a component on which a request is waiting. If there is an outage to the guardrail, then it is your agents' outage.
A cost that doesn't usually end up on the spreadsheet is detection freshness. New jailbreak and tool-poisoning techniques come out every day. A SaaS solution has a centrally managed test library and detection rules. A self-hosted instance will be no more up-to-date than the last time you upgraded it. Being a red-teaming library three releases behind is a security flaw that you gave yourself.
On the other side of the coin, self-hosting can significantly reduce vendor risk reviews. When auditors have the toughest questions, they have the easiest answers with sovereign deployment. But the operational cost is not one-sided: a self-hosted gateway with an available public log directory is more of a problem than a good SaaS.
The Capability-Parity Problem: Many "Self-Hosted" Options Are Reduced Versions of the SaaS Product
This is the one place that most content from vendors will not touch. There are lots of self-hosted tiers which are a completely different product with a lower capability ceiling, and offered as the same name. The exception is capability parity: that is, the self-hosted build is capable of doing exactly what the SaaS build does, on the same release schedule.
A pattern is available and is documented openly in other categories. The dashboards, visualizations, KPI graphs, run comparisons, and audit log UI that are offered in Timefold Cloud are not available in the self-hosted version: “Each install can only have one tenant, and the platform is fully API-only.” The "discrepancies between SaaS, Self-Managed, Dedicated, and Duo Self-Hosted feature implementations" is a part of GitLab's own engineering epic. Arize's advice to buyers is no-nonsense: "Some vendors ship features to SaaS first. And Cast.ai points out that self-hosted releases are "commonly weeks to months behind SaaS.
Among the characteristics that have the highest likelihood of being eliminated from self-hosted AI security solutions are vendor-hosted features:
LLM features (auto-generated test cases, AI triage and natural language policy authoring) calling a vendor-hosted model.
Centrally trained detection models and threat intelligence feeds.
Cross-customer baselines for anomaly detection.
Managed connectors to SaaS model platforms and identity providers.
The less-featured self-hosted option isn't always a no-go. It becomes one if the buyer does not discover it until after signing the contract. With two products, there will be two release trains, two bug queues, and even two support SLAs. Do not run your proof of concept on the SaaS demo, but on the build that you would deploy.
Architecture Options Across the Sovereignty Spectrum
AI security deployment models are not just a binary. As you move closer towards full control, you gain more of the 3 layers, and it becomes more expensive to run. The following details show the results of the above options summarized in the table. Typically, an architecture for a sovereign AI system involves a mixture, with parts of the system deployed at various locations.
Option | Data layer | Control layer | Legal layer | Operational burden | Typical fit |
|---|---|---|---|---|---|
Public cloud SaaS (regional) | Resident in chosen region, processed by vendor | Vendor | Vendor's parent and sub-processors | Lowest | Low-sensitivity traffic, fast start |
Private cloud / dedicated tenancy | Isolated, vendor-operated or in your account | Shared or vendor | Depends on operator's parent | Medium | Regulated teams without a platform team |
Self-hosted / on-premises | In your perimeter | You | Yours, if nothing phones home | High | Regulated data in prompts |
Air-gapped | In your perimeter, no egress | You | Yours | Highest | Classified, ITAR, critical infrastructure |
Public Cloud (Hyperscaler Region): Lowest Cost, Lowest Sovereignty Guarantee
For most AI security vendors, the default deployment is multi-tenant SaaS in a hyperscaler region. You pick the region, the number of vendors to release with, and have no infrastructure to run. What you don't have is control or legal separation: it runs the vendor's runtime, and both the vendor's parent and the hyperscaler's parent are in the legal layer. Failover design, global support access, and a detection model run elsewhere can also reverse region pinning. This is ideal for teams with agent traffic that does not include any regulated information, or teams that only send the tool metadata.
Private Cloud / Dedicated Tenancy: Isolated Infrastructure, Provider-Managed
With the private cloud and dedicated tenancy, the multi-tenant blast radius is gone. It includes one instance managed by the vendor, the vendor's software that you deploy within your cloud account, and hybrid SaaS-where your data plane is deployed in your VPC and the vendor's control plane and dashboard are hosted in the cloud. Isolation improves. The answer to whether control improves depends on who has admin access and where the control plane is located.
Sovereign cloud offerings aim to tackle the legal layer as well. The AWS European Sovereign Cloud was launched on January 15, 2026, in Germany in the region of Brandenburg with AWS German subsidiaries, operated exclusively by EU citizens and physically and logically separate from other AWS Regions. But critics say the parent-company issue is not resolved. The qualification of SecNumCloud for France goes further: it requires immunity from the law of other countries. Though Google Assured Workloads offers residency controls and access transparency, it doesn't offer complete physical isolation, as NeuralTrust points out.
For data at rest, this tier can be enhanced using external key managers that control encryption keys. As you saw in the previous discussion, the processor must have plaintext in memory.
Self-Hosted / On-Premises: Maximum Control, Highest Operational Burden
Self-hosting puts the data plane, control plane, storage, and keys in infrastructure you operate. If configured correctly, all three sovereignty layers are yours. Outbound calls mostly happen with most self-hosted software – as it says, "if configured correctly": pulls of container images, license checks, telemetry, alert delivery via Slack or email providers, and LLM-powered features that call an external API. These are all ways to leave your boundary. Do not rely on a configuration flag to determine which of the egresses to allow, but get the full list and block the remainder at the network layer.
This option is suitable for teams that have regulated data in their prompts and agent traffic, and already deploy Kubernetes in production.
Air-Gapped Deployment: For the Most Regulated or Sensitive Environments
An air-gapped deployment is a deployment that does not have any network path out. It is the only case in which "the vendor cannot receive your data" is a physical property and not a configuration. The list of common drivers provided by Aisle includes classified programs, ITAR-controlled environments, and critical infrastructure.
Air-gapped AI security tooling has unique requirements that a typical self-hosted build can't satisfy:
Offline license activation.
Signed offline update bundles for test libraries and detection rules; transfer cadences are known; and hash verification for import.
Hosted models to create detection and/or red team prompts locally for any LLM.
Alerts to on-network systems only.
Freshness of detection is the greatest risk. Before deployment, agree on a cadence of updates with the vendor, and verify that the vendor has tested an air-gapped install. Many “self-hosted” builds make an implicit assumption of outbound access.
A Decision Framework for Evaluating AI Security Architecture
A data sovereignty AI evaluation should be a workload-based one, not a vendor-based one. There is hardly any need for the same deployment model for a coding assistant's traffic and a claims-processing agent's traffic. The four inputs that determine placement are what the regulation actually calls for, what the data is that's actually being moved, what the team can actually run, and what the vendor can actually show.
Regulatory Drivers: What EU AI Act, GDPR, or Sector-Specific Rules Actually Require
First, distinguish between rules that must be obeyed and rules that vendors say they must obey. The EU AI Act timeline has been adjusted in 2026: The Digital Omnibus, Regulation (EU) 2026/1744, was published on July 27, 2026, with Annex III (high-risk obligations) being implemented on December 2, 2027, and Annex I (obligations) being implemented on August 2, 2028.
EU AI Act Article 10 covers training, validation, and testing data sets for high-risk systems: these data sets must be prepared and tested according to documented practices that include data origin, preparation, and bias examination. It is essential that Article 10(6) is carefully read. If you are not training models for high-risk systems, those requirements are applicable to the testing data sets. Where the corpora reside, and who can change them, becomes part of your data governance story if they are used to confirm the expected performance of a system and the evaluation result is used to do so. The Omnibus also moved the rules on processing special categories of personal data for bias detection out of Article 10(5) and into a new Article 4a.
GDPR introduces the obligations of the processors under Article 28; the transfer obligations under Chapter V; and the conflict covered above under Article 48. In addition to the rules in each sector, there are also EU rules like DORA and NIS2, or US rules such as HIPAA, FedRAMP, and CMMC. None of them literally requires any kind of deployment on-premises. What they need, Aisle says, is "risk management, accountability, and evidence of control. Match each regulation to the layer that it interacts with and select the least expensive architecture that meets all of the regulations. To get a wider sense of the frameworks that can be involved, check out our guide to AI compliance.
Data Sensitivity: What's Actually Flowing Through Prompts and Agent Traffic
Teams commonly overestimate what they send their agents. Prior to selecting an architecture, sample traffic from a representative day of agent and MCP traffic and categorize traffic. Look for:
Personal information and health information in user prompts and retrieved documents.
Tool arguments and credentials. AWS keys, Snowflake tokens, and passwords were directly harvested from AWS keys, Snowflake tokens, and passwords that had been pasted into Salesforce support cases. Agents acquire information in the same locations.
Creation of both context and source code details in the coding agent.
System prompts and tool schemas that explain internal processes.
Traffic is often less well-governed than teams think. 63% of organizations are unable to set a purpose limit on agents, and 60% are unable to end the relationship with a misbehaving agent, according to Kiteworks. There is a straightforward decision rule: If data that is regulated is found in payloads, then your data layer is inside your perimeter. A hybrid model is typically defensible when only metadata like endpoint paths, verdicts, and counts are required.
Operational Capacity: Does Your Team Have the Resources to Run It On-Prem
Evaluate them honestly before selecting self-hosted:
Are you already running Kubernetes in production, in an on-call rotation?
Back to the original questions: who is paged when the inline guardrail fails at 2 a.m., and what is the fail mode?
Are the detection content updates available within days of release, on each release?
Can you store and SIEM for months and months of AI traffic?
If both answers are "no," then you probably won't be as secure as a well-run managed service. There is a hybrid solution for just this scenario: maintain the component that interacts with payloads within your VPC and deploy the remaining components via the vendor.
Vendor Transparency: Ask for Data Flow Diagrams, Not Just Policy Language
When a vendor has a policy, the policy language explains what they intend to do. A data flow diagram indicates the function of the system. For each deployment model, ask for one that includes all of the components, their location, all of the data classes that cross every arrow, and the data classes that are persisted by each store. It's a helpful way to make a statement per component, such as:
Questions to Ask Any AI Security Vendor
The three questions listed are the essential ones to include in an evaluation checklist; each corresponds to a sovereignty layer, and each is likely to show the disconnect between marketing and architecture. Inquire in writing and retain their responses. It is not a Microsoft France answer because it was an email from procurement.
"Does Your Self-Hosted Version Have Full Feature Parity With Your SaaS Product?"
Evidence should follow a "yes. Ask for:
A feature matrix by deployment model – any feature requiring a vendor-hosted service will be marked.
The average time from SaaS build to self-hosted build.
If there is a difference between support SLAs and escalation paths across deployment models.
If the detection content (test library, rules, models) is the same and is changed at the same time.
Approval to deploy the proof of concept on a self-hosted deployment.
A “mostly” is a good response. This equates to the ability to now ask what features, and whether they are required or not.
"Where Do My Prompts and Agent Traffic Physically Go, Even Transiently?"
In this question, the word 'transiently' does the work. Examples of payloads that can leave the perimeter without being stored: in-memory processing in a vendor region, message queue buffers, crash dumps, debug logging that is turned on during a support case, LLM-judge calls to a sub-processor, or a screen share during troubleshooting. Do not ask for one retention number, ask for retention per data store; ask which fields are persisted vs. discarded. This is the kind of information that some vendors provide; for instance, Akto's documentation has details about the fields its own deployment stores and mentions a firm retention limit for raw traffic. If the vendor can't be detailed, take the most general answer.
"Who Can Access Logs, Keys, and Audit Trails, and Under What Jurisdiction?"
This question deals with the control and legal layers in combination. Ask:
Who has access to customer data within the production environment, and where are they physically located?
Do you get access that is just-in-time and approved by you, and do you get access logs?
Who has the encryption keys and where, and can the vendor decrypt without your involvement (HSM, external key manager, etc.)?
Who is the legal entity in charge of the contract, and what is its ultimate parent?
Does the vendor respond to government information requests? Does the vendor have a transparency report?
Will it alert you to an inquiry? Microsoft France told the Senate it notifies affected customers, but must first obtain the approval of the US authorities. The legal layer includes gag orders.
How Akto Supports Both Architectures Without Compromise
Akto ships as a managed cloud service, a self-hosted deployment, and an open-source project. The beauty of the sovereignty-constrained teams is that the decision for architecture is made after the data classification process outlined above is completed, not because a vendor has an architecture available.
Akto Cloud: Fully Managed SaaS
The fastest way to AI agent security without any infrastructure to run is Akto Cloud, at app.akto.io. It includes discovery of MCP servers, AI agents, tools, and resources on infrastructure, cloud, and employee laptops, agentic red teaming, agentic security posture management, and guardrails. For teams who don't have to self-host but find their data sensitivity too high for a simple SaaS solution, Akto documents a hybrid SaaS solution: the traffic aggregator is deployed on Terraform, CloudFormation, Helm, or Docker in a private subnet of your application's VPC, and the dashboard remains managed. The aggregated traffic is then directed to Akto's cloud, and you can check which fields get dropped from your VPC in your configuration, with the help of the data flow questions above.
Akto Self-Hosted: Deployable On-Prem or in Your Own VPC in Minutes
Akto Self-Hosted is deployed in your environment and has deployment guides for AWS, GCP, Azure, OpenShift, local installs, and Helm for Kubernetes. The quick start of the open-source build is claimed to take 60 seconds via Docker Compose. Akto documentation says that self-hosted deployment means your data "never leaves your VPC. In the VPC, it does not store values, only usage metrics and the list of endpoint URLs and key names from requests and responses. Real-time traffic is dropped once it has been processed; there is a hard limit of an hour to retain real-time traffic. A self-hosted instance also makes the following outbound calls, as noted on the same page: GitHub and DockerHub downloads, Slack and email notifications, and AktoGPT. Which means you have an explicit list that you can open or close; it provides the answer to the data-layer question as well as to the "what phones home" question.
Akto Open Source: Full Transparency Into What's Running
Akto is open source with an MIT license. If it is for architectural exclusivity, then this is more important than any policy page; your team can see the code that is processing traffic, they can see what it is storing, they can see all the outbound calls, they don't have to trust the vendor. Use the Parity question in this case too. Akto's README file references an Enterprise version with even more features, so this is the transparent part, not the whole commercial version. Request a written copy of the delta and select accordingly.
Why This Matters for AI-SPM, Red Teaming, and Runtime Guardrails Specifically
There are multiple types of sensitive output produced by each capability, and thus placement is important per capability:
AI-SPM and discovery create a list of all the tools, MCP servers, and agents you are running. That inventory is a map of your AI attack surface, and when you leave it within your perimeter, you leave the map out of the hands of those who compromise a vendor.
Red teaming tests AI agents and MCP servers with 4,000+ specialized security probes to test for prompt injection, tool abuse, and privilege escalation. This leads to the creation of attack logs that provide details of successful attacks. You have control of that playbook, and any testing evidence you are using for Article 10 purposes, when you self-host.
Between Agent and MCP Servers or LLMs that Agent calls, you have runtime guardrails deployed via Docker containers or Kubernetes sidecars with Agent. Agent's runtime guardrails are deployed as Docker containers or Kubernetes sidecars with Agent between Agent and MCP Servers or LLMs it calls. It validates requests for prompt injection, SQL injection, and PII and applies PII detection/redaction to the responses. Plaintext inspection occurs in your infrastructure. Guardrail policies are documented through the dashboard (app.akto.io), so it's important to make informed decisions about where you want that control plane to be.
Final Thoughts on AI Security Data Sovereignty
The one thing that needs to change is the way AI security data sovereignty is assessed: by no longer judging tools on region selection and contract clauses. Analyze them based on their expected location, who has access to the keys, and which courts have jurisdiction over the company that runs them, and choose the lowest cost architecture that allows all three functions to be contained within your perimeter for each workload.
Here are the problems that are addressed by Akto. Self-hosted deployment retains payload inspection within the VPC, only stores key names, not values, and discards raw traffic within an hour, eliminating CLOUD Act exposure and audit trail limitations that end at the vendor. The open-source core, built with the MIT license, enables you to audit data flows rather than rely on policy language. Hybrid SaaS is for teams that don't have the capacity to run everything, and the Agent Gateway runs guardrails as a sidecar to your agents.
To see how Akto fits your sovereignty requirements, book a agentic security demo.
FAQs on AI Security Data Sovereignty
Is on-prem always more secure than SaaS for AI security tooling?
No, On-prem is more sovereign, a different property. The security of an environment that is self-hosted and falls behind in detection content, has an unreviewed route to egress, or has payload logs stored in an unprotected bucket may be less secure than a well-run SaaS service. On-prem is a good choice when it's a regulated data flow, and your team can run the platform at the same level the vendor would. Where either fails, often the hybrid approach with payload inspection retained locally is the better option.
Experience enterprise-grade Agentic Security solution