Tarkastele tekoälytoimintoa: valtuutus, tulos ja vahvistettu tila

Hyvä audit‑polku ei vastaa ainoastaan “mitä malli sanoi?”. Se vastaa kuka pyysi toimintoa, mitä järjestelmä valtuutti, mitä työkalua käytettiin, mitä kohdejärjestelmässä tapahtui ja mikä tila jäi jäljelle toiminnon jälkeen.

Tämä ero on merkittävä. Koko prompti ja vastaus voivat auttaa vianmäärityksessä, mutta ne eivät korvaa operatiivista tallennetta. Ne voivat myös sisältää tietoja, joita ei koskaan pitäisi kopioida lokijärjestelmään.

Aloita tapahtuman rekonstruointikysymyksestä

Kuvitellaan, että agentti muutti kampanjabudjettia tai käyttäjän oikeuksia kaksi viikkoa sitten. Tänään joku kysyy:

• kuka aloitti muutoksen;
• oliko operaattori valtuutettu pyytämään sitä;
• miten operaatio luokiteltiin;
• vaatiiko se ihmisen hyväksyntää;
• kuka hyväksyi tarkalleen mitä;
• mitkä relevantit parametrit välitettiin työkalulle;
• mitä ulkoinen palveluntarjoaja palautti;
• vahvistettiinko tuloksena syntynyt tila;
• mikä versio turvallisuuspolitiikasta oli voimassa.

Jos näihin kysymyksiin vastaaminen edellyttää chat‑historian, HTTP‑lokien, tietokannan ja palveluntarjoajan konsolin manuaalista yhdistämistä, meillä on lokeja. Meillä ei vielä ole kunnollista audit‑polkua.

Vähimmäistoimintarekisteri agentille

Jokainen järjestelmä on erilainen. Työkaluja käyttävien agenttien hyödyllinen ydin on:

Kenttä	Miksi tallentaa
event_id	yksilöi tapahtuman
timestamp	järjestys ja aikaleima
operator_id	henkilö tai päämies, joka pyysi toimintoa
agent_id / agent_version	tunnistaa käytetyn agentin/mallin
task_id / correlation_id	yhdistää useita kutsuja yhdeksi työnkuluksi
tool	käytetty työkalu tai menetelmä
operation_class	read / write / operate / destructive tai paikallinen vastaava
target_resource	tili, tenantti, projekti tai muu kohde
authorization_decision	allow / deny sekä käytetyt scope‑t tai politiikat
approval_id	todiste hyväksynnästä, jos vaadittu
request_fingerprint	normalisoitujen parametrien sormenjälki, kun koko dataa ei tarvita
provider_result	hallittu tulos ilman salaisuuksia
resulting_state	tila luettu muutoksen jälkeen tai todisteviite
policy_version	suorituksen aikaan voimassa ollut sääntöpaketti

Ei tarvitse tallentaa jokaista arvoa tekstinä samassa rekisterissä. Jotkut voivat viitata erillisiin todisteartefakteihin. Tärkeintä on, että ketju voidaan rekonstruoida johdonmukaisesti.

Keskustelulokit ja audit‑polut ratkaisevat eri ongelmia

Keskusteluloki tarjoaa kontekstin

Se voi näyttää, mitä käyttäjä pyysi, mitä malli vastasi ja mitä tietoa istunnossa oli.

Audit‑polku tarjoaa toteutustodisteen

Sen tulisi näyttää:

operaattori
→ valtuutuspäätös
→ työkalu
→ toimintaan vaikuttavat parametrit
→ hyväksyntä, jos vaadittu
→ palveluntarjoajan tulos
→ tuloksena syntynyt tila

Jos malli kirjoittaa “kampanja on pysäytetty”, mutta työkalutapahtumaa tai kohdejärjestelmästä luettua tilaa ei ole, meillä on väite. Meillä ei ole toteutustodistetta.

Mitä tavallisesti kuuluu sensurointiin tai poissulkemiseen

Lisää lokitietoa ei automaattisesti tee audit‑polusta parempaa. Se voi kasvattaa tietovuotoriskiä.

Sisäisessä Brillnet Ads MCP -järjestelmässämme poissuljetaan audit‑tietueista tunnistetiedot, valtuutusotsikot ja raakat henkilötunnisteet. Sama periaate on hyödyllinen muuallakin.

Älä lokita salaisuuksia

• API‑avaimet;
• access‑ tai refresh‑tokenit;
• yksityiset avaimet;
• salasanat;
• istuntokeksit;
• täydelliset Authorization‑otsikot.

Jos audit‑tietueen täytyy näyttää, mitä identiteetti‑ tai avaintunnusta käytettiin, tallenna turvallinen viite‑tunniste salaisuuden sijaan.

Älä kopioi jokaista pyyntöä ja vastausta automaattisesti

Raaka API‑vastaus voi sisältää henkilötietoja, luottamuksellisia kenttiä tai tietoa, joka ei ole audit‑tarkoituksen kannalta relevanttia. Valitse metatiedot, jotka ovat tarpeen päätöksen ja tuloksellisen tilan kannalta.

Älä tee täysistä promptista pakollista osaa audit‑tietueessa

Promptit voivat olla hyödyllisiä diagnostiikassa. Ne voivat myös sisältää asiakasdokumentteja, henkilötietoja tai vahingossa liitetyn salaisuuden. Promptien säilyttämisen tulisi noudattaa erillistä tietojen säilytys‑ ja käyttöoikeuspolitiikkaa, eikä oletusta “AI‑järjestelmä = lokita kaikki”.

Sensuroi ennen tallentamista

Jos tallennamme ensin koko payloadin ja maskaamme myöhemmin, salaisuus on jo päässyt lokijärjestelmään.

Turvallisempi kulku on:

työkalu palauttaa tuloksen
↓
normalisointi
↓
kenttien luokittelu
↓
sensurointi / pseudonymisointi
↓
audit‑tietueen tallennus

Herkkä data voi pysyä lähdejärjestelmässä, jossa on omat käyttö‑ ja säilytyskontrollinsa. Audit‑järjestelmän tulisi säilyttää vain se vähimmäismäärä, joka riittää päätöksen ja vaikutuksen rekonstruointiin.

Write‑after‑read sulkee aukon “kutsuttu” ja “muutettu” välillä

Kirjoitustoiminnoissa tallennamme paitsi kutsun tuloksen myös – kun palveluntarjoaja sen sallii – kohderessurssin tilan luettuna muutoksen jälkeen.

Esimerkki:

14:02:11 kirjoituspyyntö: kampanjan tila → PAUSED
14:02:12 palveluntarjoaja: success
14:02:13 read‑after‑write: campaign.status = PAUSED

Tämä mahdollistaa erottelun:

• agentti pyysi muutosta;
• palveluntarjoaja hyväksyi pyynnön;
• resurssi oli odotetussa tilassa, kun se tarkistettiin.

Tämä ei todista, että tila ei olisi muuttunut sekunnin kuluttua. Se on silti paljon vahvempi todiste kuin mallin viesti “valmis”.

Hyväksyntä on itsenäinen audit‑tapahtuma

Ihmisen hyväksynnän tulisi omaa tunnisteensa ja sitoutua tiettyyn operaatioon.

Käsitteellinen tietue voi sisältää:

approval_id: apr_...
approved_by: operator_...
approved_at: 2026-09-12T14:01:44+02:00
action_hash: sha256(...)
operation: ENABLE_CAMPAIGN
target: campaign_...
expires_at: ...

Suorittaja voi sitten tarkistaa, että hyväksyntä on olemassa juuri tälle operaatio­versiolle sen sijaan, että luottaisi chat‑viestiin “käyttäjä suostui”.

Read: When should an AI agent require human approval?

Eheyden varmistus: vain‑lisäyspäätteet ja hash‑ketjut

Sisäisessä Ads MCP -työkalussamme audit‑tietueet ovat vain‑lisäyspäätteisiä ja hash‑ketjutettuja. Tavoitteena on tehdä hiljaisen historian muokkauksen havaitseminen helpommaksi.

Käsitteellisesti:

record_1 + hash(record_1)
↓
record_2 contains hash(record_1)
↓
record_3 contains hash(record_2)

Jos vanhempaa tietuetta muutetaan, myöhemmät linkit eivät enää täsmää.

Tämä ei ole taianomainen muuttumattomuus. Järjestelmänvalvoja, jolla on riittävät oikeudet, voi silti tuhota lokijärjestelmän tai koko tallennustilan. Tietueiden eheys tulisi siksi yhdistää:

• rajoitettuun lokien käyttöön;
• määriteltyyn säilytykseen;
• varmuuskopiointiin/vientiin, kun se on perusteltua;
• valvontaan aukkojen tai ketjuvirheiden varalta;
• hallittuihin aikoihin ja tunnisteisiin.

Hyödyllinen telemetria MCP‑työkaluille

tools/call‑tai vastaavan paikallisen toiminnon yhteydessä hyödyllisiä kenttiä ovat usein:

• työkalun nimi;
• riskiluokka;
• normalisoidut resurssitunnisteet;
• arvioidut scope‑t;
• valtuutuspäättös;
• näytettiinkö toiminnon esikatselu;
• hyväksyntätunniste;
• aloitus‑ ja lopetusaika;
• palveluntarjoajan tila;
• hallittu virhekoodi;
• tapahtuiko uudelleenyrittäminen;
• idempotenssi‑avain tai sen turvallinen sormenjälki;
• kirjoituksen jälkeen syntynyt tila;
• malli/agentti‑tunniste diagnostiikkaa varten.

Tämä ei vaadi kaikkien raaka‑työkalun argumenttien tallentamista.

Entä chain‑of‑thought (ajatusketju)?

Emme tarvitse mallin sisäistä ajatusketjua luodaksemme käyttökelpoisen operatiivisen audit‑polun. Tarvitsemme havaittavissa olevat faktat:

• päätökseen vaikuttava syöte;
• valittu toiminto;
• sovellettu politiikka;
• hyväksyntä;
• tulos;
• tuloksellinen tila.

Kun perustelu on hyödyllinen, agentti voi kirjoittaa lyhyen eksplisiittisen decision_reason‑kentän tarkastelua varten. Tämä eroaa mallin piilotetun päättelyprosessin säilyttämisestä.

Säilytys: “ikuisesti” on yleensä huono oletus

Jokaiselle tapahtumatyypille määrittele:

• käsittelyn tarkoitus;
• säilytysaika;
• kuka voi käyttää tietoja;
• voidaanko dataa aggregoida tai pseudonymisoida;
• milloin tietue on liiketoimintatodiste vs. insinööritelemetria;
• miten laillinen/operatiivinen poisto toteutetaan, jos se on vaadittu.

Älä pidä debug‑telemetriaa ja virallisia päätöstietueita yhdessä loputtomiin ilman perusteltua syytä.

Esimerkkitapaus: tapahtuman rekonstruointi

Tilanne: kampanja alkoi kuluttamaan rahaa, vaikka sen oli pitänyt pysyä pysäytettynä.

Hyvän audit‑polun tulisi antaa seurata:

1. task_id — mistä pyyntö tuli;
2. operator_id — kuka sen aloitti;
3. tool — mikä työkalu valittiin;
4. operation_class=operate — miksi lisäkontrolli tuli;
5. approval_id — oliko joku todella hyväksynyt aktivoinnin;
6. parametrit — mitä tila ja budjetti hyväksyntä kattoi;
7. provider‑result — mitä Google Ads hyväksyi;
8. read‑after‑write — mikä tila havaittiin suorituksen jälkeen;
9. myöhemmät tapahtumat — muuttuiko tila myöhemmin toisen toimijan toimesta.

Ilman tätä ketjua joudumme lukemaan chat‑historian ja arvailemaan.

AI‑agenttien audit‑polun tarkistuslista

• Jokaisella merkittävällä tapahtumalla on uniikki ID ja aikaleima.
• Operaattorin identiteetti ja agentin identiteetti erotetaan.
• Useita kutsuja voidaan yhdistää yhdeksi task‑/correlation‑ID:ksi.
• Valtuutuspäätökset kirjataan, ei vain onnistuneita kutsuja.
• Hyväksyntä on erillinen, tarkistettava tapahtuma.
• Tulosvaikutukseen vaikuttavat parametrit tallennetaan tai sormenjälkitetään.
• Salaisuudet ja valtuutusotsikot poistetaan ennen tallentamista.
• Henkilötiedot minimoidaan / sensuroidaan.
• Uudelleenyrittämiset ja idempotenssi ovat havaittavissa.
• Kirjoituksilla on palveluntarjoajan tulos ja, jos mahdollista, read‑after‑write‑todiste.
• Politiikkaversio voidaan rekonstruoida.
• Audit‑pääsy on tiukemmin rajoitettu kuin tavallinen sovellus‑pääsy.
• Säilytys on määritelty eikä vahingossa tapahtuva.
• Polun eheyttä valvotaan.

Kenelle tämä opas on tarkoitettu

Prosessinomistajat ja kehittäjät tarvitsevat toteutustodisteita. Esimerkkitoimintoja ovat valmistuksen laatu­lippujen muuttaminen, kiinteistönomistajille ilmoitusten lähettäminen ja IT‑pääsyn hallinta. Nämä ovat suunnitteluskenaarioita, eivät väitteitä olemassa olevista toteutuksista; prosessi määrittää tarvittavan todistusaineiston.

Ads MCP on sisäinen suunnitteluesimerkki Brillnet‑omistamille tileille, eikä se edusta asiakaspalvelua tai itsenäistä tuotantoarviota.

Tuntematon tulos on pidettävä näkyvästi tuntemattomana

Aikakatkaisu ei todista epäonnistumista: palvelin on saattanut suorittaa kirjoituksen ennen vastauksen katoamista. Erota requested, accepted, verified ja unknown. Älä raportoi epävarmuutta onnistumisena.

Integraatio‑omistaja määrittelee sovituksen käyttäen palveluntarjoajan job‑tunnistetta tai resurssiviitettä. Ota operaattori mukaan ennen toistamista, jos korkean vaikutuksen toimenpiteet ovat ratkaisematta. Lisää linkitetty sovitustapahtuma sen sijaan, että kirjoitat historiaa uudelleen.

Viivästynyt kirjoituksen näkyvyys vaatii samaa huolellisuutta. Vanha tila voi heijastaa palveluntarjoajan konsistenssimallia. Kirjaa havaintoaika ja rajoitus. Uudelleenyrittämisille on asetettava rajallinen määrä ja lopullinen tila, jonka ihmiset ymmärtävät.

Päätä, mitä tapahtuu audit‑toimituksen epäonnistuttua

Lokit voivat menettää yhteyden, täyttyä levytilasta tai hylätä tietueita. OWASP suosittelee epäonnistumisten testaamista. Päätä erikseen, mitkä seuraukset voivat jatkua viivästyneen toimituksen aikana ja mitkä vaativat kestävää päätöstodistetta ensin.

Tämä ei edellytä koko yrityksen pysäyttämistä yhden puuttuvan diagnostiikkaviestin takia. Erottele rutiini‑telemetria operaatioiden hyväksynnän todistuksesta. Oikeuksien muutos voi vaatia kestävää valtuutustodistetta ennen suoritusta; julkisen manuaalin lukeminen voi sallia rajatun metadatan puskurin. Nämä ovat esimerkkisuunnittelupäätöksiä, eivät universaaleja OWASP‑vaatimuksia.

Puskuri tarvitsee kapasiteettirajat, käyttöoikeusrajoitukset ja viivevalvonnan. Säilytä alkuperäiset tunnisteet ja tapahtuma‑ajat palautuksen aikana. Seuraa puuttuvia tapahtumia erottamaan passiivisuus hukkatun näkyvyyden sijaan. Lähetä hälytys henkilölle, joka voi palauttaa tallennuksen tai keskeyttää kyseisen toimintaluokan.

Sormenjälki ei automaattisesti poista yksityisyysriskiä

Sähköpostiosoitteen hash‑arvo voi edelleen tunnistaa henkilön vertaamalla lyhyeen tunnettujen osoitteiden listaan. Jos operaattorin tunnistaminen on tärkeää, harkitse satunnaista sisäistä tunnistetta ja erillistä suojattua kartoitusta. Audit‑lukijoilla ei automaattisesti tarvitse olla tätä kartoitusta.

request_fingerprint‑kenttä tarvitsee myös määritellyn normalisointimenetelmän ja skeemaversiot. Hash‑arvo ei riitä, jos kukaan ei pysty todistamaan, mitä se kattoi. Määrittele turvallinen todistepaikka, mutta vältä koko asiakirjan säilyttämistä pelkästään hash‑arvon uudelleenlaskemiseksi. Prosessin omistaja määrittelee todisteiden tarpeet; tietosuojavastaava tarkistaa säilytettävän datan.

Rekonstruktio ilman agenttia

Käytä fiktiivistä palvelupyyntöä. Operaattori hyväksyy ilmoituksen lähettämisen tietylle toimittajalle. Agentti valitsee työkalun, portti tarkistaa scope‑t ja palvelin kirjaa tuloksen sekä viestin tunnisteen. Toisessa suorituksessa vastaanottajaa muutetaan hyväksynnän jälkeen. Suoritus tulisi hylätä ja kirjata syy. Käytä testidataa eikä oikeita asiakastietoja.

Anna riippumattomalle tarkastajalle todistepaketti. Hänen tulisi pystyä vahvistamaan operaattori, hyväksytty sisältö, vastaanottaja, sovellettu politiikka ja todellinen vaikutus. Jos tarkastaja joutuu kysymään agentilta, mitä se aikoi, paketti on puutteellinen. Korjaa puuttuva yhteys sen sijaan, että tallentaisit koko keskustelun automaattisesti.

Prosessin omistaja hallitsee hyväksyntää. Kehittäjä toimittaa viennit ja hallitut virheet. Lokihallinnon ylläpitäjä tarkistaa käyttöoikeudet ja paketin eheyden. Pienessä yrityksessä yksi henkilö voi kantaa useita rooleja, mutta roolit on silti määriteltävä selkeästi.

Mitä tehdä huomenna

Valitse yksi merkittävä toiminto ja tunnista jokainen järjestelmä, joka sen tallentaa. Lisää yhteinen korrelaatiotunniste. Listaa säilytettävät kentät ja poissuljetut kentät. Suorita yksi sallittu ja yksi hylätty yritys testidatalla, ja rekonstruoi molemmat viennistä.

Mittaa merkittävät toiminnot täydellisillä poluilla, ratkaisemattomilla tuloksilla ja viiveellä toiminnon ja saatavilla olevan todisteen välillä. Aseta prosessikynnys. Lokimäärä ei todista hyödyllisyyttä: yksi puuttuva askel vaatii silti tutkimusta.

Tekninen suositus ei määrittele laillista säilytystä

NIST SP 800‑92 käsittelee lokien hallintaa. AU‑kontrolliryhmä NIST SP 800‑53:ssa auttaa järjestämään audit‑vaatimuksia; kumpikaan asiakirja ei myönnä sertifiointia tai aseta yhtä säilytysaikaa kaikille yrityksille. OWASP ei ole lainsäädäntö. Tunnista lailliset ja sopimusperusteiset velvoitteet erikseen, niiden soveltamisala ja peruste. Tämä opas ei määrää lainmukaista tietojen säilytysaikaa.

Rajaus

Audit‑polku ei automaattisesti todista, että päätös oli oikea. Se todistaa, mitä järjestelmä on kirjannut siitä, miten toiminto valtuutettiin ja toteutettiin. Säännellyt prosessit saattavat vaatia lisävaatimuksia eheyden, säilytyksen, yksityisyyden ja todisteiden laadun osalta.

Katso myös Least privilege for AI agents ja Brillnet Security.

Synteettinen rahoitusoperaatioharjoitus

Käytä omaa esittelyympäristöä kuvitteellisella laskulla. Ehdotettu agenttitoiminto muuttaa laskun sisäisen tarkistuksen tilan; se ei liikuta rahaa. Anna operaattorille ja agentille erilliset identiteetit, rajoita tietueen laajuutta ja vaadi asianmukaista henkilöä valtuuttamaan toiminto. Tallenna käytäntöversio ja päätös tallentamatta valtuustietoja tai täydellistä luottamuksellista kopiota.

Lue sallitun toimenpiteen jälkeen laskun tila ja asiaankuuluva muutoshistoria. Vertaa niitä pyydettyyn tulokseen. Tekninen vastaus, jossa lukee hyväksytty, ei ole todiste aiotun muutoksen tapahtumisesta. Säilytä pyynnön tunniste, tulos ja viittaus tarkistettuun tilaan, jotta toinen henkilö voi rekonstruoida sekvenssin.

Yritä sitten suorittaa esittelykäytännön ulkopuolelle jäävä toimenpide. Tarkista kieltäytyminen ja varmista, että asianomainen tila ei ole muuttunut. Tämä osoittaa tietyn rajan kuvitteellisessa asetelmassa. Se ei ole todiste siitä, että jokaisella agenttityökalulla, talousjärjestelmällä tai asiakasympäristöllä on sama valvonta.

Käytä Pulsaria valvontavaatimuksen, omistajan, harjoitustoiminnan ja todisteiden tallentamiseen. 14 päivän kokeilu testaa vaatimustenmukaisuuden työnkulkua. Se ei sisällä täydellistä agenttitoiminnan auditointialustaa, pankkiyhteyttä tai maksun valtuutuspalvelua. Todellinen integraatio tai pilotti tarvitsee erikseen sovitun laajuuden. Tarkista kokeilujakson vaadittu maksutapa, valittu sopimus ja peruutusehdot ennen aloittamista.

Lähteet

Tekniset lähteet tukevat esitettyjä periaatteita. Toteutusskenaariot ja toimintasuunnitelma ovat kirjoittajan suunnittelusuosituksia.

• OWASP AI Agent Security Cheat Sheet — accessed: 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — accessed: 2026-10-02. Lähteet tarkistettu: 2026-10-10.
• OWASP — Logging Cheat Sheet — Hyödyllisiä tapahtumatietoja ja poissuljettuja arkaluonteisia tietoja.
• NIST SP 800-92 — Log Management — Lokinhallinta.
• NIST SP 800-53 Rev. 5 — Kulunvalvonta ja auditointi-valvontaperiaatteet.
• MCP — security best practices — Integroinnin turvallisuus ja valtuutusrajat.
• Pulsar GRC — actual scope — Vaatimukset, valvonta, todisteet ja kokeilujakso.
• Julkaistu tuotevalikoima ja kokeiluehdot — Julkaistu tuotevalikoima ja kokeiluehdot.

Tarkista ehdot ja aloita 14 päivän kokeilu

Tekoälyagenttien vähimmät käyttöoikeudet SaaS-palvelussa

Elintarviketuotannon CAPA: poikkeamasta vaikuttavuuden arviointiin

Lääkealan SOP muuttunut: tarkista koulutus- ja lähdeversio