A run in continuous integration is governed by three requirements, and all three follow from the absence of a human. It must be non-interactive - there is nobody to ask, and any confirmation prompt turns into a stalled job that at best gets killed by a timeout. It must be limited by repository, branch and token rights - otherwise a single wrong setting repeats on every run and lives exactly as long as the pipeline file lives. And it must end with machine-readable evidence - otherwise there is nothing to check the result against except reading the log by eye, and nobody reads the log until an incident happens.

The naive approach is to take a ready example from the documentation and consider security solved by the vendor. Cursor publishes a working template, and it genuinely works: the run will start on the first attempt. But the threat model remains yours. Your environment has forks, someone else's build scripts, your own secrets and your own branching rules - everything the template cannot know about, because it was written to demonstrate a mechanism rather than to fit your organization. A ready file is a starting point, not a policy.

It helps to see a minimal review run once. Below are a trigger on a pull request with read-only rights to the contents, installing the command line, reviewing the changes with output to a file and saving the result as an artifact. The key thing here is not that the agent can read a diff but what the file does not contain: write rights, permission to change files and broad tokens. A time limit on the job stands next to the rights for the same reason - both of them cap the damage from a run that behaved differently than intended.

Rights are granted strictly for the required behavior. Review needs reading; commenting on a pull request requires write access to discussions; committing requires rights to the contents. Every widening is made a separate decision, because in continuous integration the cost of a mistake is multiplied by the number of runs: a permission granted just in case fires not once but every day and on every branch. The way back is planned from the start - rights are easier to narrow while the pipeline is new than after neighboring jobs have come to depend on them.

Pull requests from forks deserve separate caution. That is code written by an outsider, and running a privileged process on it without a separate security model is dangerous: the contents of the branch effectively govern what executes on the runner. Platforms have their own mechanics for secrets on forks, and relying on them blindly is not acceptable. The right move is to separate trusted and untrusted runs so that the untrusted one has no access to secrets at all, while everything requiring privileges runs as a separate job on already reviewed contents.