Ongelma, josta harva puhuu yritysten tekoälyagenttien yhteydessä
CFO kysyy AI-agentilta: “Paljonko käytimme palkkoihin viime kvartaalilla?”
Agentti kutsuu palkka-APIasi. API palauttaa jokaisen työntekijän palkan, bonuksen ja henkilötunnuksen. Agentti tiivistää sen selkeäksi summaksi.
Toistaiseksi hyvä — CFO saa nähdä tiedot.
Harjoittelija esittää saman kysymyksen samalle agentille. Agentti kutsuu samaa APIa. API palauttaa saman hyötykuorman. Agentti vastaa.
Tämä on lähes jokaisen tuotannossa olevan “enterprise AI agent” -käyttöönoton hiljainen vikatila.
Miksi endpoint-tason RBAC ei riitä
Useimmat integraatioalustat — mukaan lukien meidän, kunnes äskettäin — suojaavat API-kutsuja endpoint-tasolla. Joko saat kutsua GET /payroll/employees tai et. Malli toimi, kun ihmiset rakensivat käyttöliittymiä, jotka suodattivat asiakaspuolella, ja ainoat kutujat olivat luotettuja taustapalveluja.
Agentit rikkovat mallin kahdella tavalla:
- Agentit ovat yleiskutsujia. Ne eivät tiedä, mitkä kentät pitää piilottaa. Ne tiivistävät kaiken saamansa.
- Agentit toimivat monen käyttäjän puolella. Yksi agenttiprofiili voi palvella toimitusjohtajaa ja varastotyöntekijää. Endpoint-RBAC ei erota heitä, kun pyyntö on jo valtuutettu.
Tulos: agenteista tulee confused deputy -ongelma teollisessa mittakaavassa. Käyttäjä ilman suoraa tietokantapääsyä voi poimia kaiken datan, mihin agentti yltää — oikealla kysymyksellä.
Missä lähdejärjestelmän RBAC jää lyhyeksi
Vastaus on usein “anna lähdejärjestelmän hoitaa”. Välitä käyttäjän identiteetti palkkajärjestelmään. Anna sen suodattaa.
Toimii — kun lähde tukee sitä. Käytännössä:
- Vanhat järjestelmät käyttävät usein yhtä palvelutiliä täydellä oikeudella. Ei käyttäjäkohtaista delegointia.
- Kolmannen osapuolen SaaS-API:t usein ilman rivitason oikeuksia. Joko admin-scope tai ei mitään.
- Omat sisäiset API:t rakennettiin ennen AI-agentteja. Kukaan ei lisännyt
filter_by_user. - Aggregaatit vuotavat. Vaikka rivisuodatus olisi, summat ja keskiarvot lasketaan usein koko joukolle.
CISO:lle tämä tarkoittaa, että altistuspinta määräytyy heikoimmasta liittimestä agentin työkalulaatikossa.
Puolustus syvyyssuunnassa: politiikkapohjainen vastausten suodatus
Olemme lisänneet Copyl Integration Platformiin uuden kerroksen: DataAccessPolicy. Se istuu lähdejärjestelmän vastauksen ja agentin välillä ja soveltaa deklaratiivisia sääntöjä palautettavaan dataan.
Mallissa on kolme ydintä:
1. Politiikat kiinnittyvät integraatiotoimiin, eivät agentteihin.
Palkka-endpointilla on yksi politiikka. Jokainen agentti — jokainen käyttäjä — käyttää samaa evaluaattoria. Väärin konfiguroitu agentti ei kierrä sääntöä.
2. Säännöt vastaavat subjektikontekstia, ei endpointia.
Evaluaattori näkee koko subjektin: käyttäjän, roolit, claimit, agenttiprofiilin, yrityksen. Sääntö voi olla “jos rooli sisältää CEO, salli kaikki rivit” tai “jos käyttäjä on Employee, palauta vain rivit joissa employeeId vastaa heidän ID:tään.”
3. Pushdown kun mahdollista, jälkisuodatus varalla.
Jos lähde-API tukee suodatusta, politiikka kirjoittaa pyynnön uudelleen — ?employeeId=42 — jolloin arkaluonteinen data ei poistu lähdejärjestelmästä. Ilman pushdownia vastaus suodatetaan palvelimella ennen agenttia.
Viimeinen kohta on tärkeä compliance-näkökulmasta. Suodatus kyselyhetkellä on aidosti turvallisempaa kuin jälkikäteen. Jälkisuodatus on syvyyspuolustus, ei korvike lähdekontrolleille.
Sec/Compliance-tiimin näkökulma
Kolme ominaisuutta tekee tästä hallittavaa:
Tilintarkastettava. Jokainen evaluointi kirjoittaa audit-merkinnän: mikä politiikka, mikä sääntö, montako riviä sisään/ulos, montako kenttää maskattu. Vastaus kysymykseen “kuka näki palkkatiedot tiistaina ja mitä suodatettiin?” SQL-kyselyllä.
Versioitu. Luonnos → julkaistu → arkistoitu. Jokainen muutos on uusi versio. Diff, palautus ja todiste aktiivisesta versiosta tietyllä päivämäärällä.
Testattavissa ennen julkaisua. Dry-run — suodatus evaluoidaan ja logataan, vastausta ei muuteta. Validointi oikeaa liikennettä vasten viikkoja. Julkaisu vaatii läpäistyn testin tai eksplisiittisen ohituksen.
Säännellyillä aloilla (finanssi, terveys, julkinen sektori NIS2/DORA Euroopassa) “luota agenttiin” muuttuu “todista agentti”.
Mitä se ei ratkaise
Rehelliset rajat:
- Lähdejärjestelmän delegointi on parempi kun saatavilla. Käytä ensin. Politiikkasuodatus on kun et voi.
- Aggregaatit ovat hankalia. Rivisuodatus yhden palkan kanssa ja kenttä
total: 4 200 000koko henkilöstölle vuotaa. Mallimme tunnistaa aggregaattikentät ja joko virhettää, poistaa tai vaatii opt-in — endpoint-kohtaista ajattelua tarvitaan. - Kenttämaskaus ei ole salausta. Tiivistetyt henkilötunnukset ovat yhä henkilötietoja. Maskaus pienentää vahinkoa; velvoitteet jäävät.
- Politiikat ovat vain yhtä hyviä kuin säännöt. Väärä subjektimatch yli- tai alisallii. Siksi testiajot ja audit-näkyvyys.
Käytännön merkitys
Jos ajat AI-agentteja järjestelmiä vastaan ilman rivitason RBAC:ia — useimmat legacy-ERP:t, palkat, omat API:t ennen 2024 — sinulla on altistus, jota endpoint-tason valvonta ei sulje.
Korjaus on rakenteellinen, ei prompt-temppu. “Näytä vain käyttäjän omat tiedot” vain system promptissa kestää seuraavaan jailbreakiin. Pakota integraatiokerroksessa versioitavalla, auditointikelpoisella politiikalla — sitten CISO voi hyväksyä.
Otamme DataAccessPolicyn käyttöön Copyl marketplace -agenteissa, aluksi palkka-, HR- ja finanssiintegraatioissa. Jos operoit säännellyssä ympäristössä ja haluat käydä läpi missä altistus on omassa pinossasi, ota yhteyttä.
Copyl on alusta yritysten tekoälyagenttien rakentamiseen, käyttöönottoon ja hallintaan. Integration Platform (CIP) yhdistää agentit liiketoimintajärjestelmiin päästä päähän -politiikan, audit-lokituksen ja versionhallinnan kanssa.