Tools › Connector Types Reference
Who this is for. Engineers choosing how one system, or an AI agent, should talk to another, and anyone designing or reviewing a connector layer. If you have a concrete need, start with Which connector do I need?; if you have a name, jump to it in the summary table.
When an application, an integration platform or an AI agent has to reach another system, it does so through a connector: a component that knows one protocol, one way of authenticating and one set of operations. This page lists the connector types you meet in practice, what each one is for, where it is the right choice and where it is not. It then rates them for security, sketches a connector manager, lists the configuration fields every connector should carry and gives a few working configuration examples.
Updated: November 4, 2026 (7531)
A connector is described at three separate levels, and most confusion comes from mixing them:
"SSO" is a goal, not a protocol: it is delivered by SAML or OpenID Connect. "SSH with a password" and "SSH with a key" are one transport with two authentication methods. The security section rates the three levels separately for the same reason.
Answer the first question that applies and follow it down. The links lead to the full entry.
| Connector type | Level | What it is | Typical example |
|---|---|---|---|
| MCP | Protocol | Model Context Protocol: tools and data exposed to AI agents | AI agent → MCP server |
| REST API | Protocol | HTTP-based integration between systems | Jira, GitHub, GitLab |
| SOAP API | Protocol | XML-based web services with a WSDL contract | SAP, Oracle |
| GraphQL API | Protocol | Client-shaped queries against one schema | GitHub GraphQL |
| gRPC | Protocol | Binary remote procedure calls over HTTP/2 | Microservices |
| WebSocket | Protocol | Persistent, bidirectional connection | Real-time applications |
| Webhook | Protocol | Event-driven HTTP notification from the other side | GitHub → CI/CD |
| Message queue | Protocol | Asynchronous messaging through a broker | RabbitMQ, Kafka |
| Username / password | Authentication | Credentials sent directly to the system | Legacy applications |
| API key | Authentication | A static secret that identifies the caller | OpenAI API |
| Bearer token | Authentication | Any token in the Authorization header; opaque or a JWT | REST services |
| JWT | Authentication | A self-contained token with claims, signed (JWS) or encrypted (JWE) | Service-to-service, OIDC ID tokens |
| OAuth 2.0 / OIDC | Authentication | Delegated authorization and federated login | Microsoft 365, Google |
| SAML | Authentication | Federated web login (one way to get SSO) | Enterprise applications |
| Mutual TLS | Authentication | Both sides present a certificate | Service-to-service, banking APIs |
| SSH key | Authentication | Public/private key pair for SSH | Linux, Git, SFTP |
| SSH | Protocol | Remote shell and tunnels; password or key authentication | Linux servers |
| WinRM / PowerShell Remoting | Protocol | Remote management of Windows hosts | Windows Server |
| SFTP / SCP | Protocol | File transfer over SSH | File servers |
| Object storage | Protocol | HTTP API for blobs in buckets | AWS S3, MinIO, Azure Blob |
| Database direct | Protocol | Native driver connection to a database | Oracle, PostgreSQL, MSSQL |
| JDBC / ODBC | Protocol | Standard database interfaces for Java and BI tools | Java applications, BI tools |
| LDAP / Active Directory | Protocol | Directory and identity lookups | Enterprise AD |
| SMB / NFS | Protocol | Shared filesystem access | Windows and Linux shares |
| Kubernetes API | Protocol | REST API of a cluster's control plane | Kubernetes clusters |
| Docker Engine API | Protocol | REST API of a container host | Docker hosts |
| CLI connector | Execution | Driving a command-line tool | kubectl, Docker, Terraform |
| SDK connector | Execution | Integration through the provider's library | AWS SDK, Azure SDK |
| Custom connector | Any | Anything that fits none of the above | Internal applications |
What it is. An open protocol through which an AI agent discovers and calls tools, reads resources and fetches prompts from a server. The server describes each tool with a JSON schema, so the model knows what arguments it takes without hand-written glue. Transports are stdio for a local server and streamable HTTP for a remote one; remote servers authenticate with OAuth 2.0.
Good for. Giving an LLM-based agent controlled access to a system: a ticket tracker, a database, a filesystem, an internal API. One MCP server serves every MCP-capable client, so the integration is written once.
Use it when the caller is an AI agent and you want the tool list, argument validation and permissions in one place rather than in each prompt. Put the MCP server in front of an existing REST or database connector; it is a presentation layer for agents, not a replacement for the underlying protocol.
Not for system-to-system traffic with no model in the loop, high-volume calls, or anything that needs streaming of large payloads. There the plain API is simpler and faster.
What it is. HTTP requests against resource URLs, usually with JSON bodies, using the standard verbs (GET, POST, PUT, PATCH, DELETE) and status codes. The most common integration surface today; almost every SaaS product has one.
Good for. Request/response operations on well-defined resources: create an issue, read a repository, update a user. Easy to test with curl, easy to cache, easy to put behind a gateway.
Use it when the other system publishes a REST API and your needs are CRUD-shaped. Pair it with the authentication the provider supports (API key, bearer token, OAuth 2.0) and a retry policy that respects 429 and 5xx responses and the Retry-After header.
Not for server-initiated events (use a webhook or a queue), long-lived bidirectional sessions (WebSocket), or deep object graphs where one screen needs ten calls (GraphQL may fit better).
What it is. XML messages in an envelope, described by a WSDL contract, usually over HTTPS. Strongly typed, with built-in standards for security (WS-Security), transactions and reliable delivery.
Good for. Enterprise systems that already speak it: SAP, Oracle E-Business Suite, banking and insurance back ends, government services. The WSDL lets you generate a typed client in minutes.
Use it when the target only offers SOAP, or when the contract and schema validation matter more than payload size. Keep the generated client in the connector and expose a plain method surface to the rest of the system. Disable external entities in the XML parser.
Not for new APIs you design yourself, browser clients, or anything bandwidth-sensitive. The XML overhead and tooling complexity are not worth it where REST or gRPC is available.
What it is. A single endpoint and a typed schema; the client writes a query that names exactly the fields it wants, and gets back a JSON document of that shape. Mutations change data, subscriptions stream it.
Good for. Reading connected data in one round trip: a pull request with its reviews, labels and commits from GitHub, or a product catalogue with nested variants. Good when many clients need different subsets of the same data.
Use it when a REST integration would need several dependent calls per operation, or the provider's GraphQL API exposes fields the REST one does not. Always set a query complexity or depth limit on the connector side; a careless query can be expensive for both parties.
Not for simple CRUD on one resource, file uploads, or HTTP caching by URL. Rate limits are usually counted in query cost rather than requests, which makes capacity planning harder.
What it is. Remote procedure calls defined in Protocol Buffers, carried over HTTP/2 as compact binary messages. Supports unary calls and client, server and bidirectional streaming, with generated clients for every major language.
Good for. Service-to-service traffic inside your own platform: microservices, sidecars, data pipelines, anything where latency and throughput matter and both ends are under your control.
Use it when you own both sides, need streaming, or call the same operation thousands of times per second. Use deadlines on every call and keep the .proto files versioned with the services.
Not for public APIs consumed by browsers or third parties (they need gRPC-Web or a REST gateway), debugging with plain text tools, or environments where HTTP/2 is blocked by a proxy.
What it is. One connection that stays open and carries messages in both directions. Classically an HTTP/1.1 connection upgraded with the Upgrade: websocket handshake (RFC 6455); over HTTP/2 the same is done with an extended CONNECT (RFC 8441), so one HTTP/2 connection can carry WebSocket streams next to ordinary requests. Either side can send at any time without a new request.
Good for. Live updates and interactive sessions: dashboards, chat, collaborative editing, terminals in the browser, market data feeds, control of a device that reports back continuously.
Use it when the data changes faster than polling can follow, or the server must push to a specific client. Plan for reconnects, heartbeats and a way to resume from the last message, because connections drop. If the traffic is server-to-client only, Server-Sent Events are simpler.
Not for occasional request/response work (REST is simpler), fan-out to many consumers across services (a queue does it better), or anything behind a load balancer that cannot hold long connections.
What it is. The other system calls you: an HTTP POST to a URL you registered, sent whenever an event happens. Usually signed with a shared secret so you can verify the sender.
Good for. Reacting to events without polling: a push to GitHub starts a build, a paid invoice updates the ledger, a new ticket pages the on-call engineer.
Use it when the provider offers it and the sender can reach your endpoint. For a SaaS provider that means a public HTTPS URL, but it does not have to be your application itself: a relay or gateway on the edge, a VPN or private link to the provider, or a tunnel service can receive the call and forward it inside. Verify the signature, respond quickly (queue the work, do not do it inside the request), and make the handler idempotent because deliveries can repeat.
Not for guaranteed delivery or ordering (providers retry a few times and give up), or cases where you need the full state rather than a notification. Pair a webhook with a periodic reconciliation call.
What it is. Producers write messages to a broker, consumers read them later. RabbitMQ (AMQP) gives you queues, routing and acknowledgements; Kafka gives you an ordered, replayable log partitioned for scale; MQTT is the lightweight variant for devices; cloud equivalents are SQS, Pub/Sub and Service Bus.
Good for. Decoupling systems in time: order processing, audit trails, event sourcing, buffering bursts, feeding several consumers from one event, work that must survive a restart of either side.
Use it when the producer must not wait for the consumer, when consumers come and go, or when you need to replay history. Decide early on the delivery guarantee. "Exactly-once" offered by a broker (Kafka transactions, for example) covers the broker's own state; the moment a consumer calls an external system, sends an email or writes to another database, a retry can repeat that side effect. Build consumers idempotent and key the side effects on the message id, whatever the broker promises.
Not for synchronous questions that need an answer now, tiny integrations where a broker is more infrastructure than the problem deserves, or transfers of large files (put the file in object storage and send a reference).
These are not transports; they are the way a connector proves who it is over one of the transports on this page. A connector's authentication_type field picks one of these.
What it is. The connector sends a user name and a password, either as HTTP basic auth, in a form, or in a protocol handshake.
Good for. Legacy applications and appliances that offer nothing else; local test environments.
Use it when there is no alternative, and only over TLS or SSH. Create a dedicated service account with the minimum rights, store the password in the secrets store and reference it, never embed it in the configuration.
Not for anything that can take a token or a key. Passwords are long-lived, cannot be scoped, and are often shared with a human login, so rotation breaks things.
What it is. A static secret issued by the provider, sent in a header or query parameter. It identifies the calling account and usually carries a quota.
Good for. Server-to-server calls to SaaS APIs: OpenAI, Stripe, mapping services, monitoring back ends. Simple to issue, simple to revoke.
Use it when the provider offers keys with scopes, you can keep the key server-side, and you have a rotation routine. Prefer a header over a query string so the key does not land in access logs.
Not for browser or mobile clients (the key leaks), per-user access on behalf of someone else (that is OAuth), or systems where the key cannot be scoped below "everything".
What it is. Any token sent as Authorization: Bearer <token> (RFC 6750). "Bearer" only says that whoever holds the token may use it; it says nothing about the token's format. An opaque bearer token is a random string the issuer looks up on each call (or checks through token introspection, RFC 7662); it has no structure and no built-in expiry, the issuer decides both. A JWT is the other kind, described next.
Good for. OAuth 2.0 access tokens from providers that keep token state server-side, session tokens, personal access tokens from GitHub, GitLab or Atlassian.
Use it when the provider issues them; you do not choose the format, the issuer does. Treat the token as a password: TLS only, never in a URL, store it by reference, and expect it to be revocable at any moment (opaque tokens are, which is their advantage).
Not for verifying the caller locally without a call to the issuer; an opaque token means nothing on its own. If you need stateless verification, you need a JWT.
What it is. A self-contained token that carries claims (who, what for, until when) as JSON. Usually it is signed (JWS, RFC 7515), so any service with the issuer's public key can verify it without calling the issuer; it can instead or additionally be encrypted (JWE, RFC 7516) when the claims must stay hidden from the holder. A JWT is normally carried as a bearer token, but a bearer token is not necessarily a JWT.
Good for. REST and gRPC services inside a platform, where an identity provider issues short-lived tokens and each service verifies the signature locally; OIDC ID tokens; signed assertions between services.
Use it when you want scoped credentials with stateless verification. Verify signature, issuer, audience and expiry on every call, reject alg: none and unexpected algorithms, keep lifetimes short, and have the connector refresh before expiry rather than on the first 401.
Not for long-lived credentials (that is what an API key is for) or cases where instant revocation is required; a JWT stays valid until it expires unless you add a revocation list or short lifetimes with refresh.
What it is. OAuth 2.0 (RFC 6749) lets a user or a service grant your connector limited access without handing over a password; OpenID Connect adds identity on top, so the same flow also logs the user in. Which flow you use decides what tokens you get:
Good for. Microsoft 365, Google Workspace, Salesforce, GitHub apps: any integration that acts as a specific user or tenant with consented scopes; and service-to-service calls where the identity provider should be the single place that issues credentials.
Use it when the data belongs to a user or a tenant rather than to you, when scopes must be granular, or when the provider mandates it. Token handling: cache the access token securely and reuse it until shortly before expiry, do not request a new one per call. In the authorization code flow, persist the refresh token (encrypted, by reference) because it is what survives; in client credentials, persist the client secret or certificate and nothing else. Handle consent revocation and refresh-token rotation gracefully.
Not for simple machine-to-machine calls where an API key would do with far less setup, or offline systems with no identity provider.
What it is. SAML 2.0 is an XML-based protocol: an identity provider signs an assertion about the user and the browser carries it to the service provider. Single sign-on is the outcome, one corporate login for many applications, and it can be delivered by SAML or by OpenID Connect; SSO is not itself a connector type.
Good for. Enterprise single sign-on into browser applications: HR systems, ticketing, intranet portals, SaaS admin consoles, especially older ones that predate OIDC.
Use it when the organisation's identity provider and the target application both support it and the target is a web application with a human at the keyboard. Prefer OIDC for new integrations if both sides offer it; it is simpler to implement correctly.
Not for API or automation traffic; SAML is built around browser redirects. For services, use OIDC or client-credentials tokens from the same identity provider.
What it is. Both the client and the server present an X.509 certificate during the TLS handshake, so the transport itself authenticates the caller.
Good for. Service meshes, banking and payment APIs, B2B links with a fixed partner, anything where the caller must be a known machine rather than a known account.
Use it when you control certificate issuance (an internal CA or a mesh) and can automate renewal. Combine it with a token for the "which user" part if needed.
Not for ad-hoc integrations, many small partners, or teams without a certificate lifecycle; an expired client certificate is the classic 3 a.m. outage.
What it is. A public/private key pair used to authenticate an SSH session. The private key stays with the connector (ideally in an agent, a hardware token or a secrets manager); the public key is placed in the target's authorized_keys. An SSH certificate is a public key signed by an SSH CA with a validity period, so hosts trust the CA instead of a list of keys.
Good for. Every automated SSH, SFTP and Git-over-SSH connection.
Use it when a connector needs SSH at all. One key per connector, restricted with authorized_keys options (forced command, source address), rotated on a schedule; short-lived certificates from an SSH CA where the fleet is large enough to justify one.
Not for sharing between tools or people; a key with no owner is a key nobody will rotate.
What it is. An encrypted remote shell, command execution and tunnelling protocol (RFC 4251 family). The transport is the same whether the login uses a password or a key; the difference is in the authentication method and what it lets you control.
Good for. Running commands and scripts on Linux and BSD servers, port forwarding to reach a database behind a jump host, the carrier for SFTP and Git. The standard way for configuration management and deployment tools to reach a host.
Use it when you need shell-level access and the target is a Unix-like system. Authenticate with a key or certificate. Password authentication is not a weakness of the cryptography, the session is encrypted either way; it is an operational one: passwords get brute-forced on any reachable port, cannot be scoped to a command or a source address, are shared with the human account and leave no way to tell which tool logged in. Allow it only for first access to a new machine, behind a bastion, and switch it off once a key is installed. Log sessions.
Not for structured data exchange (an API is easier to validate and audit), Windows hosts without an SSH server (WinRM is the native choice), or operations that a narrower connector can do; a shell can do anything, which is exactly the problem.
What it is. Windows Remote Management, Microsoft's implementation of WS-Management: SOAP over HTTP (5985) or HTTPS (5986) that carries PowerShell sessions and WMI queries. Authenticates with Kerberos in a domain, or NTLM, basic or certificate outside one.
Good for. Managing Windows Server fleets: installing software, reading event logs, configuring IIS, joining domains. Ansible, SCCM-style tooling and most Windows automation use it.
Use it when the target is Windows and the task is administrative. Use HTTPS or Kerberos (Kerberos encrypts the payload even over port 5985), a dedicated service account, and Just Enough Administration (JEA) endpoints to limit what a session can run. Windows now ships an OpenSSH server too; for cross-platform tooling SSH to Windows is a reasonable alternative.
Not for non-domain hosts over plain HTTP with basic or NTLM authentication (credentials and commands are exposed), or application-level integration where the application has an API.
What it is. File transfer over an SSH connection. SFTP is a full remote filesystem protocol (list, rename, resume); SCP only copies.
Good for. Batch exchange of files with partners, banks and government portals, nightly exports and imports, moving backups between hosts.
Use it when the unit of exchange is a file and the other side runs an SSH server. Write to a temporary name and rename on completion so the receiver never picks up a half-written file; verify a checksum when the content matters.
Not for many small messages (use an API or a queue), shared access by several users at once (a network share or object storage), or anything where you need notification on arrival (add a webhook or poll on a schedule).
What it is. An HTTP API for storing blobs in buckets with a flat key namespace. The S3 API is the de facto standard, implemented by AWS, MinIO, Ceph, Backblaze and most others; Azure Blob and Google Cloud Storage have their own APIs plus S3-compatible layers. Requests are signed (SigV4 on S3) with an access key or a short-lived role credential.
Good for. Anything file-shaped at scale: backups, exports, build artifacts, media, data lake inputs, the payload side of a queue message, log archives. Durable, cheap, versioned, reachable from everywhere over HTTPS.
Use it when files must be shared between systems or sites, must survive any single host, or are too large for an API or a message. Use a bucket policy and an identity per connector (IAM role, workload identity, or a scoped access key), server-side encryption, versioning for anything you cannot regenerate, and pre-signed URLs to hand a single object to a third party without sharing credentials.
Not for workloads that need a POSIX filesystem (locking, partial writes, rename semantics), very small objects at very high rates (per-request cost and latency), or as a database.
What it is. A native driver connection to the database engine: psycopg for PostgreSQL, python-oracledb for Oracle, pyodbc or a TDS driver for MSSQL. Full SQL, transactions and the engine's own features.
Good for. Reporting and ETL, migrations, bulk loads, anything where the application owning the data has no API or the API is too slow for the volume.
Use it when you own the schema or have an agreement with whoever does, the connection stays inside a private network or uses TLS, and the account is read-only or scoped to the tables it needs. Use parameterised queries, connection pooling and timeouts.
Not for integrating with a third party's application database; you bypass its business rules, break when the schema changes, and the vendor will not support you. Use the application's API where one exists.
What it is. Standard database interfaces: JDBC for Java, ODBC for everything else. The application talks to one API and a driver translates it for the specific engine.
Good for. Java applications, BI and reporting tools (Power BI, Tableau, Excel), integration platforms that must support many databases through one code path.
Use it when the consuming tool only speaks JDBC/ODBC, or you need to swap database engines without rewriting the connector. Keep the driver version pinned and tested; driver upgrades change behaviour.
Not for engine-specific features (array types, listen/notify, bulk copy) that the standard interface hides; there a native driver is simpler.
What it is. A directory protocol for reading and writing users, groups and machines. Active Directory is Microsoft's directory, reachable over LDAP and LDAPS; Kerberos usually rides alongside.
Good for. Authenticating users against the corporate directory, resolving group membership for authorisation, provisioning and deprovisioning accounts, looking up contact details.
Use it when the organisation's identities live in AD or another directory and your system needs to honour them. Use LDAPS or StartTLS, bind with a service account that can only read what it needs, and cache group lookups briefly. For provisioning into SaaS, SCIM is the standard built for the purpose.
Not for modern web login flows (use SAML or OIDC in front of the same directory) or storing application data; a directory is optimised for reads and is not a database.
What it is. Network filesystems: SMB (CIFS) for Windows-style shares, NFS for Unix-style exports. Mounted, they look like local directories.
Good for. Shared document folders, scanner and printer drop folders, legacy applications that read and write files in a fixed path, home directories, media stores.
Use it when an application expects a filesystem and cannot be changed, or several machines need the same files with locking. Keep shares on the LAN or a VPN, never on the public internet, and use SMB 3 with signing or NFSv4 with Kerberos.
Not for cross-site or cloud workloads (latency and locking semantics suffer; use object storage), high-concurrency writes to the same file, or anything that must survive a share going away mid-operation.
What it is. The REST API of a cluster's control plane. Everything kubectl does is a call to it: list pods, apply a manifest, read logs, exec into a container. Authenticates with client certificates, bearer tokens (service accounts, OIDC) or a cloud provider's identity; authorises with RBAC.
Good for. Deployment tooling, operators and controllers, dashboards, cost and security scanners, an AI agent that needs to inspect workloads.
Use it when you need to read or change cluster state programmatically. Use a service account with an RBAC role limited to the namespaces and verbs required, short-lived tokens (bound service account tokens, OIDC), and the official client library for your language, which handles discovery, watches and retries.
Not for application-level integration (talk to the application, not to its pods), or anything granted cluster-admin "for now"; a connector with that role owns the cluster.
What it is. The REST API of a container host, served on the local Unix socket (/var/run/docker.sock) or on TCP (2375 plain, 2376 TLS). The docker CLI and Compose are clients of it.
Good for. Build agents, single-host deployment tools, monitoring agents that list containers, test harnesses that start throw-away services.
Use it when the target is one Docker host rather than a cluster. Prefer the local socket; if remote access is needed, use TLS with client certificates (2376) or tunnel over SSH (DOCKER_HOST=ssh://). Access to the API is root on the host, so mount the socket into a container only when that container is trusted as root, and consider a socket proxy that allows only the endpoints needed.
Not for plain TCP on 2375 (anyone who reaches the port owns the host), multi-host orchestration (Kubernetes or Swarm), or application integration.
What it is. The connector runs a command-line tool (kubectl, docker, terraform, the cloud vendor's CLI, a vendor utility) and parses its output, preferably in JSON.
Good for. Tools that have no API of their own, or whose CLI encodes a lot of logic you do not want to reimplement: Terraform plans, Helm releases, database dumps.
Use it when the tool is the official interface, you can pin its version, and it offers machine-readable output (-o json). Pass arguments as a list, never through a shell string, and set a timeout. Give the tool its credentials through its own secure mechanism (config file with restricted permissions, credential helper) rather than environment variables visible to every process.
Not for high call rates (process start-up is slow), tools whose output format changes between versions, or anywhere a proper API or SDK exists for the same operation.
What it is. Integration through the provider's own client library: AWS SDK (boto3), Azure SDK, Google Cloud client libraries, Stripe or Twilio packages. The SDK handles signing, retries, pagination and credential discovery.
Good for. Cloud platforms and large SaaS providers where the raw API is wide and the SDK encodes the conventions (request signing, waiters, resource models).
Use it when an official, maintained SDK exists in your language. Pin its version, use the credential chain it provides (instance roles, workload identity) instead of static keys, and wrap it so the rest of your system does not depend on the SDK's types.
Not for languages the provider does not support, environments where the dependency footprint matters, or cases where you need one call and the raw REST request is clearer.
What it is. Code written for one proprietary or in-house system: a binary protocol, a screen-scraped terminal, a mainframe transaction, a file-drop convention with a specific layout.
Good for. Internal applications and legacy systems that fit no standard type and will not be replaced soon.
Use it when nothing standard works, and only after checking whether the system has a hidden REST, SOAP or database path. Give it the same configuration fields and the same logging and retry behaviour as the standard connectors, so operators see no difference.
Not for anything a standard connector can reach, even imperfectly; custom code is the first thing to rot when the one person who wrote it leaves.
Types that turn up in connector catalogues without needing a full entry here:
| Connector | Where it fits | Example |
|---|---|---|
| Server-Sent Events (SSE) | One-way server-to-client stream over plain HTTP; simpler than WebSocket when the client never sends. Also the older MCP remote transport. | Progress feeds, LLM token streaming |
| AMQP / MQTT | The protocols behind RabbitMQ and IoT brokers; a message-queue connector with a specific wire protocol. MQTT for constrained devices and unreliable links. | IoT telemetry, sensor networks |
| SMTP / IMAP | Sending and reading email; authenticate with OAuth 2.0 where the provider supports it (Microsoft 365, Google), app passwords otherwise. | Notifications, ticket-by-email |
| SCIM | REST standard for provisioning users and groups into SaaS from an identity provider; the modern replacement for LDAP sync scripts. | Okta or Entra ID → SaaS |
| Kerberos / GSSAPI | Ticket-based authentication inside a domain; the method behind WinRM, SMB, NFSv4 and LDAP on Windows networks. | Active Directory environments |
| SNMP v3 | Reading and writing device metrics and configuration with authentication and encryption; v1 and v2c send the community string in clear text. | Network monitoring |
| Git protocol | Repository access over SSH or HTTPS; a specialised SSH or bearer-token connector. | GitOps, CI checkouts |
| FTPS | FTP over TLS; only for partners who cannot move to SFTP. Plain FTP is not an option. | Legacy file exchange |
Protocol-level connectors side by side. Security assumes the transport is used as described in the entry (TLS on, keys not passwords); complexity is the effort to build and operate the connector; latency is per operation.
| Connector | Security | Complexity | Latency | Best for | Avoid when |
|---|---|---|---|---|---|
| MCP | Depends on tools exposed | Medium | Medium | AI agents calling tools | No model in the loop; high volume |
| REST | Good | Low | Low-medium | CRUD against SaaS and internal APIs | Server-initiated events; deep object graphs |
| SOAP | Good with care (XML parsing) | High | Medium | SAP, Oracle, government endpoints | New APIs; bandwidth-sensitive clients |
| GraphQL | Good | Medium | Low-medium | Connected data in one round trip | Simple CRUD; file uploads; URL caching |
| gRPC | Good | Medium | Low | Service-to-service, streaming | Browsers, third parties, HTTP/2-hostile proxies |
| WebSocket | Good (wss) | Medium | Very low once open | Live two-way sessions | Occasional requests; fan-out across services |
| Webhook | Good only with signature check | Low | Seconds (provider-driven) | Reacting to provider events | Guaranteed delivery or ordering needed |
| Message queue | Good with TLS and ACLs | High (a broker to run) | Milliseconds to seconds | Decoupling, bursts, replay, fan-out | Synchronous answers; tiny integrations |
| SSH | Good with keys | Low | Low | Commands on Linux hosts, tunnels | Structured data exchange; Windows |
| WinRM | Good with HTTPS or Kerberos | Medium | Medium | Windows administration | Plain HTTP outside a domain; app integration |
| SFTP | Good | Low | Batch | Files to partners and banks | Many small messages; concurrent shared access |
| Object storage | Good with IAM and encryption | Low | Low-medium per object | Files at scale, between sites and systems | POSIX semantics; tiny objects at high rates |
| Database direct | Depends on account scope | Low | Very low | Reporting, ETL, bulk loads on your schema | Someone else's application database |
| JDBC / ODBC | Depends on account scope | Low | Very low | BI tools, Java, multi-engine code | Engine-specific features |
| LDAP / AD | Good with LDAPS | Medium | Low | Users, groups, directory auth | Web login flows; application data |
| SMB / NFS | Good only on SMB 3 / NFS v4 + Kerberos, inside the LAN | Low | Low on LAN | Legacy apps that need a filesystem | Cross-site, cloud, high-concurrency writes |
| Kubernetes API | Good with scoped RBAC | Medium | Low | Deployment tooling, operators, inspection | Application-level integration; cluster-admin |
| Docker Engine API | Root on the host; socket or TLS only | Low | Low | Build agents, single-host deploys | TCP 2375; multi-host orchestration |
| CLI connector | Depends on argument handling | Low | High (process start) | Tools with no API, JSON output | High call rates; unstable output formats |
| SDK connector | Good with workload identity | Low-medium | Low | Cloud platforms, wide APIs | Unsupported languages; one-off calls |
| Category | Types |
|---|---|
| Integration / communication | MCP, REST, SOAP, GraphQL, gRPC, WebSocket, SSE, webhook, message queue (AMQP, MQTT, Kafka) |
| Authentication | Username/password, API key, bearer token, JWT, OAuth 2.0, OIDC, SAML, SSH key, mTLS, Kerberos |
| Data access | Database direct, JDBC, ODBC, object storage, LDAP, SMB, NFS, SFTP |
| Infrastructure / execution | SSH, WinRM, CLI, SDK, Kubernetes API, Docker Engine API |
Rated at the three levels from the start of the page. A protocol can be sound while the authentication is weak or the configuration undoes it; most incidents are in the third table.
| Transport | Rating | Why | Use instead |
|---|---|---|---|
| Telnet, FTP, plain HTTP, SNMP v1/v2c, Docker API on TCP 2375, WinRM over HTTP without Kerberos | Do not use | Credentials and data cross the network in clear text, or the port gives root to anyone who reaches it. Still found on network gear, printers, old appliances and lab hosts. | SSH, SFTP or FTPS, HTTPS, SNMP v3, Docker over TLS or SSH, WinRM over HTTPS or Kerberos |
| SMB 1, NFS v3 without Kerberos | Weak | SMB 1 is the WannaCry protocol; NFS v3 trusts the client's claimed user ID. Both are open to anyone on the segment. | SMB 3 with signing and encryption, NFS v4 with Kerberos, or object storage |
| LDAP without TLS | Weak | The bind password travels in clear text on every connection. | LDAPS or StartTLS, Kerberos where available |
| SOAP, XML-based protocols | Needs care | XML parsers add attack surface (XXE, entity expansion); legacy endpoints often accept HTTP. | HTTPS, parser with external entities disabled, WS-Security or mTLS |
| SSH, SFTP, HTTPS (REST, GraphQL, SOAP over TLS, object storage), gRPC, WebSocket (wss), WinRM over HTTPS, Kubernetes API, message brokers with TLS | Good | Encrypted and authenticated transport. What goes wrong is in the next two tables. | — |
| Method | Rating | Why | Use instead |
|---|---|---|---|
| Direct username / password (basic auth, DB password, SMB password) | Weak | Long-lived, shared with a human login, cannot be scoped, breaks on rotation; guessable. | API key with scopes, OAuth 2.0 client credentials, JWT from an identity provider, Kerberos |
| SSH password | Weak (operationally) | The session is still encrypted; the problem is brute force on any reachable port, no scoping to a command or source, no attribution to a tool. | SSH key with authorized_keys restrictions, or SSH certificates |
| Static API key | Needs care | Never expires on its own; one leak is a permanent leak until someone rotates it. | Scoped keys with a rotation schedule; OAuth client credentials or workload identity where the provider offers them |
| Long-lived bearer token / JWT | Needs care | A JWT cannot be revoked before expiry; a leaked token is valid for as long as it lives. An opaque token is revocable, but only if someone notices. | Short lifetimes with refresh, audience and issuer checks, key rotation |
| Static cloud access keys (AWS access key id/secret, service account JSON) | Needs care | The single most common credential found in leaked repositories. | Instance roles, workload identity federation, short-lived STS credentials |
| OAuth 2.0 / OIDC, SAML, mTLS, SSH key or certificate, Kerberos | Good | Scoped, expiring or revocable credentials with identity managed in one place. Complexity is the main risk: misconfigured redirect URIs, missing audience checks, an expired client certificate. | Follow the provider's hardening guide, test revocation and renewal |
| Setting | Rating | Why | Do this |
|---|---|---|---|
ssl_verification: false | Do not ship | Turns HTTPS into HTTP with extra steps; added "temporarily" for a self-signed certificate and never removed. | Point the connector at the right CA bundle |
| API key or token in a URL query string | Weak | Lands in web server logs, proxy logs, browser history and referrer headers. | Send it in a header |
| Secrets inline in the connector configuration | Weak | Configuration gets committed, backed up, pasted into tickets. | credentials_reference into a secrets store |
| Database account with full schema rights; direct connection to a third party's application database | Risky | Bypasses the application's rules and audit; a wide account exposes everything; a schema change breaks you silently. | The application's API; otherwise a read-only account limited to a view |
| SQL or commands built from strings | Risky | SQL injection and command injection whenever input reaches the query or the command line. | Parameterised queries; argument lists without a shell |
| Webhook endpoint without signature verification | Risky | Anyone who finds the URL can send fake events. | Verify the HMAC signature, allow-list sources, idempotent handlers |
| MCP server with broad or destructive tools | Risky | The model can be talked into calling any tool it sees (prompt injection); a "run shell" or "write file" tool is a remote shell for whoever controls the input. | Narrow, read-mostly tools; per-tool permissions; human confirmation for destructive ones; no secrets in tool results |
Kubernetes service account with cluster-admin; Docker socket mounted into untrusted containers | Risky | The connector owns the cluster or the host. | Namespaced RBAC role with the verbs needed; socket proxy or rootless Docker |
| No timeout, unlimited retries | Risky | One slow dependency takes the whole integration layer down; retries amplify an outage into a flood. | Connect and read timeouts on every connector, bounded retries with back-off that honour Retry-After |
| No audit log of connector calls | Risky | You cannot answer "what did the agent do yesterday" or prove it to an auditor. | Log connector, operation, principal, outcome and duration for every call |
Two rules cover most of these tables: never carry a credential in clear text (TLS or SSH everywhere, keys in headers not URLs, secrets by reference), and never give a connector more than it needs (a key instead of a password, a scope instead of a whole account, a read-only view instead of a schema, a narrow tool instead of a shell).
Put one layer between the callers and the connectors. It owns registration, configuration, credentials, permissions, retries, rate limits, health and audit, so every connector behaves the same way and a new one is a plug-in rather than a project.
Applications / AI agents / automation
|
v
+---------------------------------------------------------------+
| Connector manager |
| |
| Registry ........ which connectors exist, their types, versions
| Authentication .. picks the method per connector, refreshes tokens
| Secrets ......... resolves credentials_reference, rotates on schedule
| Permissions ..... which caller may run which operation on which connector
| Retries / limits back-off, Retry-After, per-connector rate limits
| Health checks ... periodic probe per connector, circuit breaker on failure
| Audit / metrics . every call: who, what, outcome, latency; counters per connector
| Lifecycle ....... register, enable, test, disable, retire; config versioning
+---------------------------------------------------------------+
| | | | | |
v v v v v v
MCP / API SSH / CLI DB / Webhooks Messaging Custom
(REST, (WinRM) storage (in/out) (queues)
gRPC, SOAP) (SQL, S3)
| | | | | |
v v v v v v
External systems / infrastructure
The lifecycle matters as much as the boxes: a connector is registered with its configuration, tested against the target before it is enabled, probed by a health check while it runs, disabled automatically after repeated failures or on a rotated secret that no longer works, and retired with its audit history kept. Every state change is itself an audit event.
| Field | Description |
|---|---|
connector_id | Stable identifier used in logs, permissions and audit; never reused |
connector_name | Human-readable name |
connector_type | What it talks to: Jira, PostgreSQL, Linux host, S3 bucket |
transport_type | The protocol: REST, gRPC, SSH, JDBC, S3 API, MCP |
endpoint | Server URL, host name or connection string, without credentials |
authentication_type | Password, API key, OAuth client credentials, SSH key, mTLS: the credential, chosen independently of the transport |
credentials_reference | A reference into the secrets store, never the secret itself |
secret_rotation_policy | How often the credential is rotated and whether rotation is automatic |
timeout | Connect and read timeouts; no connector runs without one |
retry_policy | Attempts, back-off and which errors are retried |
rate_limit | Maximum calls per interval towards this target |
ssl_verification | Certificate verification on, with an explicit CA bundle where needed |
proxy_configuration | Outbound proxy or bastion for this connector, if any |
permissions | Allowed operations and scope: read-only, which tables, which paths, which commands; and which callers may use the connector |
enabled | Whether the connector may be used at all |
audit_enabled | Whether calls are logged in detail (default on; off only for high-volume read-only connectors with a reason) |
connection_status | Result of the last health check: healthy, degraded, failed, disabled |
last_success_at / last_error | When the connector last worked and what the last failure was; the first thing an operator looks at |
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Connector",
"type": "object",
"required": ["connector_id", "connector_type", "transport_type", "endpoint",
"authentication_type", "credentials_reference", "timeout", "enabled"],
"additionalProperties": false,
"properties": {
"connector_id": {"type": "string", "pattern": "^[a-z0-9][a-z0-9-]{2,63}$"},
"connector_name": {"type": "string", "maxLength": 120},
"connector_type": {"type": "string"},
"transport_type": {"type": "string", "enum": ["mcp", "rest", "soap", "graphql", "grpc", "websocket",
"webhook", "amqp", "kafka", "mqtt", "ssh", "winrm", "sftp", "s3", "jdbc", "odbc",
"db_native", "ldap", "smb", "nfs", "kubernetes", "docker", "cli", "sdk", "custom"]},
"endpoint": {"type": "string", "not": {"pattern": "://[^/]*:[^/]*@"}},
"authentication_type": {"type": "string", "enum": ["none", "password", "api_key", "bearer_token", "jwt",
"oauth2_client_credentials", "oauth2_authorization_code", "saml", "mtls",
"ssh_key", "ssh_certificate", "kerberos", "cloud_identity"]},
"credentials_reference": {"type": "string", "pattern": "^(vault|aws-sm|azure-kv|gcp-sm)://"},
"secret_rotation_policy": {"type": "object", "properties": {
"every": {"type": "string", "pattern": "^[0-9]+[hdw]$"},
"automatic": {"type": "boolean"}}},
"timeout": {"type": "object", "required": ["connect"], "properties": {
"connect": {"type": "string"}, "read": {"type": "string"},
"command": {"type": "string"}, "query": {"type": "string"}}},
"retry_policy": {"type": "object", "properties": {
"attempts": {"type": "integer", "minimum": 0, "maximum": 10},
"backoff": {"type": "string", "enum": ["none", "fixed", "exponential"]},
"retry_on": {"type": "array", "items": {"type": "integer"}},
"honour_retry_after": {"type": "boolean"}}},
"rate_limit": {"type": "string", "pattern": "^[0-9]+/(s|min|h)$"},
"ssl_verification": {"type": "boolean", "const": true},
"proxy_configuration": {"type": "object"},
"permissions": {"type": "object"},
"enabled": {"type": "boolean"},
"audit_enabled": {"type": "boolean", "default": true},
"connection_status": {"type": "string", "enum": ["healthy", "degraded", "failed", "disabled"], "readOnly": true},
"last_success_at": {"type": "string", "format": "date-time", "readOnly": true},
"last_error": {"type": "string", "readOnly": true}
}
}
Two deliberate constraints: ssl_verification can only be true, and endpoint rejects a user:password@ in the URL. Validate with the AI Response Validator on this site or any JSON Schema library.
The same field set across four transports. Secrets are references; nothing here is a credential.
connectors:
- connector_id: mcp-jira-01
connector_name: Jira tools for the support agent
connector_type: jira
transport_type: mcp
endpoint: https://mcp.internal.example.com/jira
authentication_type: oauth2_client_credentials
credentials_reference: vault://connectors/mcp-jira-01/client
timeout: { connect: 5s, read: 30s }
retry_policy: { attempts: 3, backoff: exponential, retry_on: [429, 502, 503, 504] }
rate_limit: 60/min
ssl_verification: true
permissions:
tools_allowed: [search_issues, get_issue, add_comment]
tools_confirm: [transition_issue] # human approval before the call
callers: [support-agent]
enabled: true
- connector_id: rest-github-01
connector_type: github
transport_type: rest
endpoint: https://api.github.com
authentication_type: bearer_token # fine-grained PAT, opaque
credentials_reference: vault://connectors/rest-github-01/token
secret_rotation_policy: { every: 90d }
timeout: { connect: 5s, read: 20s }
retry_policy: { attempts: 4, backoff: exponential, honour_retry_after: true }
permissions: { methods: [GET], paths: ["/repos/acme/*"] }
- connector_id: ssh-web-prod
connector_type: linux_host
transport_type: ssh
endpoint: web-01.prod.example.com:22
authentication_type: ssh_certificate
credentials_reference: vault://ssh/ca/web-prod # short-lived cert signed per session
proxy_configuration: { jump_host: bastion.prod.example.com }
timeout: { connect: 10s, command: 120s }
permissions:
user: deploy
commands_allowed: ["systemctl restart app", "journalctl -u app *"]
audit_enabled: true
- connector_id: pg-reporting-ro
connector_type: postgresql
transport_type: jdbc
endpoint: jdbc:postgresql://db-ro.prod.example.com:5432/erp?sslmode=verify-full
authentication_type: password # the only thing this engine offers
credentials_reference: vault://db/erp/reporting_ro
secret_rotation_policy: { every: 30d, automatic: true }
timeout: { connect: 5s, query: 60s }
rate_limit: 10/s
permissions: { role: reporting_ro, schemas: [reporting] }
And the same REST connector exercised by hand, which is what the health check does:
curl -sS --max-time 20 \
-H "Authorization: Bearer $(vault kv get -field=token connectors/rest-github-01)" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/rate_limit