सुरक्षित नियंत्रणों के साथ पुल रिक्वेस्ट खोलने वाले AI एजेंट

API के ज़रिए पुल रिक्वेस्ट खोलने वाले AI एजेंट इंजीनियरिंग का काफ़ी समय बचा सकते हैं, लेकिन तभी जब रिपॉज़िटरी हर generated change को traceable author वाले untrusted contribution की तरह माने। सही सीमा सरल है: एजेंट proposed change तैयार कर सकता है; इंसान और रिपॉज़िटरी controls तय करते हैं कि वह codebase का हिस्सा बनेगा या नहीं।

मैंने टीमों को model की code quality पर ध्यान केंद्रित करते और उसके आसपास की permissions को नज़रअंदाज़ करते देखा है। गंभीर विफलताएं आम तौर पर बहुत साधारण होती हैं। Staging service के लिए बनाया गया task production रिपॉज़िटरी में पहुंच जाता है। Broad token चुपचाप हर project को write access दे देता है। Timeout के बाद एजेंट दस लगभग एक जैसी पुल रिक्वेस्ट खोल देता है। कोई व्यक्ति सिर्फ़ title विश्वसनीय लगने के कारण एक को merge कर देता है।

सुरक्षित setup इस बात पर निर्भर नहीं करता कि एजेंट सावधानी बरतेगा। यह तय करता है कि एजेंट कहां काम कर सकता है, बदलाव को सामान्य review प्रक्रिया से गुज़ारता है और इतना अच्छा रिकॉर्ड रखता है कि बाद में जांच की जा सके।

रिपॉज़िटरी scope स्पष्ट और machine-enforced होना चाहिए

एजेंट को ऐसी wildcard organization scope की जगह रिपॉज़िटरी के नामों की स्पष्ट सूची की अनुमति मिलनी चाहिए, जिसे कोई बाद में सीमित करने का इरादा रखता हो। Repository scope एक ठोस सवाल का जवाब देता है: यह process किन codebases को पढ़ सकता है, किनमें branches में write कर सकता है और किनके विरुद्ध पुल रिक्वेस्ट खोल सकता है?

Allowlist को एजेंट के instruction text से बाहर रखें। Prompts व्यवहार का मार्गदर्शन कर सकते हैं, लेकिन authorization लागू नहीं करते। जिस component के पास repository credential है या जो API request करता है, उसे allowlist में न होने वाली रिपॉज़िटरी को अस्वीकार करना चाहिए।

हर allowed repository के लिए permitted base branches और permitted write namespace तय करें। एक उपयोगी record इस तरह दिख सकता है:

repositories:
  - name: acme/payments-api
    base_branches: ["main", "release/2025.1"]
    write_branch_prefix: "agent/"
    pull_request_drafts: true
  - name: acme/docs
    base_branches: ["main"]
    write_branch_prefix: "agent/"
    pull_request_drafts: false

यह fragment एक आम विफलता रोकता है: एजेंट को «checkout copy ठीक करने» का request मिलता है, वह ऐसी ही file उस रिपॉज़िटरी में खोजता है जिसे वह search कर सकता है और वहां लिख देता है, क्योंकि उसकी credential ऐसा करने देती है। Allowlist इस स्थिति को किसी और के लिए cleanup job बनाने के बजाय denied request में बदल देती है।

Scope में repository operations भी शामिल हैं। अधिकांश एजेंटों को files पढ़ने, branch बनाने, commits push करने, checks पढ़ने और पुल रिक्वेस्ट बनाने या अपडेट करने की ज़रूरत होती है। उन्हें repository settings बदलने, webhooks register करने, protected branch rules बदलने, deploy keys जोड़ने, members manage करने या changes merge करने की शायद ही कभी ज़रूरत होती है। सुविधाजनक broad token के साथ मिलने के कारण ये permissions न दें।

Developer के personal access token की जगह अलग bot identity इस्तेमाल करें। Personal token attribution को अस्पष्ट बनाता है, job बदलने पर ठीक से manage नहीं होता और अक्सर ऐसी permissions रखता है जिन्हें देने की किसी को याद नहीं रहती। Bot identity से आपको एक ऐसा actor मिलता है जिसे गलत व्यवहार होने पर suspend किया जा सकता है।

Read access पर भी write access जितनी ही चर्चा ज़रूरी है। हर private repository देख सकने वाला एजेंट अपने logs, task context और responses के ज़रिए source code या configuration उजागर कर सकता है। एजेंट को सबसे छोटी उपयोगी repository set दें, भले ही उसे direct write credential कभी न मिले।

Branch prefix नाम रखने की पसंद नहीं, execution boundary है

एजेंट को केवल agent/ जैसे dedicated prefix के नीचे branches बनानी चाहिए और repository server को इस restriction को लागू करना चाहिए। Prompt में लिखी convention आखिरकार टूटेगी, चाहे वजह malformed tool call हो, retry bug हो या कोई बहुत broad task पूरा करने की कोशिश करता एजेंट।

main, release branches, environment branches और अपने-आप deploy होने वाली हर branch को protect करें। एजेंट को इनमें push नहीं करना चाहिए। उसे इन पर force-push की अनुमति नहीं होनी चाहिए। उसे इनकी सुरक्षा करने वाले rules बदलने में सक्षम नहीं होना चाहिए।

Branch names इतने deterministic रखें कि जांच हो सके और इतने unique कि collisions न हों। इनमें task reference के साथ छोटा random suffix या execution identifier जोड़ें:

agent/OPS-1842-retry-payment-7f3a

Issue titles को सीधे branch names के रूप में इस्तेमाल न करने दें। Titles में secrets, customer names, unsafe characters या misleading language हो सकती है। Controller में branch name generate करें और फिर उसे immutable value की तरह एजेंट को दें।

Base commit के लिए भी स्पष्ट rule चाहिए। जब controller run शुरू करे, तो approved base branch को commit SHA में resolve करके उसे दर्ज करे। एजेंट को अपनी branch उस SHA से बनानी चाहिए, न कि लंबे code-generation run के बाद main का जो भी अर्थ हो, उससे। इससे drift पूरी तरह खत्म नहीं होता, लेकिन वह दिखाई देने योग्य और reproducible बन जाता है।

Branch में केवल assigned task से जुड़े commits होने चाहिए। इसका अर्थ है कोई opportunistic formatting sweep नहीं, unrelated dependency bump नहीं और पास के code को अजीब दिखने के कारण «clean up» करने की कोशिश नहीं। Generated changes अक्सर भरोसेमंद लगते हैं, और reviewers उस समय unrelated edits छोड़ देते हैं जब वे एक सामान्य दिखने वाले patch के भीतर छिपी हों।

काम शुरू होने से पहले change budget तय करें। Budget बदली गई files, कुल lines या requested component के बाहर के paths की सीमा तय कर सकता है। यह सीमा अपने-आप risk का आकलन नहीं है। यह एक tripwire है, जो एजेंट को छोटी repair को चुपचाप पूरी रिपॉज़िटरी के rewrite में बदलने के बजाय रुककर नया task मांगने का संकेत देता है।

पुल रिक्वेस्ट बनाने के लिए checked API transaction चाहिए

Successful HTTP response इस बात का प्रमाण नहीं है कि एजेंट ने सही पुल रिक्वेस्ट खोली। Controller को सफलता बताने से पहले repository, head branch, base branch, commit SHA और लौटाए गए pull request identifier की जांच करनी चाहिए।

GitHub-style API में महत्वपूर्ण request fields proposed title, head, base, body और draft status होते हैं। Exact endpoint forge के अनुसार बदलता है, लेकिन safety checks नहीं बदलते:

{
  "title": "OPS-1842: retry transient payment gateway failures",
  "head": "agent/OPS-1842-retry-payment-7f3a",
  "base": "main",
  "body": "Task: OPS-1842\nBase commit: 4b2c...\nTests: unit payment retry suite\nLimits: no configuration changes",
  "draft": true
}

Request भेजने से पहले branch को query करें और पुष्टि करें कि उसका tip SHA उस commit के बराबर है जिसे run ने दर्ज किया था। Response मिलने के बाद pull request fetch करें और उसके head, base और state की request से तुलना करें। केवल URL नहीं, platform का immutable pull request number या node identifier भी दर्ज करें।

Retries के लिए विशेष handling चाहिए। Network timeout से classic duplicate pull request problem पैदा होती है: server ने शायद pull request 418 बना दी हो, लेकिन client को response न मिला हो और वह फिर कोशिश करे। अपने controller में task ID, repository, branch, base SHA और pull request number के साथ idempotency record रखें। Retry पर create call करने से पहले मौजूदा branch और open pull request खोजें।

Task title को अकेला idempotency value न बनाएं। «generated documentation अपडेट करें» जैसा recurring request पिछले run से टकरा जाएगा। Execution ID एक run की पहचान करे, जबकि task ID लोगों को संबंधित काम जोड़ने में मदद करे।

Agent work के लिए draft pull requests अच्छा default हैं। वे reviewers को बताते हैं कि बदलाव मौजूद है, लेकिन creator के अपने घोषित completion gate को पार नहीं किया है। Required commands पूरी होने और run record में उनके परिणाम दर्ज होने के बाद ही एजेंट पुल रिक्वेस्ट को ready कर सके। अगर आपकी repository drafts का इस्तेमाल नहीं करती, तो agent-created जैसा label trusted controller से लगाएं, एजेंट द्वारा लिखे गए text से नहीं।

Reviewer assignment ownership और risk के अनुसार होना चाहिए

पहला reviewer repository के ownership rules से आना चाहिए, न कि एजेंट के इस अनुमान से कि कौन जानकार लगता है। GitHub का CODEOWNERS documentation changed paths के आधार पर review request करने वाला file-to-owner mapping बताता है। GitLab में approval और code-owner के समान mechanisms हैं। ये files routing data के लिए उपयोगी हैं, लेकिन जब तक branch protection या merge rules review को अनिवार्य न बनाएं, वे अपने-आप review को mandatory नहीं बनातीं।

यह अंतर महत्वपूर्ण है। Settings के आधार पर repository requested code owner दिखा सकती है और फिर भी उस व्यक्ति की approval के बिना merge की अनुमति दे सकती है। Routing और enforcement को अलग controls मानें। Policy पर भरोसा करने से पहले जानबूझकर unauthorized test pull request के ज़रिए दोनों की जांच करें।

Final commit के बाद changed file list का इस्तेमाल करें, न कि उन paths का जिन्हें एजेंट ने बदलने की योजना बनाई थी। Generated patch run के आखिरी हिस्से में shared library, deployment directory या migration folder तक पहुंच सकता है। Reviewer calculation को वास्तव में हुए बदलाव देखने चाहिए।

जब task ऐसे क्षेत्रों को प्रभावित करे जहां ownership rules बहुत broad या अनुपस्थित हों, तो एक responsible human जोड़ें। यह व्यक्ति task के intent का मालिक होता है। Code owner पुष्टि कर सकता है कि implementation component के अनुरूप है; responsible person यह पुष्टि कर सकता है कि मांगा गया behavior product के लिए सही है। केवल इसलिए दर्जनों लोगों को assign न करें कि diff कई सीमाओं से होकर गुज़रा है। बड़ी reviewer lists का परिचित परिणाम यह होता है कि हर व्यक्ति मान लेता है कि कठिन हिस्सा किसी और ने देख लिया होगा।

कुछ paths को अधिक सख्त route अनिवार्य करना चाहिए। उदाहरणों में database migrations, authorization code, build और release definitions, dependency manifests, infrastructure configuration और generated artifacts शामिल हैं। सही प्रतिक्रिया हमेशा «एजेंट को रोकें» नहीं होती। अक्सर सही प्रतिक्रिया होती है, «उस owner की approval लें जो परिणाम समझता हो।» Migration unit tests पास कर सकता है और फिर भी rollback को असंभव बना सकता है।

Pull request बनने के बाद ही API से reviewers assign करें और resulting assignment की पुष्टि करें। अगर कोई owner group requests प्राप्त नहीं कर सकता, तो controller को random developer चुनने के बजाय pull request को blocked mark करना चाहिए। Silent fallback ownership rule को केवल दिखावा बना देता है।

Tests evidence बताते हैं, approval acceptance तय करती है

एजेंट को ठीक-ठीक बताना चाहिए कि उसने क्या चलाया, क्या नहीं चलाया और क्यों। «Tests पास हो गए» commands, exit status और tested commit SHA के बिना बेकार दावा है। उस evidence को pull request prose के बाहर भी रखें, क्योंकि एजेंट बाद में prose बदल सकता है।

हर run के लिए एक छोटी structured report इस्तेमाल करें:

{
  "run_id": "run_01J...",
  "repository": "acme/payments-api",
  "head_sha": "8c71...",
  "commands": [
    {"command": "npm test -- payment-retry", "exit_code": 0},
    {"command": "npm run lint", "exit_code": 0}
  ],
  "not_run": ["integration suite requires payment sandbox approval"]
}

जब evidence में branch tip से अलग SHA हो, तो controller को ready-for-review transition अस्वीकार करनी चाहिए। इससे एक सूक्ष्म लेकिन आम sequence पकड़ा जाता है: एजेंट tests चलाता है, एक और «छोटा» सुधार करता है और कुछ भी दोबारा चलाए बिना पुल रिक्वेस्ट खोल देता है।

Required status checks repository-side ही रहने चाहिए। एजेंट के पास checks को waive करने, अपनी पुल रिक्वेस्ट approve करने, branch protection बदलने या merge करने की permission नहीं होनी चाहिए। Check यह बता सकता है कि कोई ज्ञात command पास हुआ। वह यह साबित नहीं कर सकता कि नया authorization rule सही है, requirement समझी गई थी या उस repository में task शुरू ही किया जाना चाहिए था।

Generated summary को diff review का विकल्प न बनने दें। अच्छी summaries reviewers को दिशा समझने में मदद करती हैं, लेकिन वे author के दावे हैं। Reviewers को वास्तविक file changes, tests, संबंधित issue context और जानबूझकर छोड़ी गई चीज़ें देखनी चाहिए।

हर created change के लिए ऐसा audit trail चाहिए जो incident में भी सुरक्षित रहे

Pull request URL audit record नहीं है। Repositories move होने, branches delete होने, access बदलने या description edit होने पर वह बेकार हो सकता है। Append-only event record रखें, जिससे investigator यह पता लगा सके कि run किसने शुरू किया, हर call किस process ने की, कौन-सी repository बदली और system ने क्या लौटाया।

कम-से-कम ये fields दर्ज करें:

• run ID और मूल task या ticket reference
• acting bot identity और authenticated agent process identity
• repository, base branch, base SHA, head branch और बनाए गए हर commit SHA
• API request type, immutable pull request identifier, timestamps और result status
• reviewer requests, approvals, check results, closure, merge या rejection events

Default रूप से audit log में plaintext credentials, पूरी source files या arbitrary task prompts न रखें। Investigators को sensitive material की एक और uncontrolled copy नहीं, भरोसेमंद action facts चाहिए। अगर patch content रखना हो, तो content digest दर्ज करें और अपनी सामान्य retention तथा access rules लागू करें।

Activity log और decision log के बीच का अंतर बनाए रखना उपयोगी है। Activity log कहता है कि API call ने pull request 418 बनाई। Decision log कहता है कि उस agent session को किसने approve किया, उसके authorization में किसने बदलाव किया और उसे किसने revoke किया। Incident के दौरान दोनों महत्वपूर्ण हैं। आपको यह भी जानना होता है कि क्या हुआ और उस समय actor के पास authority क्यों थी।

Sallyport अपने encrypted, hash-chained audit log से projected journals में agent sessions और individual HTTP या SSH calls रख सकता है, और sp audit verify ciphertext पर offline chain की जांच करता है। यह उस setup के लिए उपयुक्त है जिसमें एजेंट action मांगता है, लेकिन repository credential खुद प्राप्त नहीं करता।

Hash chaining बाद में किए गए modification को detectable बनाती है; यह कमजोर event record को complete नहीं बनाती। Action boundary पर repository और commit identities दर्ज करें। «HTTP request sent» का पूरी तरह verified record आपको यह नहीं बताएगा कि request ने गलत pull request बनाई या नहीं।

Credentials एजेंट से बाहर रखें और creation को merge से अलग रखें

एजेंट के prompt, environment, workspace file या tool output में broad repository token कभी नहीं होना चाहिए। एक बार token उस context में आ गया, तो वह logs, shell history, error messages, copied transcripts या एजेंट को उसे print करने के लिए उकसाने वाले instruction के ज़रिए leak हो सकता है। बाद में redaction करने से secret को भरोसेमंद ढंग से फिर नियंत्रण में नहीं लाया जा सकता।

ऐसे action gateway या narrow controller का इस्तेमाल करें जो specific request स्वीकार करे: इस repository में branch बनाएं, इन commits को allowed prefix पर push करें, approved base branch के विरुद्ध draft pull request बनाएं या इन reviewers को request भेजें। Gateway credentials डालता है और result लौटाता है। उसे declared scope में फिट न होने वाली calls अस्वीकार करनी चाहिए।

Creation rights और merge rights अलग privileges हैं। Pull request बनाने वाली service हजारों खराब changes propose कर सकती है। Merge कर सकने वाली service एक खराब change को production में पहुंचा सकती है। Demo को आसान बनाने के लिए इन्हें combine न करें। Merge action को protected branch rules और accountable human के पास रखें, भले ही एजेंट ने flawless patch बनाया हो।

Per-run authorization भी permanently trusted agent process से बेहतर है। Agent tools subprocesses शुरू कर सकते हैं, unexpected jobs में reuse हो सकते हैं और उस task के बाद भी active रह सकते हैं जिसके कारण access दिया गया था। Process को एक bounded session दें, approval दर्ज करें और revocation को तुरंत प्रभावी बनाएं।

Failure drill उन gaps को सामने लाती है जिन्हें policy prose छिपा देती है

Automated pull request creation पर भरोसा करने से पहले controlled failure drill चलाएं। Test repository या disposable branch policy इस्तेमाल करें और एजेंट को ऐसा task दें जो हर boundary पार करने की कोशिश करे। उद्देश्य happy-path demonstration की प्रशंसा करना नहीं, denial और recording behavior की पुष्टि करना है।

एक allowed repository और एक prohibited repository से शुरुआत करें। पुष्टि करें कि controller पहली में expected draft pull request बना सकता है और दूसरी को कोई branch बनने से पहले अस्वीकार करता है। फिर main पर push, agent/ branch पर force push और unapproved release branch के विरुद्ध पुल रिक्वेस्ट बनाने की कोशिश करें। केवल controller messages नहीं, repository events भी जांचें।

इसके बाद create request के repository API तक पहुंचने के बाद timeout का simulation करें। Run restart करें और पुष्टि करें कि वह original pull request खोजता है, दूसरी नहीं बनाता। Test results दर्ज करने के बाद branch बदलें और verify करें कि SHA mismatch पर ready transition रुक जाती है।

अंत में run के दौरान agent session revoke करें और एक और API call आज़माएं। Call विफल होनी चाहिए, denial decision record में दिखना चाहिए और agent output में कोई credential दिखाई नहीं देनी चाहिए। अगर इनमें से किसी test के लिए इंसान को chat message देखकर ध्यान देना पड़े, तो control अभी मौजूद नहीं है।

पहली practical कार्रवाई आज इस्तेमाल हो रहे agent token की inventory बनाना है। हर वह repository सूचीबद्ध करें जिसे token छू सकता है, हर वह branch जिसे update कर सकता है और यह कि वह merge या settings बदल सकता है या नहीं। अधिकांश टीमों को पता चलता है कि token job से कहीं अधिक broad है। एजेंट से एक और पुल रिक्वेस्ट बनवाने से पहले उसका scope घटाएं।