Skip to main content
A built-in integration is a connection the Komodor Agentic Operation Platform (KAOP) already knows how to make. You supply credentials once; the tools, the auth handling, and the connection health come with it. This page lists what is in the catalog, what each provider asks for, and how connecting, testing, and reconnecting work.

​
Where the catalog lives

Everything on this page lives under Integrations. The section rail splits it into:

​
The catalog

Some providers are unavailable until this deployment has the corresponding OAuth or app registration configured. The catalog says so on the tile rather than letting you start a connect that cannot finish.

​
Providers with sub-selections

Two providers let you narrow what the connection covers, so an agent is not handed more surface than it needs:
  • Google Cloud — choose the products to include: Cloud Logging, Cloud Monitoring, Error Reporting, Cloud Trace, Service Health, Cloud Quotas, Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Billing, Recommender, Cloud Asset Inventory, Network Management, and Policy Troubleshooter.
  • Google Workspace — choose from Drive, Docs, Sheets, Slides, Calendar, Chat, Contacts, and Gmail. Because each product is its own connection, one organization legitimately has several Google Workspace connections.

​
The auth modes

Four shapes of connection exist, and which one you get is decided by the provider, not by you.
You paste the provider’s key or token into the connect dialog and press Connect. For API-key providers the credential is checked as part of connecting: an authentication failure refuses the create outright, so you never end up with a connection that was never going to work.
Prefer the AWS IAM-role variant over access keys. It avoids storing long-lived credentials, and the role can be scoped read-only at creation time.

​
Connect one

1

Open the catalog

Go to Integrations and press Add integration. Search or browse by category.
2

Pick the provider

Press Connect on its tile. If you already have a connection to that provider, the tile reads Add another instead — connecting twice is normal when you have two accounts or two regions.
3

Choose the variant, if it has one

AWS asks whether to authenticate with access keys or an IAM role. The choice decides what the connection can do, so make it deliberately.
4

Name it and supply credentials

A display name is required and must be unique for that provider — it is how you tell two connections apart everywhere else in the product. Fill in the provider’s fields, then complete the connect, authorize, or install.
5

Confirm it works

Use Test connection from the connection’s menu. See Test and reconnect for how to read the result.
6

Attach it to an agent

A connection existing does not give any agent access to it. Attach it on the agent — directly, or as part of an integration group.

​
What each provider asks for

Field labels are the provider’s own vocabulary, which is what you will see in the dialog.
The Datadog site and the Dynatrace environment URL are not cosmetic — they select which regional endpoint the connection talks to. Getting them wrong produces authentication failures that look like a bad key.

​
One connection per real account

An account holds one connection per thing on the provider’s side: one per Slack workspace, one per GitHub App installation, and a single AWS connection at a time. Connecting the same Slack workspace again does not create a second row — depending on the state of the existing one, KAOP either adopts it or tells you it is already connected and which workspace it belongs to. What you can have is several connections to the same provider for different accounts or regions, told apart by display name. Anything that consumes an integration is bound to a specific connection, not to “whichever Datadog”.
When only a provider is named and you hold more than one connection to it, the most recently created active connection is used. If that matters for your case, bind the connection explicitly rather than relying on the default.

​
Test and reconnect

A connection carries two independent pieces of state, and reading them as one is the most common source of confusion. Skipped is not a pass. Not every provider has a check KAOP can make, and for those the result is skipped rather than a green tick you should not trust. A failure is additionally classified so you know where to look: authentication, network, timeout, a tool error, a missing credential, or no available check.

​
Testing

Use Test connection from the connection’s menu. The test makes one real call to the provider — an identity or a light read — and records the verdict on the connection.
Testing runs when you ask for it. Nothing re-checks a connection in the background, so a credential that expires after a passing test keeps reading as passed until someone tests again. A result older than a day is shown as verified earlier rather than as current — treat that as a prompt to re-test before relying on it.

​
Reconnecting

When a connection’s last check has failed, a Reconnect button appears directly on the row. When it is not failing, the same action lives in the menu as Re-authorize — use it to replace an expired credential or extend a grant.
  • Reconnecting an OAuth connection is pinned to the account it already serves. Authorizing a different workspace is refused rather than silently repointing the connection.
  • Replacing a credential clears the previous verdict, so test again afterwards.

​
The other actions

Disconnecting is refused while something still depends on the connection, and the refusal names what depends on it. Detach or repoint those first rather than forcing it — an agent left pointing at a removed connection loses the tools it was relying on.

​
Exposing a provider’s tools

Connecting a provider stores a credential. For providers that ship an MCP surface, the setup wizard also stands up the tool server that uses it, in three steps — Connect account, Expose tools, and Route. On the way through you choose whether to expose every discovered tool and which integration group the result belongs to. Some providers instead authenticate against their MCP server’s own authorization server, in which case signing in is the setup and no separate stored credential is involved. For your own tools rather than a provider’s, see the MCP Gateway.

​
Next steps

Integration groups

Bundle connections and attach the set to an agent.

Credentials & secrets

How stored secrets reach a run without being exposed.

MCP Gateway

The other connection path — your own tools.

Triggers & schedules

Endpoints, and why they are not triggers.