Key Points: Cyber Risk is a Trade-Off Problem

• Cyber risk is not just technical issues; it is fundamentally about trade-offs between competing outcomes, and what to prioritise for customers.
• Incident decisions should be driven by the nature of the threat (e.g., data exposure vs service disruption), with predefined thresholds and response plans agreed across the business before incidents occur.
• Effective cyber leadership focuses on communicating business impact and options, not technical details, enabling executives to make informed decisions under uncertainty.
• Strong cyber risk management requires early collaboration with the business and clear alignment on risk appetite, recognising that improving security often involves sacrificing flexibility, speed, or convenience.

The Personal Access Token seats comfortably in the domain of developer convenience: something you generated in a settings page, pasted into a script, and forgot about. More and more, PATs have moved well beyond personal scripts and into CI/CD pipelines, service integrations, and third party connections that touch production systems and customer data. And in a modern enterprise stack, where every access point is also an exposure, that shift deserves a lot more scrutiny than it's getting.

If you design technology solutions in any organisation, you have almost certainly been offered a PAT as the quickest way to connect two systems. The question worth asking isn't whether it will work. It will. The question is whether "quickest" should ever have been the deciding factor.

The Quiet Rise of the Personal Access Token

A PAT is a long lived, opaque bearer credential a user generates directly inside a product, then presents on every subsequent API call in place of an interactive login. Structurally, it is the user themselves authenticating: whatever the token can do, the person who created it could already do through the UI, and any action taken with it is indistinguishable from an action that person took directly. There is no consent screen, no delegating party, no MFA, no third party application in the picture. That absence of ceremony is precisely the point, and precisely why developers reach for it.

Compare that to an OAuth 2.0 access token, which represents a third party application a user has explicitly authorised to act on their behalf, for a defined and revocable set of scopes, typically issued with a short lifetime and refreshed automatically. The authorisation server knows which application asked for access, what it was granted, and when. A PAT carries none of that context. It's a bearer secret. Whoever holds it, is you, pretty much forever.

When the Platform Makes the Insecure Choice the Easy One

Here's what doesn't get said enough: PATs haven't spread because engineering teams sat down and decided a static, unscoped, often non expiring credential was the right architecture for system to system access. They've spread because the platforms we all build on made it the easiest option, and in some cases the only one.

GitHub's classic personal access tokens defaulted to "no expiration" until 2021. Fine grained, expiring tokens exist now, but the classic, all or nothing version is still available and still widely used, because changing a default years after millions of integrations were built around it is a lot harder than setting the right default in the first place. GitLab's own CLI authenticates via PAT out of the box. Look at the quickstart documentation for Stripe, Twilio, or SendGrid and you'll find an API key front and centre, because it gets a developer to a working integration in minutes, well before OAuth's authorisation code flow would. CI/CD platforms compound this: a PAT gets stored as a pipeline secret once, and from that point on it quietly becomes "how we connect to that system", inherited by every engineer who touches the pipeline afterwards without ever revisiting the decision.

None of this is malicious. It's a rational response to a real problem: OAuth's consent and redirect model is genuinely disproportionate friction for an individual developer at home, scripting against their own account. But rational at the level of one integration becomes a systemic weakness at the level of an enterprise, and organisations have hundreds, sometimes thousands, of these integrations accumulating quietly across teams that never had a reason to ask "is this still the right way to do this?"

The Convenience Is the Vulnerability

Every property that makes a PAT easy to use is also the property that makes it dangerous.

A user's SSO session might expire in eight hours. A PAT created with no expiration can outlive that session by years, surviving password resets and, in some configurations, even the deactivation of the account it belongs to. Because the token authenticates as the issuing user, it inherits that user's entire permission set, admin rights included, rather than a scope negotiated for the specific integration it was created for. And when it's used, there's typically no MFA challenge, no conditional access policy, and no anomaly detection standing between an attacker and the resource. It's a string that works from anywhere it's presented, which is exactly what makes it so easy to leave behind in a CI log, a config file, a container layer, or shell history.

This maps directly onto what OWASP calls out as Broken Authentication in its API Security Top 10: weak, non rotating keys and unsigned, non expiring tokens sitting at the centre of some of the most common API compromises in production today. The fix OWASP prescribes is the one the PAT model was never built for: short lived tokens, standard authentication flows, and multi factor authentication.

The Breaches Already Told Us This

We don't have to speculate about how this plays out, because it's already happened, repeatedly, to organisations with mature security programs.

In the CircleCI incident of December 2022, malware on an employee's laptop was enough to harvest a valid session and pivot into customer secrets, including customer issued tokens stored on the platform. CircleCI's own response was to ask every customer to rotate every credential they'd ever stored with them, a remarkable admission of how far a single compromised credential can reach.

In March 2023, GitHub detected and revoked a set of compromised personal access tokens tied to Atlassian's Bitbucket organisation, tokens that had been used to clone private repositories exactly as a legitimate user would, generating no alarm until the activity was noticed from the other end.

In late 2024, a GitHub PAT belonging to a Home Depot employee sat exposed in a public repository commit for over a year, granting read write access to hundreds of private repositories and the CI/CD pipelines connected to them, discovered only when an external researcher stumbled on it.

And earlier this year, an extortion group used a compromised token to access Grafana Labs' GitHub environment and source code. No expiration, no scope boundary, no monitoring signal, just a single credential doing exactly what it was designed to do, for the wrong person.

The pattern doesn't change across any of these. A long lived, broadly scoped credential sits exposed somewhere ordinary, a build log, a config file, a laptop, until someone finds it and uses it precisely as intended. For a source code platform, that's a serious incident. For a bank, the equivalent exposure sits behind core banking APIs, payment rails, and customer records, and the severity moves into an entirely different category.

Personal Access Tokens Have No Place In Modern Development Pipelines

I'm not arguing PATs should disappear. For a developer automating their own personal workflow, on a low risk system, the friction of a full OAuth flow might not be justified, and banning the pattern outright would just push people toward something worse and less visible.

What I am arguing is that PATs have no business being the default pattern for enterprise-grade development pipelines. In those contexts, the preferred design should be OAuth 2.0 or OpenID Connect where delegation and consent matter, mutual TLS or workload identity federation for service to service calls, and cloud native managed identities wherever the workload runs in infrastructure that can issue and rotate its own short lived credentials without a human ever generating a secret at all.

If a PAT genuinely is the right tool for a specific, low risk case, it needs to earn that trust: a hard expiry measured in weeks not years, scope narrowed to exactly what the integration needs, storage exclusively in a secrets vault rather than a config file, automated scanning to catch it if it ever surfaces somewhere it shouldn't, and immediate revocation the moment the person who owns it leaves or changes role. None of that is exotic. It's the same discipline we already apply to every other credential in the estate. The only thing that's changed is that we've let PATs quietly opt out of it because they were convenient.

Final Thought

The technology industry has a long history of confusing "the option the platform makes easiest" with "the option that's actually appropriate", and personal access tokens are the clearest current example. They didn't earn a place at the centre of how a modern organisation institution connects its systems to the world, and the breaches piling up behind exactly this pattern should be enough evidence that the convenience was never free.

The next time a PAT shows up as the fastest way to close out an integration, the right question isn't whether it works. It's whether we're solving today's ticket at the cost of next year's incident report.

Disclaimer: This article is not legal or regulatory advice. You should seek independent advice on your legal and regulatory obligations. The views and opinions expressed in this article are solely those of the author. These views and opinions do not necessarily represent those of AMP or its staff. Artificial Intelligence Technology was used to proof-read this article.