Hi Jonas, and welcome to the community!
This is a noble challenge, however, it requires some deep thought to achieve the stated requirement. The deepest of the thought is central to what Airtable requires in an automated process, not so much what users require.
When Airtable is presented with a URL, it uses that endpoint to retrieve a document (like an image, or a PDF, etc). In that process, Airtable has no understanding of a security context unless, of course, it is already established in the context of your browser when performing attachment additions manually.
Making attachments automatically is a completely different security climate; there is no browser and the automated process can only hand-off to Airtable’s API URLs that are publically accessible. And the only option to make this work with attachment URLs that are private is a proxy that does possess the ability to establish a security context with the platform hosting the secure URLs (ergo, the platform possessing the private URLs must also provide a modern API).
I have created this approach many times but it’s complicated. The proxy must mimic (for Airtable’s benefit) document URLs that are (in fact) public. It must do this for a few seconds; long enough for Airtable to make a copy of the target URL and then immediately thereafter, it must invalidate that URL.
The Cat is Out of the Bag
And doing this makes the documents once protected by private URLs, suddenly publically accessible because Airtable attachments are open URLs; if you know the link, you can access the attachments.
