作者：徐可甲（烨陌）
随着 Qoder 在企业内覆盖更多团队，它参与的开发任务也随之增多。为完成这些任务，Qoder 可能需要读取项目配置、分析运行日志或调用内部工具，并在这一过程中接触访问凭据、客户信息等敏感数据。当这些操作分散在不同成员、项目和环境中，安全团队需要持续掌握：哪些任务接触了敏感数据，这些数据被用于什么操作，是否符合企业的安全要求？
作出这些判断，需要结合任务目的、工具调用和返回结果，核对敏感内容的使用是否超出了允许范围。如果问题涉及多个项目共用的配置或工具，还要检查使用它们的其他任务，确认是否存在同类情况。这些核查需要以能够关联到具体任务与调用的 Agent 审计日志为依据。
智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志，将发现的风险线索关联到具体会话、工具调用、成员和环境，帮助安全团队回查任务过程、明确需要整改的环节，并复查处理效果。针对任务中凭据类敏感数据的泄露风险，企业还可在已适配的 Qoder 客户端中启用本地凭据保护，拦截命中规则的内容。
隐藏在 AI Agent 任务中的敏感数据风险
2026 年公开的调查与案例，记录了开发环境中的安全问题、公开配置中的凭据暴露，以及利用 Coding Agent 转移企业数据的行为：
- 开发环境中的安全问题：Snyk 于 2026 年 6 月发布了基于近 1 万个开发环境匿名遥测的研究 [ 1] 。在已安装 MCP 服务的开发者样本中，约每 7 人就有 1 人的配置检出至少一项安全问题，约每 12 人就有 1 人检出高危或严重问题。安全发现不限于凭据，检出率不等于实际泄漏率。
- 公开暴露且仍然有效的凭据：GitGuardian 2026 年 3 月发布的报告 [ 2] 在公共 GitHub 的 MCP 相关配置文件中发现 24,008 项不同的密钥等敏感信息，其中 2,117 项凭据在验证时仍然有效。
- 执行过程中的大规模数据转移：据 Noma 于 2026 年 9 月披露的案例 [ 3] ，一名企业员工指挥 Coding Agent 收集、打包私有源码等公司数据并上传到外部云存储，后续指令还明确要求不排除认证密钥。整段活动跨越两天，最终转移了数十 GB 数据。该案例来自厂商披露，未公开客户名称或原始日志，仅凭公开材料无法独立核验事件全貌。
凭据泄露风险并不只来自恶意行为。即使任务本身合理，Agent 也可能在排查问题的过程中，无意间将凭据带入后续交互。设想开发者用 Qoder 新增文件上传接口，复用项目已有的文件存储服务。联调时，存储服务返回 AccessDenied，Qoder 为核对连接参数读取 config/storage.local.json，其中的 AccessKey 随文件内容一并出现在工具返回结果中。如果后续模型请求带上这段工具结果，凭据也会进入模型上下文。
风险还可能延伸到后续的对外请求。为进一步排查原因，开发者要求将错误摘要提交至外部诊断服务 https://diagnostics.example.com/report（示例地址）。Qoder 随后调用工具，向该地址发起 HTTP POST 请求。若请求参数中除了错误摘要，还包含刚读取的含凭据配置，凭据就可能随请求发送到该服务。即使企业允许使用该服务排查问题，向其提交访问凭据也可能超出允许范围。
图 1：凭据在模型交互与对外请求中的潜在传递路径。
判断这类风险，需要结合企业的数据使用要求和 Agent 审计日志，核对凭据的来源、请求内容与执行结果。仅命中 AccessKey，不能证明凭据已成功外发；还需查看审计日志中对应工具调用的返回内容，根据实际响应核实请求是否发送成功。
类似的文件读取、日志分析和工具查询，还可能接触业务资料、个人信息和源码：
下文以 AccessKey 为例，说明如何从配置读取中的凭据线索出发，开展审计、调查和处理，并通过本地保护减少凭据继续传递的风险。
为敏感数据审计留存执行证据
审计开发任务中的敏感数据使用情况，需要核查敏感数据的来源、使用方式及去向。Qoder 提供 Hook 扩展机制，允许在用户提交、工具调用前后等环节运行自定义逻辑，为审计日志采集和安全检查提供接入基础。不过，若直接基于 Hook 建设审计，企业仍需自行开发和维护日志采集、格式整理、会话与调用关联，以及脱敏和上报等处理流程。
AgentLoop 通过开源采集组件 LoongSuite Pilot [ 4] （下文简称 Pilot）承接这些工作。Pilot 运行在 Qoder 所在的终端或主机上，持续采集并整理用户请求、工具参数和返回结果，形成 Agent 审计日志。这些日志保留会话、调用标识与执行顺序，并关联用户、主机和工作区。经处理后，日志接入 AgentLoop，调查人员便能沿同一任务回查凭据的来源、出现位置及后续相关操作，并定位涉及的成员与环境。企业因此可以减少自行建设和维护采集处理流程的工作，将精力集中在风险调查与处置上。
Agent 审计日志中也可能包含凭据等敏感内容。Pilot 可按已启用的脱敏规则，在企业本地域内将命中的敏感值替换为类型标记，再上报处理后的审计日志。内置脱敏规则覆盖特定格式的云 AccessKey、API Key、SSH 私钥等凭据，以及部分个人信息，企业可按需启用相应规则。处理后，调查人员仍可结合保留的类型标记、出现位置、会话与调用关系核查任务，在减少敏感原值留存的同时保留调查线索。企业安全团队还可结合 Pilot 的源码与部署配置，核查采集范围、脱敏规则和上报流程是否符合企业的安全要求。
上报后的审计日志存储在客户名下的 SLS 中，通过 RAM 权限控制访问。企业可设置审计人员的访问范围与日志保留周期，管理数据的留存和使用。
图 2：Qoder 审计日志的采集、处理与上报。
用 AgentLoop 追查风险并推进整改
AgentLoop 持续分析已采集的 Agent 审计日志，通过规则检测与模型语义研判发现风险。规则检测匹配敏感特征与行为条件，识别已知风险；需要结合上下文判断的线索，则通过回查会话证据、对照任务要求与实际操作，进一步研判是否构成风险。满足判定条件后，AgentLoop 形成风险事件，保留判定依据、证据位置与关联会话，供安全团队调查和复核。
图 3：AgentLoop 的规则检测与语义研判流程。
定位并核实凭据外发风险
以上述诊断请求为例，若发往外部诊断服务的请求参数中包含访问凭据，就会形成“阿里云凭证出现在外发意图中”的风险线索。安全团队可在风险浏览器中，按应用、时间、风险类型和严重性筛选事件，定位需要调查的诊断请求。
图 4：在风险浏览器中定位凭据外发线索。
调查人员可从风险事件进入关联会话，核对向 diagnostics.example.com 发起请求的工具调用，再对照配置读取结果与后续模型交互，核查凭据是否来自 config/storage.local.json，并追溯其进入诊断请求参数的过程。
图 5：外发请求中的凭据线索与关联会话。
在此基础上，调查人员需结合诊断目的、任务要求和企业的数据使用规定，判断请求中携带的凭据是否属于允许提交的内容，并依据工具调用记录中的服务响应，核实请求是否发送成功。对于已确认外发的凭据，还可结合云账户访问记录，核查访问来源与操作内容，判断是否存在未经授权的使用。
通过实体调查排查同类风险
同一凭据可能被多个任务使用，单次事件的调查也可以延伸到这些关联任务。AgentLoop 支持以凭据为起点开展实体调查：Secret 实体概览汇总该凭据关联的风险与会话，实体关系则展示相关成员、主机、应用、工具和外联域名，为确定核查范围提供线索。
图 6：凭据关联的风险与会话概览。
图 7：凭据与成员、主机、工具等实体的关联关系。
围绕本次发现的凭据，调查人员可结合 qoder:read、qoder:exec 与 diagnostics.example.com 等关联对象，回查相应会话中的文件读取和外联请求，核对诊断请求是否同样包含该凭据，从而判断相关任务中是否存在同类的凭据外发问题。
从用户维度分析风险构成
调查还可从凭据延伸到关联用户，查看其开发任务中的风险分布。AgentLoop 的用户风险详情汇总当前查询范围内该用户关联的风险与会话，并提供主机、应用、工具和外联域名等信息。安全团队可结合风险类型、严重性和发生时段，查看凭据暴露是否反复出现，非预期代码执行、文件删除等风险是否集中在特定任务或环境中，据此确定需要优先核查的会话。
图 8：用户风险构成、发生环境与关联实体。
落实整改并持续复核
对于调查确认的凭据传递问题，研发团队可调整配置访问权限与诊断内容的生成方式，避免将凭据写入对外请求；凭据负责人则结合暴露范围与云账户访问记录，评估是否需要轮换凭据或调整权限。若确认多起问题源于共用配置或诊断工具，应同步修正涉及的项目；成因不同的问题则分别处理。
整改中明确的数据使用要求，也可以转为后续任务的审计条件。内置规则用于发现凭据外发等通用风险；对于企业特定的文件范围和上传目标限制，可通过自定义规则补充。例如，在整理客户数据或生成报表时，企业可要求 data/customer-export/ 和 data/finance/ 目录中的文件仅提交至批准的 files.corp.example。若 Qoder 调用工具，将这些目录中的文件上传至 convert.example.com 等未获准服务，规则便可根据上传参数中的文件路径与目标地址，发现不符合企业要求的上传请求。这类检测不依赖日志中是否包含完整文件内容，也不以命中已知凭据特征为前提。
审计人员可用自然语言说明受限目录、批准服务和判定条件，由 Agent 助手生成规则，并准备正、反例进行验证。例如，同一文件上传至未获准服务时应命中，上传至批准服务时则不应命中。经验证和人工审核后启用规则，即可持续检查后续 Qoder 任务的相关审计日志，并回查命中记录对应的会话与工具调用。
图 9：自定义受限文件上传审计规则。
整改后，还要看看后续任务中，诊断请求是否仍有不该提交的凭据，文件上传是否符合企业要求。如果问题再次出现，就回到对应会话，检查相关配置和工具还有哪里需要调整。
在 Qoder 执行时拦截凭据传递
通过 Agent 审计日志，安全团队能够发现风险、追查原因并推进整改。但发现风险时，相关操作可能已经执行，凭据也可能已经进入模型上下文或发送到外部服务。因此，除了事后调查，企业还需要在任务执行过程中介入，在凭据被传递之前进行检查和拦截。
凭据拦截依托本机运行的 LoongSuite-Pilot 服务。Pilot 通过本地规则识别凭据，由 Qoder 根据检查结果执行阻断。检测环节无需将原始内容传出本机，也不依赖模型推理，省去了远端检测的网络往返和推理等待，也不产生额外的模型调用费用，适合在日常开发中持续启用。
图 10：本地凭据检查、客户端拦截与审计上报。
在本地检测并拦截含凭据的内容
在已适配的 Qoder 客户端中（包括 Qoder CLI），企业可启用本地凭据保护，减少凭据进入模型上下文或随请求外发的风险。Pilot 在以下三个环节进行检查，由 Qoder 根据检查结果执行拦截：
- 用户提交时：检查用户输入。若提交内容包含命中规则的凭据，Qoder 拒绝提交。
- 工具调用前：检查待执行的工具参数。例如，发往 diagnostics.example.com 的诊断请求包含命中规则的凭据时，Qoder 拒绝该次调用，阻止请求执行。
- 工具返回时：检查文件读取或脚本执行的返回内容。例如，config/storage.local.json 的读取结果中包含命中规则的 AccessKey 时，Qoder 会在将结果交给模型前，把整段工具结果替换为拦截提示。
图 11：Qoder 拦截含凭据的工具返回内容。
在 AgentLoop 中核查拦截效果
Pilot 将本地凭据检查记录和相关 Agent 审计日志上报至 AgentLoop，日志中的敏感字段按启用的脱敏规则处理。安全团队可在“拦截记录”中查看处理决策，并结合会话记录与客户端反馈，核实 Qoder 是否实际执行了拒绝或替换。
图 12：查看拦截记录与关联会话。
当前，本地保护主要覆盖规则可识别的凭据传递风险，包括特定格式的云 AccessKey、部分 API Key、私钥和带密码的数据库连接串。Pilot 服务不可用或检查超时时采用放行策略，因此，核查保护效果时也要关注本地服务是否正常、相应规则是否启用。
后续计划支持基于审计风险发现的自定义拦截规则。届时，安全团队可依据审计调查中确认的风险和企业安全要求配置拦截条件，对后续任务中命中条件的操作实施阻断。
通过 Qoder 企业管理统一部署审计与凭据保护
要让审计采集和本地凭据保护覆盖更多团队，需要将 Pilot 部署到相应成员的开发终端。企业可以通过 Qoder 的企业专属市场统一分发 Pilot 安装插件，并随插件交付管理员准备的初始配置，减少成员逐一安装和配置的工作。
图 13：通过 Qoder 企业专属市场分发 Pilot 安装插件。
管理员可选择向全员或指定分组下发插件，并根据企业管理要求，设置客户端可配置、强制开启或静默启用等策略，分别确定部署范围与客户端启用方式。
图 14：设置插件下发范围与启用策略。
插件下发并启用后，会在成员开始新会话时检查本地状态，按需安装或更新 Pilot，并应用相应的采集与凭据保护配置。
接入后，安全团队可在 AgentLoop 中查看相应成员的审计日志与凭据检查记录，核对开发任务的接入情况，并结合关联会话检查本地保护的处理结果。随着 Qoder 在更多团队中使用，企业既可以统一组织部署，也能持续回查实际开发任务中的敏感数据风险。
可通过审计接入指南 [ 5] 了解支持的接入方式，也可访问 AgentLoop 演示环境 [ 6] ，体验风险查询、会话查看与实体调查。
相关链接：
[1] 研究
[2] 报告
blog.gitguardian.com/the-state-o…
[3] 案例
[4] LoongSuite Pilot
[5] 审计接入指南
[6] AgentLoop 演示环境
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
by Seo Koji
As Qoder reaches out to more teams within the enterprise, its involvement in development tasks increases. To accomplish these tasks, Qoder may need to read project configurations, analyse running logs or call in-house tools and, in the process, access sensitive data such as certificates, client information, etc. When these operations are dispersed among different members, projects and environments, the security team needs to maintain an ongoing grasp of: Which missions have access to sensitive data, what have they been used for, and compliance with business safety requirements?
These judgements need to be made by checking whether the use of sensitive elements is beyond the permissible limits, taking into account the purpose of the mission, tool call and the return results. If the question relates to configurations or tools shared by multiple projects, other tasks in which they are used are examined to determine whether similar situations exist. These verifications need to be based on the Agent audit log that can be linked to specific tasks and calls.
The AI agent Observatory and Optimization Platform AgentLoop continuously analyses the Qoder audit logs already collected, linking the identified risk trails to specific sessions, tool call, members and environments, helping the security team to re-examine the mission process, identify the links that need to be overhauled and review the effects of the treatment. In response to the risk of leaking evidence-based sensitive data in missions, enterprises can also use local evidence protection to intercept the content of the hit-off rule in a suitable Qoder client.
Sensitive data risks hidden in AI Agent missions
Publicly published surveys and cases in 2026 documented security in the development environment, evidence exposure in open configuration, and the use of Coding Age to transfer business data:
- Security in the development environment: Snyk conducted a study based on almost 10,000 development environments anonymous telemetry [1] in June 2026. Of the developers of MCP services that have been installed, sample, about 1 person per 7 persons has been identified with at least one security problem and 1 person per 12 persons with high risk or serious problems. Safety discoveries are not limited to evidence and detection rates do not equal actual leakage rates.
- Publicly exposed and still in force: GitGuardian ' s March 2026 report publish[2] found sensitive information such as 24,008 different keys in a public GitHub MCP configuration document, of which 2,117 were still valid at the time of validation.
- Large-scale data transfer in implementation: According to Noma ' s disclosure in September 2026[3], an enterprise employee directs the company ' s data collected by Coding Agent, packaged private source code and uploaded to external cloud storage, and the subsequent directive explicitly requires that authentication keys not be excluded. The whole event spanned two days and resulted in the transfer of dozens of GB data. The case was revealed by the manufacturer, the name of the client or the original log was not disclosed and the full picture of the incident could not be independently verified on the basis of publicly available material alone.
The risk of disclosure on the evidence does not flow solely from malicious acts. Even if the task itself is reasonable, Agent may inadvertently bring the evidence into subsequent interaction during the process of searching for the issue. It is envisaged that the developer will upload the new file interface with Qode and reuse the existing file storage service of the project. When connected, the storage service returns AccessDenied, Qoder reads contact/storage.local.json to check the connection parameters, where AccessKey appears with the file content and returns the result with the tool. If the follow-up model requests the results of this tool, the evidence will also enter the model context.
Risk may also extend to subsequent external requests. For further reasons, the developer requested that error summary be submitted to an external diagnostic service https://diagnostics.example.com/report (example address). Qoder then called a tool to launch HTTP POST requests to that address. If the request parameters include a newly read documented configuration in addition to the error summary, the documentation may be sent to the service upon request. Even if an enterprise permits the use of the service, the submission of a certificate of access to it may go beyond the permitted scope.
Figure 1: Potential transmission pathways based on model interactions with external requests.
These risks need to be judged against the sources of the evidence, the content of the request and the results of the execution, taking into account the data-use requirements of the enterprise and the Agent audit log. AccessKey alone did not prove successful; it also needed to look at the return of the audit log for tool call and verify the success of the request based on the actual response.
Similar document access, log analysis and tool search, and possible exposure to operational information, personal information and source code:
The following is an example of how to conduct audits, investigations and disposals from the evidence trail in the configuration and reduce the risk of continued transmission of evidence through local protection.
Retain execution evidence for sensitive data audits
The use of sensitive data in audit development assignments requires verification of the source, mode of use and destination of sensitive data. Qoder provides a Hook Extension mechanism that allows the self-defined logic to be run around user submissions, tool call, and provides the basis for access to audit log collections and security checks. However, if a construction audit is based directly on Hook, the enterprise will still have to develop and maintain its own log collection, formatting, conversational and call-up linkages, and processes such as desensitization and reporting.
AgentLoop undertakes these tasks through open source collection component LoongSite Pilot [4] (hereinafter Pilot). Pilot runs on a terminal or host where Qode is located, continuously collecting and collating user requests, tool parameters and returns to form the Agent Audit Log. These logs maintain sessions, call identification and order of execution, and relate to users, hosts and workspaces. Upon processing, log access to AgentLoop enabled investigators to return to the source, location and subsequent operation of the evidence along the same mission and to locate the members and environment involved. Enterprises can thus reduce their own efforts to build and maintain capture processing processes, focusing on risk investigation and disposal.
Agent audit logs may also contain sensitive elements such as supporting evidence. Pilot can replace life-sensitive values with type tags within the enterprise ' s geographical area, in accordance with the activated de-sensitization rule, and then report the processed audit log. The built-in de-sensitization rules cover evidence such as cloud accessKey, API Key, SSH private keys, and some personal information in a particular format. After processing, investigators can retain investigative trails while reducing the retention of sensitive original values in conjunction with the retained type tags, location, conversation and call relationship verification missions. The enterprise safety team could also verify the extent of collection, dissensitization rules and reporting processes for compliance with the enterprise ' s security requirements, in conjunction with Pilot ' s source code and deployment configuration.
Audit logs after reporting are stored in SLS under the client 's name and access is controlled through RAM permission. Enterprises can set up access and log retention cycles for auditors and manage the retention and use of data.
Figure 2: Collection, processing and reporting of the Qode Audit Log.
Use AgentLoop to track risks and advance fixes
AgentLoop continuously analyses the already collected Agent audit logs and detects risks through rules testing and modelling. The rules detect the matching of sensitive characteristics with behavioural conditions and identify known risks; the clues that need to be determined in conjunction with context are further assessed as to whether they pose a risk by reviewing back-to-back interview evidence, against mission requirements and operations. Upon meeting the conditions for determination, AgentLoop formed a risk event and retained the basis of the determination, the location of the evidence and the related conversation for investigation and review by the security team.
Figure 3: Rules testing and semantic interpretation process for AgentLoop.
Positioning and verification of risk from external sources
In the case of the above-mentioned diagnostic requests, if the request parameters sent to external diagnostic services included access documents, a risk trail would be created for “Alibaba Cloud certificates appearing in the context of an external intent”. The safety team can screen events in the risk browser by application, time, type of risk and severity and locate diagnostic requests that require investigation.
Figure 4: Location of external trails in risk browsers.
Investigators can enter contact sessions from risk events to check the tool call that initiated the request to the diagnostics.example.com, and then read the results against the configuration and interact with subsequent models to verify whether the evidence is from config/storage.local.json and to trace the process of entering the parameters of the diagnostic request.
Figure 5: Correlation and association sessions in outgoing requests.
On this basis, investigators are required to determine whether the evidence contained in the request is permitted to be submitted, taking into account the purposes of the diagnosis, the requirements of the mission and the data-use requirements of the enterprise, and to verify whether the request was sent successfully on the basis of the service response in the tool call record. In the case of confirmed outgoings, access records can also be linked to cloud accounts to verify access to sources and operations and to determine whether unauthorized use exists.
Identification of similar risks through entity surveys
The same evidence may be used by more than one mission, and the investigation of a single incident may extend to these related tasks. AgentLoop supports the evidence-based starting point for the entity survey: the Secret entity overview summarizes the evidence-based risk statements, while the entity relationship presents relevant members, hosts, applications, tools and outreach domain names and provides a clue for determining the verification scope.
Figure 6: Overview of risk-based interventions.
Figure 7: Evidence of association with entities such as members, hosts, tools, etc.
On the basis of the evidence found, the investigators can look back at the documents in the corresponding session for reading and outreach requests and check whether the diagnostic request contains the same evidence to determine whether or not there is a problem of the same kind in the relevant task.
Analysis of risk composition from user dimensions
The survey can also extend from evidence to relevant users to see the risk distribution in their development assignments. AgentLoop's user risk details summarize the user's associated risk conversation within the current query and provide information such as host, application, tool and outreach domain names. The security team can determine the sessions that require priority verification by combining the type, severity and time period of risk to see whether the exposure is repeated and whether risks such as unexpected code execution and document deletion are concentrated in a given mission or environment.
Figure 8: User risk formation, occurrence and associated entities.
Implementation of restructuring and ongoing review
With regard to the transmission of evidence identified in the survey, the R & D team may adjust the way in which access to permission and the content of the diagnosis is generated, so as to avoid the inclusion of the evidence in the external request; the responsible person, in conjunction with the exposure range and cloud account access records, evaluates the need for rotation of the certificate or adjustment of permission. If it is confirmed that many problems arise from shared configurations or diagnostic tools, the items involved should be amended simultaneously; different causes are dealt with separately.
The modified explicit data-use requirements could also be translated into audit conditions for subsequent missions. The built-in rules are used to identify generic risks such as out-of-pocket issuances; they can be supplemented by self-defined rules for enterprise-specific document scope and upload target limits. For example, when collating customer data or generating a report, an enterprise may request that the documents in the data/customer-export/ and data/finance/ directory be submitted only to approved files.corp.example. If Qoder calls the tool to upload files from these directories to unauthorized services such as convert.example.com, the rules can be found that the upload request does not meet the requirements of the enterprise, based on the file path and the target address in the upload parameters. Such testing does not depend on the full document contained in the log, nor is it premised on known evidence characteristics.
The auditors may describe the restricted catalogue, the approved services and the conditions of the determination in natural languages, generate rules by Agent ' s assistant and prepare positive and negative validations. For example, when the same document is uploaded to an unaccredited service, it should not be. The rules that are activated after validation and manual review, i.e. the audit log for the follow-up Qoder mission is checked on a sustainable basis, and the corresponding session and tool call are returned to the command.
Figure 9: Self-defined restricted documents upload audit rules.
This will be followed by a review of follow-up tasks, whether there is still evidence that the diagnostic request should not have been submitted, and whether the documentation is uploaded in accordance with business requirements. If problems arise again, return to the corresponding session and check where adjustments are needed to the configuration and tools.
Intercept transmission at Qode execution
Through the Agent audit log, the security team is able to identify risks, track the causes and advance improvements. However, when risks are identified, the operation may have been performed and the evidence may have entered the model context or been sent to external services. Thus, in addition to ex post facto investigations, enterprises are required to intervene in the performance of their tasks and to conduct inspections and intercepts prior to transmission of evidence.
The LoongSite-Pilot service, operated on the machine, was intercepted on the basis of evidence. Pilot identifies the documents by local rules and executes the block on the basis of the results of the inspection. The detection chain does not need to transfer the original content out of the machine, nor does it rely on model reasoning, saves network traffic and reasoning waiting for remote detection, and does not incur additional model call costs that are suitable for continuous use in day-to-day development.
Figure 10: Local evidence checks, client interdiction and audit reporting.
Local detection and interception of documented content
In a suitable Qoder client (including Qoder CLI), the enterprise can use local certificate protection to reduce the risk of entry of the model context on the basis of the proof or out-posting upon request. Pilot inspects the following three stages and is stopped by Qoder on the basis of the results:
- When submitted by the user: Check the user input. Qoder refused to submit if the submission contained evidence of the hit-off rule.
- Before tool call: Checks the tool parameters to be implemented. For example, when the request for diagnosis sent to diagnostics.example.com contained evidence of the hit-off rule, Qoder refused the call and prevented the request from being executed.
- When the tool returns: check the return content of the file for reading or script execution. For example, when accessKey, whose reading results contain a hit rule, is read in config/storage.local.json, Qoder replaces the whole tool with a stop alert before handing the results over to the model.
Figure 11: Qode Interception of return of documented tools.
Verify intercept effects in AgentLoop
Pilot reports local documented logs and related Agent audit logs to AgentLoop, where sensitive fieldes are processed in accordance with the activated desensitization rules. The security team can check processing decisions in the “interception record” and verify whether Qoder actually executed the rejection or replacement in conjunction with the session log and client feedback.
Figure 12: View interception records and associated sessions.
Currently, local protection primarily covers the documented transmission risk that is identifiable by the rule, including cloud accesskey in a specific format, partial API Key, private key and password-based database links. Pilot services are not available or use a release strategy when checking timeout, so that the effectiveness of protection is verified with regard to the normality of local services and the operation of the corresponding rules.
The successor plan supports self-defined interdiction rules based on audit risk findings. At that time, the security team may block the operation of the hit-off conditions for subsequent assignments, based on the risks identified in the audit investigation and the requirements for the security of the enterprise.
Unified deployment of audit and evidence protection through Qoder enterprise management
To allow audit collection and local warranty protection to reach more teams, Pilot needs to be deployed to the development terminals of the respective members. Through the Qoder enterprise exclusive market, an enterprise can distribute a Pilot installation plugin and reduce the individual installation and configuration of members with the initial configuration prepared by the plugin delivery manager.
Figure 13: Pilot installation plugins distributed through Qoder Enterprise's exclusive market.
Administrators may choose to send plugins to full or specified groups, and set up strategies such as client configuration, forced turn-in or silent start-up, according to enterprise management requirements, to determine deployment ranges and client enablers, respectively.
Figure 14: Set out the distribution range and enabler strategy for plugins.
When the plugin is sent out and enabled, the local state is checked at the start of the new session of the member, the Pilot is installed or updated as necessary, and the corresponding collection and certificate protection configuration is applied.
After access, the security team is able to check the audit logs of the respective members in the AgentLoop with the supporting logs, check the access of the development mission and check the local protection processing results in conjunction with the associated session. As Qoder is used in more teams, the enterprise can both unify its organizational deployment and continuously recheck sensitive data risks in the actual development mission.
Supported access is available through the audit access guide [5], as well as access to the AgentLoop demonstration environment [6], exposure to risk queries, session views and entity surveys.
Related links:
[1] Research
[2] Reporting
blog.gitguardian.com/the-state-o…
[3] Cases
[4] LoongSuite Pilot
[5] Audit access guidelines
[6] AgentLoop Demonstration Environment
Auto-fetched and translated by AI Atlas. All rights belong to the original author.