For most engineering organizations, yes. An approved connector list limits where low-code apps can send data, and restricting custom connectors to a few trained people closes the easiest path for leakage. Keep the list short, publish the reason for each entry and offer a fast exception route.
What the guidance says
OWASP's advice for Sensitive Data Leakage (CD-SEC-04) includes limiting connectors to an approved services list, limiting creation of custom connectors to dedicated personnel and monitoring for data flow outside the organizational boundary, including multi-hop paths. For Authentication and Secure Communication Failures (CD-SEC-05) it adds limiting new connections in production to authorized people or teams.
The reason is that these platforms cannot classify data on their own. They do not know which field is personal data, so a connector to an unvetted service can move it without a warning.
Building the list in four steps
- Collect. Export the connectors already in use.
- Sort. Group them by what they touch: internal data, customer data, third party tools, personal accounts.
- Decide. Approve, approve with limits, or block. Note the data class each may carry.
- Publish. A one-page list with the reason and an owner for each entry.
Three categories that work
| Category | Examples of rules |
|---|---|
| Approved | Vetted business systems, allowed for stated data classes |
| Limited | Allowed only for non-sensitive data, or only with a service identity |
| Blocked | Personal storage and mail, unvetted file sharing and public paste tools |
Handling exceptions without a bottleneck
A list that blocks everything pushes people to workarounds. Offer a request form with a promised response time, and a quick check covering four questions: what data, what scope, who owns the connection, and what the vendor's security posture is.
Custom connectors
A custom connector is code in disguise. It defines how a platform talks to an API, and a poor one may disable certificate checks or send data over plain HTTP, which OWASP lists among its authentication failures. Restrict creation to people who can review them, and require an owner and a review date.
Watching for drift
An allowlist is only as good as its monitoring. Review connector usage reports monthly and look for new connectors, new tenants and spikes in volume. Also look at multi-hop flows, where an approved connector hands data to an unapproved one downstream.
For a related decision about new SaaS tools, see new SaaS tool approval security checklist.
Reviewing the list itself
Treat the list as a living document. Each entry should carry an owner, the data classes it may carry and a date it was last checked. Remove entries nobody uses, and re-check any vendor whose terms or ownership change. A list that only ever grows becomes an approval of everything, which is the opposite of its purpose. Once a year, ask whether each connector still earns its place.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply to software changes and AI agent actions in engineering workflows. Platform connector lists are configured in each platform. The free scan at https://gold.safeguard.sh/scan covers your repositories.
Quick check
Will an approved list slow the business down?
Not if exceptions are quick. The list should make the safe choice obvious, not stop work.
Who should be allowed to build custom connectors?
A small trained group who can review authentication, TLS settings and data handling.
Sources
Last reviewed: 19 October 2026.
