Power Platform Custom Connector Security Assessment Scope

A Power Platform custom connector wraps an API so Power Apps, Power Automate or Copilot Studio can call its operations. Microsoft says the connector can point to a public or private API and can use authentication methods including OAuth and Microsoft Entra ID. That makes a custom connector a business data path, not merely a reusable button in a maker interface. Microsoft Learn, Custom connectors overview

Quick answer. Scope a custom connector security assessment from the app or flow, through its saved connection and connector definition, to the underlying API. Prove which identity the connection actually uses, which records and tenants it can reach, and which data policy actually governs the path. Stingrai can quote a human-led API, application and cloud assessment around these customer-owned components.

Enterprise buyers often ask whether the connector is “secure” without naming what that means. A connector might have a well-configured OAuth registration but call an API that does not check record ownership. Another might enforce API authorization, yet the team has not documented which connection the app or flow uses at runtime. A tenant may have an advanced connector policy yet still govern custom connectors through classic data policies. The right test distinguishes those questions and identifies the owner of each control.

The path a buyer needs to map

Start with the business process that uses the connector. Name the Power App, flow or agent, the environment where it runs, the person or automation that can trigger it, the saved connection used at runtime, the custom connector definition, and the API endpoint. Microsoft describes a connection as a saved credential stored in the environment that hosts the app or flow. That connection is a different object from the connector definition and from the API's own authorization rules. Microsoft Learn, Data policies

For each sensitive operation, ask what the caller is allowed to do. Can a claims processor retrieve only the claim assigned to that processor? Can a support flow update a synthetic customer record, while a different flow or business unit is denied? Can a read-only app trigger a write operation through the same connection? These examples are test-planning questions, not claims about a particular deployment. Replace them with customer-owned records and endpoints in the signed scope.

An assessment can include both design review and controlled execution. The design review identifies the declared scopes, connection owners, policy classifications and API rules. The execution phase runs positive and negative cases with synthetic records. A policy screenshot alone cannot prove the API's record decision; an API denial alone cannot prove that data cannot move through a different app or connector route.

Figure 1: The control layers a buyer should ask a tester to follow. This editorial model is based on Microsoft's connector, data policy and security testing documentation cited below.

Test the identity at each handoff

Microsoft lists Microsoft Entra ID, generic OAuth, Basic authentication and API keys among supported connector authentication methods, and recommends Entra ID for APIs and connectors. The actual customer design matters more than the label “OAuth enabled.” Microsoft Learn, Custom connectors overview The SOW should state whether the underlying API sees the end user's delegated identity, a connection owner's identity or an application identity, and how that identity maps to records in the target system. Ask the vendor to verify the configured method instead of assuming it from the connector name.

Do not infer a shared connection from a shared app. Microsoft says that when a canvas app using a custom connector is shared, the connector is shared but each user must create a connection. Other app, flow or intermediary designs need their own runtime identity review. Microsoft's custom connector FAQ also says the OAuth client credentials grant type is not supported, so a vendor should not assume that a custom connector itself uses that grant. Microsoft Learn, Share resources used by canvas apps Microsoft Learn, Custom connector FAQ

The assessment should identify the actual principal seen by the target API for each in-scope path and check how the initiating user's entitlements are enforced when business rules require them. A positive test should show an authorized synthetic user completing a harmless operation. A negative test should show a lower-privilege or different-business-unit user being denied the neighboring operation. Record whether the denial came from the app, the connection behavior or the API. This distinction determines which team can fix the issue.

Ask to inspect each operation the connector exposes, not only the operation the most popular flow uses. A custom connector can define multiple triggers and actions. A dormant write action might become available to a new maker even when current flows call only a read action. Microsoft's overview describes connectors as reusable definitions with triggers and actions, so the inventory should compare the published definition with the business-approved API surface. Microsoft Learn, Custom connectors overview

For an OAuth connector, confirm the redirect URI and registration that the current connection actually uses. Microsoft says OAuth custom connectors use a per-connector redirect URI and explains how older custom connectors using a global redirect URI were migrated or stopped creating new connections after the change. The buyer should ask the owner to identify legacy registrations and remove obsolete redirect URIs only after verifying the live connections. This is a configuration and migration check, not a reason to rotate credentials blindly during a penetration test. Microsoft Learn, Custom connectors overview

Check the classic data policy that applies to the connector

Power Platform data policies classify connectors as Business, Non-Business or Blocked. Microsoft says connectors in different groups cannot be combined in an app or flow, while connectors within the same group can share data. That is a governance boundary on connector combinations, not a substitute for API authorization. Microsoft Learn, Connector classification

The custom connector needs its own classification review. Microsoft documents environment-level classification of individual custom connectors by name and tenant-level classification through host URL patterns. A buyer should collect the tenant policy, the relevant environment policies, the connector's configured host and the resulting effective group. Then ask for one permitted and one denied app or flow combination in a controlled environment. The evidence should say which policy was evaluated and which operation was blocked, rather than merely listing the policy's name. Microsoft Learn, Data policies for custom connectors

Microsoft's custom connector policy page notes two details that change a test. A tenant-level Ignore * rule can defer classification to other policies, and if no specific rule exists it can allow custom connectors to be used with both Business and Non-Business groupings. The page also says policy evaluation happens before the use of Set Host URL, which can dynamically change a connector's destination. For an enterprise with dynamically selected endpoints, review the actual approved endpoint set and the host-selection design in a safe customer-owned environment. Do not infer that one policy pattern covers every runtime destination. Microsoft Learn, Data policies for custom connectors

The buyer should ask for an explicit negative case: could a maker in the test environment pair this custom connector with a connector the business classifies in a conflicting group? If the policy is supposed to block that combination, prove the denial at design time or runtime as appropriate to the actual policy. Use a nonproduction flow and synthetic data. A test that saves or runs a real production flow merely to prove a policy point may be unnecessary and disruptive.

Avoid a false sense of coverage from advanced connector policies

Microsoft's advanced connector policies are designed for certified connectors with an allowlist model. Its current documentation says custom and HTTP connectors are not yet supported and should continue to be governed through classic data policies. The same page describes mixed mode, where ACP and classic policies both evaluate, and ACP-only mode, where classic data policies are ignored for the affected scope. Microsoft Learn, Advanced connector policies

This distinction belongs in the buyer's evidence packet. A screenshot of an ACP allowlist is not proof that a custom connector was classified. Ask the Power Platform administrator to state which policy model currently governs custom connectors in each environment and whether a migration changed that model. Where ACP-only mode is used, require an explicit explanation of how custom connector governance is intended to work in that environment; do not infer the answer from ACP's certified connector rules. The vendor should report the observed policy behavior and any gap against the customer's intended restriction, without claiming that every tenant has the same exposure.

This table should become a scoped verification plan, not a promise that a policy configuration by itself prevents every path to the underlying API. Users may access that API through other applications or credentials. The custom connector assessment answers what happens through the named Power Platform path and the customer-owned API endpoints in scope.

Treat tenant isolation as conditional on authentication

Microsoft says Power Platform tenant isolation applies to connectors using Microsoft Entra ID-based authentication. It does not act as an Entra-wide tenant restriction, and it does not cover every custom connector merely because that connector runs in Power Platform. Microsoft Learn, Cross-tenant restrictions

The SOW should ask whether the specific custom connector uses Entra authentication and whether its target API permits cross-tenant connections. For an Entra-authenticated connector where tenant isolation is in scope, identify the direction of an expected allowed or denied connection and any tenant allowlist entry. Use a customer-owned test tenant or another explicitly authorized environment. For a connector using a different authentication method, test the underlying API's tenant and record authorization directly; do not present Power Platform tenant isolation as a control that necessarily applies.

Separate the tenant of the Power Platform environment, the tenant of the identity used for the connection, and the tenant represented by the data in the target API. These may be related, but they are not always identical business boundaries. A report that says “cross-tenant protected” without naming which connection and data boundary was observed is hard for a security leader to act on. Ask for the exact principal, destination and expected business rule in each test case.

Assess the API operation, not just its wrapper

The connector can specify the route and authentication method, but the API decides whether the caller may read or change the requested resource. A useful API test starts with a permitted synthetic object and a neighboring object the same caller should not reach. It then checks the result through the connector and, where authorized, directly against the customer-owned API. This comparison tells the team whether the access rule lives in the API or only in a flow that could be changed later.

Ask for checks of input validation, error handling, sensitive response fields and operation-level authorization when those are relevant to the exposed actions. A connector that exposes an API's administrative route in its definition creates a different procurement question from one that offers only a narrow read-only endpoint. The report should map each significant action to its backend route and required role. A test on one action does not establish that all actions are safe.

Where the connector reaches a private API through a gateway or an Azure service, add the gateway or cloud identity to the inventory. Stingrai's cloud penetration testing service covers cloud control-plane and workload paths, while its API service covers authentication, authorization and business logic. The SOW should say whether the engagement includes these surrounding components or only the Power Platform configuration and API interface. This prevents a quote for a connector review from being mistaken for an assessment of the entire cloud estate.

Write the rules of engagement around customer-owned assets

Microsoft's Power Platform security testing guidance recommends structured, repeatable testing and says organizations may perform their own penetration tests under the Microsoft Cloud Penetration Testing Rules of Engagement. It also warns that the cloud has shared infrastructure and testing must remain limited to the customer's assets. Microsoft Learn, Recommendations for security testing

For this assessment, the rules should name the tenant and environments, connector definition, app or flow versions, allowed test accounts, API endpoints, synthetic records, request budget, monitoring contact and stop condition. Identify any third-party API or managed gateway separately; the customer's permission to test its app does not automatically authorize testing a supplier's infrastructure. Prefer an isolated environment that reproduces the relevant policies and connection behavior. If a production-only configuration must be checked, define a low-impact observation and who will watch it.

The data-handling section should say how the provider will store policy exports, connection configuration, sanitized API requests and screenshots. Avoid sending live credentials in the engagement brief or final report. A connection inventory can identify the credential type and owner without copying the secret itself. Ask the provider to preserve enough evidence to retest a policy or authorization finding without retaining unnecessary business records.

What a useful quote and final report look like

A strong quote lists the exact connector and environment count, the app or flow entry points, the authentication modes, the underlying APIs, and the sensitive operations to be tested. It includes positive and negative cases across user, record and policy boundaries. It states whether cloud identity and gateway configuration are included and how retesting will be handled. A vague line item for “Power Platform pentest” leaves too many decisions until after the contract is signed.

The report should separate four kinds of findings: an app or flow design issue, a saved connection or sharing issue, a connector or policy issue, and an API authorization issue. Those categories map to different owners. For each confirmed issue, include the affected operation, expected and observed decisions, relevant principal, synthetic record, business consequence, remediation owner and a safe retest. If a policy was present but not applicable to the connector type, make that limitation explicit. A clean API response does not prove the data policy worked, and a blocked app design does not prove the API enforced the user's rights.

The buyer should also ask for a concise evidence summary that can be shared with internal security and procurement. It should list what was tested, what was excluded, and which controls were observed. Microsoft recommends evaluating test results and feeding them back into the workload's security process. Microsoft Learn, Recommendations for security testing The report can support the buyer's compliance program and audit evidence without suggesting the test itself grants a certification.

Make a launch decision from the observed boundaries

Before approving a production rollout, the owner should review a short decision record, not only a list of vulnerabilities. It should state which apps and flows can call the connector, which identity each connection uses, which actions are exposed, and whether the underlying API allowed and denied the intended synthetic records. A finding that a user can invoke a connector operation they do not need may be an app or connection sharing problem. A finding that the API accepts a neighboring record under the same principal is an API authorization problem. Both can matter, but they require different remediation and retest owners.

For a data policy concern, ask whether the policy result was observed in the environment that will host the production workload. A nonproduction environment can be safer for testing, yet its policies, connector classification or saved connections may differ. Microsoft recommends dedicated test environments while cautioning that nonproduction can diverge from production configuration. Microsoft Learn, Recommendations for security testing Record the relevant difference and decide whether a low-impact production observation is necessary before launch.

The decision record should also identify any untested dependency. If the connector calls a vendor-operated API, the penetration test may be limited to the customer's connector configuration and integration behavior. If a cloud gateway or on-premises data gateway is out of scope, say so. This is more useful than a blanket “pass” because the next architecture change can be matched to the specific control that needs retesting. A new API operation, authentication method, runtime host or environment policy may reopen a boundary even if the original tested flow continues to work.

Finally, assign a retest trigger. A custom connector is often reused as business processes change. Ask the platform team to keep the connector's owner, host, supported operations and data policy classification in a maintained inventory. Ask the API owner to notify that team when an operation's authorization behavior changes. This gives the security leader a reasoned point to commission another targeted test, rather than waiting for a generic annual review to discover that a new flow crossed a sensitive boundary.

Where Stingrai fits

Stingrai is a CREST-accredited penetration testing service provider. Its human-led API penetration testing, web application testing and cloud testing can be combined around an authorized custom connector path. The scope can follow the app or flow through its saved connection, customer-managed API and cloud identity, then deliver confirmed findings and a retest. A one-time assessment can answer a launch or procurement question; an annual or continuous program can revisit connectors as environments, policies and API operations change.

This is a custom-scoped engagement. The buyer should bring the connector inventory, a diagram of its target APIs and the current policy modes to the Get a Quote form. The resulting SOW should say which assets are included before any testing begins.

Frequently Asked Questions

What should a Power Platform custom connector security assessment cover?

It should test the app or flow entry point, saved connection identity, connector operations, applicable classic data policies and the underlying API's authorization. Require allowed and denied cases on synthetic records and a report that identifies the control owner for each result.

Do advanced connector policies cover custom connectors?

No. Microsoft's current documentation says advanced connector policies apply to certified connectors and do not yet support custom or HTTP connectors. Classic data policies remain the documented governance route for those connector types.

Does Power Platform tenant isolation protect every custom connector?

No. Microsoft says Power Platform tenant isolation works only for connectors using Microsoft Entra ID-based authentication. The assessment should verify the connector's authentication method and test the underlying API's tenant rules where that platform control does not apply.

Is a data policy enough to prove the API is secure?

No. Data policies govern connector combinations and destinations, while the underlying API must make its own user, operation and record authorization decisions. Test both boundaries with approved and denied cases.

Can we test a connector that points to a third-party API?

Test the customer-owned connector and app or flow under an agreed scope, and obtain the API owner's authorization before testing the third-party service. The SOW should identify each endpoint, tenant and environment that may receive test traffic.

What evidence should the vendor deliver?

Ask for the connection and policy inventory, identity and API mapping, positive and negative test results, sanitized requests, effective policy evidence, remediation owners and a retest of each confirmed finding.

Related reading

• Microsoft 365 Copilot connector permission testing

• Dataverse application user security assessment

• SaaS OAuth connected app penetration test scope

• Multi-tenant SaaS penetration test scope

References

1. Microsoft Learn, Custom connectors overview.

2. Microsoft Learn, Data policies.

3. Microsoft Learn, Connector classification.

4. Microsoft Learn, Data policies for custom connectors.

5. Microsoft Learn, Advanced connector policies.

6. Microsoft Learn, Cross-tenant restrictions.

7. Microsoft Learn, Recommendations for security testing.

8. Microsoft Learn, Share resources used by canvas apps and Custom connector FAQ.

Talk to Stingrai

Share the connector and API inventory through Get a Quote, or book a free discovery call to agree on the authorized test boundaries.