Skip to content
    Living security architecture · Ansvar Architecture

    A model of your system that stays true.

    Components, data flows and trust zones your agents keep current and your people approve. Threats, controls and obligations attach to the parts they concern, so the diagram is still true next quarter.

    • ExternalBrowser
    • Application zonePortal API → Event queue (proposed, owner unknown)
    • Restricted dataRecords store, written by Portal API
    ExternalApplication zoneRestricted dataBrowserPortal APIRecords storeEvent queueproposed
    How it stays true

    Agents propose, people approve, and every fact cites where it was seen.

    Nothing changes the model without a person's assent. A proposal carries the change, the evidence it rests on and the open questions, and it waits.

    Proposals, not edits

    An agent that reads your repositories, manifests or tickets proposes a component, a flow or a control. The proposal cites the commit or document it was seen in. The accepted model does not move until the owner assents.

    How agents connect
    changeAdd component Event queue in Application zone; flow Portal API → Event queue (events)proposed
    evidenceObserved in deploy/values-portal.yaml at commit 8f21c0e, 2026-09-18cited
    ownerUnknown. Assessment blocked until named.open
    assentSystem owner review, required before the model changeswaiting

    Threats and obligations attach to parts

    A threat model, a TARA or a gap finding is scoped to the components it concerns. When a component changes, the assessments that depend on it are marked stale and a review is proposed. Nothing is silently re-reasoned.

    The threat models and TARAs that read the modelThe gap analyses that read the model
    • ExternalBrowser
    • Application zonePortal API → Event queue (proposed, owner unknown)
    • Restricted dataRecords store, written by Portal API
    ExternalApplication zoneRestricted dataBrowserPortal APIRecords storeEvent queueproposed
    Start standalone

    Thirty days on your machine, then a licence.

    The evaluation licence runs the whole workspace on your own machine for thirty days: the same model, the same proposals, the same UI. No card. On day thirty-one the workspace turns read-only and nothing is deleted; a licence key opens it again.

    Ansvar never hosts your architecture model: it runs on your machine or inside your plane, and a signed licence file works air-gapped with no call home.

    Two commands

    Create the workspace, pair your MCP client with the code the first command prints, and open the UI. The published image tag is on the docs page.

    Standalone setup in the docs
    # create a workspace and print a pairing code
    mkdir -m 777 ./acme
    docker run -e ARCH_PROFILE=standalone -v ./acme:/workspace \
      -p 127.0.0.1:8080:8080 ghcr.io/ansvar-systems/arch-mcp:<tag> init acme
    
    # serve it, then open http://127.0.0.1:8080/ui and pair
    docker run -e ARCH_PROFILE=standalone -v ./acme:/workspace \
      -p 127.0.0.1:8080:8080 ghcr.io/ansvar-systems/arch-mcp:<tag> serve acme
    1. Evaluation, 30 days

      One workspace, every feature, no card. It turns read-only when the thirty days end, and nothing is deleted.

    2. Workspace licence, €149 a month

      Self-hosted: one workspace, three contributors, unlimited components, agents on the pool. On request while we measure demand.

    3. Included in Team and Company

      One licence with Team, five plus the plane with Company, next to your documents and assessments.

    4. In your plane

      The same model inside a customer-operated plane, on-prem or air-gapped, under the plane subscription. Design-partner pilots today.

    Evidence attestation for the model, a signed chain that a third party can verify without us, is built and not yet switched on for customers.

    Start with your own system.

    Thirty days on your own machine. A licence key when you keep it.