The most dangerous sentence in an AI-assisted project is not “the code failed.”
It is “the code worked, so I gave the tool access to everything.”
On July 31, npm restricted what granular access tokens configured to bypass two-factor authentication can do. Those tokens can no longer perform sensitive actions such as creating or deleting tokens, changing package access, adding maintainers, or changing trusted-publishing settings. npm says those operations now need an interactive 2FA challenge.
I did not find a more substantial AI or developer-tool development in the previous 24 hours, so I widened the search window to seven days. This change happened three days ago.
npm also previewed the next boundary. It plans to remove direct publishing from those bypass-2FA tokens in January 2027. Automation will still be able to read private packages and stage a release, but a maintainer will approve the public release with 2FA.
That is not just a package-registry detail. It is a useful operating model for anyone building with AI:
Let the tool prepare the irreversible action. Do not automatically let it own the irreversible action.
What actually changed
The immediate change applies to npm granular access tokens, not every kind of GitHub or npm credential. A bypass-2FA token can no longer use its convenience to become an account-management master key.
That closes a nasty chain of possibilities. If an attacker obtained one of those tokens, the token could previously help change maintainers, create more credentials, or alter package access. The problem was not only that the credential had power. It could use that power to create more power.
The planned publishing change makes the separation even clearer:
- Automation may build and stage a package.
- A human maintainer sees what is about to become public.
- A separate authenticated approval promotes it.
npm's trusted-publishing documentation recommends short-lived, workflow-specific OIDC credentials instead of long-lived publishing tokens. It also describes a stage-only configuration built around staged publishing, in which CI may prepare a release but a maintainer must approve it with 2FA before publication.
The exact npm setup will not apply to every app. The durable structure does.
What beginners may misunderstand about AI permissions
The npm change is about package credentials, not AI coding agents. I am applying its release model to AI-assisted work because the permission problem is the same: a system that can prepare a change does not automatically need the authority to make that change public, bill a customer, delete data, or alter account access.
Beginners often treat permissions as a binary switch:
- the AI can do nothing, so every step is slow
- the AI can do everything, so every step is exciting right up until it becomes a crime scene with excellent autocomplete
There is a better middle.
Give the tool enough access to create evidence. Keep a separate gate for actions that are difficult to reverse.
Before you connect more tools, I made the AI App Builder Starter Prompts free so you can name the user workflow, scope, data, constraints, and proof the AI should produce first.
The three-gate workflow: prepare, prove, release
I would divide an AI-assisted release into three gates.
Gate 1: Prepare
At this gate, the AI can do a lot.
It can inspect the repository, edit code, run local tests, generate a build, draft release notes, create a migration plan, and stage a deployment candidate. It can also explain the files it changed and the assumptions it made.
But “prepare” should end in a reviewable artifact, not a public consequence.
For a web app, the artifact might be a preview deployment. For a mobile app, it might be an archive or internal test build. For a package, it might be a staged version. For a newsletter, it might be a filled draft with no send permission.
The tool's job is to move the work from vague intent to inspectable candidate.
Gate 2: Prove
Now the candidate has to earn promotion.
Proof should match the risk. A button-color change may need a screenshot and a quick viewport check. An authentication change may need two accounts, expired-session behavior, password recovery, and permission tests. A database migration needs a backup, a dry run, row-count checks, and a rollback path.
For most beginner app releases, I would ask for five pieces of evidence:
- Change summary: what changed in user language.
- Automated checks: which tests, builds, or linters passed.
- Manual journey: which real user path was completed from start to finish.
- Failure check: what happened with bad input, missing data, or an unavailable service.
- Rollback note: how to return to the last known-good state.
Your AI coding tool can help produce all five. It should not get to mark its own homework merely because the output contains green checkmarks.
Gate 3: Release
Release is the shortest gate and the most protected one.
The release identity should have only the permissions required for that release. Prefer short-lived credentials when the platform supports them. Require a separate confirmation for the action that changes the outside world.
That might mean:
- promote a staged package
- deploy the verified commit to production
- submit the tested build to an app store
- run the reviewed database migration
- send the approved email campaign
- switch a payment integration from test mode to live mode
The important word is reviewed. Release should point to the exact candidate that passed Gate 2. If the code changes after review, it goes back through proof.
A beginner permission table
You do not need an enterprise security department to start. Write a small permission table for your project.
| Action | AI may prepare | AI may execute in test | Separate approval for live |
|---|---|---|---|
| Edit application code | Yes | Yes | No live effect |
| Run local tests | Yes | Yes | No |
| Create preview deployment | Yes | Yes | No |
| Read production secrets | No | No | Not needed for normal work |
| Change account owners or maintainers | No | No | Yes |
| Run destructive data migration | Draft only | On disposable test data | Yes |
| Publish a package or app | Stage only | Internal/test channel | Yes |
| Charge a real customer | Prepare test request | Test mode only | Yes |
This table is not universal. Your app may need different rows. The point is to stop permissions from being accidental.
Ask three questions about every tool connection:
- What useful evidence can this permission create?
- What damage could it create if the instruction or credential were wrong?
- Can the live action be separated from preparation?
The free AI App Builder Starter Prompts are useful here because the same scope and QA prompts can define what the tool may prepare and what proof you expect before release.
Why approval pauses are a productivity feature
People hear “human approval” and imagine a committee meeting where twelve people discuss a button for six weeks.
That is not the goal.
A good approval gate is narrow. The tool has already done the slow work. The human is answering a small question with visible evidence: Is this exact candidate allowed to cross this exact boundary?
GitHub applied a similar idea on July 28 when it announced that certain potentially malicious GitHub Actions workflows in public repositories would be held for approval. The workflow does not run until a collaborator with write access approves it through an authenticated web session.
The pause is valuable because it sits immediately before execution. It does not require a person to manually rebuild the whole workflow.
That is how I want approvals in a small AI-assisted project to feel: a speed bump before the cliff, not a parking lot at the beginning of the road.
The tradeoff: too many gates create permission theater
You can absolutely overdo this.
If every local test, preview build, typo fix, and reversible change needs manual approval, people will click through prompts without reading them. A gate that fires constantly becomes wallpaper.
The other limitation is that approval does not prove the candidate is safe. A human can approve the wrong commit, misunderstand the evidence, or miss a malicious dependency. Two-factor authentication protects the approval identity; it does not review the code for you.
That is why the three gates have different jobs:
- preparation creates the candidate
- proof creates the evidence
- release controls the consequence
Do not use the release gate as a substitute for testing. Do not use testing as a reason to hand every credential to the build tool.
What you should do next
Pick one live action in your project: production deployment, database migration, package publication, app-store submission, email send, or payment activation.
Write down:
- what the AI may prepare
- what it may execute in a test environment
- which evidence must exist
- who or what can approve the live step
- how the release identity gets its credential
- how you roll back
Then remove any permission the preparation step does not need.
You do not have to make your workflow slow to make it controlled. You want the AI doing the broad, repeatable work and a narrow verified identity owning the irreversible moment.
If you want the immediate guided action, start with the AI App Builder Starter Prompts, which are free. If you want the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering scope, stack, project rules, QA, deployment, and launch.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Top comments (0)