# AI Agent Action Catalog: जिस Access की जरूरत नहीं, उसे खोजें

AI agent action catalog उन permissions को खोजने का सबसे तेज तरीका है जिन्हें किसी ने सोच-समझकर चुना ही नहीं। इसमें वे operations दर्ज होते हैं जिन्हें agent अपने workspace के बाहर कर सकता है। फिर हर operation पर फैसला करना पड़ता है: इसका owner कौन है, गलती होने पर क्या परिणाम होगा और क्या human approval जरूरी है।

अधिकांश teams गलत जगह से शुरुआत करती हैं। वे API keys, integrations या software accounts की सूची बनाकर मान लेती हैं कि access समझ आ गया। ऐसा नहीं है। Credential केवल एक container है। असली security decision operation के स्तर पर होता है। एक ही token इस्तेमाल होने पर भी «draft invoice बनाना» और «refund जारी करना» बिल्कुल अलग actions हैं।

Permission reviews इसलिए भी विफल होते हैं क्योंकि team पूछती है, «क्या agent को billing system का access चाहिए?» यह सवाल बहुत व्यापक है। इसके बजाय पूछें कि क्या उसे एक invoice पढ़नी है, draft बनाना है, refund submit करना है, payout details बदलनी हैं या customer list export करनी है। आमतौर पर इनके जवाब अलग होते हैं। अनावश्यक access इन्हीं अंतर में दिखाई देता है।

## Integration list जरूरी permissions छिपा देती है

System inventory बताती है कि agent कहां connect होता है। Action catalog बताता है कि वह क्या कर सकता है। दोनों रखें, लेकिन एक को दूसरे का विकल्प न समझें।

Source control service से जुड़े agent को देखें। «Repository access» में code पढ़ना, pull request खोलना, branch protection बदलना, deployment key बनाना, release publish करना या repository हटाना शामिल हो सकता है। इन सबको एक permission मानने से अलग-अलग risk decisions एक आसान yes या no में बदल जाते हैं।

SSH में भी यही गलती होती है। «Agent staging पर SSH कर सकता है» अपने आप में बहुत कम जानकारी देता है। Service status पढ़ने वाली सीमित command का परिणाम उस shell access से अलग है जिसमें services restart की जा सकती हैं, deployment secrets पढ़े जा सकते हैं या firewall rules बदले जा सकते हैं। केवल transport नहीं, command family या endpoint को catalog करें।

Exposure के तीन अलग पहलू रखें:

- **Reachability** बताती है कि agent किसी system से संपर्क कर सकता है या नहीं।
- **Authority** बताती है कि संपर्क के बाद system उसे क्या करने देगा।
- **Consequence** बताती है कि गलत या manipulated request से क्या हो सकता है।

किसी internal endpoint की reachability कम, लेकिन authority बहुत अधिक हो सकती है। किसी public API की reachability व्यापक, लेकिन authority सीमित हो सकती है। केवल «internal» या «external» देखकर approval तय करना दोनों स्थितियों को चूक सकता है।

NIST Special Publication 800-53 के control AC-6 में least privilege का अर्थ assigned task पूरा करने के लिए जरूरी access तक सीमित रखना बताया गया है। Agent के मामले में «assigned task» का अर्थ «engineering में मदद करना» नहीं हो सकता। इसका अर्थ target, method, boundary और expected result वाला स्पष्ट operation होना चाहिए। जिसे आप लिख नहीं सकते, उसे least privilege नहीं कह सकते।

Action names ऐसे रखें जिन्हें reviewer code repository खोले बिना समझ सके। `POST /v1/issues` उपयोगी technical evidence है, लेकिन «engineering tracker में issue बनाना» owner को बताता है कि वह किस चीज को approve कर रहा है। Record में दोनों रखें।

## एक externally visible operation के लिए एक row बनाएं

हर catalog row सबसे छोटी ऐसी action होनी चाहिए जिसे अलग access या approval decision मिल सके। अगर दो operations के owner, impact या approval requirements अलग हो सकते हैं, तो उनकी rows भी अलग होनी चाहिए।

एक उपयोगी row में engineer के लिए control लागू करने जितनी detail और system owner के लिए उसे reject करने लायक plain language होनी चाहिए:

| Field | क्या दर्ज करें | उद्देश्य |
|---|---|---|
| Action ID | Stable identifier, जैसे `deploy.production.restart-service` | नाम बदलने पर भी decision सुरक्षित रहता है |
| System | Destination system और environment | production और test access अलग रहते हैं |
| Operation | इंसान के लिए स्पष्ट verb और object | Permission की समीक्षा संभव होती है |
| Technical route | API method और path, command pattern या tool call | Engineer boundary लागू कर सकता है |
| Identity | Credential type, account, scopes और delegation model | Shared या बहुत व्यापक authority दिखती है |
| Data handled | भेजे गए inputs और लौटाए गए outputs | Data leakage risk सामने आता है |
| Impact | Consequence category और reversibility | Approval का निर्णय तय करने में मदद मिलती है |
| Owner | Named business या technical decision maker | Access की जिम्मेदारी किसी व्यक्ति को मिलती है |
| Approval | None, per session या per call | Human control point स्पष्ट होता है |
| Evidence | Test, log reference या implementation location | Row और वास्तविक implementation का मिलान साबित होता है |
| Review date | Date और reviewer | पुराने exceptions स्थायी नहीं बनते |

Operation field में «various», «admin tasks», «full API» या «as needed» न लिखें। इन शब्दों का अर्थ है कि catalog असली काम शुरू होने से पहले ही रुक गया। Entry को तब तक बांटें जब तक कोई व्यक्ति बिना अनुमान लगाए yes या no न कह सके।

Development agent का छोटा उदाहरण:

```yaml
action_id: issue-tracker.create-bug
system: issue tracker, production tenant
operation: Create a bug report in the Engineering project
technical_route: POST /api/projects/engineering/issues
identity: service account agent-issues, scope issues:write
inputs: title, body, labels, repository reference
outputs: issue ID and URL
impact: internal write, reversible by project members
owner: Engineering operations manager
approval: per-session
review_date: 2026-09-30
```

«Production tenant» इस row में होना चाहिए, भले ही action केवल tickets बनाती हो। कई teams real customer, employee और incident information के लिए एक ही production SaaS tenant इस्तेमाल करती हैं। Environment label reviewer को बताता है कि कौन-सी boundary पार हो रही है।

हर मामूली field update के लिए अलग row बनाना जरूरी नहीं, अगर destination, owner, identity, approval और consequence सचमुच एक जैसे हों। लेकिन special field outcome बदलती है तो अलग row बनाएं। «Incident status बदलना» और «incident commander बदलना» एक endpoint से गुजर सकते हैं, फिर भी दोनों को समान approval नहीं मिलना चाहिए।

## Credentials और workflows से actions खोजें

Agent prompt पढ़कर पूरा action set नहीं मिलेगा। Prompt intent बताता है। Code, configuration, credentials और observed traffic दिखाते हैं कि agent वास्तव में क्या request कर सकता है।

उन workflows से शुरुआत करें जिनकी अपेक्षा agent से की जाती है। Engineers से कहें कि वे पिछले दस tasks या अपेक्षित tasks को verbs में बताएं। «Failed build की जांच करना» logs पढ़ने, deployment service query करने, issue खोलने, test environment restart करने और message पोस्ट करने में बदल सकता है। पार की गई हर external boundary दर्ज करें।

फिर हर credential से पीछे की ओर जाएं। API scopes, OAuth grants, service-account roles, SSH authorized keys, command wrappers, CI variables और local secret stores देखें। Credential अक्सर ऐसे operations दिखाती है जिनका workflow discussion में नाम नहीं आया। User administration scope वाला API token action candidate है, भले ही team कहे कि agent केवल tickets बनाता है।

अंत में intent को evidence से मिलाएं। Network traces, API gateway logs, command audit records और agent tool definitions वे calls दिखा सकते हैं जिन्हें workflow document ने छोड़ दिया। पहले सुरक्षित test environment में यह जांच करें, जब संभव हो। Production logs भी जरूरी हैं, क्योंकि दबाव में agents और humans अक्सर shortcuts खोजते हैं।

यह पांच चरणों वाली routine अपनाएं:

1. हर ऐसा agent workflow लिखें जो local task से बाहर जाता है।
2. Agent configuration और code से हर tool call, endpoint और shell command pattern निकालें।
3. हर credential की permissions गिनें, जिनमें inherited roles और wildcard scopes भी शामिल हैं।
4. Recent action logs में ऐसी destinations या verbs खोजें जो सूची में नहीं हैं।
5. Destination system के owner के साथ differences मिलाएं।

चौथे चरण में असुविधाजनक findings सामने आती हैं। कोई पुराना token broad repository administration दे सकता है, staging SSH key production hosts पर स्वीकार हो सकती है या «internal» webhook release trigger कर सकता है। Entry को original plan में फिट करने के लिए चुपचाप छोटा न करें। Effective operation catalog में रखें और किसी व्यक्ति से तय कराएं कि वह रहना चाहिए या नहीं।

एक उपयोगी test यह है कि row ऐसे colleague को दें जिसने integration नहीं बनाया। उसे समझ आना चाहिए कि agent क्या भेजता है, क्या वापस पाता है और सबसे खराब plausible mistake क्या होगी। अगर वह नहीं समझ सकता, तो row control record नहीं, technical debris है।

## Impact को generic risk score नहीं, consequences से समझें

Impact को इस आधार पर classify करें कि गलत action क्या बदलती, उजागर करती, खर्च करती या commit करती है। केवल «high, medium, low» rating कारण छिपा देती है कि किसी action पर human attention क्यों चाहिए।

Catalog में पांच consequence categories रखें: disclosure, integrity, availability, external commitment और privilege change। एक row में एक से अधिक categories हो सकती हैं। Customer export पढ़ने में disclosure consequence है। Deployment हटाने से availability बदलती है। Administrator जोड़ने से privilege बदलता है। Contract भेजना external commitment है, भले action technically reversible हो।

दो modifiers जोड़ें: reversibility और blast radius। Reversibility पूछती है कि क्या competent व्यक्ति बिना loss या confusion के action undo कर सकता है। Blast radius पूछता है कि गलती एक draft, project, कई users या पूरे environment को प्रभावित करेगी।

इससे decisions को defend करना आसान होता है। «Temporary test branch हटाना» reversible और सीमित integrity change हो सकता है। «Production database credentials rotate करना» security बनाए रखते हुए भी कई services की availability प्रभावित कर सकता है। दोनों write actions हैं, लेकिन इनकी approval categories अलग होनी चाहिए।

«API में undo है» कहकर reversibility तय न करें। Ledger में refund reverse हो सकता है, लेकिन customer को confusing email पहले ही मिल चुकी होगी। Published package वापस लिया जा सकता है, लेकिन downstream systems उसे fetch कर चुके होंगे। Account restore हो सकता है, फिर भी incident के दौरान former owner access खो सकता है। केवल database operation नहीं, operational consequence देखें।

Action से लौटने वाला data भी उतना ही महत्वपूर्ण है जितना भेजा गया data। Status query harmless लग सकती है, लेकिन अगर वह full environment variables, support transcripts या private keys लौटाती है तो वह disclosure action है। Agent के write access पर अधिक ध्यान देना आसान है, क्योंकि writing active महसूस होती है। ऐसा agent जो हर secret पढ़कर external endpoint call कर सकता है, serious incident के लिए पर्याप्त access रखता है।

«High impact» के बजाय concrete भाषा लिखें, जैसे «यह सभी workspace members का production authorization बदल सकता है» या «यह customer identifiers को third-party API तक भेज सकता है»। Owner को निर्णय लेने में पहली description मदद करती है, label अकेला नहीं।

## Ownership उस व्यक्ति के पास हो जो no कह सकता है

हर action का एक named owner होना चाहिए जो उसे deny, reduce या remove कर सके। वह व्यक्ति agent के हर operational result का owner नहीं, permission decision का owner है।

अच्छा owner आमतौर पर destination system से जुड़ा होता है या business consequence उठाता है। Production deployment actions का owner engineering lead हो सकता है। Refund submission finance के पास हो सकती है। Security team access administration की conditions तय कर सकती है, लेकिन हर line की default owner नहीं बननी चाहिए।

Shared ownership में catalogs खराब होते हैं। «Security and engineering» लिखने पर दोनों groups मान लेते हैं कि दूसरा review करेगा। एक accountable owner दर्ज करें और जरूरत हो तो notes में consulted teams रखें। Owner के job या team बदलने पर handover के साथ catalog rows भी transfer करें।

Owner को एक-screen decision packet दें: operation, system, effective identity, involved data, consequence, proposed approval और agent को इसकी जरूरत का छोटा कारण। Raw OAuth scope list देकर उसे governance न कहें।

Owner को चार सवालों के जवाब देने चाहिए:

- क्या agent को यह outcome चाहिए या workflow के लिए यह केवल convenient है?
- क्या narrower endpoint, role, account, target या command से वही outcome मिल सकता है?
- कौन-सी mistake unacceptable consequence पैदा करेगी?
- Use को कौन approve करे और यह decision कब expire हो?

अक्सर पहला सवाल असहज होता है। Teams future conversation से बचने के लिए broad operation दे देती हैं। यह requirement नहीं, credential से जुड़ा हुआ टाला गया access review है।

Execution path में ownership स्पष्ट रखें। Incident के दौरान कोई owner पहचान में न आए तो catalog अपना काम नहीं कर पाया। Named owner periodic review को भी व्यावहारिक बनाता है: «क्या आप अब भी इस agent और identity के लिए action X authorize करते हैं?»

## Approval commitment के क्षण से मेल खाना चाहिए

Approval तब उपयोगी है जब agent consequence पैदा करने से पहले दिखाई दे और reviewer समझ सके कि वह क्या allow कर रहा है। दस unrelated operations को bundle करने के बाद «allow tool use» button दिखाना security theater है।

Catalog में तीन approval states रखें। «None» का अर्थ है कि agent के session authority पाने के बाद action चल सकती है। «Per session» में specific agent process शुरू होने से पहले human approval देता है। «Per call» में हर use की समीक्षा होती है।

Per-session approval narrow, routine और modest consequence वाले actions के लिए ठीक है, जैसे build status पढ़ना या internal draft issue बनाना। इससे intended agent process की पुष्टि हो जाती है और repetitive prompts से user परेशान नहीं होता।

Per-call approval उन actions के लिए रखें जो commitment बनाती हैं या कठिन boundary पार करती हैं। Production access बदलना, records हटाना, customer-facing deployment trigger करना, company के बाहर message भेजना, money handle करना और sensitive dataset export करना इसके उदाहरण हैं। यहां हर request पर human inspection उचित friction है।

Approval record में context दिखना चाहिए। कम से कम calling process identity, operation, destination, target environment और material parameters दिखाएं। «Agent requests POST» reviewer को दबाव में action समझने के लिए मजबूर करता है। «Production में payments service restart करें, signed process X ने request किया है» निर्णय के लिए उपयोगी summary है।

ऐसे permission की भरपाई approval prompts से न करें जो होना ही नहीं चाहिए। «Production पर arbitrary shell command execute करें» के लिए per-call prompt भी हर बार blank check approve करवाता है। Broad shell capability को constrained commands या अलग operations से बदलें, फिर जरूरत हो तो उन्हीं को approve करें।

यहां action gateway उपयोगी है, क्योंकि वह credentials को agent से दूर रखते हुए human decision को execution के पास रख सकता है। Sallyport fixed decision ladder अपनाता है: locked vault हर action deny करता है, नया agent process default रूप से per-session authorization पाता है और selected keys को हर use पर approval की जरूरत हो सकती है।

इससे एक आम गलती बचती है: actions को ठीक से catalog करने से पहले sprawling rule language बना लेना। Design document में complex policies mature लगती हैं, लेकिन exceptions आने पर unreviewable बन जाती हैं। Clear operations, narrow identities और impact से जुड़ा approval पहले बनाएं।

## Catalog production से पहले failure path दिखा देता है

Catalog की असली उपयोगिता तब दिखती है जब वह अलग-अलग देखने में harmless choices की ऐसी chain पकड़ता है जो साथ मिलकर गंभीर समस्या बन सकती है। मान लें coding agent से पूछा गया कि order workflow क्यों fail हुआ।

Engineer उसे logs पढ़ने वाला service token देता है। उसी token से order API query भी की जा सकती है। Agent malformed order पाता है और उसे «test data साफ करने» को कहा जाता है। Integration ने tenant names स्पष्ट अलग नहीं किए, इसलिए agent production tenant पर delete endpoint call कर देता है। Request स्वीकार हो जाती है। बाद में human देखता है कि order असली था, लेकिन उसे restore करने के लिए payment, inventory और customer support systems में reconciliation चाहिए।

हर statement अलग से harmless लग रही थी: logs पढ़ना, orders query करना, test data हटाना। Action catalog chain को rows में तोड़ देता:

| Operation | छिपी समस्या | बेहतर निर्णय |
|---|---|---|
| Order workflow logs पढ़ना | Logs में customer identifiers हैं | Returned fields सीमित करें और disclosure impact दर्ज करें |
| ID से order query करना | Token को broad order access मिला है | Required tenant तक सीमित read-only identity इस्तेमाल करें |
| Test order हटाना | Production और test एक endpoint family साझा करते हैं | Environments अलग करें और per-call approval रखें |
| Customer order ठीक करना | यह cleanup नहीं है | Operations staff को owner बनाएं और agent scope से हटाएं |

उपयोगी finding यह नहीं कि «agents mistakes करते हैं»। Access boundaries अस्पष्ट होने पर humans भी यही chain बना सकते हैं। Agents तेज execution करते हैं, अधिक आसानी से retry करते हैं और locally reasonable instruction का पालन कर सकते हैं, बिना उस business context को समझे जिसे human naturally infer कर लेता।

High-consequence rows के notes में failure paths लिखें: trigger, wrong target या interpretation, action taken, immediate effect और recovery burden। इससे approval decisions कम abstract होते हैं और reviewers के पास broad access reject करने का स्पष्ट कारण रहता है।

Catalog dangerous combinations भी पकड़ता है। Incident notes पढ़ना स्वीकार्य हो सकता है। Public status page पर post करना review के साथ स्वीकार्य हो सकता है। लेकिन एक ही agent को दोनों बिना content boundary के देना internal incident details उजागर कर सकता है। उन combinations की समीक्षा करें जिनमें एक action sensitive input देती है और दूसरी data को organization के बाहर भेजती है।

## Catalog को enforceable बनाएं और reality से मिलान साबित करें

केवल spreadsheet में रखा catalog permission wish list बन जाता है। हर approved row को technical boundary से जोड़ें: अलग credential, restricted API scope, destination allowlist, constrained SSH command या approval configuration।

Configuration और logs में action IDs इस्तेमाल करें। इससे सरल test मिलता है: हर observed external action का catalog ID होना चाहिए और हर active catalog ID का current enforcement point होना चाहिए। दोनों तरह के mismatch की जांच करें। बिना row का observed action shadow access है। बिना enforcement वाली row stale plan या uncontrolled path हो सकती है।

HTTP calls के लिए method, host, path pattern, target environment और credential scope verify करें। SSH के लिए account, host group, command restrictions और arbitrary arguments पास करने की क्षमता जांचें। «SSH access approved है» enforceable statement नहीं है।

उदाहरण के लिए यह catalog entry कहती है कि agent केवल deployment status ले सकता है:

```text
Action ID: deploy.status.read
Host: deploy.internal.example
Command: deployment-status --service <approved-service>
Identity: agent-deploy-read
Approval: per-session
```

लेकिन यह implementation उस claim को कमजोर कर देती है:

```sh
command="/usr/local/bin/deployment-status $SSH_ORIGINAL_COMMAND" ssh-ed25519 AAAA... agent
```

Wrapper arbitrary original command को argument की तरह पास करता है। अगर `deployment-status` shell चलाता है या unchecked option स्वीकार करता है, तो catalog boundary केवल दिखावा है। बेहतर design approved service name को fixed command से map करता है और बाकी हर input reject करता है। Rejection path को जानबूझकर test करें।

```sh
case "$1" in
  checkout) exec /usr/local/bin/deployment-status --service checkout ;;
  search) exec /usr/local/bin/deployment-status --service search ;;
  *) echo "service not permitted" >&2; exit 1 ;;
esac
```

इस snippet को authorized-keys setup में बिना जांच के copy न करें। यह केवल एक property दिखाता है: agent arbitrary command language नहीं, defined actions में से चुनता है। आपके environment को input validation, account restrictions और command behavior समझने वाले व्यक्ति की testing की जरूरत फिर भी होगी।

Action evidence में ऐसा test दर्ज करें जो boundary के दोनों sides साबित करे। Positive test approved call के सफल होने को साबित करता है। Negative test पास की forbidden call के fail होने को साबित करता है। Teams अक्सर केवल positive test रखती हैं, इसलिए broad credentials चुपचाप बने रहते हैं।

Sallyport agent sessions और individual calls को एक encrypted, hash-chained audit log में दर्ज करता है। इसका `sp audit verify` command vault key के बिना ciphertext पर offline chain verify कर सकता है। यह evidence catalog को actual behavior से मिलाने में मदद करता है, लेकिन unnecessary action हटाने के decision की जगह नहीं लेता।

## Work बदलने पर access review करें

Tool जोड़ने, agent workflow बदलने, credential issue या rotate करने, system owner बदलने या near miss मिलने पर catalog review करें। ये घटनाएं effective access बदलती हैं। Calendar review का इंतजार करने पर integrations बढ़ते रहते हैं और पुराने assumptions बने रहते हैं।

फिर भी हर row पर review date रखें। High-consequence operations को harmless internal reads से छोटे interval पर review करें। Review का सवाल यह नहीं होना चाहिए कि spreadsheet अभी मौजूद है या नहीं। पूछें कि agent को अब भी यही exact operation चाहिए या नहीं, identity narrow है या नहीं, owner सही है या नहीं और observed use इसे बनाए रखने का समर्थन करता है या नहीं।

Unused actions को तेजी से हटाएं। Teams इस डर से removal टालती हैं कि agent को बाद में permission चाहिए हो सकती है। ऐसा होने पर उसी owner और approval decision के जरिए उसे फिर जोड़ें। Known operation दोबारा grant करना उस action को साफ करने से आसान है जिसे कभी रहना ही नहीं चाहिए था।

पहले catalog को perfect बनाने की जरूरत नहीं। एक agent चुनें, आज उसके हर external operation की सूची बनाएं और हर row पर owner से decision करवाएं। आपको ऐसा access मिलेगा जिसे पहले किसी ने नाम तक नहीं दिया था। सबसे पहले वही access हटाएं, इससे पहले कि वह सबसे खराब समय पर इस्तेमाल हो।