Inside the Sidekick architecture: "Our code, your cloud" explained

The architectural principle

Most AI tools ask an organisation to make a trade. You get the intelligence, but your data has to travel to the vendor's cloud to be processed. For regulated industries, sovereign workloads, or any environment with serious compliance obligations, that trade is a non-starter.

Sidekick is built around the opposite principle. The platform comes to the data, not the other way around. The shorthand used internally is our code, your cloud — Sidekick's software runs inside the client's own environment, processes the data where it already lives, and never sends anything out to a vendor-controlled endpoint.

The core principle: The most secure place for AI to live is exactly where your data already lives — behind your firewall. Sidekick is designed so that your data never leaves your boundary, and never has to.

The three core components

A Sidekick deployment is made up of three logical components, all of which run inside the client's controlled environment.

Windows VM — SQL Server and agent memory

The Windows virtual machine runs Microsoft SQL Server, which serves two purposes. It holds the agent's memory — the schema replication, sampled records, and structured outputs that Sidekick builds over time — and it provides connectivity into the client's data sources through linked servers. The linked-server model is what allows Sidekick to read from a wide range of source systems without any data being physically moved or copied out.

Linux VM — Sidekick's application stack

The Linux virtual machine runs Sidekick's core application as a set of Docker containers. The application itself is built in .NET Core. Alongside it runs a local web portal built in Svelte, which provides the administration interface and acts as the front end for the enterprise dashboard. Apache Airflow handles orchestration — batch jobs, scheduled scans, and the recurring tasks that keep Sidekick's understanding of the estate current.

LLMs — running locally on AI Foundry or on-premises GPUs

Sidekick uses up to five language models to handle different tasks during discovery and reasoning. The models vary in capability, and Sidekick selects the right one for each task — lighter models for classification work, heavier models for complex reasoning. Critically, these models do not run in a vendor cloud. They run on the client's Microsoft AI Foundry instance, or on local GPUs for enterprise clients with on-premises infrastructure. The inference happens inside the tenant boundary.

How data actually flows

The end-to-end data flow is deliberately simple and deliberately contained.

1. Sidekick connects to source systems via ODBC or linked servers — SQL, data lakehouses, APIs, and other supported sources.
2. Schema is replicated into Sidekick's memory, along with limited sampling of records (typically the first and last 10,000 rows per table, configurable per client).
3. The Sidekick agent reasons over the schema and samples using LLMs hosted in the client's AI Foundry, accessed via a private endpoint inside the tenant.
4. The resulting understanding — classifications, descriptions, relationships — is stored in Sidekick's local memory.
5. The final output is a structured data dictionary and ontology, accessible through the local web portal and queryable through Microsoft Teams.

Throughout this process, no raw data leaves the client's virtual network. No prompts are sent to public LLM endpoints. The agent's reasoning happens inside the tenant, against models that are also inside the tenant.

What this means for security and compliance

Because the entire system runs inside the client's environment, deployment inherits the security and compliance posture of that environment. If the client's Azure tenant is in a sovereign region, Sidekick is in that region. If the client is subject to GDPR, HIPAA, POPIA, or any equivalent regulation, those obligations are satisfied structurally rather than through promises in a vendor contract.

Several specific properties are worth calling out:

• All access to source systems is read-only. Sidekick cannot write to, modify, or move client data.
• User access is managed through Microsoft Entra ID with role-based controls.
• All connection activity, agent reasoning, and query metadata is logged and can be integrated with an existing SIEM for real-time monitoring.
• Encryption is AES-256 at rest and TLS 1.3 in transit.
• No client data is used for model training, and no cross-tenant data sharing is possible.
• For the most sensitive environments, Sidekick supports fully air-gapped deployments with zero external internet requirements.

What stays with the client

One detail that matters more than it sounds: the artefacts Sidekick produces — the data dictionary, the ontology, the documentation, the agent's memory — remain inside the client's tenant. They are the client's proprietary assets. Even if the client stops using Sidekick, the structured understanding of the estate that has been built up stays with them.

This is a deliberate design choice. Sidekick is not a hosted service that locks understanding inside a vendor platform. It is software that builds permanent, governed knowledge of the data estate inside the environment that owns the data.

The takeaway

The architecture is not complicated, but every part of it is deliberate. Two virtual machines, a set of containers, locally hosted models, and read-only access into the source systems — arranged so that the platform delivers enterprise-grade discovery without ever asking the client to give up control of their data.

For technical evaluators, this is usually the point where the security conversation becomes a short one.