Matrix trust- och arkitekturbrief

Detta dokument beskriver referensarkitektur och verifierade begränsningar. Det är inte en säkerhetscertifiering, dataskyddsbedömning eller garanti om en ännu ej definierad produktionsdeployment.

Arkitekturprincip

Matrix är ett kunskaps- och kontrollager ovanpå systemens egna dataplan. Det läser, normaliserar och härleder beslutbara artefakter; kontrollerade write- vägar går genom explicit policy, mänsklig grind när risken kräver det, journalföring och read-back (CLAIM-PLATFORM-001).

källsystem → adapter → observation/evidens → graf och bedömning
                                              ↓
                              plan → policy/grind → executor
                                              ↓
                                  receipt → read-back

Trust boundaries

Källsystem

Äger sin operativa data och sina egna administrationskontrakt. Matrix ska inte bli en dold parallell master.

Adaptergräns

Översätter externt data till typade artefakter. Den måste deklarera tenant, scope, freshness, coverage, source revision och refusal. Otrustat innehåll förblir data och får inte bli instruktion (CLAIM-SECURITY-001).

Kunskapslager

Håller definition, observation, evidens och bedömning separat. Härledningar får egna IDs, metod och dependencies. Tenant- och zonregler gäller även graftraversal och export.

Control Plane

Coordinator och Jake-funktioner hanterar arbete, stages, runs, leases, review, fynd och landing. Kontrollstyrkan måste beskrivas per repo och avslutningsväg; en lokal hook är inte server-side enforcement.

Execution

Write-adaptrar får endast effekt inom beräknat mandat. Target, tenant, credential, riskcap, idempotens och postcondition måste bindas till intentet.

Identitet och mandat

Följande identiteter får inte kollapsa:

• autentiserad människa,
• service principal/workload identity,
• agentdefinition,
• agentinstans,
• körningsepisod,
• deklarerad reviewerklass.

Ett namn som human:* eller cc:independent-review-* är klassificering tills det binds till autentiserad ingress och policy. Effektivt mandat är snittet av principal, delegation, tenant, datazon, tool, actionpolicy, riskcap och TTL (CLAIM-SECURITY-002, CLAIM-SECURITY-003).

Human control

Mänskligt godkännande är inte ett universellt säkerhetsfilter. En fungerande grind behöver begriplig diff, konsekvens, unknowns, alternatives, expiry, separation of duties och möjlighet att vägra. Hög risk eller okänd reversibilitet ska inte kunna passera genom generell automation.

Matrix nuvarande reviewmekanik har lokala, landade kontroller men också coveragegap. Findings settled verkställs i Jakes sanktionerade close_landing_stage, medan Coordinatorns äldre QueueDispatch.complete kan gå till DONE utan samma grind (CLAIM-SECURITY-009).

Agent- och modellrisk

• Modelltext är ett förslag, inte policybeslut.
• Toolmandat ska avgöras deterministiskt utanför modellen.
• Hämtat innehåll behandlas som otrustat.
• Prompt/model/tool/policy/datarevision binds till run.
• Evals behöver task population, safety population och attackbudget.
• Samma agent eller run bör inte ensam skapa, granska och verifiera en effekt.
• Read-back ska inte bara återberätta write-requesten.

Data och livscykel

Data behöver klassificering, tenant, legal purpose, retention, export, tombstone och verifierad radering per store och kopia. Eliciteringspersondata och gemensam koordinationsdata har en landad tvådatabasdesign, men den observerade driften använder fortfarande transitionell fallback och saknar applicerad migration 0022. Central flytt är därför blockerad tills fallbackens frånvaro och båda migrationskedjorna är verifierade (CLAIM-DATA-009).

Service-passport

Varje operativ tjänst bör exponera minst:

Jake bridge har ett partiellt passport. Paneltjänsten har endast ett enkelt status=ok, och Coordinatorfältet i bridge läser aktuell repo-HEAD i stället för processladdad revision. Familjehälsa är därför inte verifierad (CLAIM-OPS-011).

Säkerhetsstatus som UI-kontrakt

Gränssnittet bör visa:

• deklarerad kontra autentiserad identitet,
• policybeslut och enforcement point,
• local/client/server enforcement,
• covered kontra uncovered DONE-vägar,
• connected, stale, unknown och refused,
• planerad, applicerad och observerad effekt,
• öppna findings, waiver och expiry,
• export-/retention-/restorecoverage.

En sammanfattande grön bricka får inte dölja en svagare dimension.

Inför en produktionspilot

1. Gör threat model för exakt use case och deploymentmodell.
2. Bind alla principals till tenant och minsta scope.
3. Inventera stores, backups, logs och modellproviders.
4. Definiera service-passport för varje komponent.
5. Flytta kritiska grindar till server-side eller dokumentera bypass.
6. Testa prompt injection, confused deputy och cross-tenant negative paths.
7. Kör restore och verifiera relationsinvariants, inte bara radantal.
8. Definiera incidentväg, safe mode och break-glass.
9. Gör WCAG-granskning av beslutskritiska flöden.
10. Publicera kända begränsningar och kvarvarande unknowns.

Spårbarhet

CLAIM-PLATFORM-001, CLAIM-SECURITY-001–003, CLAIM-SECURITY-005, CLAIM-SECURITY-009, CLAIM-DATA-009, CLAIM-OPS-011.

Visuella referenser

FIG-07-01 — Adaptergränsen från extern källa till beslutbar Matrix-artefakt

FIG-12-01 — Deterministiska mandatgränser runt en probabilistisk agent

FIG-14-01 — Eliciteringens separerade artefakter och verifierade datalivscykel

SCREEN-12-01 — Styrningsvy med obruten kedja från regel till evidens. Hel konceptvy med demodata; evidensstatus är inte hämtad från runtime.

SCREEN-11-02 — Control Plane med service-passports och enforcement per repo och DONE-väg. Konceptvy byggd från daterad read-only-observation; inte en livepanel.