# Cursor Automations last mile: Security Review plus Rollouts, not hope-CI > Enable Security Review on ready PRs and Rollouts for per-env deploy health—keep Bugbot for style, and do not confuse this with Expo OTA. > By Dave · 2026-09-24 > Source: https://otf-kit.dev/blog/cursor-rollouts-security-review-last-mile Last-mile confidence is not a vibe and it is not “CI was green.” For Teams and Enterprise, Cursor Automations now cover the two gaps that still eat merge-and-ship weekends: exploitable-bug review on pull requests, and per-environment deploy health after merge—with notify and a revert path when a named regression shows up. Bugbot stays the style and nits bot. Do not replace it. Do not treat Expo OTA staged updates as the same product. The buyer question is specific: how do you enable Cursor Automations last-mile bots so every ready PR gets an attack-path-plus-fix security pass before merge, and so each environment gets deploy-health and named-regression handling after—without throwing out Bugbot? One stack answers it. Security Review on the PR. Rollouts on the deploy. Same Automations surface. One last mile. This is not two co-equal posts. Security Review without Rollouts is a merge ritual that still hopes production is fine. Rollouts without Security Review is a health dashboard on a change nobody attacked on the way in. Together they are last-mile confidence. [Expo’s staged EAS Update guide](https://otf-kit.dev/blog/eas-update-staged-rollout-guide) is a different last mile: JS bundle percentage on devices. Cursor Rollouts are PR-to-environment health, notify, and revert for the thing you just merged. Do not mix the runbooks. Primary source: Cursor’s changelog for Rollouts and the security reviewer (2026-09-23) at [cursor.com/changelog/rollouts-and-security-reviewer](https://cursor.com/changelog/rollouts-and-security-reviewer). ## What last-mile actually means here Most teams already have required checks, CODEOWNERS, and a bot that comments on unused imports. That is not last mile. Last mile is the window where a ready PR can still ship an exploitable bug, and the window after merge where a “healthy” deploy is actually a named regression in one environment. Security Review is the first window: exploitable issues with an attack path a reviewer can follow and a fix path a patcher can take. It is not a style pass. Rollouts is the second window: after merge, health per named environment, notify when it is not, and a revert path when a named regression is the story. Bugbot stays the third bot—style and consistency—cheap on purpose. Folding style into Security Review trains people to skip security comments. Folding security into Bugbot trains people to treat attack paths as nits. Keep the lanes. Pair this with an [AI app security checklist](https://otf-kit.dev/blog/ai-app-security-checklist) for boundaries Security Review cannot invent for you. ![Hope CI was enough versus Security Review plus Rollouts Automations](https://cdn.otf-kit.dev/blog/cursor-rollouts-security-review-last-mile/inbody1-20260924e.png) Hope-CI-was-enough looks like: tests passed, linter passed, two approvals, merge, assume staging and prod will tell you later. Security Review + Rollouts Automations looks like: every ready PR gets exploitable-bug review with attack path and fix; after merge, Rollouts watches per-environment health, notifies on named regressions, and can open a revert PR for review. Same PR object. Different failure modes. Different bots. ## Enable Security Review on every ready PR Treat ready (non-draft) as the trigger, not “when someone remembers to @ the bot.” Drafts are for incomplete work. The moment a PR leaves draft, it is in the merge funnel. Wire the Automation so: - Scope is Teams/Enterprise Automations, not a personal rule you cannot audit. - Event is ready pull request (opened ready, or converted from draft). Re-runs on relevant pushes keep the review honest as the diff moves. - Output is exploitable-bug review: attack path plus fix. If the model cannot name a path, it should not invent a CVE-shaped essay. - Bugbot is unchanged. Do not disable Bugbot to “reduce bots.” Reduce overlap by job, not by count. What “attack path + fix” means in practice: untrusted input reaches a sink (authz skip, template, shell, deserialization, IDOR), and the fix is the concrete change in this PR—guard, query bound, deny-by-default, or drop the endpoint. If the Automation cannot point at a hunk, it is not last-mile. Required status is a policy choice. If Security Review is advisory, people will merge around it the week you are busy. Teams that already require Bugbot for nits should not assume that requirement covers exploitable bugs. It does not. ## Enable Rollouts for PR → environment health After merge, the PR is a candidate in each environment you actually ship to. Rollouts attaches monitoring to the change, reports health per environment, notifies when health is not the story you wanted, and—depending on configuration—can open a revert PR for review or hand the finding to a cloud agent. Per Cursor’s changelog, it does not merge or roll back on its own today. Name environments the way you operate (`preview`, `staging`, `prod`). Rollouts is not Expo’s rollout percent. For OTA percentages, stay on the [EAS Update staged rollout guide](https://otf-kit.dev/blog/eas-update-staged-rollout-guide). For “this merged PR’s deploy is sick in staging,” stay on Cursor Rollouts. Health has to be named. Named regression means a check, error class, or SLO you already believe—checkout, auth, a critical job, a latency budget you page on. Wire notify to the people who can revert. You should answer: which PR, which env, which signal, who was notified, was a revert opened. ![Ready PR to Security Review to merge to Rollouts per-env health to notify or revert](https://cdn.otf-kit.dev/blog/cursor-rollouts-security-review-last-mile/inbody2-20260924e.png) Nothing in that spine is Bugbot. Nothing is an Expo runtime version. Ready is the security gate. Merge is the handoff. Per-env health is the deploy gate. Notify and revert are how you leave without a war room as the default. ## Do not confuse Cursor Rollouts with Expo staged OTA Expo / EAS Update staged rollout ships a JavaScript bundle to a fraction of clients and watches crash and runtime signals. The unit is the update on a channel. The client is a device. Use [eas-update-staged-rollout-guide](https://otf-kit.dev/blog/eas-update-staged-rollout-guide) when the question is “what fraction of phones get this bundle.” Cursor Rollouts (Automations, Teams/Enterprise, changelog 2026-09-23) asks whether the merged PR’s deploy is healthy in each environment, who hears about a named regression, and whether a revert path opens. The blast radius is an environment, not a device cohort. You can run both in one company. Document them as two last miles. ## Keep Bugbot for style Bugbot owns dead code, naming, and review hygiene. Security Review owns exploitable bugs on ready PRs. Rollouts owns post-merge per-environment health, notify, and revert path. Three bots is not a failure. One bot with three jobs is. For owned backends you already operate, keep [structured logging agents can triage](https://otf-kit.dev/blog/production-structured-logging-for-agents) so Rollouts has signals worth trusting. ## A enablement path that does not stall 1. Confirm Automations on Teams or Enterprise. 2. Turn on Security Review for ready PRs. Convert-from-draft must count. Sample a week of comments: keep only findings with a path and a fix. 3. Leave Bugbot on. If volume is high, tune Bugbot, not Security Review. 4. Turn on Rollouts for the environments you deploy. Attach signals you already trust. Wire notify to the on-call who can revert. 5. Practice one revert in non-prod so revert is not a rumor. 6. Write two sentences in the team doc: Cursor Rollouts ≠ EAS staged updates; Bugbot ≠ Security Review. The failure mode is a fourth bot that restates CI. The other failure mode is skipping Security Review because Rollouts “will catch it.” Rollouts catch deploy health. They do not reconstruct an IDOR from a 200 OK. ## What “good” looks like after a week A ready PR that touches auth gets a Security Review comment that names the path and the fix. Bugbot still nags about a leftover `console.log`. A merge to staging trips a named regression; Rollouts notifies; a revert path opens in the same spine. If Security Review only ever says “looks fine” on risky diffs, tighten the ready-PR trigger and demand path + fix. If someone asks whether this replaces Expo rollout percent, send them the EAS guide and this post. ## What we are not claiming The changelog is the source for Rollouts and the security reviewer as of 2026-09-23. This post does not invent plan SKUs beyond Teams/Enterprise Automations, does not invent package versions, and does not quote unpublished metrics. It does not claim Security Review finds every exploitable bug. It claims you can put exploitable-bug review with attack path and fix on ready PRs, keep Bugbot on style, and put PR-to-environment health, notify, and a revert path on the other side of merge. Last-mile confidence is that pair, on Automations, not a feeling that CI was enough. Owned kits still help when the app itself is the thing you review and roll out: [browse templates](https://otf-kit.dev/templates) for full-stack starting points with agent configs already in the repo. ## Sources - [Cursor changelog: Rollouts and security reviewer (2026-09-23)](https://cursor.com/changelog/rollouts-and-security-reviewer) - [EAS Update staged rollout guide (Expo OTA — different last mile)](https://otf-kit.dev/blog/eas-update-staged-rollout-guide) - [AI app security checklist](https://otf-kit.dev/blog/ai-app-security-checklist) - [Structured production logs with correlation IDs agents can triage](https://otf-kit.dev/blog/production-structured-logging-for-agents)