SEBI's AI cyber task force and CSCRF: a software supply chain guide

On 5 May 2026 the Securities and Exchange Board of India (SEBI) constituted a task force named cyber-suraksha.ai to examine the cyber risks posed by AI based models, and issued a ten-point advisory to every regulated entity in the securities market. The advisory asks for immediate patching, continuous vulnerability assessment, vendor patch commitments, API inventories and controls, faster Market SOC onboarding, AI scenarios in risk assessment, and updated asset inventories and Software Bills of Materials (SBOMs) for all critical applications, including the open source stack. It is to be read together with SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF).

For a broker, an asset management company, a depository, an exchange, a registrar and transfer agent or a KYC registration agency, none of this is a new category of work. CSCRF already requires SBOMs, VAPT, cyber audits, third party oversight and API security. What changed in May is the speed SEBI expects. Tools that can find vulnerabilities at machine speed shrink the time between a flaw being discoverable and a flaw being exploited, so a patch backlog that was tolerable in 2024 is a liability now.

This guide reads the circular and CSCRF closely, explains what each point means for your software supply chain, and ends with a 30/60/90-day plan. It is a practical reading of public documents, not legal advice. Your exchange, depository or SEBI itself is the authority on how a requirement applies to your entity.

What SEBI announced, exactly

The source is SEBI circular HO/13/19/12(1)2026-ITD-1_CIMGI/10873/2026, dated 5 May 2026, titled "Advisory on Emerging Advanced Artificial Intelligence (AI) Tools for Vulnerability Detection (like Mythos)" and issued under section 11(1) of the SEBI Act, 1992. The National Stock Exchange forwarded it to all trading members the next day as circular NSE/INSP/74077, asking members "to take note of the above and comply."

It is addressed to almost every class of regulated entity, from stock exchanges, clearing corporations and depositories to brokers, depository participants, mutual funds and AMCs, RTAs, KRAs, portfolio managers, custodians, credit rating agencies, investment advisers, research analysts, merchant bankers, debenture trustees, AIFs and VCFs.

The circular does four things.

It names the risk. "The rapid evolution of emerging technologies including AI-driven vulnerability identification tools (E.g. Claude Mythos) has introduced new dimensions of risks for Regulated Entities." Such tools may raise risk "by enabling identification and potential exploitation of existing vulnerabilities using speed and scale," and may raise concerns about data confidentiality, application integrity and the reliability of outputs.

It explains why the response must be shared. "Due to the interconnectedness and interdependency of market participants in the Securities Market Ecosystem, a periodic coordinated approach for vulnerability management, information sharing and monitoring/assessment is required to prevent a cascading impact."

It constitutes the task force. cyber-suraksha.ai, reachable at project-cyber-suraksha.ai@sebi.gov.in, comprises "representatives from MIIs, QRTAs, all QREs, and other related stakeholders." MIIs are market infrastructure institutions such as exchanges, clearing corporations and depositories. QRTAs are qualified registrars and transfer agents. QREs are Qualified REs, the highest CSCRF category below MIIs. The circular does not name a chair or individual members.

It issues the advisory. A meeting of the task force was convened with MIIs and QRTAs to review the risks posed by AI platforms like Mythos, and the advisory in Annexure A is based on that consultation. It "should be read in conjunction with the applicable SEBI circulars (including but not limited to Cybersecurity and Cyber Resilience framework)."

The task force's four-part mandate

1. Closely examine the cybersecurity risks posed by AI based models and devise a uniform mitigation strategy against them.
2. Facilitate sharing of threat intelligence, best practices on vulnerability management, use cases and playbooks.
3. Report on a priority basis cyber incidents, malicious activities, significant attack vectors and vulnerability information relevant to the securities markets.
4. Review the cyber security posture of third party application service providers, including empanelled vendors.

The fourth item matters most for software supply chains. It brings the vendors who build trading front ends, back office systems, RTA platforms and KYC systems into the task force's view, not only the regulated entities that buy from them.

Timeline

Why AI vulnerability discovery changes the clock

Anthropic announced Claude Mythos Preview on 7 April 2026 alongside Project Glasswing, which it describes as "an initiative to secure the world's most critical software for the AI era." The model is a gated research preview for Glasswing participants and selected partners. SEBI named it as an example of a class of tool, not as the only one.

SEBI's point is that the cost of finding a vulnerability is falling, for defenders and attackers alike. Three things follow.

The patch window shrinks. When validating an exploitable path took a skilled person days, a monthly patch cycle was defensible. Faster tooling shortens that gap, and a known vulnerability left on an internet facing system for a month becomes an invitation.

Old code gets re-read. Legacy applications nobody has reviewed in years, including vendor supplied COTS software, can now be analysed far faster. Bugs that survived because nobody looked will be found by whoever looks first.

The blast radius is shared. A depository participant's back office talks to a depository. A broker's order system talks to an exchange. An RTA platform serves many issuers. One compromised vendor can become everyone's incident.

That is why the advisory also asks entities to use AI on defence: vulnerability assessment using "conventional and suitable AI based Vulnerability Assessment Tools where possible," and "a long-term plan for usage of AI in detection and autonomous/agentic mitigation."

The ten-point advisory, read closely

Each point from Annexure A, with what it means in practice.

1. Patch now, virtual patch where you cannot. "Update all operating systems and applications with the latest patches on immediate basis." Where no patch exists, "virtual patching can be considered." Applications include the open source libraries compiled into them and the base images under your containers. Virtual patching usually means a WAF rule, an API gateway policy or a network control; give every one an expiry date, because auditors will ask when the real fix landed.

2. Continuous assessment, with AI where suitable. Conduct vulnerability assessment with conventional and suitable AI based tools "and undertake security audits on a regular/continuous basis in accordance with" CSCRF. Annual VAPT stays. Between cycles, scan dependencies (SCA), first party code (SAST) and running applications (DAST) on every change.

3. Vendors must patch. Entities must "engage with the respective RE's third party vendors to release timely patches." Exchanges and depositories "shall direct their empaneled application vendors (providing COTS solution to respective members) to undertake comprehensive assessment of the risks arising from the use of AI-led vulnerability detection models," and vendors "shall implement appropriate safeguards including updating patch, VAPT, continuous monitoring, hardening measures." If you are a vendor, expect requests for SBOMs, VAPT reports and patch timelines from every exchange and depository you are empanelled with.

4. Change management for every change. "Any change in the systems (including minor changes) should encompass full documentation, thorough impact analysis, structured review, rigorous testing and secure deployment." A dependency bump is a change. If your process only fits feature releases, it will slow the patching point 1 asks for. Build a documented fast path for security updates, with the pull request, test run and approval as the record.

5. API security. Keep an inventory of all APIs and the applications using them; enforce strong authentication and least privilege authorisation; apply rate limiting and throttling; and allow API connections "strictly on a whitelist-based approach." These mirror CSCRF standards PR.AA.S16 and PR.AA.S17, which also cite the OWASP API Security Top 10.

6. SOC monitoring and Market SOC. Monitor "vigorously," examine low priority alerts, and implement tested SOAR playbooks with your SIEM. The Market SOC run by NSE and BSE provides 24x7 monitoring, and "all eligible REs (not on boarded with any M-SOC) shall expedite the onboarding." Make sure logs from critical applications, including vendor ones, reach your SOC; CSCRF already requires it.

7. AI as a risk scenario. CSCRF mandates periodic risk assessment including third party providers, and "the capability of AI based models may also be considered as one of the risk scenarios." Add a scenario where an attacker uses an AI tool to exploit an internet facing application or vendor product faster than your patch cycle, then measure your real patch cycle.

8. Hardening and Zero Trust. Secure configurations, no unnecessary services or default accounts, least privilege and Zero Trust Network Access. Container base images are a common blind spot: unused libraries still carry vulnerabilities you have to explain.

9. Asset inventory and SBOMs. "Periodically update Asset Inventory and Software Bill of Materials for all critical applications including open source stack." This turns the SBOM from a procurement document into a live record, and it is the only way to answer "are we affected?" within hours of a new advisory.

10. IT committees and a long-term AI plan. Entities "shall seek guidance from their respective IT committees," and all entities "need to prepare a long-term plan for usage of AI in detection and autonomous/agentic mitigation," with "recalibration of risks for AI accelerated threats, AI augmented SOC transformation, and continuous vulnerability management using AI tools." The IT Committee for REs that CSCRF created now has a standing agenda item. The plan should say which AI tools you will use, who approves their actions, what data they can see, and how you will evidence their output.

How the advisory sits on top of CSCRF

CSCRF is a 205-page framework issued on 20 August 2024. It sorts regulated entities into five categories (MIIs, Qualified REs, Mid-size REs, Small-size REs and Self-certification REs) and scales requirements by category. It pairs governance and the Identify, Protect, Detect, Respond and Recover functions with five cyber resilience goals: Anticipate, Withstand, Contain, Recover and Evolve.

In June 2025 SEBI extended the compliance date to 31 August 2025 for all entities except MIIs, KYC registration agencies and QRTAs, which kept their earlier timeline. So by May 2026 CSCRF applied to everyone, and the advisory accelerates controls entities should already have. For an overview of the whole framework, see SEBI CSCRF in plain language.

SBOMs: standard GV.SC.S5

CSCRF is unusually specific about SBOMs. Under GV.SC.S5, mandatory for all REs:

• REs shall obtain SBOMs for existing critical systems within six months of CSCRF's issue.
• REs shall obtain SBOMs for any new critical system software product or SaaS application at procurement.
• MIIs shall include SBOM in their empanelment criteria for application software vendors.
• The SBOM shall include, but is not limited to: license information; supplier name; all primary components with their transitive dependencies, in-house or open source, and their relationships; encryption used; cryptographic hashes; frequency of updates; "known unknown" where the SBOM lacks a full dependency graph; access control; and methods for accommodating occasional incidental errors.

The governance guidelines add that SBOMs must be "kept updated with every upgrade or change." Where an SBOM cannot be obtained for a legacy or proprietary system, the Board, Partners or Proprietor must approve the exception "with proper limitation, rationale, and risk management approach." CSCRF cites Log4j and SolarWinds as the reason. More detail in the CSCRF SBOM requirement explained.

Application testing: PR.IP.S15 and PR.DS.S5

Under PR.IP.S15, mandatory for all REs, software for critical systems must pass DAST against sources such as the OWASP Top 10 and SANS Top 25 CWE; SAST for issues such as SQL injection, buffer overflows and XML external entity attacks; a functional audit; VAPT after every major release; integration of critical system logs with the SOC; and an audit of firewall, WAF and token configuration. PR.DS.S5, mandatory for MIIs and Qualified REs, requires OWASP and SANS Top 25 issues to be addressed during development and recommends DevSecOps.

Vendor code: PR.DS.S6

MIIs and Qualified REs shall obtain source code for critical applications from third party providers or, failing that, a source code escrow arrangement that includes updates and patches. For all software, vulnerabilities found later "shall be mitigated in a time bound manner," and entities "shall also stipulate timelines in their SLA with their third-party service providers." Where an entity does not own the source code, CSCRF asks for the provider's undertaking that the software is free of known vulnerabilities, malicious code and covert channels. That undertaking is only as good as the evidence behind it, which is where a current SBOM and vulnerability report earn their place.

VAPT and cyber audit clocks

Cyber audit covers all critical systems and a 25 percent sample of non-critical systems, by a CERT-In empanelled IS auditing organisation. Against the May advisory, three months to close an exploitable issue looks generous. Nothing stops an entity from closing faster, and "immediate basis" suggests SEBI expects it.

Incident reporting and other controls

Incidents under the CERT-In cybersecurity directions go to SEBI and CERT-In within six hours of detection, with details on SEBI's portal within 24 hours; brokers and depository participants also report to exchanges or depositories within six hours. Other incidents go to SEBI, CERT-In and NCIIPC as applicable within 24 hours. See the six hour and 24 hour CSCRF reporting windows.

MIIs and Qualified REs also carry ISO 27001 certification, red teaming every half year, quarterly threat hunting, the Cyber Capability Index (third party assessed half-yearly for MIIs, self-assessed yearly for Qualified REs), and dashboards for CSCRF compliance.

The AI and ML rules next to the advisory

The advisory is about AI used against you. SEBI has an older line of rules about AI you use, and the two now overlap.

Reporting AI/ML systems. A SEBI circular of 4 January 2019 (SEBI/HO/MIRSD/DOS2/CIR/P/2019/10) requires intermediaries to report the AI and ML systems they offer and use. NSE circular 85/2026 of 1 October 2026 asked every active trading member that used algorithm software between April and September 2026 to report AI/ML systems, or a NIL return, by 15 October 2026.

Sole responsibility. In February 2025 SEBI amended the Intermediaries Regulations and the stock exchange and clearing corporation regulations. Stock exchanges, clearing corporations and intermediaries that use AI and ML tools are "solely responsible" for the privacy, security and integrity of investors' and stakeholders' data, for "the output resulting from the usage of such tools and techniques," and for compliance with applicable law.

A framework in progress. SEBI's 20 June 2025 consultation paper, "Guidelines for Responsible Usage of AI/ML in Indian Securities Markets," proposed principles on governance, testing before deployment, fairness, data and cyber security and disclosure, with a lighter touch for uses that do not directly affect customers. In August 2026, chairman Tuhin Kanta Pandey told FICCI's capital markets conference that a tiered framework was coming, reported to cover accountability, data controls, human oversight and a way to stop AI systems. At the time of writing we could not find a final circular.

So an entity now has to answer two questions with evidence. Can AI tools in an attacker's hands find what is wrong with our software before we fix it? And are our own AI tools, including coding assistants and security agents, governed well enough that we can stand behind their output?

What it means for each type of entity

Stock brokers. CSCRF compliance goes to the exchanges, and so will questions about the advisory. The largest software risks are usually vendor front and back office products you cannot patch yourself, the APIs behind mobile apps and partner integrations, and the AI/ML systems you already report.

Mutual funds and AMCs. The existing technology committee is now the IT Committee for REs and will likely own the point 10 AI plan. Investor servicing and distributor platforms depend on RTAs and vendors, so vendor SBOMs and patch SLAs are the practical lever.

Depositories and depository participants. Depositories are MIIs and must direct empanelled vendors to assess AI-led vulnerability risks. DPs should expect patching and SBOM evidence requests from their depository.

Exchanges and clearing corporations. MIIs carry the heaviest load: third party CCI assessments, ISO 27001, red teaming, threat hunting and security for APIs exposed to members. They run Market SOC, and they are the channel through which point 3 reaches vendors.

RTAs and QRTAs. QRTAs sit on the task force and were consulted before the advisory. RTA platforms serve many issuers at once, the concentration risk CSCRF asks entities to assess. Start with SBOMs for the platform and fast patching of internet facing services.

KYC registration agencies. KRAs hold identity data for the whole market, so the API controls in point 5 apply directly to the interfaces intermediaries use to query and update KYC records.

Software vendors to the market. Point 3 and the task force's fourth mandate make you part of the answer. Expect SBOM requests in CycloneDX or SPDX, VAPT evidence after major releases, patch timelines in SLAs and escrow requests. A vendor who can hand over a current SBOM and vulnerability report on request has an easier empanelment conversation.

The software supply chain, in detail

SBOMs that would survive an audit

An SBOM sitting in a procurement folder does not meet point 9. The useful version is generated from the build, stored with the release, updated with every change, and queried when an advisory lands. CycloneDX and SPDX can both carry the CSCRF fields. A trimmed CycloneDX example:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-11-10T09:00:00Z",
    "supplier": { "name": "Example Back Office Vendor Pvt Ltd" },
    "component": { "bom-ref": "backoffice-api", "type": "application", "name": "backoffice-api", "version": "4.12.0" }
  },
  "components": [
    {
      "bom-ref": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2",
      "type": "library",
      "name": "jackson-databind",
      "version": "2.17.2",
      "supplier": { "name": "FasterXML" },
      "licenses": [ { "license": { "id": "Apache-2.0" } } ],
      "hashes": [ { "alg": "SHA-256", "content": "<sha256 of the jar>" } ],
      "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2"
    }
  ],
  "dependencies": [
    { "ref": "backoffice-api", "dependsOn": [ "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" ] }
  ],
  "compositions": [
    { "aggregate": "incomplete_first_party_only", "assemblies": [ "backoffice-api" ] }
  ]
}

The supplier block covers the supplier name, licenses cover license information, hashes cover cryptographic hashes, and the dependencies graph covers components with their transitive relationships. The compositions block is how CycloneDX states completeness, which is the cleanest way to express CSCRF's "known unknown." Encryption used, access control and update frequency are less standardised; record them as properties or in a companion document, and agree the convention with your auditor once.

Then make it operational:

• Generate SBOMs in CI from the build output, not from a manifest alone, so the transitive dependencies that ship are the ones listed.
• Store each SBOM with its release and keep old ones. An auditor may ask what you ran on a given date.
• Ask vendors for an SBOM at every release, not once at procurement.
• Load your SBOMs and your vendors' into one searchable place. The test of the programme is how long "where do we run version X of library Y?" takes to answer.
• Write Board-approved exceptions for legacy systems now, with compensating controls.

Third party and vendor software risk

CSCRF makes the entity "solely accountable for all aspects related to third-party services." A practical vendor programme has five parts:

1. A tiered vendor list. Which vendors supply software for critical systems, which are empanelled by an exchange or depository, and which serve many participants?
2. Contract terms. Patch timelines by severity, SBOM delivery with every release, VAPT evidence after major releases, vulnerability notification windows, and source code or escrow where you are an MII or Qualified RE.
3. Evidence on a schedule. CSCRF asks MIIs and Qualified REs to review third party managed systems half-yearly and other REs annually. Collect the SBOM, latest vulnerability report and patch history each time.
4. Your own check. Run the vendor's SBOM against current vulnerability data yourself. Their report reflects the day it was produced; your scan reflects today.
5. A plan for slow vendors. Virtual patching, network isolation, and escalation through the exchange or depository that empanelled them.

AI model and agent risk

For AI used against you, the controls are the rest of this guide: faster patching, better inventory, tighter APIs, continuous testing.

For AI used by you, start with an inventory: customer facing chatbots, research tools, developer code assistants, AI features inside vendor products and security agents. For each, record what data it can read (including investor data, for which you are solely responsible), what it can do beyond suggesting (run commands, call APIs, open pull requests, change configuration), who approves its actions and where that is recorded, where the model runs, and which model and version produced each output.

Treat AI components like code components. Agent tools, MCP servers and skills give an assistant new powers and deserve the same review as any third party integration. Some model file formats can execute code when loaded, so model files need scanning too.

Point 10's "autonomous/agentic mitigation" plan should include a human approval step. An agent that opens a pull request for review is a very different risk from one that changes production directly, and SEBI's reported direction on human oversight points the same way.

API security that maps to point 5

Inventory. Combine gateway configuration, OpenAPI specs in repositories, load balancer and WAF logs, mobile app traffic and vendor documentation, because each misses something. Record owner, consumers, data returned, authentication method and exposure.

Authentication and authorisation. Strong client authentication, short-lived tokens, and authorisation checks on every object. Broken object level authorisation tops the OWASP API Security Top 10 because it is easy to miss.

Rate limiting. Limit per client and per endpoint, alert on breaches, and test that limits hold:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=20r/s;

server {
  location /api/ {
    limit_req zone=api_per_ip burst=40 nodelay;
    limit_req_status 429;
    proxy_pass http://backoffice_api;
  }
}

Per-IP limits are a floor. For authenticated partner APIs, limit per client credential too.

Whitelisting. Known client identities and, where practical, known source networks, with mutual TLS for system to system connections, reviewed at every access review. Then test: unauthenticated calls should fail, one client should not read another's objects, and rate limits should trigger.

Vulnerability management timelines

CSCRF sets the outer limit of three months; the advisory pushes known, exploitable issues to "immediate." A workable internal policy sits between them. One example, to adjust to your risk appetite and have your IT Committee approve:

Two inputs make this workable: prioritisation beyond CVSS, using exploitation evidence (KEV), exploit likelihood (EPSS) and whether your code calls the vulnerable path (reachability); and a fix path that does not depend on someone writing every upgrade by hand. Start the clock when the vulnerability is published, not when a ticket was opened.

Audits and evidence

Build evidence as a by-product of the work. For the software supply chain keep SBOMs per release, yours and your vendors'; vulnerability scan history per application; the change record for each fix (pull request, test run, approval, deployment); exceptions with IT Committee approval and expiry dates; VAPT reports, closure and revalidation evidence; vendor evidence from each review; your AI inventory and agent approvals; and a mapping from each artifact to the CSCRF standard it supports. A single view of open vulnerabilities by application, age and owner shortens every audit.

A 30/60/90-day plan

This assumes CSCRF is broadly in place and the goal is the May advisory's pace. Adjust for your category.

Days 1 to 30: see everything

• Brief the IT Committee for REs and name an owner for each of the ten points.
• Patch known critical and high vulnerabilities on internet facing systems; virtual patch the rest with expiry dates.
• List critical applications with owners, including vendor applications.
• Generate SBOMs for your own critical applications in CI and request current SBOMs from every critical system vendor.
• Start the API inventory and the AI inventory.
• Start Market SOC onboarding if you are eligible and not on it, and confirm critical system logs reach your SOC.
• Check the incident runbook against the six hour and 24 hour windows.

Days 31 to 60: close the loops

• Run SCA, SAST and DAST continuously on critical applications.
• Load all SBOMs, including vendors', into one inventory and check them against current vulnerability data.
• Adopt a written vulnerability timeline policy with KEV and reachability inputs, approved by the IT Committee.
• Add a documented fast change path for security updates that still meets point 4.
• Apply rate limits, least privilege and whitelists to internet facing and partner APIs first.
• Send vendors written requests for patch timelines, SBOM delivery and notification terms, and add them to contracts at renewal.
• Add an AI-driven attack scenario to your risk assessment and harden container base images.

Days 61 to 90: prove it and plan ahead

• Run a tabletop: a vulnerability is published in a library you use. Measure time to "are we affected?", to fix and to deploy.
• Test APIs for broken object level authorisation and rate limit bypass.
• Escalate any vendor without an SBOM or patch plan.
• Write the point 10 AI plan, with human approval for agent actions, and take it to the IT Committee.
• Map evidence to CSCRF standards and build the open vulnerabilities view.
• Diarise a review for further SEBI and task force guidance, including the final AI/ML framework.

Choosing tools: an honest map

No single tool covers all of CSCRF. Examples from vendors' own product pages:

Application security testing. Snyk lists Snyk Open Source (SCA), Snyk Code (SAST), Snyk Container, Snyk IaC and Snyk API & Web (DAST), plus AI security products under its Evo brand. Checkmarx One covers SAST, SCA, container and IaC security, API security and AI supply chain features. Black Duck offers Black Duck SCA, Coverity for SAST, Continuous Dynamic for DAST and the Polaris platform that combines them. An entity whose incumbent tool already meets PR.IP.S15 may reasonably keep it.

Compliance automation. Vanta and Drata focus on evidence collection and control tracking. They fit when the gap is evidence management rather than the technical controls.

Where gaps usually are. The advisory is about speed from "a vulnerability exists" to "the fix is running." Scanners report; someone still writes, tests and ships the upgrade. Vendor software is the other gap, because you must analyse SBOMs you did not produce. Ask every tool to show the whole path for one vulnerability, from detection to a merged fix and an audit record.

Where Safeguard fits

Safeguard covers three areas: security, compliance, and coding agents with your choice of model.

Security

• SCA and SBOMs. Full transitive dependency inventory, SBOM generation in SPDX and CycloneDX, and analysis of SBOMs you receive from vendors, which helps you meet point 9 and gives you one place to ask "where do we run this version?"
• SAST and DAST. First party static analysis and dynamic testing of targets you have verified, on every change in CI, giving you evidence for application testing requirements such as PR.IP.S15.
• AI penetration testing. AI-driven testing of applications you own.
• Prioritisation. Vulnerability matching enriched with EPSS and CISA KEV, plus reachability analysis that ranks the code paths your application actually calls.
• Fix pull requests. Griffin, Safeguard's security model, opens policy gated pull requests to safe versions, and your own CI runs your tests before anyone merges. That gives you the change record point 4 asks for. Autonomous remediation ships off by default, and auto-merge is a separate switch.
• Policies and gates. CI rules stop builds that carry vulnerable or unapproved components.
• Third party risk. The Third-Party Risk Manager onboards vendors, requests SBOMs from them, and scores and monitors supplier risk, supporting periodic third party reviews.
• AI security. Model scanning for LLMs, SLMs, skills and agents; AI-BOM discovery; an AI gateway with guardrails for prompt injection, jailbreaks and PII egress; MCP Guardrail; and agent identity, which tracks which agent holds what access.

Compliance

The compliance suite covers frameworks, controls, evidence, monitoring, tests, questionnaires, risks and vendors. Map controls to your framework and attach the technical evidence the platform already produces, such as SBOMs, vulnerability history and the pull requests that closed them. Lion, Safeguard's compliance model, maps evidence and writes audit-ready summaries. Safeguard itself is SOC 2 Type I and Type II audited.

Coding agents with model choice

The Safeguard CLI and desktop app include a coding assistant that edits files and runs commands in your repository, asking before any command that changes something. You choose the model: Safeguard's own security models, your own approved model from providers such as Anthropic, OpenAI, Cohere or Mistral, or models run inside your environment. A Zero AI mode runs the platform with no LLM at all. That lets your AI tooling follow the data rules in your point 10 plan.

Safeguard runs as SaaS in US or EU regions, in your own cloud or VPC, or on-premises. With the local runner CLI, scans run on your own machine and only encrypted results are sent.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See it in action

Each demo shows a real Safeguard flow; the text before it explains how it applies here.

The first is a CLI session that fixes a lodash CVE. It reads the advisory, asks before any command that changes something, edits package.json, runs the install and tests with your approval, and pushes nothing. For a broker or AMC engineering team, that is how an item in the patch queue becomes a reviewed change with a test run attached, the record point 4 asks for.

Click through it at your own pace, or open it full screen.

The second sets up the local runner on your own machine, approves it with a device code and scans from the terminal. That is how a team would scan a critical application's repository or image and build the dependency inventory behind an SBOM, with the scan running on its own machine.

Click through it at your own pace, or open it full screen.

FAQ

What is SEBI's cyber-suraksha.ai task force?

A task force SEBI constituted by circular dated 5 May 2026 to examine the cybersecurity risks posed by AI based models. It includes representatives from market infrastructure institutions, qualified registrars and transfer agents, all qualified regulated entities and other stakeholders. It is to devise a uniform mitigation strategy, share threat intelligence and vulnerability management practices, report significant incidents and vulnerabilities on a priority basis, and review the security posture of third party application service providers, including empanelled vendors.

Who must follow the 5 May 2026 advisory?

Nearly every class of SEBI regulated entity, including exchanges, clearing corporations, depositories, depository participants, brokers, mutual funds and AMCs, RTAs and KRAs. It is to be read with CSCRF.

Does CSCRF require SBOMs?

Yes. Standard GV.SC.S5 requires SBOMs for existing critical systems within six months of CSCRF's issue and for new critical system software and SaaS at procurement, with license, supplier, transitive dependency, hash and "known unknown" fields among others. The May 2026 advisory asks for SBOMs of all critical applications, including the open source stack, to be updated periodically.

How fast must VAPT observations be closed?

CSCRF allows three months from the VAPT report, graded by criticality, with revalidation within five months of completing VAPT. The advisory asks for known vulnerabilities to be patched on an immediate basis, so many entities set much shorter internal targets for exploitable issues.

Has SEBI issued final AI/ML guidelines?

SEBI published a consultation paper on 20 June 2025, and in August 2026 its chairman signalled a forthcoming tiered framework. At the time of writing we could not find a final circular. Exchanges, clearing corporations and intermediaries are already solely responsible for the data handling and outputs of the AI tools they use, under February 2025 amendments.

Can Safeguard map controls to CSCRF?

Safeguard's compliance suite lets you map controls to your framework and attach technical evidence such as SBOMs, vulnerability history and fix pull requests. Ask us to walk through how your CSCRF control set would be represented.

Sources

• SEBI circular HO/13/19/12(1)2026-ITD-1_CIMGI/10873/2026, 5 May 2026, as enclosed in NSE circular NSE/INSP/74077
• SEBI CSCRF circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024
• CSCRF full text (PDF)
• All India Radio News, 6 May 2026
• ThePrint, 6 May 2026
• Business Today explainer on the task force, 6 May 2026
• Business Today on the CSCRF deadline extension, 30 June 2025
• NSE circular 85/2026 on AI/ML reporting, 1 October 2026
• AZB & Partners on SEBI's AI and ML tool provisions
• Mondaq on SEBI's AI/ML consultation paper
• Lakshmikumaran & Sridharan on the consultation paper
• The Policy Edge on SEBI's tiered AI rules, August 2026
• Anthropic: Project Glasswing
• OWASP API Security Top 10
• CycloneDX specification
• CISA KEV catalog
• FIRST EPSS
• Snyk products
• Checkmarx One
• Black Duck
• Vanta
• Drata

Last reviewed: 10 November 2026. Check sebi.gov.in and your exchange or depository for later circulars and clarifications.