Vangrails voor AI-agents en veiligheid in Jira

Met guardrails kun je AI (op)schalen door vertrouwen op te bouwen met agentische workflows. De systemen die werken, zijn ingebouwd in je workflows, zodat het systeem ze afdwingt in plaats van erop te vertrouwen dat de agent dat doet.

In Jira is dat systeem het systeem waarin je team al werk uitvoert. Jira geeft een agent de toegang die die moet hebben via machtigingen, controlepunten waar mensen hun oordeel toepassen op workflowovergangen, en een registratie van elke actie van de agent op het werkitem. De Teamwork Graph geeft de agent de juiste context om mee te werken.

In deze handleiding worden de risico's behandeld die guardrails voor agents aanpakken en hoe je die in Jira kunt afdwingen, zodat je AI veilig en verantwoord kunt opschalen en agents meer autonomie kunt geven binnen het werk van je team, van routinematige taken om de boel draaiende te houden tot projecten met meer waarde, zonder de controle te verliezen. Autonomie op die schaal berust op vier richtlijnen die je in Jira instelt met de workflows, machtigingen en regels die je team al gebruikt:

• Bereik toegang. Stel via je bestaande Jira-machtigingen in welke gegevens een agent kan bereiken, welke tools de agent kan gebruiken en waar de agent kan handelen.

• Beperk de risicovolle oproepen Gebruik workflowovergangen om menselijke goedkeuring te vereisen voordat werk met grote impact wordt doorgevoerd.

• Controleer de uitvoer. Controleer wat de agent heeft gemaakt via je normale beoordeling van pull requests voordat het wordt uitgerold.

• Bewaar de record. Elke agentactie komt in de geschiedenis van het werkitem terecht, gekoppeld aan wie deze heeft goedgekeurd.

Wat zijn guardrails in agentic engineering?

Guardrails voor agents zijn de controles waarmee het werk van een AI-agent veilig blijft, bedoeld is en wordt vastgelegd: waar de agent toegang toe heeft, de controlepunten waarop een persoon ingrijpt en de registratie van wat de agent heeft gedaan. Een randvoorwaarde wordt afgedwongen door het systeem waarin de agent werkt, en wordt niet aan de agent zelf overgelaten om die na te leven.

Je kunt een agent niet veilig maken door die te instrueren zich op een bepaalde manier te gedragen, omdat Instructies vergeten, verkeerd gelezen of overschreven kunnen worden. Een echte beveiligingsgrens bevindt zich boven de agent, in de omgeving, waar de grens standhoudt, ongeacht wat de agent wordt verteld. Het is hetzelfde principe waarop je team al werkt: het systeem bepaalt wat mogelijk is, niet de persoon die wordt gevraagd de regels te volgen.

In de praktijk omvatten gebruikslimieten voor agents een paar samenhangende gebieden:

• Toegang en scope. De gegevens waar een agent bij kan, de tools die de agent kan gebruiken, en waar de agent kan handelen.

• Begrensde taken. Welk werk een agent volledig kan bezitten en welk werk bij een persoon blijft.

• Goedkeuring met menselijke tussenkomst. De controlepunten waarop iemand een beoordeling of goedkeuring geeft voordat werk verdergaat.

• Beoordeling van uitvoer. Valideren wat de agent heeft gemaakt voordat het wordt geleverd.

• Verantwoordelijkheid en controle. Een overzicht van wat de agent heeft gedaan, waarom en wie goedkeuring heeft gegeven.

• Toezicht. De permanente instellingen die dit alles consistent houden naarmate het gebruik van agents toeneemt.

Samen zorgen deze voor vertrouwen in agentgestuurde workflows. Ze zorgen ervoor dat een team agents meer verantwoordelijkheid kan geven zonder de controle te verliezen, omdat een persoon verantwoordelijk blijft voor het resultaat.

Waarom hebben AI-agents gebruikslimieten nodig?

Agents handelen. Anders dan een chatbot die alleen suggesties doet, kan een agent code wijzigen, werk verplaatsen en echte acties triggeren in al je tools. Die autonomie maakt ze nuttig, en daarom hebben ze ook gebruikslimieten nodig: hoe meer een agent zelfstandig kan doen, hoe belangrijker het is dat het werk ervan op elkaar is afgestemd, wordt gecontroleerd en dat er verantwoording over kan worden afgelegd.

De belangrijkste risico's die gebruikslimieten aanpakken, en waar menselijk oordeel essentieel blijft:

• Verkeerde afstemming: de agent optimaliseert voor het verkeerde of wijkt af van de taak.

• Uitvoer van lage kwaliteit of onjuiste uitvoer: werk dat er voltooid uitziet maar de plank misslaat, inclusief verzonnen code of feiten.

• Te brede toegang: de agent heeft toegang tot gegevens of systemen waartoe die geen toegang zou mogen hebben.

• Niet-beoordeelde, onomkeerbare acties: ingrijpende veranderingen die je niet eenvoudig ongedaan kunt maken, zoals naar productie overzetten of gegevens verwijderen, waarvoor een menselijke controle nodig is voordat ze worden doorgevoerd.

• Geen verantwoordelijkheid of zichtbaarheid: zonder verslag kan niemand zien wat de agent heeft gedaan of wie goedkeuring heeft gegeven.

• Onbeheersbare kosten: agents kunnen tokens en rekenkracht heel wisselvallig verbruiken, dus uitgaven hebben net als elke andere resource limieten nodig.

Een gebruikslimiet werkt alleen als het systeem die afdwingt, niet de agent. Tegen een agent zeggen wat die niet moet doen, wordt niet beschouwd als gebruikslimiet, omdat de agent dat te horen kan krijgen en het alsnog kan doen zonder dat jij daarvan op de hoogte bent. Echte gebruikslimieten bevinden zich boven de agent, in de omgeving waarin die werkt, zodat de ongewenste actie niet mogelijk is, en niet alleen wordt ontmoedigd.

Daarom zijn gebruikslimieten de randvoorwaarde voor autonomie, en geen belemmering daarvoor. Teams die vertrouwen op de grenzen kunnen agents meer verantwoordelijkheid geven met minder direct overzicht. Teams die dat niet kunnen, verliezen de snelheid waarvoor ze agents hebben ingezet.

Hoe beheer je AI-agents veilig in Jira?

Als een gebruikslimiet boven de agent moet staan in het systeem waarin de agent werkt, dan is dat systeem wat telt, en voor engineeringwerk is dat Jira. Wanneer agents werken binnen het System of Work van Atlassian, krijgen ze toegang tot je gegevens en werkitems via dezelfde Jira-rechten die je team al gebruikt, plus je bestaande workflows en auditspoor. Wat een agent binnen de eigen omgeving kan doen, wordt nog steeds beheerd door de agent, dus Jira regelt de toegang tot het werk, terwijl rechten op agentniveau bepalen welke tools de agent gebruikt.

Op zichzelf stuurt een coderingsagent alleen de eigen acties aan. Jira beheert het werk, dus gebruikslimieten zijn op één plek van toepassing op elke agent, en je kunt zien welk risico elke agent aanpakt.

In de workflows vind het grootste deel van die tenuitvoerlegging plaats. De statussen, transities en regels die werk tussen mensen routeren, routeren het ook naar agents, bepalen welke transities een agent mag uitvoeren en houden ingrijpende veranderingen vast voor goedkeuring.

Toegang: wat je kunt beheren in Jira

De eerste controle is scope: met welke gegevens, tools en projecten een agent kan werken. Dit is de bescherming tegen een te brede toegang. In Jira stel je de scope op dezelfde manier in als voor elke teamgenoot, dus het voelt vertrouwd en je kunt de scope naar wens afstemmen.

• Hoe het werkt in Jira: je kiest de identiteit waarin een agent optreedt. Standaard handelt de agent namens de persoon erachter en heeft deze alleen toegang tot de gegevens, projecten en werkitems waartoe die persoon toegang heeft. Je kunt een agent ook een eigen account en rechten geven, zodat de toegang niet van één persoon afhangt. Beheerders bepalen welke agents actief zijn en waar ze zich bevinden. Wat een agent met de eigen tools kan doen, wordt ingesteld door de agent, niet door Jira. Houd de toegang breed of beperk de scope sterk, en breid die uit naarmate het vertrouwen groeit.

• De beheermogelijkheden die je afstemt. Dit zijn dezelfde opties voor rechten die je al voor mensen gebruikt: toestemmingsschema's en projectrollen bepalen wat een agent in een project kan doen, en werkitembeveiliging beperkt welke specifieke werkitems de agent kan zien. Als je een van deze aanscherpt, vergroot je het bereik van de agent, zonder een agentspecifiek systeem.

• Geef toegang tot wat nodig is voor de taak. De meeste agents werken het best als ze de ruimte hebben om te bewegen, dus stem de scope af op de taak. Voor echt gevoelige systemen moet je die ruimte specifiek achterwege laten.

Hoe bepaal je wat agents doen in je workflow?

De tweede gebruikslimiet is de workflow: de regels die bepalen wanneer een agent actief is, wat de agent zelfstandig kan doen en voor welke acties een mens nodig is. Deze vormt je bescherming tegen verkeerde afstemming en onomkeerbare acties. Je stelt deze regels in voor de transities die je team al gebruikt, zodat toezicht niet neerkomt op één enkele controle aan het einde is.

Met een transitievoorwaarde beperk je op welke fasen een agent actie kan ondernemen, een validator blokkeert werk dat nog niet klaar is, en een goedkeuringsstap houdt ingrijpende veranderingen tegen voor een persoon. Menselijke goedkeuring is een van de vele regels, en het doel is om elke regel af te stemmen op het risico.

• Hoe stel je dit in Jira in: open de workflow voor het werktype en voeg een agent toe aan een transitie, bijvoorbeeld bij het invoeren van 'Wordt beoordeeld' zodat de agent wordt uitgevoerd wanneer een werkitem dat punt bereikt. Het toevoegen van een agent bepaalt wanneer die wordt uitgevoerd, niet of een persoon goedkeuring geeft. Menselijke goedkeuring is een afzonderlijke controle: een goedkeuringsstap in de workflow bepaalt of de transitie plaatsvindt, en je kunt die combineren met de eigen instructies van de agent over wanneer deze moet pauzeren en vragen moet stellen, of met een automatiseringsregel. Een transitie is een van de vele startpunten. Een agent kan ook starten wanneer:

  • Werk wordt aangemaakt, dus het wordt beoordeeld zodra het binnenkomt

  • Een label of veld wijzigt, of volgens een planning, via een automatiseringsregel

  • Het wordt op de achtergrond uitgevoerd voor routinematige updates, zoals het opstellen van releasenotes.

• Stem de controle af op het risico. Laat werk met een laag risico zelfstandig worden uitgevoerd (een verhoging van afhankelijkheid), breng een persoon op de hoogte van werk met een gemiddeld risico (een wijziging in gedeelde configuratie) en vereis goedkeuring voor acties met een hoog risico of onomkeerbare acties (productie starten of gegevens verwijderen).

• Bepaal welke taken de agent voor zijn rekening neemt. Bepalen wat een agent voor zijn rekening neemt, gaat vooraf aan het instellen van het controlepunt. Laat een agent werk met een laag risico volledig afhandelen, zet werk met meer impact klaar zodat een persoon het kan afronden, en laat de beslissingen met de grootste gevolgen afhandelen door een mens. Het afbakenen van de taak is de eerste beslissing, het controlepunt is hoe je de taak afdwingt.

• Geef agents hun eigen instructies. Je bepaalt hoe een agent zich moet gedragen en werk in beweging moet houden, waaronder welke beslissingen de agent zelf mag nemen en wanneer de agent moet wachten en iets moet vragen, zodat de agent de afspraken van je team volgt in plaats van algemene standaarden.

Controleer de uitvoer: hoe valideer je wat de agent heeft geproduceerd?

De derde gebruikslimiet is de beoordeling van het werkproduct zelf, waarbij iemand uitvoer van lage kwaliteit en onjuistheden op tijd opvangt. Voor een coderingsagent is dat de pull request die de agent opent.

• In Jira: behandel uitvoer van de agent als niet-vertrouwd totdat een persoon of je bestaande controles die heeft geverifieerd, dezelfde maatstaf die je zou hanteren voor code van een nieuwe bijdrager. Werk van agents is gekoppeld aan het werkitem, en codewijzigingen komen binnen als een pull request die door je normale beoordelings- en samenvoegingsproces gaat. Niets wat een agent produceert, ontkomt aan de beoordeling die je team al uitvoert.

• Bekijk het werk achter de uitvoer. Je ziet niet alleen het eindresultaat. Agentsessies in Jira geeft je één plek waar je kunt zien wat een agent heeft gedaan en waarom, zodat een beoordelaar de context heeft om een begrip te krijgen van de uitvoer in plaats van die te reconstrueren.

Bijschrift: Voorbeeld: definieer AI-standaarden voor codebeoordelingen in Bitbucket Cloud en dwing die automatisch af bij elke pull request.

Houd een verantwoordingsverslag bij: wie heeft wat gedaan, en wanneer?

De vierde gebruikslimiet is de registratie, het antwoord op verantwoordelijkheid. Hiermee koppel je werk van de agent terug aan de intentie: wat de agent heeft gedaan, waarom, voor welk werkitem het was bedoeld en wie dit heeft goedgekeurd. Met die koppeling kun je werkitems gemakkelijk traceren en oplossen wanneer er iets misgaat.

• In Jira: elke agent werkt onder een bekende identiteit: ofwel de persoon die het werk heeft toegewezen of ingesteld, en handelt met de rechten van die persoon, of het eigen agent-account met rechten die je toewijst. Hoe dan ook koppelt de registratie elke actie aan een verantwoordelijke identiteit. In de registratie wordt vastgelegd wat de agent heeft gedaan en wie daarvoor verantwoordelijk is, in de werkitemgeschiedenis naast menselijke activiteit, waarbij goedkeuringen zijn gekoppeld aan de beoordelaar die goedkeuring heeft gegeven. Beheerders kunnen ook auditlogs controleren op ongebruikelijke activiteit.

• Breng lokaal agentwerk naar records. Het bijhouden van agentsessies brengt activiteit van lokale AI-coderingsagents in lokale IDE's of terminals, gekoppeld aan het werkitem, zodat werk dat buiten Jira is gedaan toch in één verantwoordingsrecord terechtkomt. Meld je aan voor de wachtlijst.

Wat zijn de best practices voor gebruikslimieten voor agents?

• Stem de toegang van een agent af op de taak en breid die uit naarmate het vertrouwen groeit (agents gebruiken je bestaande Jira-rechten).

• Geef agents duidelijke instructies over hoe ze moeten handelen en wanneer ze moeten pauzeren en vragen moeten stellen.

• Laat agents beginnen met omkeerbaar werk met een laag risico voordat ze taken met een grote impact uitvoeren.

• Zet een mens op de beslissingen die ertoe doen, met controlepunten op meer dan één moment, niet alleen een laatste goedkeuring.

• Controleer de uitvoer van de agent via hetzelfde proces als menselijke uitvoer (controle van pull request en samenvoegen)

• Houd elke agentactie bij, gekoppeld aan het werkitem (geschiedenis en auditlog)

• Geef agents context om de kosten te beheersen, want oplopende uitgaven ontstaan doordat agents gissen en werk opnieuw doen.

Atlassian heeft ontdekt dat AI die is gebaseerd op Teamwork Graph de kwaliteit van antwoorden met 44% verbeterde en het tokenverbruik met 48% verminderde.

Welke gebruikslimieten bestrijkt Jira, en welke bevinden zich ergens anders?

Gebruikslimieten bevinden zich op verschillende lagen van je agentstack. Jira beheert de laag voor werk en toegang; andere lagen vallen onder je modelprovider, agentframework en CI.

Jira bepaalt wat agents mogen doen en legt vast wat ze hebben gedaan, het is een aanvulling op veiligheid op modelniveau en runtime-niveau in plaats van een vervanging daarvoor.

Zo voeg je je eerste gebruikslimiet voor agents toe in Jira

Je hebt geen volledig governanceprogramma nodig om te beginnen. Met één gebruikslimiet kun je een agent op een verantwoorde manier echt werk laten doen, met een persoon bij de beslissingen die ertoe doen, en opschalen naarmate het vertrouwen groeit.

1. Kies één routinematige, omkeerbare taak, zoals een instabiele test of een update van een afhankelijkheid (beperkt de kosten van een fout).

2. Voer de agent uit met de toegang die je een nieuwe teamgenoot zou geven, niet meer dan de taak nodig heeft.

3. Voeg dit toe aan een workflowtransitie zodat een persoon het eerst goedkeurt (vangt acties op die niet overeenkomen of riskant zijn).

4. Controleer de pull request via je normale proces (vangt uitvoer van lage kwaliteit of hallucinaties op).

5. Bevestig dat het is vastgelegd in het werkitem (traceerbaarheid als je het moet terugdraaien).

6. Zo bouw je de workflow om AI verantwoord op te schalen: betere uitvoer van agents, minder tijd voor reviews en meer autonomie die je vanaf hier veilig kunt uitbreiden.

Bekijk onze No BS-handleiding voor verantwoord AI-governance, als onderdeel van Verantwoordelijke Technologische Principes van Atlassian.

Veelgestelde vragen over gebruikslimieten voor AI-agents

Hoe houd je AI-agents veilig?

Je houdt AI-agents veilig door te bepalen waartoe ze toegang hebben, menselijke goedkeuring te vereisen voor acties met grote impact en alles wat ze doen vast te leggen, met toezicht dat is afgestemd op het risico van elke taak.

Hoe reguleert Jira AI-agents?

Jira beheert AI-agents via de instellingen die je team al gebruikt: agents werken binnen de machtigingen en workflows van Jira, je kunt ze achter menselijke goedkeuring plaatsen bij een workflowtransitie, en hun acties worden vastgelegd in de geschiedenis van het werkitem en de auditlog.

Kunnen AI-agents in Jira menselijke goedkeuring vereisen?

Ja. Je kunt een agent toevoegen aan een workflowtransitie, zodat iemand de uitvoer beoordeelt en goedkeurt voordat het werk verdergaat, en autonomie reserveren voor omkeerbare taken met een laag risico.

Hoe zit het met promptinjectie bij AI-agents?

Promptinjectie is niet-vertrouwde invoer die een agent probeert te sturen naar onbedoelde acties. Atlassian filtert invoer naar door Rovo aangestuurde agents op injectiepogingen, en omdat geen enkel filter volledig is, vangen gelaagde gebruikslimieten de rest op: beperkte toegang, menselijke goedkeuring en een volledig audittrail.