> For the complete documentation index, see [llms.txt](https://docs.duplocloud.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.duplocloud.com/docs/extension-framework/building-an-ops-app/step-3-providers.md).

# Step 3: Connect Providers

A provider is any IT system your application will orchestrate. You register providers, supply credentials, and define scopes that control what the agent can access. Providers are what give your Ops application reach — without them, the agent has instructions but no systems to act on.

## What Is a Provider

A provider represents an external system the platform needs to access. Providers span every category of IT system an operations team might work with:

* **Cloud accounts**: AWS, Azure, GCP
* **Kubernetes clusters**: EKS, AKS, GKE, or any conformant cluster
* **Source control**: GitHub, GitLab, Bitbucket
* **CRM and sales tools**: Salesforce, Apollo, Outreach, Lemlist
* **Observability platforms**: Datadog, New Relic
* **Incident management**: PagerDuty, ServiceNow
* **Compliance and GRC tools**: Vanta, Drata
* **Any other system** accessible via MCP servers

If a system exposes an API or CLI, it can be registered as a provider. The framework does not constrain which systems you can connect — the MCP server model means coverage extends to anything with an accessible interface.

## Registering a Provider

To register a provider, supply its type, connection details, and credentials. Credentials are stored securely in the platform and are never exposed to users or surfaced in agent conversations. The agent receives credentials as structured data at ticket dispatch time, translates them into the file formats the underlying CLIs and SDKs expect (kubeconfig, AWS credential files, application default credentials, etc.), and cleans them up when the session ends.

When a user creates a ticket or resource, they select a scope — not a credential. They never see or handle the underlying authentication material.

## Configuring Scopes

A scope combines three things: a provider, a credential, and granular access controls. Access controls can restrict the agent to specific regions, resource types, namespaces, or custom resource maps — whatever level of precision your security requirements demand.

Scopes are reusable. The same scope can be attached to multiple workspaces, giving different teams access to the same underlying system without duplicating configuration. A "production AWS us-east-1" scope can be assigned to a Platform Engineering workspace with full write access and also to an L1 SRE workspace with read-only access — same provider and credential, different permission boundaries.

When a user selects a scope at ticket creation time, that selection determines which IT systems the agent can operate on for the duration of the ticket. The agent cannot exceed the scope's boundaries regardless of what it reasons.

{% hint style="info" %}
For provider-specific setup guides — including credential formats, supported regions, and MCP server configuration — see [Integrating Providers](/docs/getting-started/integrating-providers.md).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.duplocloud.com/docs/extension-framework/building-an-ops-app/step-3-providers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.