# External data source access controls

**URL:** <https://community.palantir.com/t/external-data-source-access-controls/6129>\
**Category:** Ask the Community\
**Tags:** ontology-management, osdk, security\
**Created:** [March 2, 2026, 4:42pm UTC](https://community.palantir.com/t/external-data-source-access-controls/6129 "2026-03-02T16:42:07Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Joel](https://yyz1.discourse-cdn.com/palantir/user_avatar/community.palantir.com/joel/32/3579_2.png) [@Joel](https://community.palantir.com/u/Joel)\
**Post date:** [March 2, 2026, 4:42pm UTC](https://community.palantir.com/t/external-data-source-access-controls/6129/1 "2026-03-02T16:42:08Z")

</div>

My organization maintains a dataset outside of Foundry of all users and their accessible data sources. This dataset has already been brought into Foundry via a data connection. What are the best practices for using this external resource to automatically manage data source access controls?

---

<div class="post-metadata">

**Author:** ![vedant\_sibyl](https://avatars.discourse-cdn.com/v4/letter/v/ee7513/32.png) [@vedant\_sibyl](https://community.palantir.com/u/vedant_sibyl)\
**Post date:** [March 3, 2026, 2:40pm UTC](https://community.palantir.com/t/external-data-source-access-controls/6129/2 "2026-03-03T14:40:03Z")

</div>

1 thing that comes to mind is **to**  **manage access through Multipass Groups, not directly on datasets** → keeps it clean and auditable

---

<div class="post-metadata">

**Author:** ![jakehop](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@jakehop](https://community.palantir.com/u/jakehop)\
**Post date:** [March 4, 2026, 12:05pm UTC](https://community.palantir.com/t/external-data-source-access-controls/6129/3 "2026-03-04T12:05:40Z")

</div>

Hi Joel,

Agree with the response above, and wanted to add a bit of implementation experience from workflows I’ve built:

1. **AD group management on projects**  
This works well when you have a relatively clean data access profile, and you store the data connector and everything else in there. The most straight forward solution.
2. **A central data ingestion project, managed by admins, which feed into other projects**  
This works well when your data access profile is messy, e.g. when certain rows need to be visible to certain people only.  
To solve for some of the complexity of this approach (or at least not complect it further), I built a management application in Workshop, which outputs a rules object type that are ingested by the transforms. This allows the data owners to map access rights on a group/user level.  
While Foundry UUIDs don’t translate back to your AD, you should be able to map these in Foundry. This allows you to easily map row-level access controls automatically or manually, depending on your use case.  
We also built a user-facing side of this, allowing users to request access, which streamlines the process and opens up the data landscape to the users on the platform, without revealing sensitive information.

Hope this helps!