title: “ऑडिट — एजेंटिक सुधार पहचान” description: “AgentEye ऑडिट — एजेंटिक सुधार पहचान दस्तावेज़।”
ऑडिट आवर्ती कार्य हैं जो सेशन के दौरान आपके एजेंट लॉग को खनन करते हैं ताकि सुधार के लिए महत्वपूर्ण चीजें मिलें। जहाँ एक अलर्ट एक ऐसी मेट्रिक देखता है जिसे आप पहले से जानते हैं रीयल-टाइम के करीब, एक ऑडिट जांच करता है: आपके द्वारा निर्धारित शेड्यूल पर, यह विंडो पर एक नियतात्मक नीति पास चलाता है, फिर एक AI विश्वसनीयता एजेंट को आपके सेशन पर ढीला छोड़ता है — एजेंट स्वयं डेटा को क्वेरी करता है, संदिग्ध ट्रांसक्रिप्ट पढ़ता है, और (जब यह मदद करता है) छोटी विश्लेषण स्क्रिप्ट चलाता है, फिर सुधार सिफारिशें लिखता है जिसमें प्रत्येक के पीछे का सबूत होता है। अपने एजेंट में “मुझे क्या ठीक करना या सुधारना चाहिए?” का उत्तर देने के लिए ऑडिट का उपयोग करें — और किसी विशिष्ट थ्रेशहोल्ड के पार जाते ही पेज पाने के लिए अलर्ट का उपयोग करें। हर सुधार उसके पीछे के सटीक सेशन और क्वेरी से जुड़ा होता है, और एक क्लिक पुनरावृत्तियों को पकड़ने के लिए एक पूर्व-भरे अलर्ट बनाता है। डैशबोर्ड सतह/<org-slug>/audits है (साइडबार → विश्लेषण → audits), audits:read / audits:write अनुमतियों द्वारा गेटेड।
एक रन कैसे काम करता है
प्रत्येक रन के दो परत होते हैं — एक नियतात्मक आधार और एक एजेंटिक जांच।1. नीति पास (नियतात्मक)
किसी भी मॉडल के चलने से पहले, ऑडिट विंडो के पार SQL नीति जांच के एक छोटे कैटलॉग को निष्पादित करता है: बंधी हुई कुल क्वेरी जो ज्ञात-खराब पैटर्न को फ्लैग करती हैं और कितने इवेंट / कौन से सेशन मेल खाते हैं - कभी मेल खाए हुए टेक्स्ट को नहीं। कैटलॉग में शामिल हैं:- इवेंट पेलोड में रहस्य / क्रेडेंशियल लीकेज — AWS एक्सेस कीज,
sk-…API कीज, PEM निजी कीज, JWT / वाहक टोकन, औरKEY=…क्रेडेंशियल असाइनमेंट। - प्रॉम्प्ट-इंजेक्शन मार्कर — “पिछली निर्देशों को नज़रअंदाज़ करें”, “अपना सिस्टम प्रॉम्प्ट प्रकट करें”, और समान।
- PII — SSN-आकार की संख्याएं (अनुमानी)।
- टूल-अनुमति निषेध और भागती हुई टूल-कॉल लूप।
policy) के रूप में संरक्षित किया जाता है जो हमेशा सतह पर आते हैं (वे कभी प्रति-रन कैप द्वारा ट्रिम नहीं होते हैं), और वे AI एजेंट को शुरुआती सुराग के रूप में सौंपे जाते हैं। क्योंकि इस परत को कोई मॉडल की आवश्यकता नहीं है, एक ऑडिट अपने सबसे महत्वपूर्ण सुरक्षा संकेत तब भी उत्पन्न करता है जब AI एजेंट अनुपलब्ध हो।
2. एजेंटिक जांच (AI)
ऑडिट फिर एक स्वायत्त विश्वसनीयता एजेंट चलाता है (वही Claude एजेंट SDK सेवा जो डैशबोर्ड सहायक को शक्ति देती है, एक ऑडिट-विशिष्ट प्रॉम्प्ट के साथ)। ऑडिट के स्कोप (चयनित एजेंट × वातावरण) और समय विंडो को देखते हुए, एजेंट:- आपकी विश्लेषिकी तालिकाओं के विरुद्ध केवल-पढ़ने योग्य SQL क्वेरी चलाता है,
- प्रतिनिधि सेशन ट्रांसक्रिप्ट की एक मुट्ठी पढ़ता है,
- वैकल्पिक रूप से SQL व्यक्त नहीं कर सकता उसके लिए विश्लेषण के लिए एक लॉक-डाउन में-पॉड सैंडबॉक्स में छोटी Python स्क्रिप्ट लिखता और चलाता है (कोई नेटवर्क नहीं, कोई फाइलसिस्टम एक्सेस नहीं, रहस्य स्क्रबड) — त्रुटियों को क्लस्टर करना, वितरण की गणना करना, पेलोड को स्वीप करना जिसे यह पहले से प्राप्त कर चुका है,
- और प्रत्येक अच्छी तरह से समर्थित सुधार को रिकॉर्ड करता है जो यह पाता है।
- एक सिफारिश (ठोस परिवर्तन करना — एक प्रॉम्प्ट ट्वीक, एक टूल-स्कीमा फिक्स, एक पुनः प्रयास नीति, एक गार्डरेल, अधिक eval कवरेज),
- एक अपेक्षित प्रभाव और एक प्रयास अनुमान (कम / मध्यम / उच्च),
- एक परिमाण —
big(एक ऑपरेटर को पेज किया जाना चाहिए),medium(रन रिपोर्ट में संबंधित है), याsmall(डैशबोर्ड संदर्भ), - एक स्थिर फिंगरप्रिंट (मुद्दे की श्रेणी + स्कोप से, इस रन के सेशन से नहीं) ताकि एक ही मुद्दे को रन-ओवर-रन ट्रैक किया जा सके यहां तक कि जब साक्ष्य बदल जाता है,
- और, जहाँ एक सरल नियतात्मक वाचक पुनरावृत्ति को पकड़ सकता है, एक सुझाया गया अलर्ट जिसे आप एक क्लिक में बना सकते हैं।
AI परत वैकल्पिक-लेकिन-अनुशंसित है। यदि ऑडिट पाइपलाइन के लिए कोई AI एजेंट कॉन्फ़िगर नहीं किया गया है, तब भी रन निष्पादित होते हैं, नीति निष्कर्ष को संरक्षित करते हैं, और ईमानदारी से एजेंटिक परत के लिए “विश्लेषण अनुपलब्ध” रिपोर्ट करते हैं, चुप्पी से पास करने के बजाय।
विफलता मोड
सुधार आपके संगठन के टिकाऊ विफलता-मोड कैटलॉग में वर्गीकृत होते हैं (या एक नया मोड प्रस्तावित करते हैं)। मोड पैटर्न को रन भर में और लंबे-क्षितिज पुनरावृत्ति ट्रैकिंग में एक स्थिर पहचान देते हैं।छंटाई जीवनचक्र
एक निष्कर्ष पृष्ठ पर (/audits/<id>/findings/<finding-id>):
| कार्रवाई | प्रभाव |
|---|---|
| स्वीकार करना | निष्कर्ष को दृश्यमान रखता है लेकिन इसकी प्राथमिकता को आधा कर देता है। |
| हल करना | इसे ठीक किए गए के रूप में चिह्नित करता है। यदि पैटर्न वास्तव में बाद में वापस आता है, तो यह नए के रूप में फिर से खुलता है — इसलिए एक प्रतिगमन जोरदार होता है, चुप्पी से इतिहास में नहीं। |
| मौन / खारिज करना | टिकाऊ दमन: पैटर्न की फिंगरप्रिंट याद रखी जाती है और कभी सतह पर नहीं आती है, रन भर में भी। “ज्ञात, स्वीकृत” के लिए मौन का उपयोग करें; “उपयोगी नहीं” के लिए खारिज करना। |
| फिर से खोलना | दमन / संकल्प को साफ करता है और पैटर्न को फिर से रैंक करता है। |
top_k) के साथ नियंत्रित किया जाता है। नीति निष्कर्ष कैप को बायपास करते हैं (वे सुरक्षा-प्रासंगिक हैं और हमेशा दिखाए जाते हैं)। कैप द्वारा कुछ भी कट रन के आंकड़ों में गिना जाता है — कुछ भी चुप्पी से ड्रॉप नहीं किया जाता है।
शेड्यूलिंग
- Cadence (
schedule_interval_secs): प्रति घंटा से साप्ताहिक; दैनिक डिफ़ॉल्ट है। ऑडिट जानबूझकर अलर्ट की तुलना में मोटे हैं — एक एजेंटिक जांच पूरी विंडो को स्कैन करती है और मिनटों के लिए चलती है। - विंडो: या तो एक निश्चित रोलिंग लुकबैक (उदा. “हर रन पिछले 7 दिन स्कैन करता है”) या since-last-run (डिफ़ॉल्ट) — प्रत्येक रन पिछले सफल रन से जहाँ रुका था वहीं उठाता है, एक छोटे ओवरलैप के साथ ताकि सीमा इवेंट कभी मिस न हों।
- अगला रन पिछले एक पूरा होने के बाद एक पूर्ण अंतराल के लिए शेड्यूल किया जाता है, इसलिए एक धीमा रन कभी एक ही ऑडिट का दूसरा समवर्ती रन ढेर नहीं करता।
- ऑडिट पृष्ठ पर अभी चलाएं इसे तुरंत कारण बनाता है।
मॉडल चयन
एक ऑडिट बनाते समय आप जांच के लिए कौन सा मॉडल उपयोग करता है वह चुन सकते हैं, मॉडल की सूची से जिसे आपके ऑपरेटर ने एजेंट सेवा के लिए कॉन्फ़िगर किया है। एक एकल मॉडल कॉन्फ़िगर किए जाने पर, पिकर इसे कैप्शन के रूप में दिखाता है; कई होने पर, आप चुनते हैं। इसे सेट न छोड़ने से कॉन्फ़िगर किए गए डिफ़ॉल्ट का उपयोग होता है।सूचनाएं
जब एक रन नए निष्कर्ष सतह पर आते हैं, ऑडिट आपके संगठन के कॉन्फ़िगर किए गए चैनलों को सूचित करता है — वहीalerts.enabled_channels गेट और सेटिंग्स जो अलर्ट पाइपलाइन का उपयोग करता है:
- Slack — महत्वपूर्ण (
big) नए आइटम का एक सारांश एक गहरे लिंक के साथ। - Email — एक डिज़ाइन किया गया ऑडिट रिपोर्ट जो नई सुधारें सूचीबद्ध करता है (शीर्ष गंभीरता, प्रति-आइटम सिफारिशें, गहरा लिंक), जब ऑडिट के पास एक email चैनल संलग्न होता है और कम से कम एक नया निष्कर्ष होता है।
कॉन्फ़िगरेशन संदर्भ
ऑडिट परिभाषाएं डैशबोर्ड (/audits/new) या API के माध्यम से प्रबंधित की जाती हैं। प्रति-ऑडिट सेटिंग में शेड्यूल cadence और विंडो, स्कोप ({"environments": [...], "agent_ids": [...]}) शामिल हैं, संवेदनशीलता (low / medium / high), सूचना चैनल, प्रति-रन निष्कर्ष कैप (top_k), और मॉडल (via llm_budget.model)। ऑपरेटर-स्तर सर्वर सेटिंग (टाइमआउट, सैंडबॉक्स, एजेंट-सेवा URL) deployment.md में दस्तावेज़ित हैं।
API
सभी एंडपॉइंट संगठन-स्कोप किए गए हैं और मानक वाहक-कुंजी प्रमाणीकरण का पालन करते हैं (api-keys.md देखें)।| एंडपॉइंट | अनुमति | उद्देश्य |
|---|---|---|
GET /audits · POST /audits | audits:read / audits:write | ऑडिट परिभाषाएं सूचीबद्ध / बनाएं। |
GET / PUT / DELETE /audits/:id | read / write / write | एक ऑडिट का निरीक्षण, संपादन, हटाना। |
POST /audits/:id/run | audits:write | ऑडिट को तुरंत कारण बनाएं। |
GET /audits/:id/runs | audits:read | रन इतिहास (विंडो, स्थिति, आंकड़े, निष्कर्ष गणना)। |
GET /audits/findings | audits:read | संगठन-व्यापी निष्कर्ष, audit_id, status द्वारा फ़िल्टर किए जा सकते हैं; प्राथमिकता द्वारा क्रमबद्ध। |
GET /audits/findings/:fid | audits:read | पूर्ण निष्कर्ष विवरण (सिफारिश, सबूत, प्राथमिकता)। |
POST /audits/findings/:fid/status | audits:write | छंटाई: {"action": "ack" | "mute" | "dismiss" | "resolve" | "reopen" | "assign"}. |