Connection Types

Not every service connects to Gatekeeper the same way. Which type you're dealing with changes who sets it up, what "disconnect" means, and whether you can adjust permissions yourself.

OAuth connections

The self-service path, and the one most services use — HubSpot, GitHub, Slack, Google Workspace, Atlassian and similar.

You click Connect, log in to the service directly, and approve a specific set of permissions. Gatekeeper receives an authorisation grant, never your password.

• Who sets it up: you
• Permissions: you choose from the service's requestable scopes at connect time
• To change permissions: reauthenticate with a different scope selection
• To revoke: disconnect in Gatekeeper, which revokes the grant and deletes the stored credential

This is the connection type the rest of the help centre describes by default.

Organisation-supplied API keys

Some services are connected centrally by your organisation using an API key rather than an interactive login — typically infrastructure and security tooling where a per-person OAuth login doesn't make sense.

These appear in your Services list already connected, marked as supplied by your organisation.

• Who sets it up: an administrator, outside your own account
• Permissions: fixed by the key itself — there are no scopes to select
• To change permissions: you can't; the key has to be reissued by whoever manages it
• To revoke: requires an administrator

If you need broader access to one of these, the request goes to your administrator, not through a reauthentication flow. There is nothing you can adjust from your own Services page.

HTTP API services

Some services are exposed to Gatekeeper as a set of HTTP API operations rather than through an interactive connection. These show a count of enabled tools — for example, "106 tools enabled."

That count matters. It's the number of individual operations an administrator has switched on for that service, and it's usually a deliberate subset rather than everything the API offers.

Per-tool enablement

This is worth calling out separately, because it's the most common cause of a confusing failure.

Independently of your policies, an administrator can enable or disable individual tools on a service. A disabled tool isn't a policy denial — the tool simply isn't there. Your agent won't see it when it lists what's available, and if it tries to call it anyway the call fails as unrecognised rather than as blocked.

So there are two separate reasons an agent can't do something:

Checking which of the two you're dealing with saves a lot of time. If your policy looks correct and the action still won't run, check tool enablement before rewriting the rule.

Checking what you have

Your Services list shows every service, its connection type, its status, and — for HTTP API services — how many tools are enabled. If a service shows as connected but your agent can't see any of its tools, that's an enablement question rather than a connection one.