Leverantörsinformation

Vad AgentAudit behandlar, var det finns, hur loggen skyddas och — i samma dokument — vad denna leverantör inte påstår.

Vad AgentAudit behandlar

Endast det som dina agenter rapporterar: en tidsstämpel, en åtgärd, ett utfall och valfri kontext som du väljer att skicka — en motivering, en referens till ärendet, den modell- och policyversion som gällde, om en människa granskat det och vem.

Den samlar inget på egen hand. Det finns ingen spårning, berikning, sökning i andra källor eller slutledning. Om ett fält finns i din logg beror det på att din agent lade dit det.

De tekniska kontrollerna

Var och en av dem går att kontrollera. Filen är namngiven så att köparens tekniska bedömare kan läsa mekanismen i stället för att ta meningen på tro — och de tre första kan testas direkt från sidan Bevisa det.

• Ett beslut kan inte redigeras eller raderas när det väl har skrivits.

  Det tillämpas av databastriggers på UPDATE och DELETE, inte av applikationskod. Försök nekas även för tjänstrollen, som helt förbigår säkerheten på radnivå.

  supabase/apply-agentaudit.sql — och du kan själv köra försöket på sidan Bevisa det.

• Att radera en agent kan inte radera dess beslutshistorik.

  Främmandenyckeln från ett beslut till dess agent är ON DELETE RESTRICT, så föräldraraden kan inte tas bort så länge beslut refererar till den. Agenter avslutas, de raderas inte.

  supabase/apply-agentaudit.sql

• En kund kan inte läsa en annan kunds loggar.

  Säkerhetspolicyer på radnivå begränsar varje läsning och skrivning till anropande organisation. Databasen upprätthåller det, så ett fel i applikationskoden kan inte vidga det.

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

• API-nycklar lagras aldrig i en form som skulle kunna användas.

  Endast en SHA-256-hash av nyckeln sparas. Klartexten visas en gång vid skapandet och kan inte återskapas, så ett databasläckage ger ingen användbara inloggningsuppgifter.

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

• Innehållet i beslut skickas aldrig till en språkmodell.

  Det sker inget modellanrop någonstans i AgentAudit. Ingenting sammanfattas, klassificeras, poängsätts eller skrivs om av AI — bedömningen av efterlevnad och transparensregistret är deterministiska funktioner över räknade siffror.

  src/lib/agentaudit/ — sök igenom den efter ett modellanrop så hittar du inget.

• En motivering genereras aldrig.

  Resonemanget som lagras för ett beslut är precis det kundens agent rapporterade, ordagrant. Denna plattform skriver ingen, och SDK:n drar ingen slutsats när den omsluter en funktion.

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

• Verifiering kan göras utan oss.

  Hashalgoritmen är publicerad i sin helhet. En kund, en tillsynsmyndighet eller en motpart kan räkna om varje hash från en export med ungefär trettio rader av sin egen kod. Verifieraren i webbläsaren gör inga nätverksanrop när den körs.

  /agentaudit/docs#algorithm

Underbiträden

Tre, och inga andra är inblandade i hanteringen av en beslutslogg:

Lagring och frågan om radering

Ett beslut kan inte raderas. Det är hela produkten, och det drar åt motsatt håll mot rätten till radering enligt artikel 17 i UK GDPR. En dataskyddsombudsman kommer att ta upp det vid första mötet, så det tas upp här först.

Designens avsikt är att en beslutslogg inte innehåller några personuppgifter. Fältet subject är till för en referens — ett ärendenummer, en skadeidentifierare, en kontonyckel — inte ett namn. Hållen på det sättet beskriver loggen vad en agent gjorde i ärende 88213, och den personens identitet finns i dina egna system, där radering är något du faktiskt kan utföra.

Ingenting på den här plattformen upprätthåller det. Den lagrar det dina agenter skickar, så minimering måste ske vid källan, i din kod, innan beslutet rapporteras. Det är värt att skriva in i din integrationsdesign i stället för att upptäcka det senare.

Om artikel 17 överhuvudtaget är tillämplig på en viss driftsättning, och om något undantag gäller, är en juridisk fråga om ditt användningsfall. Denna leverantör besvarar den inte och är inte behörig att göra det.

Frågor till leverantö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.

Allt som driftsättningen kan fastställa om sig själv läses från det körande systemet i stället för att skrivas in — en sida som ber en människa komma ihåg vilken region hen driftsatte i kommer så småningom att uppge fel region med övertygelse. Resten är operatörens egna uppgifter, med egna ord.

Region the application runs inLäst från driftsättningen

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 numberÄnnu obesvarat

Ännu obesvarat. Visas som en lucka i stället för att fyllas i.

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 inÄnnu obesvarat

Ännu obesvarat. Visas som en lucka i stället för att fyllas i.

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 contactÄnnu obesvarat

Ännu obesvarat. Visas som en lucka i stället för att fyllas i.

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

En leverantör som överdriver ett certifikat har redan sagt till köparen allt de behöver veta om resten av påståendena. En ärlig lucka kostar ett uppföljningsmejl; en upptäckt överdrift kostar avtalet — därför förblir de obesvarade frågorna synligt obesvarade.

Den här sidan beskriver endast AgentAudit. Blackout Intelligence OS är en separat produkt med ett annat dataavtryck, och inget här ska läsas som att det täcker den.