Security & governance
Topsoil does not rely on the model to behave. Approvals, allowlists and path checks are enforced in the client, at the point where a file is written or a command runs, and the work lands in infrastructure you operate.
| Control | What it stops | Where it is enforced |
|---|---|---|
| Plan mode | Changes before anyone has agreed on the approach. Plan mode reads and researches only; nothing changes until you approve the plan. | Topsoil client |
| Diffs and permission prompts | Silent edits. Every edit arrives as a diff, every command as its exact program and arguments. In the default mode Topsoil asks before each file change, command or use of the network. | Topsoil client |
| Command allowlist | Arbitrary commands. Commands run only if they start with an allow-listed prefix, and run without a shell. | Topsoil client |
| Network off by default for commands | Quiet egress. Outbound network access for a command is off unless the tool asks for it, and that asks separately. | Topsoil client |
| Risk classes and path checks | Writes outside the expected place. Tools carry a risk class of read, write or network, and file paths are checked before a tool touches them. | Topsoil client |
| Optional filesystem sandbox | Reach beyond the project, when you turn it on. | Topsoil client |
| Isolated git worktree | Changes to your working tree. A handed-over task is done on its own branch in its own worktree, and comes back as a pull request. Topsoil does not merge. | Your git repository and forge |
| Tests that must fail first | Tests that prove nothing. In /task, /goal and /loop, new tests are run with the rest of the change put back, and have to fail. | Topsoil verify stage |
| IAM | Who can call which model, and who can read which files. | Your AWS account |
| Budgets | Runaway spend. Checked before every model call, with an AWS budget action as the backstop. | Topsoil client and your AWS account |
Topsoil runs in your own AWS account and the Region you choose, on Amazon Bedrock. Your code, prompts and outputs stay in infrastructure you control, and no Thazen service sits in the path.
| Data | Where it lives |
|---|---|
| Source code and working files | On the developer’s machine and in your own git repository and forge. |
| Prompts and attached context | Sent only to the Bedrock, custom HTTPS or gateway endpoint you configure, in your account and Region. |
| Model outputs | Returned to the machine that asked. Files land in your working folder; handed-over work comes back as a pull request in your repository. |
| Context library and budget policy | Your own S3 bucket, in your configured Region by default, under per-user prefixes that IAM enforces. |
| Chats, sessions and credentials | On the machine that runs them. Desktop credentials are held in the operating system’s keychain. |
| Logs | Redacted before they are written. Bedrock invocation logs exist only if your account turns them on, and then in your account. |
| Shared projects and channels | When you turn them on, a DynamoDB table and Lambda function deployed in your own AWS account. |
Region choice is yours, in commercial Regions or AWS GovCloud (US), and so is the model: a cross-Region inference profile can route a request to another Region in its geography, so pick model IDs that fit your residency rules. Optional connections, such as web search, MCP servers and Slack status messages, are off until you set them up and reach only the endpoints you configure. Read the data sovereignty guide.
A coding agent reads untrusted text all day: issues, documentation, web pages, tool output. The OWASP Top 10 for LLM applications lists prompt injection first, and guidance from NVIDIA’s AI red team is to treat model output that drives tools as untrusted. That is the design assumption here. Because approvals, allowlists and path checks are enforced where the action happens rather than requested of the model, a manipulated model can propose an action, but it cannot carry it out without passing the same gates as any other. Read the checklist.
There is nothing between your people and your Bedrock endpoint that Thazen operates. A security review can start from the AWS account, the IAM policy and the network path it already knows, and finish there.
You choose from the models your account has enabled in Bedrock. Which model plans, implements, verifies and reviews is set per project, so the choice is visible and reviewable.
Questions
Only commands that start with a prefix on your allowlist, and outbound network access for a command is off unless the tool asks and you approve. In the default mode Topsoil asks before each file change, command or use of the network.
No. A handed-over task comes back as a pull request for a person to review, and Topsoil does not merge it. Unattended runs open their pull request as a draft.
No. There is no Topsoil analytics, telemetry stream or crash reporter, and no font or CDN fetch.
In your own AWS account and the Region you choose, commercial or AWS GovCloud (US). Prompts go to the Amazon Bedrock endpoint you configure, the context library is in your S3 bucket, and chats and credentials stay on the machine.
A pilot runs in your own AWS account, with your models and your material, and ends with findings you can act on.