# क्या SOC 2 evidence table agent actions साबित कर सकती है?

Agent activity ऐसी audit समस्या पैदा करती है जिसे सामान्य application logs हल नहीं कर पाते। Service account log यह बता सकता है कि किसी credential ने endpoint को call किया। लेकिन आमतौर पर वह यह नहीं बता सकता कि उस समय किसी specific agent process को authority थी या नहीं, किसी human ने action approve की थी या नहीं, authority बाद में वापस ली गई थी या नहीं, या auditor को दिया गया record वही है जो उस समय बना था।

काम आने वाले SOC 2 evidence package को केवल timeline दिखाने के बजाय एक decision को फिर से बनाकर दिखाना चाहिए। हर महत्वपूर्ण action के लिए auditor actor और authorization से call, outcome और सुरक्षित रखे गए record की integrity तक पहुंच सके। यदि किसी भी join के लिए administrator की याददाश्त या manually edited spreadsheet पर निर्भर रहना पड़े, तो control पहली नजर से कमजोर है।

Sallyport इसी chain के आसपास बनाया गया है: agent को action results मिलते हैं, credentials local encrypted vault में रहते हैं और app agent run तथा हर individual call को record करता है। यह design तभी उपयोगी है जब आप इन records को test किए जा सकने वाले evidence में बदलें, न कि journal को compliance दिखावे की तरह रखें।

## Control को दोबारा बनाया जा सकने वाला decision चाहिए

AICPA के 2017 Trust Services Criteria screenshots की सूची नहीं, बल्कि criteria हैं। Security common criteria management से logical access को सीमित करने, system operation की निगरानी करने, पहचानी गई समस्याओं पर प्रतिक्रिया देने और changes manage करने वाले controls स्थापित तथा संचालित करने की अपेक्षा करते हैं। Auditor आपके बताए control, उसकी population और examination period में उसके प्रभावी संचालन की जांच करता है।

Agent actions के लिए यह अंतर महत्वपूर्ण है। «Agent को approval चाहिए था» product behavior है। «हर नए शुरू हुए agent process को protected action channel इस्तेमाल करने से पहले attributable authorization मिली और company ने authorization को resulting calls से जोड़ने वाले records सुरक्षित रखे» एक ऐसा control statement है जिसे test किया जा सकता है।

Evidence request लिखने से पहले risk लिखें। एक व्यावहारिक risk statement ऐसा हो सकता है:

> कोई unapproved या पहले approved agent process organizational credentials का उपयोग करके external API या SSH command चला सकता है, जिससे unauthorized access या unauthorized operational change हो सकता है।

Control को इस risk का उत्तर सरल भाषा में देना चाहिए। Evidence को इन पांच छोटे सवालों का उत्तर देना चाहिए:

1. Action करने की कोशिश किस process ने की?
2. उस समय उसके पास कौन सी authority थी?
3. वह authority किसने दी, यदि किसी ने दी थी?
4. उसके बाद कौन सी exact external action हुई?
5. क्या कोई history को बदलने की कोशिश का पता लगा सकता है?

Teams अक्सर इन सवालों को मिला देती हैं। वे destination allowlist को approval control कहते हैं, successful API response को authorization record समझते हैं या log export को केवल इसलिए immutable मानते हैं क्योंकि export read-only है। हर दावा अलग चीज बताता है।

Destination restriction यह सीमित करती है कि process कहां काम कर सकता है। Authorization record बताता है कि process को काम करने की अनुमति किसने दी। Call records बताते हैं कि process ने क्या करने की कोशिश की और क्या हुआ। Integrity verification यह बताती है कि सुरक्षित रखी गई sequence बदली गई है या नहीं। System description और evidence table में इन दावों को अलग रखें। Auditors को दिखावटी भाषा नहीं चाहिए। उन्हें ऐसा control owner चाहिए जो सीमित और स्पष्ट दावा कर सके तथा supporting record दे सके।

## SOC 2 evidence table जिसे auditor test कर सकता है

Engineering, security और auditor के बीच working agreement के रूप में एक evidence table इस्तेमाल करें। इसे product features की सूची न बनाएं। हर row में risk, control activity, source population, test method और failure signal होना चाहिए।

| Control area | Control activity | Evidence population | Likely criteria connection | Auditor test | Failure signal |
|---|---|---|---|---|---|
| New agent session | Protected actions चलने से पहले नए agent process को session authorization मिलनी चाहिए | Review period का session journal | CC6.1, CC6.2 | Sessions चुनकर approval को पहली protected call तक trace करें | Preceding approval के बिना call मौजूद हो या locked vault denial मिले |
| Sensitive individual action | Approval के लिए marked credential के हर उपयोग पर human decision जरूरी है | Marked credentials की activity journal entries | CC6.1, CC7.2 | Calls चुनकर हर call से जुड़े decision की जांच करें | Marked credential approval record के बिना इस्तेमाल हुआ |
| Session revocation | Reviewer active session समाप्त कर सके और उसके बाद की calls deny हों | Revocation events और बाद की attempts | CC6.2, CC7.3 | Revocation दोबारा करके बाद की attempted action test करें | Revocation के बाद session ने action किया |
| Call accountability | हर completed या denied call में session, destination, operation, result और time record हों | Activity journal | CC7.2 | चुनी गई calls को session और result records से मिलाएं | Fields missing हों, duplicate identifiers हों या call trace न हो |
| Audit integrity | Retained encrypted audit sequence को vault access के बिना independently verify किया जा सके | Archived log ranges और verification records | CC7.2, CC7.4 | चुनी गई retained range पर offline verification चलाएं | Broken chain report हो या range उपलब्ध न हो |
| System change | Gateway को प्रभावित करने वाले code, configuration और deployment changes company की change process से गुजरें | Pull requests, tickets, test results, deployment records | CC8.1 | Sampled production change को approval से deployment तक trace करें | Unapproved या untested system change production में पहुंच जाए |

Criteria references केवल शुरुआत हैं, coverage की गारंटी नहीं। Final mapping आपके service description, risk assessment, system boundaries और auditor के judgment पर निर्भर करती है। खास तौर पर हर agent record को CC8.1 के अंतर्गत रखने की कोशिश न करें। AICPA के examples और guidance में change management को application programs और संबंधित technology में changes के control के रूप में देखा गया है। Customer account edit करने वाली, support reply भेजने वाली या remote process restart करने वाली call operational action है। वह तभी change management evidence बनेगी जब system में approved और tested change का हिस्सा हो।

यह table audit week की एक आम समस्या भी रोकती है: किसी एक दिन का perfect artifact जमा करना। Type 2 examination यह पूछता है कि बताए गए controls पूरे period में प्रभावी ढंग से चले या नहीं। Population column केवल paperwork नहीं है। यह बताता है कि sample लेने से पहले आपको कौन सा पूरा universe उपलब्ध कराना आना चाहिए।

## Session approval process authority साबित करती है, identity governance नहीं

Per session approval यह evidence है कि किसी particular agent run को action gateway इस्तेमाल करने की अनुमति मिली। यह evidence नहीं है कि company ने employee access सही तरह manage किया, identity provider account सही तरीके से provision किया या cloud administrator role की समीक्षा की। इनके लिए अलग controls और records चाहिए।

उपयोगी दावा अधिक सीमित है। नए process की पहली protected call से पहले उसे approval decision मिलती है। Record में session identifier, process identity, जहां उपलब्ध हो वहां code signing authority, decision time, approver identity और termination state सुरक्षित रहनी चाहिए। Sallyport में approval card सबसे पहले process की code signing authority दिखाता है। इससे human decision उस executable से जुड़ता है जिसने वास्तव में access मांगा था, न कि agent द्वारा दिया गया अस्पष्ट label।

यह अंतर महत्वपूर्ण है। Agent prompt, terminal title या process argument में खुद को कोई भी नाम दे सकता है। Self-reported name approve करने वाला control आसान bypass का रास्ता देता है। Code signing authority दिखाने वाला control reviewer को जांचने के लिए स्थिर attribute देता है। इससे signed software पर भरोसा करने की जरूरत खत्म नहीं होती, लेकिन trust boundary साफ रहती है।

Session approval test के लिए auditor से session population में से sample चुनने को कहें और हर record को दोनों दिशाओं में trace करें:

- Session approval से शुरू करके उसके बाद हुई पहली protected call खोजें।
- Activity entry से शुरू करके उसे authorize करने वाला session खोजें।
- Confirm करें कि call का time approval के बाद और session exit या revocation से पहले है।
- Confirm करें कि denied sessions में कोई successful protected call नहीं है।
- Confirm करें कि session record process की पहचान आपके बताए control के लिए पर्याप्त मजबूती से करता है।

Approval dialog के screenshot पर निर्भर न रहें। Screenshots control design document करने में उपयोगी हैं, लेकिन population evidence नहीं हैं। Dialog बंद होने के बाद भी record मौजूद रहना चाहिए, identifier से query किया जा सके और किसी व्यक्ति को यह तय न करना पड़े कि कौन सी row सही लग रही है।

यह दावा भी न करें कि session approval least privilege है, यदि वह वास्तव में ऐसा नहीं है। Session decision यह नियंत्रित कर सकती है कि process बिल्कुल काम कर सकता है या नहीं। Least privilege इस बात पर निर्भर करती है कि approval के बाद कौन से credentials, destinations, operations और permissions उपलब्ध हैं। यदि approved agent unrestricted production rights वाले credential का उपयोग कर सकता है, तो approval एक gate है, scope reduction नहीं। इसे उसी तरह describe करें।

## Per call approval उन actions के लिए है जिन्हें सुरक्षित रूप से batch नहीं किया जा सकता

Per call approval, session approval से अलग assurance देती है। इसमें किसी particular credential use से ठीक पहले fresh human decision लिया जाता है। इसका उपयोग उन actions में करें जहां नुकसान agent process को काम शुरू करने देने में नहीं, बल्कि individual invocation में है।

अच्छे candidates में ऐसा production credential शामिल है जो access rights बदल सकता है, data delete कर सकता है, billing information बदल सकता है, deployment publish कर सकता है या बहुत sensitive host पर commands चला सकता है। उद्देश्य हर agent action को परेशान करने वाला बनाना नहीं है। उद्देश्य review को उस transaction boundary पर रखना है जहां एक गलत उपयोग महत्वपूर्ण हो सकता है।

Evidence को approval को एक ही use से जोड़ना चाहिए। एक अच्छे activity record में कम से कम ये बातें हों:

- Unique call identifier और उससे जुड़ा session identifier।
- Protected credential reference, लेकिन record में उसका secret value नहीं।
- Channel, destination, operation और timestamp।
- Approval की जरूरत वाले call के लिए decision state और approver।
- Outcome, जिसमें denied, failed या completed result शामिल हो।

ऐसा approval record स्वीकार न करें जो बाद की action के पास कहीं दिखाई देता हो। Time proximity binding नहीं है। यदि reviewer Call A approve करता है और agent उसी credential से Call B करता है, तो evidence में साफ होना चाहिए कि B को अलग approval चाहिए थी या नहीं और मिली या नहीं।

यहीं teams अक्सर जरूरत से ज्यादा सख्ती कर देती हैं। वे routine read actions के सामने human रख देती हैं और reviewers लगभग एक जैसी cards को बिना देखे approve करते रहते हैं। Records तो बनते हैं, लेकिन review औपचारिकता बन जाता है। Per call approval को उन सीमित credentials या actions के लिए रखें जिनकी सचमुच जरूरत है। सामान्य काम के लिए session approval इस्तेमाल करें और credential scope अलग से कम करें।

Reviewer को decision लेने के लिए पर्याप्त context चाहिए। HTTP action में आमतौर पर method, destination, credential identity और request के प्रभाव का सुरक्षित description चाहिए। SSH के लिए host identity और command या constrained command description चाहिए। केवल evidence को समृद्ध बनाने के लिए secret को approval payload में कभी न डालें। Approval card के जरिए reviewer को दिखाया गया secret फिर भी disclosed secret ही है।

## Revocation से ऐसा denial बनना चाहिए जिसे दिखाया जा सके

Revocation evidence बेकार है यदि वह केवल user interface event record करती है। Control तब काम कर रहा है जब authority समाप्त हो और बाद की attempt उसी कारण से fail हो।

Audit में मांगे जाने से पहले यह test करें। ऐसा session शुरू करें जिसे nonproduction test action इस्तेमाल करने की permission हो। Successful call confirm करें। Process के चलते रहने के दौरान session revoke करें। फिर उसी process से दूसरी call करने की कोशिश कराएं। चार linked records सुरक्षित रखें: पहली successful call, revocation event, दूसरी denied call और session state।

आपकी test worksheet इतनी सरल हो सकती है:

```text
Test ID: AGT-REV-01
Session ID: ____________________
First call ID and result: ____________________
Revocation time and actor: ____________________
Second call ID and denial result: ____________________
Reason shown for denial: ____________________
Reviewer and date: ____________________
```

Ordering ही control है। 14:03 पर revoke event के बाद 14:07 पर successful call हुई तो यह failure, clock problem या इस बात का evidence है कि session identifier का अर्थ वह नहीं है जो आपने बताया था। इनमें से किसी को भी बिना जांचे टालना ठीक नहीं है।

Ordinary session exit और explicit revocation को अलग रखें। Exit इसलिए process समाप्त करता है क्योंकि वह चलना बंद कर चुका है। Revocation इसलिए authority समाप्त करती है क्योंकि reviewer ने उसे वापस लेने का निर्णय लिया। दोनों को बाद की calls रोकनी चाहिए, लेकिन केवल revocation यह दिखाती है कि कोई human concern के जवाब में live run समाप्त कर सकता है। Evidence table में event types अलग रखें।

यह control incident response practice का भी हिस्सा है। यदि reviewer को calls का suspicious sequence दिखे, तो उसे पता होना चाहिए कि run को कौन revoke कर सकता है, denial कितनी जल्दी प्रभावी होती है और journal में event कहां दिखाई देगा। «Agent को disable करें» कहने वाली written procedure, बिना actual action बताए, तब पर्याप्त नहीं है जब agent पहले से काम कर रहा हो।

## Offline verification application के बाहर history की जांच करती है

Activity journal accountability देती है। Independently verifiable hash chain यह test करने का तरीका देती है कि retained sequence अब भी आपस में जुड़ी हुई है। दोनों संबंधित हैं, लेकिन एक-दूसरे के बदले इस्तेमाल नहीं किए जा सकते।

Sallyport session और activity views को एक encrypted, write blind audit log से project करता है। Offline command `sp audit verify` ciphertext पर chain check करती है और उसे vault access की जरूरत नहीं होती। यह उपयोगी evidence है क्योंकि verifier उस system से credentials decrypt करने या vault access देने को कहे बिना retained history test कर सकता है जिसने report बनाई थी।

यह दावा बढ़ा-चढ़ाकर न करें कि इससे क्या साबित होता है। Hash chain verification verified scope के भीतर missing, reordered या altered record का पता लगा सकती है, यह chain design और retained material पर निर्भर करता है। यह साबित नहीं करती कि application ने हर जरूरी event emit किया था। यह भी साबित नहीं करती कि time source सही था, approver ने सही decision लिया या underlying external API ने वही किया जिसका उसने दावा किया। ये अलग control questions हैं।

Defined retained range के लिए verification record रखें। कई teams के लिए यह working-paper format पर्याप्त है:

```json
{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}
```

Failed verification के बाद clean result न बनाएं। Failure record करें, material सुरक्षित रखें, पता लगाएं कि समस्या export handling, retention, software defect या suspected alteration से आई है, और उसे incident handling में भेजें। Failed integrity check अपने आप breach नहीं है। यह investigation की मांग करने वाला event है क्योंकि आपकी evidence chain भरोसेमंद नहीं रह गई है।

Agent activity के volume और risk के अनुसार schedule बनाकर verification चलाएं, और evidence package तैयार करने से पहले भी इसे चलाएं। छोटे environment में monthly job पर्याप्त हो सकती है। जो team पूरे दिन production systems पर agents चलाती है, उसे integrity problem का पता quarter end तक नहीं चलना चाहिए। Schedule से ज्यादा जरूरी यह दिखा पाना है कि verification लगातार हुई और failures को संभाला गया।

## Operational actions और system changes के लिए अलग proof चाहिए

यही वह सीमा है जो सबसे ज्यादा धुंधली होती है। Agent action किसी चीज में बदलाव कर सकती है। इससे वह CC8.1 के लिए controlled system change नहीं बन जाती।

तीन examples देखें। Agent API का उपयोग करके customer की subscription status बदलता है। यह business operation है और इसे authorization, traceability और संभवतः review चाहिए। Agent infrastructure file को source repository में edit करता है, pull request review होती है, tests pass होते हैं और deployment pipeline उसे लागू करती है। यह system change है। Agent SSH command से production configuration file सीधे edit करता है। यह elevated risk वाली operational action भी है और यदि policy reviewed deployments मांगती है तो change process का संभावित उल्लंघन भी।

Evidence package में इन paths को स्पष्ट दिखना चाहिए, न कि reviewer को prose से अनुमान लगाना पड़े। Activity record या evidence analysis में action classification जोड़ें:

| Action class | Primary evidence | What it does not replace |
|---|---|---|
| Read or diagnostic operation | Session authorization और call record | Access scope और monitoring rules की review |
| Business data operation | Session या per call approval, call record, outcome | जरूरत पड़ने पर customer support process या financial approval |
| Production system operation | Per call approval, host या endpoint record, incident या maintenance reference | यदि operation managed configuration बदलती है तो formal change control |
| Product or infrastructure change | Pull request, approval, tests, deployment record, उपयोग हुआ हो तो agent activity | Release control स्वयं |

CC8.1 में management से infrastructure, data, software और procedures में changes को authorize, design, develop या configure, document, test, approve और implement करने की अपेक्षा होती है। Agent journal इस कहानी को बेहतर बना सकता है, जैसे यह दिखाकर कि agent ने pull request खोली या deployment-related action शुरू की। वह review, test evidence और deployment record की जगह नहीं ले सकता।

यह बात कुछ लोगों को पसंद नहीं आती क्योंकि एक audit log से हर सवाल का उत्तर मिलने की उम्मीद होती है। ऐसा नहीं हो सकता। Agent activity trail को delegated action के record के रूप में रखें। System changes के required path पर चलने का proof engineering change records में रखें। दोनों को तभी जोड़ें जब agent ने उस path में हिस्सा लिया हो।

## Evidence package screenshot folder से नहीं, population से बनाएं

हर review period के लिए एक repeatable package बनाएं। पहला काम population तय करना है। Agent activity में आमतौर पर period के सभी sessions, सभी protected calls, सभी call denials, सभी revocations और सभी log verification runs शामिल होंगे। यदि आप counts या complete export नहीं दे सकते, तो यह विश्वसनीय रूप से नहीं कह सकते कि auditor ने पूरी population में से sample चुना।

फिर एक छोटा evidence manifest तैयार करें जो immutable या retained source artifacts की ओर संकेत करे। final-final-audit जैसे नामों वाली files का ढेर upload न करें। Stable identifiers, source location, period, owner और artifact क्या साबित करता है इसका note रखें।

Reviewer यह sequence इस्तेमाल कर सकता है:

1. Period की session और activity populations तथा integrity verification records प्राप्त करें।
2. Activity entries में referenced session identifiers की संख्या को session population से मिलाएं और unmatched records की जांच करें।
3. Approved sessions, denied attempts, sensitive calls, revocations और अलग-अलग time ranges से samples चुनें।
4. हर selected call को authorization तक पीछे और result तक आगे trace करें, फिर उसकी retained range को cover करने वाला log verification record देखें।
5. Gateway या संबंधित production controls में changes के लिए संबंधित pull request, test, approval और deployment record को अलग से trace करें।

यह sequence gaps जल्दी दिखा देती है। Call का session न हो तो authorization join fail हुआ। Session में process identity न हो तो process claim test नहीं किया जा सकता। Revocation के बाद denial test न हो तो केवल इतना पता है कि किसी ने button दबाया। Verification records ऐसे archive को cover करते हों जिसे reproduce नहीं किया जा सकता, तो integrity claim कमजोर है।

Sample के साथ reviewer notes रखें। «Call ID 54b, Session ID 12a से match हुई; session employee A ने approve की; per call approval जरूरी थी और मौजूद थी; activity result completed था; audit range verification pass हुई» जैसा छोटा note दस screenshots से अधिक उपयोगी है। इससे अगला reviewer जानता है कि क्या test हुआ और control बदलने पर trail बना रहता है।

## जब owners exceptions समझा नहीं पाते, evidence fail हो जाता है

सबसे अच्छी evidence table भी fail हो जाएगी यदि exception path का कोई owner नहीं है। Agent actions deny होंगी। Approval requests expire होंगी। Remote endpoint पर calls fail होंगी। Sessions revoke होंगी। Verification problem report कर सकती है। ये outcomes population में दिखाई देने चाहिए और team को पता होना चाहिए कि किन पर action जरूरी है।

Exceptions की सीमित categories तय करें: unauthorized attempt, approval rejection, remote action failure, post revocation attempt, missing record join और verification failure। हर category के लिए owner, review cadence और expected record तय करें। हर denied API request को security incident बनाने की जरूरत नहीं है। किसी unexpected signed process की बार-बार denials, engineer द्वारा अपना experimental command decline करने से अधिक ध्यान मांग सकती हैं।

असल test यह है कि क्या कोई selected exception को chat messages से कहानी जोड़कर नहीं, बल्कि records के आधार पर समझा सकता है। Activity record immediate reason बताए। Session record run की पहचान करे। Follow-up में लिखा हो कि team ने outcome स्वीकार किया, configuration सुधारी, access revoke किया या incident handling शुरू की।

यहीं control changes में भी discipline चाहिए। यदि approval behavior, credential flags, logging fields या retained logs verify करने की procedure बदलते हैं, तो इसे control environment में change मानें। Control narrative update करें, नया behavior test करें और existing engineering process के जरिए deployment record करें। वरना आपकी evidence table पिछले quarter के system का वर्णन करेगी जबकि इस quarter के agents कुछ और इस्तेमाल कर रहे होंगे।

Auditor से evidence connections पर राय मांगने तक इंतजार न करें। इस सप्ताह एक real session चुनें, उसे authorization से call outcome तक trace करें, safe environment में revoke करें और retained audit range को offline verify करें। यदि आपकी team यह exercise पहले से उपलब्ध records के साथ पूरी नहीं कर सकती, तो control wording पर बहस करने से पहले evidence path ठीक करें।