Security · intended architecture
Security architecture
This page describes two things and keeps them separate: the security architecture we intend to build for real execution, and what the prototype actually does today. Nothing here is a compliance claim.
What the prototype does today
Tavronus Forge is currently a static site. All demo state lives in your browser's localStorage. There is:
- ◆No repository access of any kind — the code in the workspace is demo content shipped with the site.
- ◆No data transmitted to any server — including early-access form submissions, which are a preview only.
- ◆No model provider connected — the execution trace is a deterministic simulation.
This is the strongest security posture a product can have, because there is nothing to secure yet. Everything below is what changes when real infrastructure ships — and each item is labeled accordingly.
Intended repository access model
Planned
Repository read access is scoped to the task, not the account. When you cast a task, VULCAN's analysis reads only the parts of the repository the task requires, and execution happens in an isolated per-task workspace — a disposable copy that is created when the task starts forging and destroyed when it tempers or is rejected. Tasks never share workspaces, and nothing writes back to your repository without passing the review gate.
Secrets handling
Planned
Before any content reaches a model call, it passes through secret scanning and exclusion: environment files, credential patterns, key material, and paths you designate are stripped from context. The design assumption is that secrets will exist in repositories despite best practice, so exclusion is enforced at the boundary rather than trusted to hygiene.
Model-provider boundary
Planned
What would cross the boundary to a model provider, and what never would:
| Sent | Never sent |
|---|---|
| The task prompt, the current plan, and scoped file excerpts the task actually needs. | Environment files, credentials, key material, or files outside the task's scope. |
Logging & audit
Planned
Every task carries an auditable ledger: each command executed, each file touched, each permission gate hit and how it was resolved, timestamped and reviewable after the fact. The same ledger that powers the review workflow doubles as the audit trail — there is no separate, weaker record.
Permission gates
Certain actions always stop and wait for a human, regardless of mode: dependency changes, any network access during execution, and git operations that leave the workspace (push, PR creation). The prototype demonstrates these gates in simulation today; the intended architecture enforces them in a policy layer that the runner cannot bypass. Details in the documentation.
Local & self-hosted runner direction
For teams whose code cannot leave their machines, the intended architecture supports a local or self-hosted runner: execution happens on hardware you control, with only the scoped model calls you configure leaving the boundary. See local runner for the full picture.
What we will not claim
We hold no SOC 2 attestation, no ISO 27001 certification, no HIPAA compliance, and no penetration-test report — because none exist. No real infrastructure has shipped, so there is nothing to certify. When real infrastructure ships, we will publish evidence, not badges. Any page on this site claiming otherwise would be dishonest, and you will not find one.