We run Ansvar the way we tell you to run yours.
One estate, modelled in our own twin. No one logs into a production node. Every change is a reviewed commit, read by an agent that did not write it. Here is the map, and what happens behind each box.
One estate, drawn once.
The panel shows what each box is, what it talks to, and the rule it enforces.
- Your side
- Rehearsal: dr-dev
- Production cluster, EU
- Hosts we own, each isolated
Read the map as a list
Your AI client
Your own AI. Ansvar plugs into it.
Claude, Copilot, ChatGPT or your own agent. It stays yours.
- Ansvar never sees your model traffic.
- Your client calls the gateway over OAuth.
- Your model stays with your provider, under that provider's own terms.
Edge and identity
Checks who is calling and what they may see.
Where a call arrives and proves who it is: the Cloudflare edge, the gateway's OAuth 2.1 and customer identity on Keycloak, in our EU cluster.
- Tier and entitlement claims come from identity.
- Every tool call is checked against those claims.
- An unknown tier fails closed.
The gateway
One door to every source. Every answer cited.
gateway.ansvar.eu: one MCP endpoint in front of the whole fleet.
- It routes each call, fans out to the servers that hold the answer, and cites what comes back.
- When every downstream server fails, it returns an error instead of a clean empty answer.
- A row withheld for licensing says so with a visible message instead of disappearing.
The fleet
The law, standards and tools, one server each.
Corpus servers, one process per corpus, beside workflows, documents, risk scoring, regulatory intelligence and CVE and advisories.
- Each corpus runs in its own pod with its own memory limit, so corpora do not evict each other's search indexes from memory.
- A source is cleared for commercial reuse before the first fetch, and a red licensing verdict takes a corpus off every route.
- New and changed corpora ship as digest-pinned images, so the pod serves the exact bytes a reviewed PR pinned.
Data plane
Databases, backups and keys. Nothing applied by hand.
Postgres (CNPG), object storage, digest-pinned content images, and secrets in the OpenBao transit KMS and sealed secrets.
- No secret is applied by hand.
- Tenant data is envelope-encrypted with a key per tenant.
- Backups go to object storage, and a monthly job restores each store from its archive to prove it.
Delivery
How a change reaches production: reviewed, pinned, applied by a robot.
GitHub, independent review, CI gates on our own runners, images pinned by digest, the deploy repository and ArgoCD.
- Every change is a pull request, read by a model that did not write it.
- A red CI gate is never admin-merged.
- ArgoCD applies the deploy repository and reverts out-of-band changes to the resources it manages.
dr-dev: the rehearsal cluster
A second cluster we wipe and rebuild on purpose.
dr-dev is a separate cluster with its own identity and synthetic data, running the same deploy repository as production. Risky changes land here first, and rebuilding it from nothing is how we rehearse disaster recovery.
- Chart templates, identity configuration and cluster upgrades land on dr-dev before production, and the PR records the run.
- In the August 2026 drill we deleted both servers and every volume, then rebuilt from git and escrow, attended, to a verified serving path in 43 minutes. A rehearsal rig, not a production recovery-time claim.
- The rebuild repeats quarterly; the next is due by 19 November 2026.
- Every month a job in production test-restores each database store from its backup archive into a scratch namespace and checks the point in time with a marker written before and after the target. A failed restore raises an alert and is investigated and rerun.
- Customer databases take a daily base backup with thirty days of archive.
Observability and SIEM
Logs, flows and host audit, read by an agent.
A SIEM host of its own, dark to the internet, receives logs, network flows and host audit from the cluster and our hosts. Inside the cluster, Prometheus, Grafana and Loki watch live state.
- The hosts outside the cluster ship kernel audit through auditd and LAUREL.
- Cilium Hubble exports who talks to whom inside the cluster.
- The SIEM host takes no inbound connection from the internet.
- Grafana shows live state; the operator console shows governed state.
The twin
A live model of this estate, in our own product.
The estate twin in arch-mcp: zones, assets, flows, the threat register and behaviour baselines (pilot).
- Zones, assets, data flows and trust boundaries, queried by our agents.
- One threat register: a scenario exists once, with per-system applicability. In build, October 2026.
- A signal marks the conclusions that depend on it stale and opens a review.
The agent plane
Agents watch, triage and propose. People decide.
Log review, SRE watch, regulatory radar and corpus watch.
- Every agent honours a global run, mute or kill switch and a per-agent shadow or live mode.
- By default a new agent soaks in shadow for 48 hours before it acts.
- An agent's write is a proposal; it lands only after someone other than the proposer assents.
Security testing
Autonomous penetration testing, in a sealed box.
An AI penetration-testing agent on a host of its own, inside an isolated virtual-machine network. A person starts each run.
- It runs on a host of its own, outside the production estate.
- A person starts each run, and the run gets a time-boxed lease; the route to its one target is still being built and proven.
- Built and released on the contained host; no target run yet.
Nothing reaches production by hand.
Production is an immutable Kubernetes cluster in the EU. There is no SSH. The only way to change it is a commit that someone reviewed and a reconciler applied.
- 1Pull request
One PR per piece of work, pushed when the change is complete.
- 2Agent review
A model that did not write the diff reads it before merge.
- 3CI gates
Tests, licence policy, routing validity, schema parity, personal-data screen state, pin ratchets.
- 4Our own runners
By default CI runs on compute we own, a fresh runner for each job.
- 5Image by digest
Images are pinned by digest. A CI ratchet stops new floating tags.
- 6Deploy repository
Production state is a second repository. ArgoCD applies it and reverts drift in what it manages.
- 7Rollout and probe
Whoever merged confirms the rollout and runs live probes. Rollback is a git revert.
- A red gate is never admin-merged.A merge waits for every required check to pass.
- Short-lived credentials.Sessions authenticate to GitHub with one-hour tokens from a GitHub App. The default cluster credential is read-only; admin actions take a separate, deliberate configuration.
- Untrusted builds get a fresh machine.Pre-review code that needs a Docker daemon runs on its own VM, deleted after the job.
- Base images carry provenance.The shared base images are built with signed attestations.
- The whole organisation is scanned.Dependencies, secrets, containers and infrastructure code, with GitHub-native code scanning beside it.
- Restores are tested monthly, dr-dev is rebuilt quarterly.A monthly job test-restores each production database store from its backup archive into a scratch namespace and checks the point in time; a failure raises an alert and is rerun. Every quarter we wipe dr-dev and rebuild it from nothing.
- High-blast-radius changes rehearse first.Chart templates, identity configuration and cluster upgrades land on dr-dev before production, and the PR records the run.
- The console shows governed state, Grafana shows live state.Live infrastructure telemetry belongs to Grafana; the console renders manifests, registries and reviewed records.
Agents review the work. People make the calls.
Agents write most of our code and run most of our operations. We trust them with the doing, not with the deciding. Three rules make that safe.
An agent's write is a proposal.
No agent on the plane mutates a source of truth. It proposes a diff with the evidence that triggered it; a person, or a different agent that never proposed it, assents; the change then lands with an evidence artifact linking proposal, assent and diff. Corpus re-ingestion and architecture changes run through this path.
Every merge has an independent reviewer.
Each PR is read by a model that did not write it, at a set reasoning effort, with the repository in front of it, and the review is recorded. A confirmed finding gets a row in a findings ledger, and the row closes only when it names the mechanical gate (a test, a build check, an alert) that catches the class next time. A fix without a gate stays visibly open.
Every agent has a kill switch.
All agents honour a global override (run, mute, kill) and a per-agent mode (shadow, live). By default a new agent soaks in shadow for 48 hours before it acts. Agents on the plane run with a per-run identity and a read-only tool surface.
- Log review: every three hours a strong model reads a typed digest of both log planes and escalates what needs a person.
- SRE watch: a sweep every 15 minutes, triaged before anything reaches a person.
- Regulatory radar: a daily pass over regulator and agency announcements.
- Corpus watch (shadow): watches publishers for changes that affect a served corpus and files a review proposal.
- Refresh: a served corpus refreshes as one signal in, one reviewed PR out, with a verdict that diffs old content against new; a clean diff ships by policy.
We watch ourselves the way we would watch you.
Logs, flows and host audit land in a multi-tenant log store that an agent reads and a person can query. The SIEM host itself is dark to the internet.
- Hosts ship kernel audit.The hosts outside the cluster run auditd through LAUREL; the records land in the SIEM with the host and rule key attached.
- Network flows are metrics.Cilium Hubble exports who talks to whom inside the cluster.
- Alert rules live in git.Prometheus rules are reviewed PRs; a rule that fires without an incident behind it goes to a dashboard, not a channel.
- Public IPs are scanned from outside.Every public IP, every six hours; an unexpected open port is an alert.
- Exposure is minimal by construction.Cluster nodes are immutable and have no SSH, the control plane is reachable only over a private network, and per-node cloud firewalls sit in front of the cluster policies.
- Behaviour baselines (pilot, October 2026).The baseliner learns what each workload and host normally does and compares it with the twin. Its detectors run in shadow and raise no alerts yet.
Ansvar runs on Ansvar.
The estate on this page is modelled in our own architecture twin. We dogfood the product on the only company we fully control.
- One model of the estate.Zones, assets, data flows and trust boundaries, held in arch-mcp and queried by our agents.
- One threat register, no duplicates.A threat scenario exists once, with per-system applicability; look-alikes are held for a person to merge, never auto-merged. In build, October 2026.
- Signals land on the twin.A CVE, an advisory or a runtime signal maps to the asset it touches, marks the conclusions that depend on it stale, and opens a review. Nothing re-reasons on its own.
Autonomous penetration testing, in a sealed box.
An agent does the work, a person starts each run, and every claim must cite its evidence or stay marked unverified.
What it is
An AI penetration-testing agent (PentAGI) on a host of its own, with a European model provider behind it. A person starts each run, and the run gets a time-boxed lease. The model gateway is lease-gated today; the route to the one target a run may test is still being built and proven.
How it is contained
The agent and its tools run inside an isolated virtual-machine network. The guest cannot connect to host services; its requests go through a lease-gated gateway. Credentials are minted for the run and die with it. Each release of the lane is a versioned artifact, validated before it is activated, with rollback to the previous one.
How findings stay honest
A reference policy admits a CVE, CWE, CAPEC, ATT&CK or D3FEND reference only from Ansvar's own corpora: cited, licensed and current. A claim it cannot ground stays unverified and unscored. Only a reproduced control test marks a claim verified; today that is the SQL control-pair verifier.
Where it stands, October 2026
Built and released on the contained host; no target run yet. The broker that serves the reference policy during a run stays off until its serving boundary is finished. Attended runs against our own fixtures and dr-dev are the next step, and scheduled runs come after. Customer engagements follow once the lane has proven itself on our own estate.
Our own tests so far
A white-box penetration test of the platform in August 2026, covering the gateway, authentication and the web applications. The first independent third-party test is planned ahead of ISO 27001 certification; we publish the status, not the claim.
Report a finding
Good-faith research on our public systems is authorised; scope and safe harbour are in responsible disclosure.
The law we serve is governed like our code.
Every served row has a provenance chain, because a wrong citation in compliance work is worse than none.
- Licence before fetch.A source is cleared for commercial reuse before the first request; the gate refuses an unverified host.
- Personal data before serving.A new or rebuilt corpus passes a personal-data screen, or a validated skip proof, before it serves; confirmed personal data of a private person is never served.
- Raw upstream kept.Ingestion keeps the raw upstream response verbatim and content-addressed, within the source's licence terms, so a parser fix is a reparse and a served answer is provable against the bytes we ingested.
- Citation verification.verify_citations re-fetches the exact row and compares it to the quote.
Where we stand, in plain words.
| ISO 27001 | Stage 1 assessed by BSI on 31 August 2026, one minor finding. Stage 2 scheduled for October 2026. Status as of September 2026; Stage 1 is an assessment, not a certificate. |
|---|---|
| SOC 2 | Not planned. We say so rather than list it as coming. |
| Penetration testing | A white-box test of the platform in August 2026. The first independent third-party test is planned ahead of ISO 27001 certification, and we will not claim it until the report exists. |
| Cybersecurity Made in Europe | Labelled by ECSO. Ansvar Systems AB, registered in Sweden, org.nr 559547-2225. |
| Data protection officer | Appointed, October 2026. |
Ask us to walk you through it.
Bring your own architecture. We show you the matching part of ours and how the twin would hold it.