Leverandørinformasjon

Hva AgentAudit behandler, hvor det befinner seg, hvordan oversikten er beskyttet, og — i samme dokument — hva denne leverandøren ikke hevder.

Hva AgentAudit behandler

Bare det agentene dine rapporterer: et tidsstempel, en handling, et utfall og eventuell valgfri kontekst du velger å sende — en begrunnelse, en referanse til saken, modell- og policyversjonen som gjaldt, om et menneske gjennomgikk det og hvem.

Den samler ikke inn noe på egen hånd. Det finnes ingen sporing, ingen berikelse, ingen oppslag mot andre kilder og ingen slutninger. Hvis et felt finnes i oversikten din, er det fordi agenten din la det der.

De tekniske kontrollene

Hver av dem kan kontrolleres. Filen er navngitt slik at kjøperens tekniske vurderer kan lese mekanismen i stedet for å ta setningen på tro — og de tre første kan testes direkte fra siden Bevis det.

• En beslutning kan ikke endres eller slettes når den er skrevet.

  Håndheves av databasetriggere på UPDATE og DELETE, ikke av applikasjonskode. Forsøk avvises selv for tjenesterollen, som omgår sikkerhet på radnivå fullstendig.

  supabase/apply-agentaudit.sql — og du kan selv kjøre forsøket på siden Bevis det.

• Sletting av en agent kan ikke slette beslutningshistorikken hens.

  Fremmednøkkelen fra en beslutning til agenten er ON DELETE RESTRICT, så forelderraden kan ikke fjernes mens beslutninger refererer til den. Agenter pensjoneres, de slettes ikke.

  supabase/apply-agentaudit.sql

• Én kunde kan ikke lese en annen kundes oversikter.

  Sikkerhetspolicyer på radnivå begrenser hver lesing og skriving til den som kaller organisasjonen. Databasen håndhever det, så en feil i applikasjonskoden kan ikke utvide det.

  supabase/apply-agentaudit.sql, supabase/apply-tenancy.sql

• API-nøkler lagres aldri i en form som kunne brukes.

  Bare en SHA-256-hash av nøkkelen beholdes. Klarteksten vises én gang ved oppretting og kan ikke gjenopprettes, så et databaseutlekk gir ingen andre brukbare legitimasjoner.

  src/lib/apiPrincipal.ts, src/app/api/access-keys/route.ts

• Innholdet i beslutninger sendes aldri til en språkmodell.

  Det finnes ingen modellkall noe sted i AgentAudit. Ingenting oppsummeres, klassifiseres, poengsettes eller skrives om av KI — etterlevelsesvurderingen og åpenhetsoversikten er deterministiske funksjoner over tallene som er talt opp.

  src/lib/agentaudit/ — søk i den etter et modellkall, og du finner ingen.

• En begrunnelse genereres aldri.

  Resonnementet som lagres mot en beslutning er det kundens agent rapporterte, ordrett. Denne plattformen vil ikke skrive en, og SDK-en vil ikke utlede en når den pakker inn en funksjon.

  src/lib/agentaudit/ingest.ts, packages/agentaudit-sdk/

• Verifisering kan gjøres uten oss.

  Hashalgoritmen er publisert i sin helhet. En kunde, en regulator eller en motpart kan beregne hver hash på nytt fra en eksport med rundt tretti linjer av sin egen kode. Nettleserverifisereren gjør ingen nettverksforespørsel når den kjører.

  /agentaudit/docs#algorithm

Underleverandører

Tre, og ingen andre er involvert i å håndtere en beslutningsoversikt:

Oppbevaring, og spørsmålet om sletting

En beslutning kan ikke slettes. Det er hele produktet, og det trekker mot retten til sletting etter artikkel 17 i UK GDPR. En personvernansvarlig vil ta det opp i det første møtet, så det tas opp her først.

Designintensjonen er at en beslutningsoversikt ikke inneholder personopplysninger. Feltet subject er til en referanse — et saksnummer, en kravidentifikator, en kontonøkkel — ikke et navn. Holdt slik beskriver oversikten hva en agent gjorde i sak 88213, og identiteten til den personen lever i dine egne systemer, der sletting er noe du faktisk kan gjennomføre.

Ingenting på denne plattformen håndhever det. Den lagrer det agentene dine sender, så minimering må skje ved kilden, i koden din, før beslutningen rapporteres. Det er verdt å skrive inn i integrasjonsdesignet ditt i stedet for å oppdage det senere.

Om artikkel 17 i det hele tatt gjelder for en gitt utrulling, og om et unntak gjelder, er et juridisk spørsmål om din bruk. Denne leverandøren besvarer det ikke og er ikke kompetent til det.

Spørsmål til leverandøren

1 of 7 supplier questions answered. 6 are outstanding and shown as such — a visible gap costs a follow-up email, and an invented answer costs the contract.

Alt utrullingen kan fastslå om seg selv leses fra det kjørende systemet i stedet for å skrives inn — en side som ber et menneske huske hvilken region de rullet ut til, vil til slutt oppgi feil region med selvsikkerhet. Resten er operatørens egne erklæringer, med egne ord.

Region the application runs inLest fra utrullingen

London, United Kingdom (lhr1)

Read from the running deployment, not typed in. A supplier page that asks a human to remember which region they deployed to will eventually state the wrong one confidently.

Legal entity, registered address and company numberIkke besvart ennå

Ikke besvart ennå. Vises som et gap i stedet for å bli fylt ut.

Procurement screening asks in the first form. An incorporated supplier that cannot state this quickly reads as one that has not been asked before.

Region the database is hosted inIkke besvart ennå

Ikke besvart ennå. Vises som et gap i stedet for å bli fylt ut.

A UK public body usually needs to know whether data leaves the UK or EEA. Find it in the Supabase dashboard under Project Settings → General → Region. The APPLICATION region is resolved automatically and shown above.

Data protection officer or named contactIkke besvart ennå

Ikke besvart ennå. Vises som et gap i stedet for å bli fylt ut.

Needed for a buyer’s DPIA and for any Article 30 record that names this supplier.

En leverandør som overdriver en sertifisering har fortalt kjøperen alt de trenger å vite om resten av påstandene. Et ærlig gap koster en oppfølgingsmail; en oppdaget overdrivelse koster kontrakten — derfor blir de ubesvarte stående synlig ubesvart.

Denne siden beskriver bare AgentAudit. Blackout Intelligence OS er et eget produkt med et annet datafotavtrykk, og ingenting her skal leses som at det dekker det.