What your AI tools are logged in as

You clicked Allow. Claude got your Drive, ChatGPT got your calendar, an automation you built in an afternoon holds a token for the app that sends your invoices, and a local server you installed to read one repository runs with whatever access the terminal already had. None of it felt like a security decision, because each one arrived as a setup step with a blue button. Each provider keeps a list of the grants it issued, and only those: Anthropic in Claude’s settings [3], OpenAI in ChatGPT’s [4], Google on its third-party access page [5], GitHub in developer settings [6]. Assembling the whole picture across all of them is a job nobody does for you, so the only complete list is the one in your head, and the one in your head is wrong.

This guide treats each of those grants as what it is: an identity, with permissions, acting when you are not watching. It is for a solo operator, a freelancer or a small team with no security staff, no identity provider and no budget for a monitoring product. If you have an admin console, single sign-on and someone whose job is access review, the controls below are ones you already own and this document is too small for you. Everyone else is running a set of standing permissions nobody has read since the day they were granted.

A connector is a second copy of your own access

Start with the reassuring part, because it is also the frightening part. Anthropic’s connector documentation says Claude inherits each user’s existing permissions from the connected service: “If someone can’t access a specific file, channel, or record in the source system, the connector can’t reach it from Claude either” [3]. OpenAI puts the same boundary in its own words: “App permissions do not grant an app new access. The data and actions available to an app are determined by the app, the access granted when it was connected, and any workspace controls” [4].

That is a ceiling, not a floor. It means an AI tool connected to your account can reach everything your account can reach, and the smaller your business, the more that turns out to be. Check yours rather than assuming. If the same Google login holds the client folders, the shared drive, the billing inbox and the domain records, then connecting that login to anything hands over the whole surface, not the corner of it you had in mind when you clicked.

The design consequence is unglamorous and it is most of the work: which account you connect matters more than which tool you connect it to. A separate account with access to one shared folder produces a small identity. Your own account produces a large one. Nothing you configure later moves that line as far as choosing the right account at the start.

Scope is the control, and the defaults are set wide

Once you have picked the account, the second lever is scope: the specific list of things the credential is permitted to do. The Model Context Protocol’s security guidance names the failure modes plainly under scope minimisation, listing among the common mistakes “Using wildcard or omnibus scopes (*, all, full-access)” and “Bundling unrelated privileges to preempt future prompts,” and describing the result as “Expanded blast radius: stolen broad token enables unrelated tool/resource access” [1]. Broad scopes are granted for convenience, and convenience is what you are trading away.

GitHub is the clearest worked example a small operator can copy, because both kinds of credential sit side by side in one settings page. GitHub is blunt about what the older kind reaches: a personal access token (classic) “will grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account” [6]. A fine-grained token is different: “Each token is limited to access resources owned by a single user or organization. Each token can be further limited to only access specific repositories for that user or organization. Each token is granted specific, fine-grained permissions, which offer more control than the scopes granted to personal access tokens (classic)” [6]. GitHub’s own position is not neutral: “GitHub recommends that you use fine-grained personal access tokens instead of personal access tokens (classic) whenever possible” [6].

Apply the same shape everywhere else. Read-only unless writing is the actual point of the integration. One repository, one folder, one calendar, one mailbox label. If a connector asks for send permission when all you wanted was search, that is a decision to make on purpose, not a checkbox to clear. The friction of a narrow scope is paid once, at setup. The cost of a wide one is paid on the worst day you have.

Access you granted once lasts until you take it back

Credentials do not lapse out of politeness. GitHub recommends you set expiry yourself, in its own words: “To provide additional security, we highly recommend adding an expiration to your personal access tokens” [6]. The platform’s backstop runs long: “As a security precaution, GitHub automatically removes personal access tokens that haven’t been used in a year” [6]. A year is a long time for a forgotten key to sit in a script you no longer run.

OAuth connections behave the same way. The grant you made to a note-taking app in a busy week persists through your redesign, your tool switch and the day you stopped using that app entirely. Google’s account documentation gives the removal path and states the trade honestly: “If you remove access, the app can’t access your Google Account. This may make some features unavailable” [5]. Anthropic points at the same idea from the other end, telling users to manage connections under Customize then Connectors, where you can “disconnect it, modify connection settings, or review permissions and access levels,” and advising directly that you “disconnect services you no longer need or use” [3]. In ChatGPT the equivalent lives under Settings then Apps [4].

Set an expiry wherever a field exists, and read what the field allows. On a fine-grained GitHub token the permanent option sits in the same menu: “Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy set by your organization or enterprise owner” [6]. In a business of one there is no organization policy to block it, so the guardrail is your own restraint. Where no expiry field exists at all, the expiry is you, on a date in your calendar. Both of those are better than the alternative, which is a credential that outlives the reason it was created and stays valid until something goes wrong with it.

The instructions can arrive in the content, not from you

Scope decides what a credential could do. Something has to decide what it actually does, and once an AI tool can act, that decision is partly made by whatever text it reads. OWASP files this under excessive agency and traces it to three primary factors: “excessive functionality; excessive permissions; excessive autonomy” [2]. The trigger can be a hallucination from a poorly engineered prompt or an underperforming model, or a prompt injection arriving from a malicious user, a compromised extension or another agent [2].

The mitigations OWASP lists are the ones that transfer to a small business without a security budget: “Limit the extensions that LLM agents are allowed to call to only the minimum necessary,” replace open-ended capabilities such as shell command execution and URL fetching with granular purpose-specific tools, give each extension the minimum permissions it needs downstream, run extensions in an individual user’s context rather than a privileged account with broad access, and “Utilise human-in-the-loop control to require a human to approve high-impact actions” [2]. Note the honest limit that comes with them: monitoring, logging and rate-limiting “will not prevent Excessive Agency, but can limit the level of damage caused” [2].

Vendors treat this as live rather than solved. OpenAI’s description of its own defence is carefully worded: “Suspicious or hidden instructions in app content can also cause ChatGPT to ask for approval or block the request” [4]. Can cause, not will. Read every approval prompt as the last control rather than a formality, and be more suspicious of what a tool proposes right after it has read a web page, an email or a shared document than of what it proposes cold.

A connector is software you installed, not a feature you switched on

There is a category difference between a connector built by the company whose data you are connecting and one built by somebody else. Anthropic states it about its own product: “Custom connectors allow you to connect Claude to services that haven’t been verified by Anthropic,” alongside the general instruction to “Only connect services you trust and need for your workflows” [3].

Locally installed servers deserve more caution again, because they are executables on your machine rather than a permission on a website. The protocol’s security guidance says these servers “may have direct access to the user’s system,” lists the risks as including “Arbitrary code execution. Attackers can execute any command with MCP client privileges” and “No visibility. Users have no insight into what commands are being executed,” and tells client software to warn users “that MCP servers run with the same privileges as the client” [1]. The same document forbids servers from acting as pass-throughs for credentials they were not issued: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server” [1]. You are not going to audit that yourself. What you can do is prefer first-party connectors, install third-party ones only when you have a reason, and treat a local server the way you would treat any other program a stranger asked you to run.

The review is a list, and the list is the whole job

Large companies buy this capability. Okta closed its acquisition of Permiso Security on 26 August 2026, a platform it describes as detecting and mitigating “threats across human, non-human, and agentic identities in multi-cloud environments” and surfacing “overprivileged access, unused permissions, anomalous agent behavior and tool usage, policy violations, and high blast radius behavior, in real time” [8]. Buying a monitoring product is the enterprise answer to a question you have too, and it is not available to you at your size. Your answer is a spreadsheet with four columns and a recurring hour in the calendar.

The gap is not imaginary. In research commissioned by Okta, fielded by Apprize360 in March 2026 among 292 executives and 492 knowledge workers across seven countries, “58% of executives reported that their company experienced an AI-related security issue or close call within the last 12 months,” while “Barely a third (34%) of executives reported that their organization always applies the same security controls to the digital labor force as it does to the human labor force” [7]. Separately, “More than half (52%) of knowledge workers reported using unsanctioned AI tools at work” [7]. Those are companies with executives to survey. A business without a security function is not somehow exempt; it just has nobody counting.

Do the enumeration provider by provider, because that is where the authoritative list lives. Google’s third-party access page lets you review the permissions an app holds and remove them [5]. Claude’s connector settings show what is connected and what each connection can do [3]. ChatGPT lists connected apps under Settings then Apps [4]. GitHub keeps tokens under Settings, then Developer settings, then Fine-grained tokens or Tokens (classic), with a Delete button beside each one [6]. Add the stored connections inside whatever automation platform you use, whether that is Zapier, n8n or Make, since each saved connection there is another credential you granted and stopped thinking about. Write down what you find, and revoke anything you cannot immediately justify.

What still goes wrong

Your list will be incomplete, and you should assume so. Provider settings pages show grants that went through a consent screen. They do not show an API key you pasted into a script two years ago, a token sitting in an environment file on a server, a credential inside a workflow a contractor built, or a service account created for a migration that finished. Those are the ones that survive longest, precisely because no page lists them. The only cure is writing things down at the moment you create them, which is a habit rather than a control.

The larger limit is that none of this tells you what a credential actually did after it authenticated. Scope, expiry and revocation are all decisions made in advance; they say nothing about the gap between a token leaking and you noticing. Watching identity behaviour after login is a product category in its own right, which is the thing Okta bought rather than built [8]. OWASP’s framing agrees on the shape of the problem, listing monitoring, logging and rate-limiting as damage limiters rather than preventions [2]. At your scale you are relying on narrow permissions to keep the damage small, not on detection to catch it early.

Least privilege also fights the tool, sometimes visibly. GitHub notes that its narrower tokens still do not cover everything, and that “some features currently will only work with personal access tokens (classic)” [6]. You will hit a feature that only works with the broad credential, and the temptation will be to switch and move on. When that happens, the honest move is to grant the broad credential, write down that you did, and set a short expiry on it. Finally, this is a small-business guide and not an assurance document. If you handle regulated data, hold client systems under contract, or have obligations you would need to demonstrate to an auditor, the review above is a starting inventory and not the process you are required to run.