Security tools carry an irony that their buyers have learned to live with: the tools designed to protect sensitive data typically require that sensitive data to be sent somewhere. A DLP system inspects data by receiving it. A cloud-based surveillance platform inspects communications by ingesting them. A vendor-hosted threat detection service analyzes behavior by processing telemetry in the vendor's environment. The security program is, structurally, a series of controlled egress events — data leaving your environment and traveling to someone else's.
For most buyers and most categories of data, this tradeoff is manageable. A security vendor signs a data-processing agreement, provides their SOC 2 report, and the organization accepts the residual risk of their most sensitive data living in multiple places. But for a growing segment of regulated buyers — financial services firms with MNPI-handling obligations, healthcare organizations subject to HIPAA, enterprises operating under strict data-residency regimes — this tradeoff has become untenable. The data that matters most is also the data that the vendor cloud architecture cannot touch.
When a regulated enterprise sends communications to a vendor's cloud for surveillance inspection, several things happen simultaneously that cannot be undone by contract language. The data is transmitted across a network boundary. It enters an environment that the enterprise does not control, does not administer, and cannot audit in the way it audits its own systems. It sits, at least momentarily, in infrastructure that other customers also use — or, in a dedicated architecture, in infrastructure that is the vendor's to operate and secure. A data-processing agreement allocates legal responsibility for what happens; it does not eliminate the risk that something will.
The security failure modes in this architecture are meaningful. A breach of the vendor's infrastructure exposes data that the enterprise thought was safe. A subpoena or government request served to the vendor creates a disclosure the enterprise cannot control or even anticipate. A misconfiguration in the vendor's multi-tenant environment creates an exposure the enterprise cannot detect. And the data-handling disclosure that must accompany any regulated use of a vendor-cloud architecture creates its own examination and audit exposure.
“A data-processing agreement allocates legal responsibility for what happens to your data in a vendor cloud. It does not eliminate the risk that something will.”
None of this is new. What has changed is the scrutiny. Regulatory examinations now regularly include questions about third-party vendor arrangements and the data flows associated with them. Privacy teams that previously treated vendor-cloud security tools as a routine operational matter are increasingly being asked to formally assess and approve each arrangement. And as data-residency requirements have expanded — driven by GDPR Article 46 transfer mechanisms, regional sovereignty requirements, and sector-specific rules for financial and health data — the set of vendor-cloud architectures that a regulated enterprise can actually approve has contracted.
In-tenant architecture means that the inspection logic — the capability that evaluates data and renders findings — runs inside the enterprise's own environment. The data does not move. The inspection comes to the data.
This is architecturally straightforward to describe and has historically been difficult to deliver for sophisticated behavioral inspection. Keyword matching can run locally without difficulty because the computation is lightweight and stateless. More capable inspection — the kind that can recognize behavioral patterns, detect novel threats, and distinguish genuine risk from look-alikes — has historically required substantial compute and has been delivered as a cloud service because the infrastructure cost made tenant-side deployment impractical for most buyers.
The architectural challenge is therefore not just deploying in-tenant but delivering inspection quality that is competitive with cloud-based alternatives. An in-tenant system that provides weaker detection than a cloud service simply replaces a data residency problem with a security gap. The value proposition of in-tenant architecture is only realized when the inspection is genuinely as capable as the alternatives — running inside the enterprise's walls with no meaningful performance or quality sacrifice.
Different categories of regulated data carry different residency requirements, but the pattern is consistent: the more sensitive the data, the less flexibility there is about where it goes.
Zero egress means that no byte of the data being inspected leaves the enterprise's environment for the purpose of inspection. This is a stronger guarantee than most data-processing agreements provide, because it is a structural guarantee rather than a contractual one. A vendor can contractually commit to not retaining data, not sharing data, and protecting data in transit. None of these commitments change the fact that the data left. A zero-egress architecture changes the fact itself.
The security implications are direct. If data does not leave, it cannot be intercepted in transit. It cannot be exposed by a vendor breach. It cannot be produced in response to a third-party legal process the enterprise was not a party to. It cannot appear in an audit of a vendor's data holdings. The risk surface is eliminated, not reduced. A vendor that does not hold your data cannot expose it, regardless of what happens to the vendor.
This is also the argument that resonates with the organizational stakeholders who most often block or delay security tool procurement. Privacy teams are comfortable with tools that do not receive the data they protect. Legal teams do not need to draft and negotiate data-processing agreements for tools that do not process data externally. Procurement teams do not need to manage ongoing vendor security assessments for a tool whose architecture does not create a vendor-side data holding. The approval process for a zero-egress tool is qualitatively simpler than for any vendor-cloud alternative.
A security tool that runs in the enterprise's own environment inherits the enterprise's existing security controls. Identity and access management, network segmentation, encryption key management, endpoint protection, SIEM integration — the entire security posture the organization has invested in building is available to a tool running inside those walls.
This is the opposite of the vendor-cloud relationship, where the enterprise must assess and trust the vendor's security posture as a separate system. An in-tenant tool uses your keys, runs behind your firewall, and is logged in your SIEM. A security event involving the tool is visible in your security operations infrastructure, not hidden in a vendor's incident response process.
For organizations that have invested heavily in their Azure or on-premises security infrastructure, the practical benefit is that a new capability does not require a parallel security program. The tool is an extension of the environment rather than a dependency on someone else's.
The traditional barrier to in-tenant security tool deployment has been operational complexity. A sophisticated behavioral inspection capability requires infrastructure, configuration, and ongoing maintenance that many security teams — particularly those at mid-market firms with lean operations — cannot absorb without significant disruption.
Azure Marketplace deployment addresses this directly. A Managed Application on the Azure Marketplace installs into the customer's own Azure tenant and is administered by the customer, but arrives pre-configured and is updated through the Marketplace lifecycle management process. The operational overhead of an in-tenant deployment becomes comparable to a cloud service — without the data egress that a cloud service requires. For organizations that have committed to Azure as their cloud environment, the deployment also retires against existing Azure Marketplace Consumption Commitment balances, which transforms the procurement conversation from an incremental spend to a drawdown against a commitment already made.
The combination of structural data residency, inherited security controls, and a deployment model that simplifies rather than complicates the operational picture is the argument for in-tenant architecture. For regulated buyers, it resolves the contradiction at the center of the vendor-cloud security model: you no longer have to send your most sensitive data out to keep it safe.
Compiled runs inside your Azure tenant. Zero data egress. Your controls, your keys, your audit trail.