What is data sovereignty for an AI coding assistant?
It means your source code, prompts, context, outputs and logs stay in accounts and Regions you control, under your own policies, and you know who operates every system they pass through.
Guide
Data sovereignty for AI coding assistants.
An AI coding assistant sees your source code, your prompts and the context around them. Data sovereignty asks where all of that goes, whose account it lands in and who controls it. This guide explains what is involved, how Topsoil answers it on Amazon Bedrock, and what to ask any vendor.
What data sovereignty means for AI coding
Data sovereignty is the principle that data stays under the control, and the rules, of the organisation that owns it. Two related terms are often used alongside it:
| Term | The question it answers |
|---|---|
| Data residency | Where, physically, is the data stored and processed? For cloud services that usually means which Region. |
| Data sovereignty | Whose accounts, policies and rules govern the data, and who operates every system it passes through? |
| Data privacy | Who is allowed to see the data, and for what purpose? |
For an AI coding assistant, residency is not enough on its own. A tool can run its models in the right Region and still route every prompt through a service its vendor operates, keep a copy of your conversations, or send usage data home. Sovereignty means knowing every hop, and owning as many of them as possible.
What data an AI coding assistant handles
| Data | Examples | Why it matters |
|---|---|---|
| Source code | The repository, including files the assistant reads to understand a change | Often the most valuable and most sensitive asset a team has |
| Prompts | What people type: questions, task descriptions, pasted errors | Prompts routinely contain code, customer names, hostnames and plans |
| Context | Attached files, documents, issue text, editor selections, command and test output | Context is sent to the model with the prompt, so it travels wherever the prompt does |
| Outputs | Generated code, diffs, reviews, reports and documents | Outputs describe your code and are often as sensitive as the input |
| Logs and history | Chat history, session files, model invocation logs, telemetry | History and logs keep data long after the task is finished |
| Identity and credentials | Who signed in, with what keys or tokens | Decides who can use the models, and whose policies apply |
Where the data lives with Topsoil
Topsoil is a client that runs on your machines and calls Amazon Bedrock in your own AWS account, in the Region you choose. There is no Thazen service in the request path, no Thazen prompt store, and no telemetry, analytics or crash reporter sending anything to Thazen.
| Data | Where it lives | Under whose control |
|---|---|---|
| Source code and working files | On the developer’s machine and in your own git repository and forge | Yours |
| Prompts and attached context | Sent only to the Bedrock, custom HTTPS or gateway endpoint you configure, in your AWS account and Region | Your account, served by Amazon Bedrock |
| Model outputs | Returned to the machine that asked. Files land in your working folder; a handed-over task comes back as a branch and pull request in your repository | Yours |
| Context library | Your own S3 bucket, in your configured Region by default, under per-user prefixes that IAM enforces | Your account and IAM policy |
| Chats, sessions and credentials | On the machine that runs them. The desktop app keeps credentials in the operating system’s keychain | The user, under your device policy |
| Logs | Written locally, with anything that can hold a key, token or session redacted first. Bedrock invocation logs exist only if your account turns them on, and then they are in your account | Yours |
| Shared projects and channels (optional) | A DynamoDB table and a Lambda function deployed in your AWS account | Your account |
On the model side, AWS states that with Amazon Bedrock, inputs and outputs are never shared with model providers or used to train base models, and that model providers have no access to customer prompts and completions. Read AWS’s own pages for the details and for your side of the shared-responsibility model.
Choosing the Region, including AWS GovCloud (US)
Residency starts with the Region. Topsoil signs every model request for the Region you configure, and its context-library bucket is created in that Region unless you name another. Topsoil ships IAM policies for both the commercial AWS partition and AWS GovCloud (US), and runs the same way in either.
- Commercial Regions. Pick the Region that matches your residency rules, and enable the models you need there.
- AWS GovCloud (US). AWS describes GovCloud as isolated AWS Regions designed to allow U.S. government agencies and customers to move sensitive workloads into the cloud. Topsoil runs there as a client in your GovCloud account, in either GovCloud Region. Running Topsoil in GovCloud.
- The model you pick matters too. Some Bedrock model IDs are cross-Region inference profiles. AWS documents that a geographic profile routes requests to Regions within its geography, such as the US, while a global profile can route to any supported commercial Region. In GovCloud,
us-govprofiles span both GovCloud Regions. Where residency is a rule, choose a model ID whose routing fits it. Topsoil lists the models and inference profiles your account can call, so the choice stays yours.
AWS notes that cross-Region inference requests are logged in CloudTrail in your source Region, with the Region that processed each request.
Optional connections you control
A few features reach beyond your AWS account, and each one is off until you set it up and points only where you point it:
- Web search is off by default; when enabled, queries go to the search provider or custom endpoint you choose.
- MCP servers are enabled per project, with their credentials kept host-side.
- Your backlog and git forge, such as GitHub, or Jira and Bitbucket Data Center inside your network, receive the branches and pull requests you would push anyway.
- Slack status messages are off by default and carry metadata only, never code, diffs, prompts or file paths.
Questions to ask any AI coding vendor
- Where does inference run? In whose AWS account or cloud tenancy, and in which Region?
- Who operates each hop? List every service between the developer’s machine and the model, and who runs it.
- Is there a vendor-operated proxy, prompt store or telemetry stream? If so, what does it keep, where and for how long?
- What is stored, and where? Chat history, indexes, context files and logs, and whether each sits on the device or in your own storage.
- Can requests leave the Region? Which model IDs or routing options could send a request elsewhere, and can you prevent it?
- Whose identity signs the request? Can you use your own IAM roles and single sign-on, and revoke access in one place?
- Are prompts and outputs used for training? By the vendor, and by the model provider behind it.
- What else leaves the machine? Updates, crash reports, analytics, fonts or CDN fetches.
Topsoil’s answers are on the deployment and security pages. Your own legal and compliance teams decide what your rules require; this guide is not legal advice.
Questions
Frequently asked questions.
Where does Topsoil process our code and prompts?
On Amazon Bedrock in your own AWS account, in the Region you configure, commercial or AWS GovCloud (US). Topsoil is a client, and Thazen operates no service in the request path.
Can a Bedrock request be processed in another Region?
It can if you choose a cross-Region inference profile. AWS documents that geographic profiles route within their geography and global profiles route across commercial Regions. Choose a model ID whose routing fits your residency rules.
Does Thazen see or store our prompts?
No. There is no Thazen prompt store, telemetry stream or crash reporter. Prompts go from your machine to the endpoint you configure.
See it against your own codebase.
A pilot runs in your own AWS account, with your models and your material, and ends with findings you can act on.