Skip to content
HelvetiCode
Menu
ENDE
Explore a design partnership

Security & architecture

One checkpoint between your code and any model

Governance cannot live in the editor: the editor is a client, and clients can be bypassed. The design puts the checkpoint on the network path instead, inside the environment you control.

Architecture

The gateway is the only path to the models

In a customer installation, the design makes model endpoints reachable only through the gateway. Every request from an IDE or a coding agent passes the same checks, whichever tool sent it.

Your environment or Swiss-hosted

Developer tools

IDEs and coding agents

HelvetiCode Gateway

  1. Check
  2. Route
  3. Record

Approved models

Self-hosted open models; external only where allowed

Audit trail

Append-only, access-restricted

Architecture diagram: inside your own environment or a Swiss-hosted one, developer tools such as IDEs and coding agents send every AI request through the gateway. The gateway is designed to check the request, route it to an approved model (self-hosted open models, or external models only where your rules allow), and write the request and its decision to an append-only audit trail.

Design principles

What the design commits to

  • The editor is never the trust boundary

    Rules are applied on the server side, where a developer's local settings cannot switch them off.

  • Checked before inference

    Decisions are made before a request reaches a model, not reconstructed from traffic afterwards.

  • Fail closed

    If the policy service is unavailable, requests are held back rather than let through.

  • Graded responses

    Hard blocks are reserved for precise rules. Otherwise a request can be redacted, rerouted to a self-hosted model, or require a justification.

  • Evidence, not a log file

    The audit trail is designed to be append-only, encrypted, and readable only by audit and compliance roles.

  • Open models, no lock-in

    Built on self-hostable open models and open standards; external models only where a rule allows them.

Request lifecycle

What happens to one request

Every request is designed to pass the same six stages.

  1. Request

    The tool sends the prompt, the assembled context, and metadata: repository, files, user and requested model.

  2. Authenticate

    The gateway identifies the user and the session.

  3. Check

    Deterministic scanners run first (secrets, repository scope, model allowlist), then a classifier for sensitive content. Result: allow, redact, reroute or block.

  4. Forward

    Approved requests go to the permitted model, after redaction or rerouting where required.

  5. Check the response

    The streamed response is checked as it arrives and can be stopped if it breaks a rule.

  6. Record

    Request, data origin, decisions, response, user and time are written to the audit trail.

Regulation

Built with FINMA and the revised FADP in mind

The gateway is designed to help clients meet their own obligations: keeping protected data inside Swiss jurisdiction, and producing the evidence internal audit and supervisors ask for. Regulators do not approve software as such, and we make no claim of certification or formal compliance.

This website

How this site itself is built

A small thing, but telling: the site practises the restraint it describes.

  • Strict content security policy

    Scripts and styles run only with a per-request nonce: no inline-script injection, no third-party origins.

  • Hardened response headers

    HSTS, content-type nosniff, a strict referrer policy, and a locked-down permissions policy on every response.

  • No analytics, no forms

    No third-party analytics or trackers, and no form that collects data. Contact happens by email.

  • Accessible by default

    Semantic structure, full keyboard navigation, visible focus, and WCAG 2.2 AA contrast.