Cursor AI and code security: what to check before deploying

Those who arrive at this question are usually no longer experimenting: they already have a function, web app, dashboard, or workflow built or modified with Cursor that seems to work. The critical point is to understand whether that code can be connected to real data, users, payments, corporate APIs, or production environments without introducing unseen risks.

The useful question before deployment is not whether Cursor is “secure” in the abstract. It is another one: what has Cursor changed in the code, permissions, dependencies, tests, secrets, configurations, and exposed application paths?

This article is not a review of Cursor nor an audit of the platform. It is an operational checklist to understand if a product developed or modified with Cursor is ready to go online, or if it requires an independent verification before go-live.

When a prototype created with Cursor becomes a real risk

The delicate moment is not always when Cursor generates the first code. The risk grows when the prototype changes state: from local demo to reachable service, from dummy data to personal or corporate data, from private repository to shared pipeline, from single test user to different roles and teams, from development script to cloud deployment, from “fix later” code to a feature used by customers, colleagues, or partners.

In that transition, “it works” is not enough. A dashboard can load the correct data for the right user and, at the same time, allow another user to read the same records by changing an ID in the request. A build can pass and have overly permissive CORS. A generated test can be green because it confirms the behavior introduced by the agent, not because it challenges it. Security must therefore be brought back to the product: APIs, roles, data, secrets, dependencies, configurations, and exposed surfaces.

The real risk is the diff that looks reasonable

Cursor works inside the repository. With Agent mode, it can explore the codebase, modify multiple files, fix errors, update tests, propose packages, and intervene in configurations—which is very different from accepting a single completion. The result can be a large diff, distributed across frontend, backend, middleware, routes, tests, lockfiles, and deployments. This is where so-called “diff fatigue” arises: after many lines are modified, the reviewer tends to check that the feature works and that the suite is green, but struggles to reconstruct every security implication.

Some typical examples: a multi-file refactoring removes an authorization check because it seems duplicated; a middleware is moved but not applied to a new route; a permissive fallback makes a test pass but opens a bypass; server-side validation is considered redundant because it already exists in the frontend; tests are updated to confirm the new behavior instead of challenging it; a build error is resolved by changing a security default; a tenant check is lost during data model normalization.

Before deployment, diffs generated or modified by Cursor must be separated into small, reviewable change sets. Sensitive areas should never be accepted with a generic “Accept All”: authentication, authorizations, roles, APIs, databases, input validation, logging, secrets, dependencies, pipelines, and production configurations require manual review. Asking Cursor for a summary of the security impact can help guide the review, but it is not proof: the agent cannot certify its own output.

Where Cursor can introduce application errors

Cursor’s specific functions should be read as possible causes or amplifiers of errors in the product. The question is not “is this feature secure?”, but “could this feature have produced code, permissions, configurations, or tests that no one has actually verified?”.

Authentication, roles, and tenant isolation

Many bugs introduced during AI-assisted development do not break login. The app continues to authenticate the user but loses more subtle controls: roles, tenant isolation, object access, administrative permissions, policies for routes or APIs. Before deployment, it is therefore necessary to test scenarios that go beyond the normal flow: changing user_id, project_id, tenant_id, or organization_id in requests, directly calling routes that do not appear in the interface, verifying that every new API route has correct middleware and policies, testing users without roles, users from another tenant, and expired tokens. It is also important to check that permissions are applied server-side and not just in the frontend, verify caching, queries, and filters to avoid cross-user data, and check RLS, Security Rules, or equivalent policies if the app uses Supabase, Firebase, or other BaaS.

On this front, Code Review and Web Application Penetration Testing complement each other: the former looks for the problem in the logic and code, the latter verifies the behavior exposed by the app.

APIs, routes, middleware, and business logic

Cursor can create or refactor controllers, route handlers, server actions, middleware, and services. The risk is that the generated code is consistent with the intended flow but fragile against abusive use. It is worth checking in particular: routes created for debugging that remained reachable, middleware not applied to new APIs, role checks applied in UI but not in the backend, parameters accepted without an allowlist, error handling that reveals internal details, code branches that allow “allow” in case of error, and business logic based on client-controllable data.

A practical rule: every endpoint touched by Cursor must be tested as if the user were hostile, not just as if they followed the UI flow.

Secrets, logs, and environment variables

Cursor works on the repository, so if the workspace contains real secrets, dumps, or logs, the risk is not just committing them by mistake: they can enter the context, terminal outputs, tests, files created by the agent, or configurations generated to “make a feature work”. Before a refactoring or an Agent task on sensitive areas, it is advisable to perform secret scanning on the repository and history, remove real .env files, SQL dumps, application logs, and customer fixtures, rotate already exposed keys, use .env.example without real values, adopt secret managers and limited dev tokens, and verify that the agent has not created files with hardcoded credentials.

.cursorignore and .cursorindexingignore help reduce exposure and indexing, but should not be treated as complete protection: terminal, scripts, MCP, and external tools remain separate surfaces.

Dependencies and supply chain

An agent that wants to close a task might introduce a new library, replace an existing one, or update lockfiles and configurations. This solves the visible problem but can increase supply chain risk. One must always check packages added to package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, or equivalents, modified lockfiles, postinstall, prepare, build or test scripts, the actual maintenance of the package, the license, known vulnerabilities and transitive dependencies, any cases of typosquatting or near-homonym packages, and the replacement of consolidated libraries with little-known alternatives.

Before accepting a new dependency, it is worth asking if there is a solution with already approved libraries or standard libraries. When the dependency is truly needed, it must be handled as a supply chain modification: review, SCA, checked lockfile, and clear motivation.

Build, deploy, and cloud configurations

A build or deploy error can push Cursor to modify configurations in a functional but insecure way. The question is not just “does the build pass?”, but: what security assumptions were changed to make it pass? Among the diffs to check carefully are: CORS made permissive, CSP removed or weakened, validation disabled, debug mode left active, detailed errors exposed, rate limits removed, tokens ending up in the frontend, callbacks and redirects not allowlisted, server actions or route handlers without auth, Dockerfile executed as root without reason, GitHub Actions with secrets exposed in logs, Terraform, IaC, or cloud configs modified without review.

These changes are not technical details: they are decisions that change the application’s level of exposure. If they are accepted only because the build passes, the risk can reach production without being discussed. If Cursor has touched architecture, IaC, cloud, containers, pipelines, or production configurations, the perimeter is no longer just “code” and a Secure Architecture Review or a Cloud Security Assessment may also be necessary.

Specific Cursor functions to consider in the review

The following sections do not concern the operational security of Cursor as a platform, but serve to understand how the Cursor workflow can influence the product that will go online.

Rules, AGENTS.md, and persistent instructions

Cursor can use rules and persistent instructions to guide Agent and Inline Edit. Rules can live in .cursor/rules, user rules, AGENTS.md, and, in older projects, in .cursorrules. They are useful for standardizing style and architecture but can become a risk surface if not managed carefully. It is important to review these files as code, remove or migrate legacy .cursorrules if the project uses more structured rules, avoid secrets, internal endpoints, tokens, or sensitive policies in instructions, separate style rules from security rules, and avoid instructions like “make everything work even if tests fail”. It is better to add verifiable guardrails—for example “do not modify auth without negative tests” or “do not use service role keys in the client”—and check every change to instruction files in PRs.

The risk of document prompt injection also concerns READMEs, issues, comments, and technical documents: an agent can interpret content in the repository as operational context.

Agent mode, terminal, and commands

For analysis and planning, Ask mode is often the more prudent choice because it does not apply changes automatically. Agent mode is useful for producing code, but increases risk when it suggests commands, installs packages, runs tests, modifies configurations, or chases errors with auto-fix chains. Concrete risks include: commands run in the wrong directory, migrations executed against an unintended database, installation of unreviewed packages, build or test scripts that execute untrusted code, terminal output with tokens or sensitive data reported in the context, configurations changed to make tests pass, use of cloud CLI, Docker, Terraform, or Kubernetes with overly broad credentials.

Command allowlists are useful as operational friction, but are not enough as a primary security control. Install, migration, deploy, delete, chmod, cloud CLI, Docker, Terraform, and Kubernetes must require explicit approval in sensitive repositories.

MCP and external tools

MCP can connect Cursor to external tools and data sources. The risk is not MCP itself, but giving the agent context or tools that can influence code, permissions, data, or configurations—for example, an MCP server connected to a database, an integration with GitHub or GitLab, tools that read internal documentation, connections to cloud or deployments, MCP servers installed from unverified sources, or tokens shared between projects.

The minimum controls to apply are: install MCP servers only from trusted sources, review their code and configuration, use dedicated credentials and minimum privileges, prefer read-only tokens when sufficient, separate global and project-level configurations, verify the list of available tools before using Agent, require approval for sensitive actions, and disable unnecessary MCP on critical repositories.

Background Agents and remote environments

Background Agents introduce another scenario: the agent works asynchronously in a remote environment, can modify code, and deliver work to repositories or branches. This is useful for long tasks but changes the risk perimeter. Aspects to evaluate include: remote environment with internet access and the ability to install packages, installation and startup commands, read-write privileges on the connected repository, dev secrets provided to the environment, autonomous iteration on tests and commands, branches and PRs that seem ready because “tests are green”.

Before using them on corporate code, it is advisable to limit who can start them, use dedicated branches, avoid production secrets, review .cursor/environment.json as a sensitive file, and treat every generated PR as untrusted output.

Privacy Mode: useful, but not sufficient

Privacy Mode, codebase indexing, and enterprise settings are important for defining how code and prompts are treated by the vendor, but they do not prove that the application is secure. The distinction must be sharp: vendor security concerns the platform, data processing, retention, and enterprise policies; application security concerns auth, authorizations, input, output, secrets, dependencies, databases, APIs, and deployments. A team can use Privacy Mode correctly and still have a BOLA, a SQL injection, a token in the frontend, a vulnerable dependency, or an open CORS policy.

Checklist before go-live

Code and authorizations

• Cursor diffs divided into small, reviewable change sets.
• Changes to auth, roles, tenant isolation, middleware, and APIs reviewed manually.
• Negative tests present for unauthorized users, roles, tenants, and objects.
• Server-side controls verified, not just UI.

Repository, secrets, and context

• Repository cleaned of .env files, dumps, real logs, customer fixtures, and historical secrets.
• Secret scanning performed on repository and history.
• .cursorignore and .cursorindexingignore reviewed without treating them as complete protection.
• Rules, AGENTS.md, and .cursorrules reviewed as code.

Agent, terminal, and external tools

• Ask mode used for read-only analysis when sufficient.
• Agent mode used with clear limits.
• Install, migration, deploy, delete, cloud CLI, Docker, Terraform, and Kubernetes commands approved manually.
• MCP servers necessary, trusted, with minimum permissions and dedicated tokens.
• Background Agents used only with dedicated branches, limited dev secrets, and full PR review.

Dependencies, build, and deploy

• New dependencies and lockfiles reviewed.
• Install/build/test scripts checked.
• CORS, CSP, callbacks, redirects, env, logging, rate limits, and pipelines verified.
• WAPT planned if the app is exposed online.
• Code Review planned if Cursor touched logic, authorizations, data, dependencies, or critical configurations.

A checklist is not meant to slow down the team: it is meant to decide if the risk is under control. If an item remains open, it must have an owner, a priority, and an explicit choice: fix before go-live, accept temporarily, or block the release.

When an internal review is enough and when an independent verification is needed

An internal review may be enough if Cursor has modified non-exposed code, without real data, without roles, without external integrations, and with a competent reviewer who knows the area. An independent verification is needed when the app handles real data, users, payments, or corporate APIs; when Cursor has modified auth, roles, tenant isolation, middleware, or routes; when dependencies have been added or lockfiles updated; when the deployment exposes new web or API surfaces; when cloud configurations, pipelines, or IaC have been touched; when the team has accepted large diffs without line-by-line review; or when the beta involves customers, employees, or partners.

The point is not to slow down Cursor, but to separate what can be accelerated from what must be verified: authorization boundaries, real data, exposed surfaces, secrets, dependencies, and production configurations.

How to verify an application developed with Cursor

Verification must follow the actual perimeter of the change, not the name of the tool used.

If Cursor touched…	Main risk	Recommended check
Application logic, controllers, middleware, auth, roles, dependencies	Regression or vulnerability in the code	Code Review
Web app, API, or routes exposed online	Behavior abusable from the outside	Web Application Penetration Testing
Architecture, trust boundary, integrations, data flows	Weak security assumptions	Secure Architecture Review
Cloud, IAM, buckets, databases, IaC, pipelines	Misconfiguration or excessive privileges	Cloud Security Assessment
Multiple teams, multiple releases, continuous use of coding agents	Lack of repeatable process	Software Assurance Lifecycle

Have you used Cursor on code that is about to go into production? ISGroup can help you verify what has actually changed: application logic, authorizations, APIs, dependencies, secrets, and deployment configurations. Depending on the perimeter, the verification can include Code Review, WAPT, Secure Architecture Review, Cloud Security Assessment, or Software Assurance Lifecycle.

Evidence to prepare before the review

Before involving an external team, it is advisable to prepare the necessary material to make the verification effective and targeted:

• Repository or branches with diffs generated or modified by Cursor.
• List of parts generated, refactored, or corrected with Agent mode.
• URLs of environments to be tested.
• Description of roles and tenants.
• List of APIs, integrations, and external systems.
• Added or updated dependencies.
• Schema of treated data.
• Deployment, cloud, CI/CD configurations, and environment variables.
• Rules files, AGENTS.md, MCP configurations, and relevant settings.
• Any decisions already made on accepted risks or planned remediations.

This evidence reduces ambiguity and allows distinguishing code problems from configuration problems, application vulnerabilities from process gaps, immediate risks from governance improvements.

The final decision should not be “do we publish or not” in the abstract. It should be: which risks do we fix before go-live, which can we accept temporarily, which require monitoring, and which are incompatible with real data or external users. Cursor can greatly accelerate development; security serves to prevent that speed from bringing an application into production with broken authorizations, exposed secrets, abusable APIs, unevaluated dependencies, or weak configurations. The question to ask is simple: has the code produced or modified with Cursor been verified as a product, or only accepted as a working diff?

FAQ

• Does Cursor Privacy Mode make my application secure?
• No. Privacy Mode concerns the vendor’s handling of code and prompts, not the quality of the generated code. An app can use Cursor with Privacy Mode active and still have broken authorizations, hardcoded secrets, open CORS, vulnerable dependencies, or weak configurations.
• What is the biggest risk before deployment?
• Accepting a large diff because it compiles, passes tests, or seems reasonable. The most dangerous vulnerabilities are not always syntactic errors: they are often logical regressions on auth, roles, tenant isolation, validation, dependencies, and deployment.
• Is Ask mode safer than Agent mode?
• Ask mode is more suitable for reading, understanding, and planning because it does not apply changes automatically. Agent mode is useful for producing code, but must be used with control over diffs, commands, tools, dependencies, and tests.
• Is MCP in Cursor dangerous?
• MCP is not dangerous in itself. It becomes risky when it connects the agent to databases, repositories, cloud, or tools with overly broad permissions, without audit logs, approval, or isolation. Every MCP server should be treated as an application component with defined credentials, scopes, and trust boundaries.
• Are automatic tests enough if they were generated by Cursor?
• No. Tests generated together with the code can confirm the implemented behavior instead of looking for abuse and regressions. For sensitive areas, negative tests, manual review, and, when the app is exposed, application verification on real behavior are needed.
• Do I always have to do a WAPT if I use Cursor?
• No. If Cursor only touched internal, non-exposed code, a Code Review might be more consistent. If, on the other hand, the app or APIs are reachable online, WAPT verifies the real behavior from the outside. If architecture, cloud, or pipelines were touched, an architectural or cloud review might be needed.

Sources and useful references

• Cursor Privacy & Security: https://docs.cursor.com/account/privacy
• Cursor Agent Security: https://docs.cursor.com/account/agent-security
• Cursor Rules: https://docs.cursor.com/en/context
• Cursor MCP: https://docs.cursor.com/context/model-context-protocol
• Cursor Background Agents: https://docs.cursor.com/en/background-agents
• OWASP Top 10 for LLM Applications 2025: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• OWASP Agentic Skills Top 10: https://owasp.org/www-project-agentic-skills-top-10/