Plugin or authorized connection: what's actually different?

Two different questions get collapsed into one

"Installing a plugin" answers one question: what could this bot theoretically do? "Authorizing a connection" answers a different one: has anyone actually granted it the right to do that against a specific account? In OpenAI's GPT Actions framework, an action is defined by two separate components: how the GPT authenticates with the API, and a schema that defines what the API can do.

Those two components can move independently. A builder can finish the schema, publish the tool, and still have zero live access, because the authentication side hasn't been configured yet. That's the installation step. The authorization step is what turns the declared capability into something that can actually touch a real account, and it usually involves the account owner signing in somewhere.

Sources: Getting started with GPT Actions.

What installing a tool actually configures

When you add an action to a GPT, the schema defines what your API can do — it tells ChatGPT which operations exist and what parameters they take. By default, the authentication method for all actions is set to "None", so a freshly installed action can be reachable without any sign-in step at all, until someone deliberately changes that.

That default matters because it means installation and authorization aren't just conceptually different, they're set independently, and the wrong default can leave a tool answering requests before anyone intended it to hold real access. Builders can mix a single authentication type along with endpoints that don't require authentication at all inside the same tool, so "installed" doesn't tell you much about what's actually reachable without a credential.

There's also a structural boundary worth knowing: a GPT can use either apps or actions, but not both at the same time. That's a platform-level constraint on installation itself, separate from anything about consent or credentials.

Sources: GPT Action authentication | OpenAI API, Getting started with GPT Actions, Production notes on GPT Actions.

What an authorized connection adds on top

Authorization is the step where a person, not a developer, grants access. Actions allow OAuth sign in for each user, and that flow is described as the best way to provide personalized experiences and make the most powerful actions available. Setting it up means entering a client ID, client secret, and authorization details, and once configured, the platform hands back a callback URL that has to be registered with the third-party provider before sign-in will work.

The Model Context Protocol's authorization specification draws the same line more formally: an MCP client acts as an OAuth 2.1 client, making protected resource requests on behalf of a resource owner, while the authorization server is responsible for interacting with the user and issuing access tokens for use at the server. The tool definition and the credential are handled by different parties on purpose.

Transport matters here too. Implementations using an STDIO transport — the kind of local, same-machine tool call common in personal bot setups — are told they should not follow the OAuth-style flow at all, and should instead retrieve credentials from the environment. So a locally installed tool and a remotely authorized one aren't just different in permission scope; they're often authorized through entirely different mechanisms, one via a login screen, one via whatever's sitting in a local environment variable or keychain.

Sources: GPT Action authentication | OpenAI API, Authorization - Model Context Protocol.

A third setting: whether it runs on its own or waits for you

Even after a connection is authorized, there's a separate switch controlling whether a call executes automatically or pauses for a human. In the OpenAPI schema behind an action, an endpoint can be marked with an x-openai-isConsequential flag. A good example of a consequential action is booking a hotel room and paying for it on behalf of a user. If that field is set to true, the operation is treated as one that must always prompt the user for confirmation before running, and the interface won't offer an "always allow" shortcut.

That flag is independent of both installation and authorization. A read-only endpoint on the same authorized connection can run without asking, while a write endpoint sitting right next to it pauses every time. This is the practical layer of "bot enablement" — not whether the bot has access, but whether it's allowed to use that access without checking in first.

Sources: Production notes on GPT Actions.

A worked example (illustrative)

Say a small team builds a scheduling bot they call Aria. First, someone installs a calendar tool: they write a schema declaring a GET operation to list events and a POST operation to create them. At this point Aria has a plugin installed, but it can't touch anyone's calendar — there's no credential attached yet, and by default the action's authentication is set to none.

Next, the team switches the create-event endpoint to OAuth. They register Aria's app with the calendar provider, get a client ID and secret, and paste the provider's authorization and token URLs into the tool's settings. The provider hands back a callback URL, which the team registers on their side to complete the loop.

The first time a team member actually asks Aria to book something, they're redirected to the calendar provider's own sign-in page, not anything BotBento or the bot builder controls. They approve a scope like "read and write calendar events." That approval — done on the provider's site, by the account owner — is the authorized connection. It didn't exist when the tool was installed; it exists now because a specific person consented to a specific scope for a specific account.

Finally, the team marks the POST /events endpoint as consequential. Now Aria can read the calendar freely, but every time it tries to create an event, it stops and asks first. Reading, writing, and confirming are three separate settings stacked on the same tool — installed, authorized, and enabled are not the same fact.

What to check before you call a connection "live"

Before assuming a connected tool is safe to leave running, it's worth checking a short list. First, what's the actual authentication setting on each endpoint — not what you intended, but what's configured, since the default is none unless someone changed it. Second, what scope did the account owner actually approve during sign-in, since OAuth grants are scoped, not all-or-nothing. Third, which endpoints are marked consequential and which aren't, since that's what decides whether the bot pauses before acting.

For tools that run locally rather than through a hosted OAuth flow, the check is different: credentials come from the environment rather than a login screen, so revoking access means removing or rotating whatever's stored locally, not clicking "disconnect" on a provider's consent page. Knowing which model your tool uses — hosted OAuth or local environment credentials — is part of what BotBento's permission views are being built to make visible in one place, rather than something you have to reconstruct from separate settings screens.

Sources: Authorization - Model Context Protocol.