Skopa

skopa · security · switzerland

Security is a way of building, not an add-on.

Security can't be bolted onto a finished system. It arises when the architecture is designed — in the choice of location, of permissions, of keys, and of the points where a human decides. That is exactly where we start.

control & trust secured
  • Human sign-off
    at every sensitive step — Human-in-the-Loop
  • Complete audit log
    every action traceable and recorded
  • Data in Switzerland
    stored and operated in europe-west6 (Zurich)
  • Secured access
    MFA · App Check · least-privilege
0
long-lived keys
MFA
on every access
100 %
audit coverage

the stance

The best protection is the one you no longer have to add in later.

Many security concepts are a list of measures added after development. That rarely works: what isn't built that way from the start remains a weakness you manage instead of avoiding.

We take the opposite route. Location, identity, keys, logging and control over AI are design decisions — made before the first line of production code runs. The following five principles are not a wish list, but the architecture on which our platform and our clients' systems run.

01_datenhaltung

Data sovereignty

Your data stays in Switzerland.

Application and client data are processed and stored in Google Cloud, region europe-west6 (Zurich). Operations follow the revised Swiss Data Protection Act (revDSG) — not as a label, but as a constraint the architecture is built around.

region
europe-west6 · Zurich
law
revDSG
transit
encrypted (TLS)
at rest
stored encrypted
02_identitaet

Access & identity

Every access has a name — and the smallest permission required.

Access is protected with multi-factor authentication (MFA/TOTP). Permissions follow the least-privilege principle: every role and every service gets exactly as much access as the task demands — no more. This keeps the attack surface small and every action attributable to an identity.

login
MFA / TOTP
rights
least privilege
default
Access denied
03_haertung

Platform hardening

The platform defends itself before a human has to step in.

App Check (reCAPTCHA Enterprise) shields requests against abuse and automated attacks. New versions are shipped by keyless CI/CD with Workload Identity Federation — there are no long-lived keys that could be stolen.

abuse
App Check · reCAPTCHA Enterprise
ci/cd
Workload Identity Federation
keys
no long-lived keys
04_nachvollzieh

Traceability

What happened can be shown without gaps.

Every relevant operation lands in a gapless audit log: which process, when, with what result, who approved. Traceability isn't pieced together on request — it accrues in operation anyway and is viewable at any time.

log
gapless
content
who · when · what · result
review
viewable any time
05_ki_kontrolle

Control over AI

AI takes over your work — not your control.

At every sensitive step sits a Human-in-the-Loop gate: before an automation does anything consequential — posting, sending, approving — a human approval is required. The system proposes, the human decides. Every approval is in the audit log.

gate
Human-in-the-Loop
sensitive
Approval required
trail
Approval in audit log

the flip side

Security also means deliberately not doing certain things.

No long-lived keys

Where no permanent key exists, none can be stolen. Delivery authenticates short-lived via Workload Identity Federation.

No unsupervised follow-on steps

No automated process makes a consequential decision without a human gate. When in doubt, the system halts and asks.

No silent processing abroad

Client data stays in Switzerland (europe-west6). No convenient detours around data sovereignty.

No action without a trail

What the system does is in the audit log. No second, undocumented path around the logging.

intro call

Questions about the architecture? Let's get concrete.

In the intro call we walk through how these principles apply to your case — which data sits where, who has access to what, and at which points a human decides.