In the Roman Republic, as Polybius wrote, a sentry’s “watchword” was written on a wooden tablet, and then passed hand to hand up each street of the camp with witnesses at every handoff. Clever, no? Every tablet had to be back with the tribune before dark. A missing tablet was easily traced to the specific relay team, under a specific unit leader. A sentry who was found asleep was tried by the tribunes and punished severely. Polybius says the watches held because the penalty was certain, and the fault was accurately assigned. The severity is the part that usually sticks with people, because it shocks the senses. But accuracy and certainty is what actually made it work. And on that note, the certainty is the part that is easiest to replicate today.

When you look at GitHub today, you have to wonder if nobody in the whole organization studied any history. The user interface hands each installation admin a tablet that represents everything, and therefore nothing: the whole camp may as well be charged with whatever happens, meaning nobody reliably will be held to account.

Take for example how an “application permission” email will be sent from GitHub.

What? Who? Where?

Let’s have a look at one example: “[GitHub] Claude is requesting updated permissions” seems to be going around right now.

A GitHub App, Claude, installed on your account is requesting updated permissions.

Visit https://github.com/settings/installations/ to review and accept or ignore these permissions.

You may choose to ignore this request. If you do, Claude will retain its current permissions.

You can view pending requests by viewing your Apps settings page.
https://github.com/settings/installations

If you run into problems, please contact support by visiting: https://support.github.com/contact?tags=dotcom-integrations

Thanks,
Your friends at GitHub

With friends like these, who needs Romans?

Eight permissions are in the GitHub interface, with a vendor badge and reference and one sentence of explanation for the lot. This particular vendor, should you be bothered to look, has published research on approval fatigue, the exact failure this design produces. The request for updated permissions is nearly impossible to untangle. Five scopes are new. Three are upgrades from read to write. And the “developer note” at the bottom says: “Allow the Claude Apps to automatically create repositories when desired.” That sentence explains one scope. The other seven get… nothing.

GitHub sends this kind of email automatically whenever an app’s permission manifest is changed. GitHub’s documentation says the installer may approve or decline. A declined app keeps its old permissions and keeps doing what it did; whatever needs the new scopes fails, and the installer is told only that it “may not function as expected.” The choice is all or none, with uncertainty pressed firmly onto the none side.

The eight, as they appeared:

• Administration, read
• Merge queues, read
• Repository creation, read and write
• Webhooks, read and write
• Commit statuses, read
• Actions, upgraded from read to read and write
• Checks, upgraded from read to read and write
• Organization members, read

Anthropic publishes material on just two of them. The enterprise-server setup guide says webhook write creates a hook on a plugin marketplace repository when automatic sync is turned on, and organization member read checks a connecting user’s role when an installation is linked. The plugin support article confirms the webhook purpose.

The remaining six? Pound sand.

This is the second such email from Anthropic alone this year. In March the app asked for Checks write, with Administration and Merge queues read alongside, and a user filed an issue saying the first thing they assumed was a credential leak. Anyone who declined in March sees those same scopes again in November, stacked on top of the new ones, because GitHub shows the gap between what an installation approved and what the manifest now asks for.

Reasonable assumption, which opens Pandora’s box of operator confusion and fatigue from poor authentication prompt hygiene.

The explanation in that thread was based on text that was said to be from Claude itself. In May a GitHub organisation admin opened a community discussion after the same app sent the same kind of request, asking for per-scope approval, and documented that revoking a single scope after approval requires uninstalling the app, and reinstalling presents the same bundle again.

Just for some perspective, Cursor sent the same email to its users ahead of a review feature. AWS did too in 2024.

This is not a good look for the industry, especially as we know how to do this better.

As I already mentioned, Anthropic has itself published notes on what’s wrong with what Anthropic is doing to its users. In its engineering post on Claude Code auto mode, Anthropic reports that users approve 93% of permission prompts, and that over time this produces approval fatigue, where people stop reading what they approve.

I said as much about this topic in the book I co-wrote in 2012 about cloud security threats. I mean, nothing here is a surprise or new to anyone who has even a few years of real security experience.

Anthropic built classifiers to intercept threats inside the terminal. Meanwhile, it sent the GitHub version of a bad prompt design to every installation admin. The GitHub prompt is through email, completely outside any classifier or sandbox. And then the approval is account-wide and sticky.

If you are already thinking about phishing surface, well done. GMO Flatt Security reported to Anthropic in January that anyone can register a GitHub App, install it on a repository they control, and use its token to open issues on any public repository. Registering an app named Claude with a similar icon and sending this template is kids play. Every email Anthropic sends with a one-line note is pushing the kind of fatigue on its installers that greases them to click through a fake one.

Ok Anthropic, let’s get real. You know the risks. You know the harms. You know better.

You published all this yourself. Does the left hand know what the right is doing?

A vendor that measures approval fatigue in one of their products as a bad thing and manufactures it in another of their products… has a governance failure. Anthropic publishing the harm research and then setting it off under its own installers is evidence the company needs some serious security leadership reconfiguration.

Customers’ repositories deserve better than a sapper blown up by his own charge.

The fix is clear and cheap, which is what makes this a governance (and history education!) failure rather than an engineering one. A changelog entry per scope, published before the manifest changes, stating which feature uses it and what stops working when it is declined. The email links to it.

Done.

Beyond that, one app per capability. Code review, cloud sessions, security scanning and plugin sync carry different scopes. An installer who turned on one should approve the scopes for one. If the tablet has everything and everyone on it, it effectively has nothing and nobody to hold accountable.