A është coding agent-i po aq i sigurt sa kodi që shkruan?

Për vite me radhë, një nga pyetjet kryesore në zhvillimin e software-it ka qenë: a është kodi i sigurt?

Zhvilluesit analizojnë dobësitë, kontrollojnë varësitë, testojnë aplikacionet dhe përcaktojnë se cilët përdorues mund të aksesojnë pjesë të ndryshme të sistemit.

Por hyrja e coding agents në procesin e zhvillimit po krijon një pyetje tjetër.

A është vetë agjenti që shkruan dhe ekzekuton kod po aq i sigurt sa software-i që po përpiqemi të ndërtojmë?

Kjo pyetje bëhet më e rëndësishme ndërsa agjentët e AI-së kalojnë nga sugjerimi i disa rreshtave kodi te kryerja e veprimeve reale në mjediset e zhvillimit.

Një coding agent mund të lexojë skedarë, të modifikojë kodin, të ekzekutojë komanda, të instalojë varësi, të përdorë mjete dhe, në disa konfigurime, të komunikojë me shërbime përmes rrjetit.

Në këtë moment, siguria nuk lidhet më vetëm me kodin që prodhon AI.

Ajo lidhet edhe me mjedisin ku AI lejohet të veprojë.

Nga asistenti që sugjeron kod te agjenti që ekzekuton komanda

Gjenerata e parë e mjeteve AI për programim funksiononte kryesisht si një sistem sugjerimesh.

Zhvilluesi shkruante kod dhe modeli propozonte funksione, fragmente kodi ose zgjidhje të mundshme.

Coding agents po e ndryshojnë këtë model.

Një agjent mund të marrë një detyrë, të analizojë repository-n, të identifikojë skedarët që duhet të ndryshohen, të modifikojë kodin dhe të ekzekutojë mjete për të kontrolluar rezultatin.

GitHub e përshkruan këtë evolucion të Copilot nga një asistent brenda editorit drejt një partneri zhvillimi që mund të përdorë mjete, të ekzekutojë komanda dhe të ndryshojë skedarë.

Sa më shumë veprime të mund të kryejë agjenti, aq më e rëndësishme bëhet pyetja se çfarë lejohet të prekë ai.

Një gabim në një përgjigje tekstuale mund të korrigjohet përpara se të përdoret.

Një komandë e ekzekutuar në një sistem real mund të ketë pasoja të menjëhershme.

Coding agent-i duhet të trajtohet si një përdorues i sistemit

Nga perspektiva arkitekturore, një coding agent nuk duhet parë vetëm si një model AI.

Ai po bëhet një aktor aktiv brenda sistemit.

Nëse mund të lexojë filesystem-in, të përdorë terminalin dhe të komunikojë përmes rrjetit, atëherë ai ka një sipërfaqe aksesi që duhet kontrolluar.

Kjo është e ngjashme me mënyrën se si sistemet moderne trajtojnë përdoruesit dhe shërbimet.

Një aplikacion nuk duhet t’i japë çdo përdoruesi akses në çdo burim. Në të njëjtën mënyrë, një coding agent nuk duhet të ketë automatikisht akses në të gjithë kompjuterin vetëm sepse i duhet të ndryshojë një repository.

Parimi bëhet i thjeshtë:

Agjenti duhet të ketë vetëm aksesin që i nevojitet për të përfunduar detyrën.

Ky është një aplikim i drejtpërdrejtë i parimit të privilegjit minimal në zhvillimin me AI.

Sandbox-i po bëhet kufiri i ri i sigurisë

Më 2 qershor 2026, GitHub prezantoi në public preview cloud dhe local sandboxes për GitHub Copilot.

Qëllimi është që veprimet e Copilot të mund të ekzekutohen në mjedise të izoluara, në vend që agjenti të ketë akses të pakufizuar në sistemin ku punon zhvilluesi.

Në një local sandbox, komandat dhe mjetet e ekzekutuara nga agjenti mund të kenë akses të kufizuar te filesystem-i, rrjeti dhe aftësitë e sistemit.

Cloud sandbox shkon një hap më tej duke e zhvendosur sesionin në një mjedis Linux të izoluar dhe të përkohshëm të hostuar nga GitHub.

Kjo krijon një ndarje të rëndësishme arkitekturore.

Në vend që coding agent-i të ekzekutojë çdo veprim direkt në sistemin kryesor, ai vendoset brenda një kufiri ku mund të përcaktohet se cilat burime mund të përdorë.

Sandbox-i, në këtë mënyrë, nuk është thjesht një veçori shtesë sigurie.

Ai po bëhet shtresa e ekzekutimit të coding agents.

Filesystem-i është një nga kufijtë më të rëndësishëm

Një coding agent që punon me një projekt duhet të lexojë dhe të ndryshojë skedarë.

Por kjo nuk do të thotë se duhet të lexojë çdo skedar që ekziston në pajisjen e zhvilluesit.

Dokumentacioni aktual i GitHub lejon konfigurimin e aksesit të sandbox-it sipas path-eve të filesystem-it. Zona të caktuara mund të jenë të lexueshme dhe të shkrueshme, të tjera vetëm të lexueshme dhe disa mund të bllokohen.

Kjo krijon një model shumë më të kontrolluar.

Agjenti mund të ketë akses te repository ku duhet të punojë, pa pasur domosdoshmërisht të njëjtën liri në pjesën tjetër të sistemit.

Ky dallim bëhet veçanërisht i rëndësishëm kur në pajisjen e zhvilluesit ekzistojnë projekte të tjera, konfigurime, kredenciale ose të dhëna që nuk kanë lidhje me detyrën e agjentit.

Rrjeti krijon një problem tjetër: daljen e të dhënave

Filesystem-i kontrollon se çfarë mund të lexojë ose ndryshojë agjenti.

Rrjeti kontrollon se ku mund ta dërgojë informacionin.

Një coding agent mund të ketë arsye legjitime për të përdorur internetin. Mund t’i duhet të shkarkojë një dependency, të kontaktojë një package registry ose të përdorë një shërbim të nevojshëm për procesin e zhvillimit.

Por akses i pakufizuar në rrjet krijon gjithashtu rrezik.

GitHub e lidh kufizimin e aksesit në internet me menaxhimin e rrezikut të nxjerrjes së të dhënave. Sjellja e papritur e një agjenti ose instruksionet keqdashëse mund të krijojnë situata ku kodi ose informacione të tjera sensitive tentojnë të dërgohen drejt një destinacioni të jashtëm.

Për këtë arsye, Copilot cloud agent përdor firewall për të kufizuar aksesin në internet dhe organizatat mund të kontrollojnë destinacionet e lejuara.

Kjo e zhvendos sigurinë nga pyetja:

“A i besojmë modelit?”

te një pyetje më praktike:

“Edhe nëse modeli gabon, çfarë e lejon infrastruktura të bëjë?”

Prompt injection nuk është më vetëm problem i chatbot-eve

Një tjetër rrezik shfaqet kur agjentët marrin instruksione nga përmbajtje që nuk kontrollohet plotësisht nga zhvilluesi.

GitHub paralajmëron se përmbajtja në issues ose komente mund të përdoret për të tentuar prompt injection ndaj cloud agent.

Kjo është veçanërisht e rëndësishme për coding agents sepse ata nuk prodhojnë vetëm tekst.

Ata mund të kryejnë veprime.

Në një sistem tradicional AI, një instruksion keqdashës mund të ndikojë përgjigjen e modelit.

Në një sistem me mjete, i njëjti problem mund të tentojë të ndikojë se cilat komanda ekzekuton agjenti, cilët skedarë lexon ose me cilat shërbime komunikon.

Prandaj, mbrojtja nuk mund të mbështetet vetëm te aftësia e modelit për të dalluar instruksionet e sigurta nga ato të pasigurta.

Duhet të ekzistojnë kufij teknikë jashtë modelit.

Kredencialet duhet të trajtohen si një privilegj, jo si parazgjedhje

Një nga burimet më sensitive që mund t’i jepet një coding agent-i janë kredencialet.

Nëse një agjent mund të përdorë Git ose GitHub CLI me identitetin e zhvilluesit, ai mund të kryejë veprime që shkojnë përtej ndryshimit lokal të një skedari.

Për këtë arsye, konfigurimi i sandbox-it duhet të përcaktojë jo vetëm aksesin te skedarët dhe rrjeti, por edhe se cilat kredenciale janë të disponueshme gjatë ekzekutimit.

Kjo është një arsye tjetër pse coding agents duhet të trajtohen si identitete operative brenda arkitekturës.

Pyetja nuk duhet të jetë vetëm “çfarë di agjenti?”, por:

Çfarë mund të bëjë agjenti me identitetin që i kemi dhënë?

Sandbox-i redukton rrezikun, por nuk e eliminon atë

Izolimi është një shtresë e rëndësishme sigurie, por nuk duhet trajtuar si garanci absolute.

Vetë dokumentacioni i GitHub thekson kufizime të firewall-it dhe paralajmëron se sulme të sofistikuara mund të tentojnë ta anashkalojnë atë.

Po kështu, një coding agent mund të gjenerojë kod që duket korrekt, por përmban gabime funksionale ose probleme sigurie.

Kjo do të thotë se ekzistojnë dy probleme të ndryshme.

Problemi i parë është siguria e kodit që prodhon agjenti.

Problemi i dytë është siguria e veprimeve që kryen agjenti gjatë prodhimit të atij kodi.

Sandbox-i ndihmon kryesisht me problemin e dytë.

Code review, testimi, analizat statike dhe kontrollet e sigurisë vazhdojnë të jenë të nevojshme për problemin e parë.

Human review mbetet pjesë e modelit të sigurisë

Autonomia e coding agents nuk duhet të nënkuptojë mungesën e kontrollit njerëzor.

GitHub rekomandon që output-et e agjentit të kontrollohen përpara se të bashkohen me kodin kryesor dhe përdor kufizime shtesë për cloud agent.

Për shembull, agjenti ka akses të kufizuar në repository, nuk mund të shtyjë ndryshime drejtpërdrejt në branch-in kryesor dhe workflows të caktuara kërkojnë miratim njerëzor përpara ekzekutimit.

Këto masa tregojnë një parim më të gjerë për arkitekturën e sistemeve me AI:

Autonomia duhet të rritet së bashku me kontrollin.

Sa më shumë veprime mund të kryejë një agjent, aq më të qarta duhet të jenë kufijtë, lejet, gjurmueshmëria dhe pikat ku kërkohet miratim njerëzor.

Siguria e coding agents po bëhet problem arkitekturor

Për Soft&Solution Group, zhvillimi me coding agents duhet të trajtohet si një ndryshim arkitekturor, jo thjesht si adoptimi i një mjeti të ri produktiviteti.

Në momentin që një AI mund të përdorë terminalin, të ndryshojë skedarë, të komunikojë me rrjetin dhe të veprojë me kredenciale, ajo bëhet pjesë aktive e modelit të sigurisë së sistemit.

Kjo do të thotë se ekipet duhet të përcaktojnë kufijtë e aksesit përpara se të përcaktojnë nivelin e autonomisë.

Siç shprehet Ermal Beqiri, themelues i Soft&Solution Group:

“Një coding agent nuk bëhet i sigurt vetëm sepse modeli është i avancuar. Siguria fillon te kufijtë që ndërtojmë rreth tij: çfarë mund të lexojë, çfarë mund të ndryshojë, ku mund të komunikojë dhe cilat veprime kërkojnë miratim njerëzor. Sa më autonom të bëhet AI, aq më e rëndësishme bëhet arkitektura që kontrollon këtë autonomi.”

Coding agents po ndryshojnë mënyrën se si ndërtohet software-i.

Por evolucioni nga sugjerimi i kodit drejt ekzekutimit autonom krijon edhe një ndryshim në mënyrën se si duhet menduar siguria.

Nuk mjafton më të kontrollojmë vetëm kodin që del nga AI.

Duhet të kontrollojmë edhe mjedisin ku AI punon.

Filesystem-i, rrjeti, kredencialet, sandbox-i, politikat e aksesit dhe miratimi njerëzor po bëhen pjesë e së njëjtës arkitekturë sigurie.

Në këtë model, coding agent-i nuk duhet konsideruar një proces që i besohet automatikisht.

Duhet konsideruar një komponent me privilegje të kufizuara, sjellje të monitorueshme dhe veprime që mund të kontrollohen.

Sepse në zhvillimin e software-it me AI, pyetja e ardhshme e sigurisë nuk do të jetë vetëm:

“A është kodi i sigurt?”

Por edhe:

“A ishte i sigurt agjenti që e ndërtoi?”