I watched Klinger, my AI agent, test access controls for our newsletter database. It proposed running a temporary script through Chrome's JavaScript console. That was a clever approach I probably would not have thought of myself.
The work required my approval. Chrome also displayed a warning:
Warning: Don't paste code into the DevTools Console that you don't understand or haven't reviewed yourself. This could allow attackers to steal your identity or take control of your computer. Please type 'allow pasting' below and hit Enter to allow pasting.
I reviewed the code and watched it get pasted and run. The work matched my expectations. I saw no evidence of misuse.
Then I started asking what else that approval meant.
Three things changed, not one
Afterward, Klinger's review laid out what the script actually did. Looking back, I see three separate things.
The temporary script. It briefly watched the page's own web requests, copied the login pass from one my signed-in session was already sending, then put things back the way they were. The script itself was short-lived.
The lasting backend changes. While it ran, the script used my existing login to call an API we were building, the direct line programs use to talk to it as me. The tests created and changed hosted records. The credential never left the browser. That avoided exporting it by hand, but it did not limit what my login was allowed to do, and those record changes stayed after the script was done.
The persistent warning behavior. Google documents that typing "allow pasting" turns off future self-XSS warnings for that Chrome profile. ("Self-XSS" is when someone tricks you into pasting harmful code into your own browser.) Google also describes a second rule: the warning is skipped once the profile has at least five entries in the console's history.1
Five commands show activity. They do not show understanding, especially when an agent supplies the expertise.
The warning told me the code could be dangerous. It did not tell me that allowing paste would carry into future sessions.
A plausible fix wasn't a verified fix
Klinger later suggested restoring DevTools defaults. It reasoned from Chromium's source code (the open-source code Chrome is built on) that this should bring the warning back.
I tried it. In my setup, the warning did not return.
Then I fully shut Chrome down, restarted it, and opened an Incognito window first. The warning still did not appear, and pasting was allowed. So for me, Incognito was not a way to get the warning back either.
Chrome documents the restore-defaults button, but does not promise it restores this warning.2 Google's post says a brand-new Chrome profile starts with the warning on. I haven't tried that, and it wouldn't reset my existing profile.1 I don't know why the warning stayed away. It could be the "allow pasting" setting, the five-entry history rule, my browser version, or something else. What I do know is that the suggested fix did not do what we expected.
That is a useful distinction. An educated guess is something to test, not something to present as a solution.
Pause, learn, then decide
Google has a real tradeoff to manage. Developer tools need to run code without constantly interrupting experienced users. Chrome treats a few past console commands as a sign of experience. When an agent is supplying the code, that may not mean the person understands it.
My recommendation is practical:
-
Pause when you don't understand the risk.
-
Research and learn. Whose login does the method use? What will it change on the server? What settings will stay changed afterward? How do you end its access?
-
Ask for alternatives. In our case, Klinger pointed to an API test runner with its own test login. For checks like ours, that seems like the better fit. It doesn't borrow my login, and it doesn't touch the paste warning. For checks that need a real browser, use test accounts.
-
If you proceed, stay and watch. Review before it runs, follow the work, and check the results afterward, including what changed on the server.
Watching has limits. I could have shut things down, but code can run faster than I can step in. Staying present supports understanding and accountability. It does not guarantee prevention.
Platforms need to meet us halfway
Chrome's team, Apple, and Microsoft belong on the front line. They control permissions, the screens where we approve access, and the walls between apps, accounts, and data.
When those tools and our agents ask for approval, they should tell us:
- whose identity will be used,
- what it can reach,
- what it is allowed to do,
- how long it lasts,
- what settings will stay changed afterward, and
- how to take it back.
People cannot reasonably rebuild every security boundary in their heads while trying to get useful work done.
We don't have to understand everything about the tool. We do need to understand the decision it is asking us to make.