Every Model Context Protocol (MCP) server has to answer one question before it does anything useful: who is calling, and are they allowed to. Get the authentication pattern wrong and you either lock out the people who need access or hand a live token to something that should never have held it. For Australian businesses connecting Claude to internal systems, that choice also carries Privacy Act weight, so it is worth deciding deliberately rather than copying whatever the first tutorial used.
Why authentication is the first design decision
An MCP server sits between Claude and a real system: a database, a CRM, an accounting ledger, or an internal API. The moment it can read or write real records, it becomes a credential holder. The pattern you pick decides three things at once: how a caller proves who they are, how much access the resulting token carries, and how fast you can revoke it when a laptop goes missing or a contractor rolls off.
Three patterns cover almost every server we build for clients: personal access tokens, OAuth, and service accounts. They are not interchangeable. Each fits a different combination of who is calling and on whose behalf, and mixing them up is how a low-risk reporting tool quietly gains the ability to delete production data.
Personal access tokens: the quick start
A personal access token (PAT) is a long-lived secret tied to one user account. The user generates it in the target system, pastes it into the MCP server config, and every call the server makes runs as that user with that user's permissions. It is the fastest way to stand up a working server, which is exactly why so many first builds use it.
The catch is that a PAT is a bearer secret. Anyone who reads it can act as the user until it is manually rotated, and most PATs carry the full scope of the account rather than a narrow slice. A PAT belonging to a finance manager can do everything that manager can do, which is rarely what a single reporting tool needs.
Good fit: a single-user internal tool, a proof of concept, or a server only you run on your own machine.
Poor fit: anything multi-user, anything customer-facing, or any system holding personal information covered by the Privacy Act.
Non-negotiables: store the token in a secret manager, never in code or chat; scope it down where the system allows; and set a calendar reminder to rotate it.
OAuth: delegated, multi-user access
OAuth solves the problem PATs create. Instead of one shared secret, each user authorises the MCP server through a consent screen, and the server receives a short-lived access token plus a refresh token scoped to only the permissions that user granted. Claude then acts on behalf of whoever is actually signed in, not a single hard-coded identity.
This is the right pattern whenever more than one person uses the server, whenever the server touches data belonging to different customers, or whenever you need a clean audit trail of who did what. Access tokens expire in minutes, so a leaked one is far less dangerous than a leaked PAT, and revoking a single user is a one-click action rather than a full rotation. The cost is engineering effort: you need to register an OAuth client, handle the redirect and token-exchange flow, and store refresh tokens securely. For an APRA-regulated firm or any business under serious compliance scrutiny, that effort is not optional, it is the baseline.
Service accounts: system-to-system work
A service account is a non-human identity built for background and machine-to-machine jobs: a nightly sync, a scheduled report, a pipeline that runs with no person present to click a consent screen. It authenticates with its own credential, usually a key pair or a client secret, and carries a fixed, deliberately narrow set of permissions.
The discipline that makes service accounts safe is least privilege. A service account that reads invoices should not be able to issue refunds. Because there is no user behind it, an over-scoped service account is a standing risk that no login prompt will ever catch, so its permissions have to be defined tightly up front and reviewed on a schedule.
Use a PAT when one known person runs a low-stakes internal tool and speed matters more than isolation.
Use OAuth when real people log in, when data spans multiple users or customers, or when you need per-user audit and revocation.
Use a service account when there is no human in the loop, such as a scheduled job or a system integration, and pair it with strict least-privilege scoping.
Choosing the pattern for an Australian business
The decision is really about blast radius. Ask what the worst credential in this server could do if it leaked, then pick the pattern that keeps that number small. A single over-scoped PAT behind a customer-facing tool can turn a minor mistake into a notifiable data breach, and remediation, legal review, and lost trust can run well past $45,000 for a mid-sized firm before you count the reputational hit.
For most Sydney and Melbourne clients we start with OAuth for anything people log into, service accounts for anything that runs on a timer, and reserve PATs for throwaway internal prototypes that never touch customer data. That mapping keeps identity, scope, and revocation aligned with how the tool is actually used, which is what auditors and the Privacy Act both expect.
If you are planning an MCP server that will connect Claude to a system holding real business or customer data and want a second set of eyes on the authentication design before you ship it, book a short session with us.
We can walk through the trade-offs against your specific compliance obligations: talk to Automata AI.
