Perplexity Agent API Connectors: What Can Shared Agents Access?

Perplexity's managed Agent API connectors let a project administrator configure an approved service connection once and make it available to Agent API requests. That can remove a repetitive setup step for each application. It also creates a security question that deserves an explicit answer before a team adds more callers: who can use that shared connector?

Perplexity's current connector documentation says any API key in the same Project can use a connector configured there. The API key still authenticates the Agent API request, while the connector holds the external service connection details. An application does not need to send the service's MCP token on every request. But the documented boundary is the Project, not an individual application. So the practical rule is: inventory every same-project API key and caller before you connect a service, then decide whether the project is the right trust boundary.

This is a different question from whether Profiles are useful. A Profile concerns the reusable configuration of a run. A connector concerns an agent's path into an external service. The two can be combined, but sharing a Profile does not define a per-app credential boundary, and centralizing a connector does not automatically make its permissions least-privilege. The September 28 news is valuable because these resources can be assembled together, yet the permission design remains the administrator's work.

The access decision: Perplexity documents connector availability at Project level: any API key in that Project can use its connector. Inventory those keys and callers, check the external account's actual scope, and test permitted and denied actions before production. The docs do not prove per-app isolation.

View image detail

A project administrator routes a shared connector through a permission gate to several apps; all are within one project boundary.

Actual size

Choose Actual size to read the graphic closely.

The access model in plain English

The current connector documentation describes a connector as an integration configured once on a Perplexity Project. An administrator chooses a managed service or registers a custom remote MCP server. Perplexity stores the connection settings and credentials. An application refers to the connector by ID when making an Agent API request. The app still authenticates with a Perplexity API key from the same Project.

The convenience is straightforward. Each application no longer needs to store and attach the remote MCP server's token on every request. The connector configuration has one project-level home. If the service connection changes, an administrator can manage it centrally instead of asking each application owner to wire it separately.

The boundary is equally straightforward and easy to miss in a “connect once” demo: any API key in that Project can use the connector. That does not mean every user in every company can use it. It means the scope of the Perplexity API key and project needs to be understood alongside the scope of the connected service account. A key created for an internal prototype is not magically restricted to a narrower application just because the application itself has a separate codebase.

That distinction is why “shared credentials” needs precise language. A connector avoids requiring each app to transport the external connector credential with every request, but it does not replace Perplexity request authentication or prove per-app isolation. The service account's exact permissions still depend on that integration and organization account.

View image detail

The credential path separates a Perplexity API key, a project-stored connector credential and the external service authorization.

Actual size

Choose Actual size to read the graphic closely.

What arrived, and how the catalog changed

Perplexity's September 28 announcement presents managed connectors as one part of a broader reusable layer for Agent API projects. The current list names GitHub, Slack, Google Drive, Datadog, Linear and Notion. The announcement labels managed connectors as preview. Current docs list the same six services.

Some older descriptions of the launch list only four integrations: GitHub, Slack, Google Drive and Datadog. That difference is temporal, not evidence that one of those lists is fabricated. Perplexity's API forum announced those first four in August. The current documentation and September announcement add Linear and Notion to the listed set. Skills also existed before September 28. The new September layer is not the first time teams could use Skills or any connectors; it brings Profiles and describes the composition of these resources as a reusable, project-level pattern.

The availability caveat matters if an article or implementation plan treats the list as a promise to every tenant. A service appearing in current documentation is not proof that it has been enabled for your project, that your workspace admin has approved it, or that a particular connector's tools expose the exact actions your app needs. Perplexity says project administrators configure managed connectors, and managed connectors are in preview. Check the live console and the current service-specific connector documentation before treating one as available in your environment.

The profile feature and connector catalog also have separate release states. Profiles and custom Skills are available now according to the announcement. Managed connectors are in preview. A team should not collapse these into one phrase such as “the new feature is generally available.” State the scope with the relevant component.

Why project scope changes the design conversation

Many teams organize API projects around billing, environments, or an application boundary. When a connector becomes available to any API key in that same project, that project's membership and keys become part of the connector's effective caller set. A design that was safe when a project only powered one server-side service could become broader if another service key is created and handed to a test environment or contractor.

This is not a claim that an unauthorized person automatically gains access to a connector. They still need the relevant API key and the connected service still has its own access control. The point is narrower: once a key from that Project is available to an application, the connector's project-level availability is relevant to what that key can request. If the same Project serves multiple unrelated apps, ask whether the shared connector should be available to all of them.

View image detail

Project membership and connected-service permissions are separate boundaries that must both be reviewed.

Actual size

Choose Actual size to read the graphic closely.

The connected identity matters too. If a connector is authorized with a broad service account, its reach may exceed what the agent's narrow task requires. If it is authorized with a carefully limited account, the potential effect may be smaller. The vendor documentation describes where the connector is configured and how calls reference it. It does not promise that every service offers a particular permission preset. It also does not say Perplexity can infer your desired minimum or that an agent will select only the tools you intended.

View image detail

Different connector actions carry different authority: reading context, drafting, human review and an approved write.

Actual size

Choose Actual size to read the graphic closely.

A practical access review should therefore cover both sides of the boundary. On the Perplexity side, identify the Project, every API key, the applications holding them, owners, environments and allowed connector use. On the external service side, identify the connected account, its repositories, channels, folders or workspaces, and whether its authorization includes read, write or administrative actions. A narrow Perplexity tool list cannot compensate for an external identity with unnecessary reach.

View image detail

A two-sided review joins the Perplexity Project and API keys to the external account's own permission scope.

Actual size

Choose Actual size to read the graphic closely.

A connector is an access path, not a task guarantee

A connector's presence in a request gives the agent an access path to some available service tools. It does not guarantee that the agent will call a tool when it should, understand every tool result, or refuse a request that falls outside your policy. Connectors are deferred-discovery by default in current docs: the agent can first search a connector's available tool catalog, then call a tool. That behavior is operationally useful, but it also makes a realistic test more than “the connector ID is in the JSON.”

Your application needs to handle three separate outcomes. The connector may not be available or the request may not be able to discover its tools. A tool call may execute and return incomplete or unexpected information. Or the tool can return a result that the agent misinterprets. Those failure modes differ. A caller that maps them all to “agent failed” makes it difficult to decide whether to retry, ask a human, or return a safe fallback.

Think carefully about write actions. If the connector exposes a tool that can modify an external system, the workflow should make the authorization and confirmation point explicit. For example, drafting a Slack message is different from sending one; listing repository issues is different from closing one. This is general design guidance, not a statement that every managed connector currently offers those exact tools or that Perplexity requires a confirmation step. Inspect the service's current tool catalog and set the application policy around actual actions.

A useful launch test includes both allowed and forbidden cases. Confirm the agent can retrieve an item it should see. Confirm that an unrelated project key cannot silently gain access by accident, if your architecture claims such separation. Try a disallowed action in a safe test environment and confirm the application refuses or requires approval. Then inspect what happened in the trace. A passing happy path says little about the boundaries.

A decision framework for administrators

Before connecting a service, draw a small map of the intended flow. Name the Project, the administrator who configures the connector, the service account used for the connection, the API keys that can call it, the applications where those keys are stored, and the users whose requests ultimately drive those applications. If any of those boxes has “everyone” or “we'll figure it out later” attached to it, pause and narrow the design.

Then ask whether the existing Project matches the set of applications that should share access. If it does, create a key inventory and ensure development, staging and production use distinct keys where your API key policy permits. If two applications should have genuinely different external access, do not assume that different code repositories create that separation. Evaluate separate Projects or another supported service-side permission boundary before attaching the connector. Confirm the consequence with current project/connector documentation, because names and access controls can change.

Next choose the narrowest service identity available. If the connected service permits access to one repository instead of an organization, one shared channel instead of all workspace messages, or one folder rather than the entire drive, grant the smaller scope when it supports the job. The examples are prompts for an access review, not claims about what every listed connector can configure today. Ask the service administrator to confirm the exact authorization scope visible in the consent screen.

Finally decide which tools the workflow actually needs. If an application only reads issue state, it should not add unrelated write actions just because the connector exposes them. If the API config allows tools to be attached at the Profile or request level, inspect the effective combination rather than assuming one layer replaces the other. Perplexity's connector docs show the connector entry is added to the Agent API tool list and note deferred tool discovery. Your own request construction and version control determine how it is combined with other runtime configuration.

View image detail

A permission review narrows service identity, project callers and selected connector tools before an agent is enabled.

Actual size

Choose Actual size to read the graphic closely.

Example: an incident-response helper

Consider a hypothetical software team that wants an assistant to gather context during a production incident. It might need monitoring data from Datadog, related code context from GitHub, and a prepared status update for a human to review. Slack might be part of that workflow too, depending on the exact tools and permissions available to the team. This example is an architecture exercise. It is not a Perplexity integration test or a claim that the connectors independently solve incident response.

The team should first define the user job: assemble evidence, cite where it came from, identify what is unknown, and prepare a draft update. It should explicitly state that the agent does not close issues, change code, page a customer or publish a status message without a person approving the action. That is a product-policy decision made by the team, not a connector default we can infer from a launch announcement.

Next the administrator should identify who can call the connector-backed Project. If a production API key and a developer sandbox key share the same Project, both can use the connector according to current docs. The team should decide whether that is intended. If not, separate the application/project boundary or revoke and recreate keys under the design it chooses. Keep the external connected identity as narrow as the service allows, especially if the agent can access production telemetry or private repositories.

Before rollout, make safe sample runs. Include an incident with complete information, one with a misleading alert, one where an expected GitHub issue is missing, and one containing an instruction embedded in untrusted issue text. Check whether the agent treats retrieved content as data rather than obeying instructions inside it. This is a general tool-use security test. The sources used for this article do not show that the Perplexity connector layer by itself mitigates prompt injection or enforces the team's action policy.

If the test succeeds, the output is still a proposal until a human checks source freshness and decides whether to send it. The team should save the trace, review the connected identity's permissions periodically, rotate API keys and connector credentials when policy calls for it, and revoke access when the use case ends. The central configuration helps administrators update a connection once. It also means an ownership change should trigger a review of every application that references the same project resource.

What the announcement does not establish

The launch post does not report a comparative security evaluation, connector uptime, task success rates, time saved, pricing for each integration or a general-availability date for managed connectors. It gives example workflows and says the project administrator can configure approved connections. Those examples demonstrate the intended shape of the product, not independently verified outcomes.

The docs describe the API key and project relationship, connector ID use, setup authority and current catalog. They do not tell us the exact permission semantics for every service account, how a customer's internal separation policy is configured, whether a particular project has the preview flag, or how each tool handles writes. Those are questions to ask in the API Console, the current service documentation and your own safe tests.

Independent coverage of the September announcement also remains mostly descriptive. Revenue Hub LatAm reported the six-service preview list and described the project-admin setup, but did not claim to have tested permission boundaries. The September 8 Perplexity API guide from Perplexity AI Magazine is useful architecture context for the Agent API, but it predates the new Profile announcement. Neither is evidence that a particular connector is safe or effective for your production workload.

A responsible recommendation can still be useful without pretending those gaps are closed. Treat the Perplexity Project as the shared connector boundary documented today. Inventory its API keys and applications, verify the connected account's scope, and test allowed and denied actions before production. NIST's February 2026 NCCoE concept paper frames identity and authorization for software and AI agents as an area under active study. NIST classifies it as an initial public draft, with the public comment period closed on April 2, 2026. It is not a Perplexity-specific control or final standard. Make the caller, connected identity, permitted actions and approval owner explicit in your own design.

View image detail

An evidence boundary separates documented connector behavior, independent summary and questions that require tenant testing.

Actual size

Choose Actual size to read the graphic closely.

The connector review checklist

Use this checklist with the service owner and application owner before adding a connector:

• What exact business task needs this service, and which data or actions are necessary?
• Is the connector managed or custom, and what is the current preview or availability state?
• Which Perplexity Project will own the connector?
• Which API keys from that Project exist, who holds them, and in what environments are they used?
• Which applications or jobs can send requests with each key?
• Which identity did the external service authorize, and what workspaces, repositories, folders or channels can it access?
• Does the application need read access only, or a specific write action as well?
• Can the service account or connector be limited more narrowly?
• Which connector tools are actually available when discovery runs?
• What is the human approval point for external changes?
• How are tool calls and results reviewed, logged and tied to a request?
• What is the revocation path if a key or account is exposed or the project no longer needs the service?

If you cannot answer the API-key inventory question, solve that before relying on the connector. Centralized connection settings reduce duplicated credential handling, but an unknown set of callers undermines the point of a deliberate shared boundary.

View image detail

The connector preflight ties the project admin, API-key inventory, connected identity and approval owner together.

Actual size

Choose Actual size to read the graphic closely.

FAQs

Which Perplexity Agent API connectors are currently documented?

The current connector docs and September 28 announcement list GitHub, Slack, Google Drive, Datadog, Linear and Notion. The announcement identifies managed connectors as preview. The listing does not prove each connector is enabled for every Project.

Who can use a Perplexity managed connector?

A Project administrator configures the service connection. Current docs say any Perplexity API key in the same Project can use that connector in Agent API requests. Therefore, review the keys and applications associated with that Project.

Does the application need to send the external connector token?

The docs say Perplexity stores connector settings and credentials for the Project, while an application references the connector by ID. The application still authenticates its Agent API request with a Perplexity API key from the same Project.

Are connectors limited to read-only access?

Do not assume so. The available tools and service permissions depend on the particular connector and connected identity. Inspect the live tool catalog, consent scope and service-side permissions. The sources reviewed here do not provide one universal read-only guarantee.

Do managed connectors make the system secure automatically?

No such conclusion follows from the announcement or connector documentation. Centralizing credentials can reduce repeated app-side token handling, but the team still needs to manage API keys, Project membership, connected identities, tool scope, logging, approval and revocation.

Should every app use the same Project?

Only if they are meant to share the same project-level connector availability and governance. If unrelated applications need different external access, assess whether separate Projects or service-side scopes better match that boundary.

Decide what should be shared before you connect it

A managed connector centralizes setup, and that makes reuse easier. It also makes shared administration more important. Before attaching one, map the path from Perplexity Project keys to applications, the connected account and the available tool actions. Narrow that path wherever Project and service controls allow it, and put human approval before consequential writes. The launch materials describe a configuration model, not whether a particular tenant has the right scope or whether a workflow is safe. Verify the boundary in the current console, test allowed and denied actions, and record who can revoke the connection. Make that decision before reuse becomes routine.

For the separate versioning decision, see our companion guide to Perplexity Agent API Profiles. It explains what a pinned Profile controls and what it does not freeze. If you are comparing connected-agent permissions across products, our guide to Notion Agent MCP connections covers a related access-and-approval question. For application ownership and review responsibilities, see Should Your Team Build an Internal App with Copilot Code?. These pages address adjacent decisions; this article stays focused on Perplexity's Project-level connector boundary.