Summary Cursor introduces powerful agentic coding capabilities, but also expands the attack surface by allowing AI to read, modify, and execute code. Its native controls reduce risk but are not sufficient on their own. Organizations must apply additional guardrails, validation, and governance to securely use Cursor in development workflows. What Is Cursor AI Security? Cursor AI security refers to the security considerations involved in using the Cursor platform and its AI agents within software development workflows. It is not a single control or feature; rather, it is a layered concept that includes the platform’s built-in security posture, the new risks introduced by agent-driven coding, and the safeguards organizations must apply to use it safely. At the platform level, Cursor security includes how the tool handles data, authentication, code access, and integrations. This covers how source code is transmitted and stored, how models process prompts and context, and how access to repositories or local environments is controlled. It also includes trust boundaries between the IDE, remote services, and any third-party APIs used by the agent. Agentic coding workflows introduce new risks that do not exist in traditional development. Cursor agents can read large portions of a codebase, generate code, modify files, and execute commands. This creates risks such as unintended data exposure, insecure code generation, prompt injection, dependency misuse, and over-permissioned actions. The speed and autonomy of agents can amplify small mistakes into larger issues if not constrained. Additional, explicit controls are needed to use Cursor safely. These include limiting agent access to sensitive files, enforcing least-privilege permissions, validating generated code, and monitoring agent activity. Controls such as integrated automated testing, audit logging, policy enforcement, network restrictions, and human approval checkpoints help reduce risk. Security also depends on developer awareness, since misuse or overreliance on agents can bypass existing safeguards. In practice, Cursor AI security is about managing the interaction between AI agents and the development environment. It requires treating the agent as an active participant in the system, with defined permissions, observable behavior, and enforced boundaries. This is part of a series of articles about AI in software development How Cursor Works To understand Cursor security, it’s important to understand the platform’s architecture, its common usage within organizations, and how each of these expands the traditional attack surface. Cursor Agentic Coding Workflows Cursor’s Agent is an AI coding assistant designed to complete complex development tasks inside the editor. It works by combining three core components: Instructions include the system prompt and any Cursor rules that guide behavior. Tools let the agent search the codebase, read files, edit files, run shell commands, use the browser, and fetch context. The selected AI model decides how to plan and execute the task, while Cursor orchestrates the available tools for that model. Cursor’s documentation states that a Cursor Agent can independently complete coding tasks, run terminal commands, and edit code, and that there is no fixed limit on the number of tool calls it can make during a task. In practice, this means a developer can describe a goal, such as implementing a feature, fixing a bug, refactoring code, or adding tests, and Cursor can iteratively inspect the repository, identify relevant files, apply changes, run checks, and continue until it reaches a result. Cursor also creates checkpoints during Agent sessions before significant changes, allowing users to restore earlier code states if the agent takes the work in the wrong direction. How this capability changes the attack surfaceAgentic coding changes Cursor from a passive code-assistance tool into an active participant in the development environment. The agent is not only suggesting code; it can read project context, modify files, invoke tools, and chain many actions together. This expands the attack surface from “what code does the developer copy and paste?” to “what actions can the agent take with the context, tools, and permissions available to it?” Risks include prompt injection through repository content, malicious instructions embedded in documentation or comments, unintended edits across multiple files, insecure generated code, and over-trust in agent output. Because the agent can operate quickly and repeatedly, small mistakes can propagate into many files before human review. File, Shell, and Tool Access Cursor Agents use first-party tools to interact with the development workspace. These tools include reading files, editing files, running terminal commands, searching the web, and searching code. Reading files and searching code do not require approval by default, while actions that could expose sensitive data require explicit approval. Agents can modify workspace files without approval, except for configuration files, and changes are saved immediately to disk. Cursor recommends using version control so changes can be reverted. Shell access is more sensitive. In Cursor, terminal commands require approval by default and should be reviewed before execution. However, users can enable auto-approval. The documentation recommends not to use “Run Everything” mode because it skips safety checks. Cursor also supports external tools through MCP. MCP lets Cursor connect to external tools and data sources such as databases, APIs, third-party services, local command-line servers, and remote HTTP/SSE servers. Cursor supports MCP tools, prompts, resources, roots, elicitation, and interactive app responses. MCP tools require approval by default, and Cursor recommends verifying the source of MCP servers, reviewing what data and APIs they can access, limiting API keys, and auditing critical integrations. Cursor provides terminal and MCP allowlists, but according to its own documentation, these allowlists are enforced on a “best-effort”; they are not a security guarantee, and bypasses are possible. How this capability changes the attack surfaceFile, shell, and tool access create the most direct security impact because they connect AI reasoning to real execution: File access can expose secrets, credentials, proprietary code, customer data, or internal architecture if sensitive files are not excluded. File editing can introduce vulnerabilities, weaken controls, or alter configuration in ways that are hard to detect without review. Shell access can execute destructive commands, install dependencies, exfiltrate data, alter local state, or interact with cloud and production tooling if credentials are present in the environment. MCP extends this further by connecting the agent to external systems such as databases, APIs, SaaS tools, and internal services. The attack surface therefore includes not only the local repository, but every tool, token, API, and network path reachable through Cursor. Cloud Agents and Connected Services Cursor Cloud Agents run the same agentic coding workflow in isolated cloud environments instead of on the developer’s local machine. Cloud Agents can run in parallel, do not require the local machine to stay connected to the internet, and have access to their own virtual machine where they can build, test, and interact with changed software. They can control a desktop and browser, and can use MCP servers to access external tools and data sources. Cloud Agents are connected to source control; they clone repositories from GitHub or GitLab, work on a separate branch, and push changes back to the repository for handoff. Users need read-write privileges to the repository and to dependent repositories or submodules. Cloud Agents can be started from Cursor Web, Cursor Desktop, Slack, GitHub, Linear, and the API. Like regular Agents, Cloud Agents also support team-configured MCP servers, OAuth where needed, and project hooks. Project hooks from .cursor/hooks.json run in Cloud Agents, and Enterprise plans can also run team and enterprise-managed hooks. This allows formatters, audit scripts, and policy checks to remain active when work runs in the cloud. Cursor documentation recommends that Cloud Agent secrets be managed through the Secrets tab, and warns that if .env.local files are included during snapshot creation, they will be saved, possibly exposing secrets. How this capability changes the attack surfaceCloud Agents move agent execution from a developer-controlled workstation into remote execution environments connected to source control, collaboration tools, secrets, and external services. This changes the attack surface in several ways: Repository access becomes a cloud-side permission problem: the agent can clone code, create branches, and push changes using the privileges granted to the connected account. Secrets and environment configuration become critical because cloud tasks may need tokens, package registry credentials, API keys, or service credentials to build and test software. If secrets are over-scoped, copied into snapshots, or exposed through logs, the blast radius increases. Integrations such as Slack, GitHub, Linear, APIs, and MCP servers introduce additional trigger points and trust boundaries; a task can be initiated outside the IDE and may run without the developer’s local context. Parallel cloud agents can amplify mistakes or exploits by producing multiple branches or pull requests at once. Development teams should treat Cloud Agents like remote build workers or junior service accounts. They should isolate environments, minimize repository and secret permissions, require branch protection and code review, run CI/security checks on every PR, and restrict which integrations can start agents. Related content: Read our guide to AI developer tools What Cursor Protects and What It Doesn’t Cursor includes native controls that help reduce risk, but those controls should be understood as safeguards, not full security boundaries. For enterprise teams, the key question is not whether Cursor has security features – it does – but where those features end and where organizational controls still need to take over. Native Security Guardrails Cursor provides native guardrails for agentic coding, but they should be treated as risk-reduction controls rather than complete security enforcement: Terminal commands and actions that could expose sensitive data require approval by default, while reading files and searching code do not. Agents can edit workspace files without approval, except for configuration files. Cursor recommends using .cursorignore to restrict sensitive files and version control to revert agent changes. Cursor gives teams controls for command execution, MCP tools, and enterprise administration. Terminal auto-approval can be enabled; Cursor documentation warns users to do this at their own risk. Cursor documentation states that terminal and MCP allowlists are “best-effort,” and advises against “Run Everything” mode because it bypasses safety checks. For enterprise deployments, Cursor documents controls such as SSO, SCIM, RBAC, MDM policies, audit logs, network controls, model and integration management, hooks, terminal sandboxing, and agent guardrails. Vendor Trust, Security Posture, and Privacy Cursor provides vendor-assurance measures such as SOC 2 Type II report availability, annual third-party penetration testing, vulnerability disclosure, MFA enforcement, least-privilege infrastructure access, vendor risk management, security monitoring, privacy documentation, and compliance logging. While this supports enterprise requirements, it does not mean that agent-generated code or agent-executed workflows are automatically safe. Cursor’s data-handling posture depends heavily on Privacy Mode and organizational configuration. According to Cursor documentation: When Privacy Mode is enabled, it uses technical controls and contractual zero-data-retention terms with model providers so code is not stored by providers or used for training. However, Cursor may still store some code data to provide its features. If Privacy Mode is off, Cursor may use and store codebase data, prompts, editor actions, code snippets, and related actions to improve AI features and train models. Cursor also states that codebase indexing uploads small chunks of code to compute embeddings, while embeddings and metadata such as hashes and file names may be retained. Where Responsibility Still Falls on Users and Organizations Cursor’s controls do not eliminate the need for organizational governance. Cursor itself warns that AI can behave unexpectedly because of prompt injection, hallucinations, and similar issues, so organizations remain responsible for deciding which repositories, files, commands, MCP servers, APIs, and credentials the agent can access. Teams should define clear policies for agent permissions, approval requirements, sensitive-file exclusions, and acceptable use. Organizations must treat generated changes as untrusted code until reviewed and tested. Because Cursor agents can edit files immediately, and some changes may execute before review if auto-reload is enabled, teams should put in place all possible security and engineering controls, including: Git rollback Protected branches Pull request review CI tests Static application security testing (SAST) Dependency scanning Secret scanning License checks Production change controls Cursor should be governed like a powerful developer workstation used by an external or untrusted operator. It should be protected by least-privilege access, monitoring, code review, and developer security awareness. Top 6 Cursor AI Security Risks In light of the above, here are the primary security risks facing organizations and individuals using Cursor. 1. Prompt Injection Attacks Prompt injection attacks can manipulate Cursor through comments, documentation, repository content, or external context that the agent treats as relevant instructions. Because Cursor works inside the development environment and may act on large amounts of contextual data, malicious or misleading instructions can influence code generation, configuration changes, or command execution in ways that are hard to spot during normal development. 2. Remote Code Execution (RCE) Cursor’s ability to run shell commands and automate development workflows creates a direct path to remote code execution. If the AI generates or executes a malicious command, it can run with the same permissions as the developer’s environment. This allows attackers to execute arbitrary scripts, modify system files, or install persistent backdoors. RCE risks are especially pronounced when combined with automation features. For example, an AI-generated command that appears harmless may include hidden side effects such as downloading and executing external scripts. Once executed, these scripts can exfiltrate data, alter dependencies, or establish ongoing access to the system, often without immediate detection. 3. Malicious Dependencies and Supply Chain Attacks Cursor can install dependencies as part of its AI-assisted workflows, often pulling packages directly from public registries. If a malicious package is introduced, it may contain obfuscated install scripts that execute automatically. These scripts can perform actions such as stealing environment variables, modifying files, or opening network connections to attacker-controlled servers. Supply chain attacks are particularly dangerous because they exploit trusted workflows. Developers may not review every installed package in detail, especially when automation is involved. This allows malicious dependencies to blend in with legitimate ones, increasing the likelihood of compromise across multiple projects or environments. 4. Credential and Token Leakage AI-generated responses may unintentionally include sensitive information such as API keys, access tokens, or internal credentials. This can happen when the model references environment variables, configuration files, or previously seen context. Once exposed, these secrets may be stored in logs, committed to version control, or shared across teams. Leaked credentials can provide attackers with direct access to systems, bypassing traditional security controls. In some cases, a single exposed token is enough to access cloud infrastructure, databases, or third-party services. Because these leaks often occur silently within normal development workflows, they can remain undetected until they are actively exploited. 5. Agent Abuse and Auto-Execution Risks Cursor’s agent system can execute actions automatically, especially when auto-run mode is enabled. This removes the need for manual approval and allows commands to run immediately. While this improves speed, it also eliminates an important checkpoint where developers could catch unsafe or unexpected behavior. Additional risks come from how agents are configured and identified. Compromised rules files can include hidden instructions that trigger malicious actions whenever certain conditions are met. Similarly, if an attacker can spoof or hijack an agent, they can impersonate a trusted component and execute unauthorized commands. These issues make it possible for harmful actions to persist and operate within the environment without clear visibility. 6. Sensitive Data Exposure Through Prompts and Context Cursor agents rely on prompts and retrieved context to decide what actions to take. This context often includes source code, configuration files, logs, and environment variables. If sensitive data is present in any of these inputs, it can be surfaced in model outputs, cached in session history, or transmitted to external model providers depending on configuration. The risk is not limited to explicit secrets. Internal APIs, database schemas, private endpoints, and business logic can also be exposed when large portions of a repository are included in context. Because the agent selects context automatically, developers may not be aware that sensitive files or snippets are being sent to the model. Context aggregation increases the blast radius. A single prompt can pull in data from multiple files, combine it, and generate outputs that unintentionally reveal relationships between systems. This can expose architectural details that are not visible in any single file but become clear when combined. Limitations of Cursor’s Native Security Controls Cursor’s native controls are useful, but they should be treated as a baseline rather than a complete security model. They reduce risk around some actions and workflows, but they do not independently validate generated code, enforce SDLC policy, govern dependency trust, or prevent all forms of prompt/context manipulation. We have extensively reviewed Cursor’s security controls. It is clear that these controls should be treated as a baseline rather than a complete security model. Agentic coding introduces risks across code quality, dependency changes, data exposure, tool execution, and governance: Native controls do not create a full security boundary. Cursor provides approvals, .cursorignore, MCP controls, enterprise settings, and audit capabilities, but some actions remain broad by design. Agents can read and search code without approval by default, and they can modify many workspace files immediately. These controls help manage risk, but they do not guarantee safe agent behavior. Generated code is not automatically secure. Cursor can create or modify code quickly, but it does not prove that the output is correct, secure, or compliant with internal standards. AI-generated code may introduce insecure validation, weak authorization checks, unsafe error handling, flawed business logic, or vulnerable patterns. Generated changes still need code review, testing, SAST, and secure design review. Dependency risks are not fully covered. Cursor may suggest, add, or update packages, but built-in controls do not determine whether a dependency is malicious, vulnerable, typosquatted, abandoned, or license-incompatible. Organizations need dependency scanning, lockfile review, approved package policies, SBOMs, and controls over package registries and install scripts. Prompt injection remains a structural risk. Repository files, comments, documentation, web pages, issue content, and MCP outputs may contain malicious or misleading instructions. Cursor approvals can reduce the impact of some actions, but they cannot reliably distinguish trusted instructions from injected ones in every context. High-risk actions should require human review and least-privilege access. Sensitive data can still enter prompts or context. Privacy Mode and data controls help, but they do not replace data classification or file-level governance. Source code, secrets, internal APIs, logs, customer data, database schemas, and proprietary logic may be exposed if they are available in the agent’s context. Teams need clear rules for restricted repositories, excluded files, and sensitive data handling. Shell and tool access can expand the blast radius. Terminal commands, MCP tools, browser access, APIs, databases, and cloud credentials can turn AI suggestions into real execution. Approval prompts are helpful, but unsafe commands, over-scoped tokens, or trusted integrations can still cause damage. Organizations should restrict tool access, keep approvals enabled, avoid broad auto-run settings, and use least-privilege credentials. Cloud Agents introduce remote execution risks. Cloud Agents operate in remote environments connected to repositories, branches, secrets, integrations, and external services. Built-in isolation helps, but organizations still need branch protection, CI enforcement, secret scoping, integration controls, logging, and review of cloud-generated pull requests. Enterprise controls still require governance. SSO, SCIM, RBAC, audit logs, MDM, model controls, and admin settings are valuable only if they are configured according to policy. Organizations must define who can use Cursor, which repositories are allowed, which models and MCP servers are approved, what actions require approval, and how exceptions are handled. Rollback is not the same as prevention. Cursor checkpoints and Git can help undo unwanted changes, but they do not prevent insecure code from being written, executed, committed, or merged. Preventive controls such as protected branches, mandatory reviews, automated security checks, and deployment gates are still required. Human accountability remains necessary. Cursor can assist development, but it should not become an unreviewed decision-maker for security-sensitive work. Developers and AppSec teams must remain responsible for reviewing commands, validating generated changes, approving dependencies, protecting secrets, and enforcing secure engineering standards. Cursor Security Best Practices Here are a few best practices your organization can use to reduce the risks of using Cursor in software development workflows. Control AI Execution Restricting how and when Cursor executes commands is critical to reducing risk. Auto-run features should be disabled or tightly limited so that AI-generated actions require explicit human approval before execution. This prevents unintended or malicious commands from running silently in the environment. Organizations should implement allowlists and deny lists for commands, ensuring only safe and expected operations can be executed. Monitoring and logging AI actions also provides visibility into what the system is doing, helping teams detect suspicious behavior early. Since Cursor can execute shell commands and modify files directly, controlling execution is one of the most effective ways to reduce exposure to remote code execution and automation abuse risks. Enforce Least Privilege Access Cursor operates with the same permissions as the developer using it, which means excessive access rights can amplify the impact of any exploit. Applying the principle of least privilege ensures the AI only has access to the files, systems, and resources necessary for its task. This includes limiting access to sensitive directories, restricting environment variables, and isolating development environments where possible. Role-based access controls (RBAC) should also be applied so that different users and agents operate with appropriate permission levels. By reducing the scope of access, organizations can minimize the damage caused by compromised prompts, malicious dependencies, or agent abuse. Protect Sensitive Data Sensitive data such as API keys, tokens, and internal code should never be freely exposed to AI tools. Cursor can access environment variables, configuration files, and repository context, which increases the risk of accidental data leakage if not controlled. Teams should use privacy modes, redact sensitive inputs, and avoid including secrets in prompts or code comments. Data loss prevention (DLP) controls and secret-scanning tools can help detect exposures before they are committed or shared. Because AI-generated outputs may unintentionally surface confidential data, organizations must treat all outputs as potentially sensitive and validate them before use. Lock Down Dependencies Since Cursor can install packages automatically, dependency management must be tightly controlled. Only trusted registries and verified packages should be allowed, and automated installs should be reviewed before execution. Teams should use dependency scanning tools to detect known vulnerabilities and malicious packages, and implement policies that block unverified or risky dependencies. Pinning package versions and maintaining an approved dependency list can further reduce supply chain risk. These measures are essential because malicious packages can execute code during installation and compromise the entire environment. Govern Rules and Configuration Files Cursor rules files and configuration settings directly influence how the AI behaves, making them a high-value target for attackers. These files should be treated as sensitive assets and protected with strict access controls and versioning. Organizations should review rules regularly, validate changes through code review processes, and prevent unauthorized modifications. Using signed or centrally managed rule sets can help ensure integrity. Because compromised rules can introduce hidden instructions or backdoors, securing these files is essential to maintaining trust in AI-generated actions. Avoid Hardcoding Secrets Hardcoding secrets in code is a well-known security risk that becomes even more dangerous with AI-assisted development. Cursor may generate code that includes plaintext credentials or expose them through suggestions and outputs. All sensitive data should be stored in secure environment variables or secret management systems, never directly in the codebase. Developers should also ensure that secrets are excluded from version control and regularly rotated. Automated scanning tools can help detect hardcoded credentials early. This practice reduces the risk of accidental leaks, which are increasingly common in AI-assisted workflows. Review All AI-Generated Code Before Merge AI-generated code should be treated the same as code written by an untrusted contributor. Every change must go through standard review processes before it is merged into shared branches. This includes inspecting diffs, validating logic, and checking for unintended side effects across files. Fast generation does not replace careful evaluation. Security-focused review is especially important. Reviewers should look for common issues such as improper input validation, broken authorization logic, insecure defaults, and unsafe dependency usage. Automated tools like SAST, linters, and policy checks should run on all AI-generated changes to catch patterns that are easy to miss during manual review. Testing is also required before merge. Unit tests, integration tests, and regression checks help confirm that the generated code behaves as expected and does not introduce instability. If the agent modifies multiple files, reviewers should verify that interactions between components remain correct. What Critical Security Controls Do Teams Need Beyond Cursor’s Native Security? These controls help address various Cursor AI security concerns. 1. AI-Generated Code Validation Teams need an independent validation layer for code written or modified by Cursor. Generated code should not be treated as secure simply because it compiles or passes basic tests. Validation should happen in the IDE, in pull requests, and again in CI for security-sensitive areas such as authentication, authorization, payment logic, customer data, and production-facing APIs. 2. Secrets and Dependency Scanning Cursor can work with repository context, configuration files, dependency manifests, logs, and environment-related code. This increases the chance that secrets or sensitive values may be exposed, generated into files, committed, or copied into outputs. It also increases the risk that new dependencies are added too quickly, without enough review of whether they are vulnerable, malicious, typosquatted, abandoned, over-permissive, or license-incompatible. Teams need automated scanning for secrets and dependencies throughout the workflow. Secret scanning should cover the IDE, pre-commit stage, pull requests, CI/CD, and repository history, because removing a secret from the latest file does not remove it from Git history. Dependency scanning should review new packages, updated versions, lockfile changes, transitive dependencies, known vulnerabilities, malicious package indicators, and license risk. These controls help ensure that AI-generated changes do not silently introduce credentials exposure or supply chain risk. 3. SDLC Policy Enforcement Cursor should operate within the organization’s normal software development lifecycle, not outside it. AI-generated code should be subject to the same requirements as human-written code, including protected branches, peer review, automated testing, SAST, SCA, secrets detection, license checks, infrastructure scanning, and deployment gates. For higher-risk areas such as identity, authorization, data access, encryption, payment flows, production infrastructure, and customer-facing APIs, teams should require stronger approval and security review. Policy enforcement should also define how Cursor itself may be used. Organizations should specify which repositories are approved for AI-assisted development, which files must be excluded from context, which integrations and external tools are allowed, what commands require human approval, and whether autonomous or cloud-based agent execution is permitted. Rules and configuration files that guide agent behavior should be version-controlled and reviewed. The objective is to preserve accountability, traceability, and secure engineering standards while still allowing developers to benefit from AI assistance. 4. Risk Prioritization and Remediation Support As Cursor increases the speed and volume of generated changes, teams may see more scan findings, more pull requests, and more remediation work. Treating every finding equally can slow development and distract from the issues that are most likely to be exploitable or damaging. Teams need a way to prioritize risk based on severity, exploitability, reachability, affected asset, business context, and whether the vulnerable code is actually used. Remediation support should help developers understand the issue, why it matters, where it appears, and how to fix it safely. For AI-generated code, this is especially important because developers may be reviewing logic they did not write manually. Effective remediation should provide clear context, reduce false positives, suggest secure fixes, and keep humans in control of final approval. This helps teams maintain development speed while focusing security effort on the risks that matter most. Add independent validation to Cursor workflows Checkmarx One Assist Built for modern development. Built for real security. Proactively protect software from AI-driven and software supply chain threats. See it in Action How to Choose Cursor Security Tools Choosing security tools for Cursor should start with how developers actually use AI agents in the coding workflow. The right solution should secure AI-generated changes without slowing developers down or forcing security checks to happen only after code reaches CI or production. Developer workflow fit: Look for tools that work where developers already spend their time, including the IDE, pull requests, and CI/CD pipelines. Security feedback should appear early, be easy to understand, and fit naturally into AI-assisted coding, review, and remediation workflows. Coverage for code, secrets, and dependencies: Cursor security controls should cover the main risk areas introduced by AI coding: insecure generated code, exposed secrets, and risky dependencies. This includes SAST, secrets detection, SCA, license risk, malicious package indicators, and checks for newly introduced vulnerabilities. Policy and governance support: The tool should help enforce organizational rules for AI-assisted development. This includes policies for approved repositories, sensitive files, dependency usage, secret handling, pull request requirements, and security gates for high-risk code areas. Visibility into risky agent actions: Teams need visibility into what AI agents changed, added, or attempted to execute. Useful tools should help identify risky file changes, suspicious dependency additions, secret exposure, unsafe patterns, and actions that may require human review before merge or deployment. Remediation guidance: Security findings should come with clear, developer-friendly guidance. The tool should explain what the issue is, why it matters, where it appears, and how to fix it safely. Strong remediation support helps developers correct AI-generated issues quickly while keeping final approval in human hands. Checkmarx Solutions for Securing Agentic AI Coding Platforms Securing Agentic AI Workflows with Checkmarx One Assist Checkmarx One Assist is a family of agentic AI AppSec agents: Developer Assist, Policy Assist, and Insights Assist. Powered by the Checkmarx One platform and its unified telemetry, these agents live where teams work: the IDE, CI/CD pipelines, and executive dashboards. Together they prevent and remediate vulnerabilities in real time, standardize security policies at scale, and give leadership a live, risk-based view of the entire application portfolio so enterprises can ship AI-era software faster without losing control. Checkmarx One Assist provides CISOs and Security Leaders continuous, portfolio-level visibility into application risk, policy adherence, and remediation performance via Insights Assist, and links AppSec outcomes to business objectives with trend data and live posture views drawn from the entire Checkmarx One platform. For AppSec leaders and security teams, Checkmarx One Assist orchestrates and standardizes AppSec policies across diverse pipelines, minimizing manual gatekeeping and reducing noise. Key features include: Secure coding in the IDE: Developer Assist prevents and fixes vulnerabilities as code is written, including AI-generated code, across SAST, SCA, IaC, containers, and secrets. Policy enforcement in CI/CD: Policy Assist continuously evaluates code, configurations, and dependencies in pipelines, automatically enforcing AppSec policies, SLAs, and risk thresholds while reducing alert noise. Portfolio-level insights and governance: Insights Assist aggregates signals from Checkmarx One to surface posture, trends, and exceptions for leadership, enabling risk-based planning, reporting, and investment decisions. End-to-end AI threat coverage: The agents use shared intelligence from Checkmarx One: spanning applications, open-source packages, containers, cloud, and malicious package telemetry: to protect against AI-driven threats and software supply chain risk. Faster adoption and less friction: Role-specific agents fit naturally into developer, AppSec, and leadership workflows, accelerating value realization and helping organizations scale secure development practices without large process overhauls. Learn more about Checkmarx One Assist Securing AI Assisted Coding with Checkmarx Developer Assist Securing GitHub Copilot and other AI coding assistants requires application security tooling designed for the agentic coding era. Checkmarx Developer Assist is a standalone, agentic AI security assistant that lives in the IDE and fixes code as fast as GitHub Copilot generates it and developers approve it. Developer Assist continuously scans human and AI-generated code for issues across SAST, SCA (including malicious packages), IaC, containers, and secrets, then generates safe, explainable fixes in-line so vulnerabilities never reach the repository. Built for all popular AI-native IDEs, including Cursor, Windsurf, VS Code, and JetBrains, Developer Assist brings Checkmarx One intelligence directly to developers, shrinking remediation from hours to minutes without slowing delivery. Key capabilities of Checkmarx Developer Assist: Secure AI-generated and human code in real time: Detect vulnerabilities, misconfigurations, hard-coded secrets, and malicious packages as code is written, before commit. Inline, agentic remediation: Use Checkmarx agentic AI to propose and apply validated code changes, not just suggestions, directly in the IDE. Shorter fix cycles and lower remediation cost: Cut pre-commit fix cycles from hours to minutes and reduce remediation costs per issue, helping teams avoid expensive downstream rework. Guardrails for AI coding assistants: Work alongside copilots such as GitHub Copilot, Cursor, and Windsurf to provide security guardrails and safe refactoring for AI-generated changes. Frictionless rollout and adoption: Run locally in the IDE, send only minimal metadata (no source code), and be adopted independently of the full Checkmarx One platform as an easy on-ramp to agentic AppSec. Learn more about Checkmarx Developer Assist Conclusion Cursor can be used securely, but not casually. Its native controls help reduce risk around data handling, approvals, and agent behavior, but they do not replace secure review, dependency governance, secrets protection, and SDLC policy enforcement. Organizations that treat Cursor as a powerful coding system – not just a smart editor – will be better positioned to capture the productivity benefits of agentic development without expanding risk faster than they can control it.
