Someone else's automation runs with your credentials

Sharing protects the person sharing. It is the person importing who takes on something.

Every automation tool with a share feature has the same design. You export a workflow, the export strips your credentials, and what leaves is structure without secrets — the steps, their order, their configuration, with the connections replaced by placeholders. This is correct and necessary, and it means posting a flow publicly does not leak your keys.

The half that gets less attention is what happens at the other end. The recipient imports the file, connects their own accounts to the placeholders, and runs it. The flow now executes with their credentials, doing whatever it says.

Why this is not like installing a library

Package ecosystems have this problem too, and have built decades of defences: signing, registries, lockfiles, advisories, large numbers of eyes on popular packages. A shared workflow has none of that. It is a file in a forum post.

It is also, unlike most libraries, guaranteed to have credentials attached. That is the entire point of connecting it. A workflow with no access to your accounts does nothing useful, so the moment it is worth running, it is running with real authority.

What to actually look at

An exported flow is readable JSON. It is not pleasant reading, but it is short, and you only need to answer four questions.

What does it talk to

Find every step that makes an outbound request and read the destination. A generic HTTP step can point anywhere, and that is exactly what makes it useful and worth checking. A flow that claims to tidy a spreadsheet has no business posting to a host you do not recognise.

What does it send

Look at what is in the body of those requests. Data flowing outward from a step that has access to your records is the case that matters. Field names are usually enough to tell.

What does it delete or overwrite

Destructive operations are the ones you cannot walk back. A flow that writes is a flow that can write the wrong thing to the right place.

What is its schedule

A thing that runs every five minutes has a hundred times the opportunity of a thing that runs daily. Check the trigger before you check anything else, because it multiplies everything.

Run it small first

Reading catches the obvious. The rest is caught by not trusting your reading.

• Connect a test account rather than the production one, if you have both.
• Run it manually once and read the per-step output before enabling the schedule.
• Point it at a small slice of data the first time — a folder with three files, not three thousand.
• Leave the schedule off until a manual run has done something you can verify.

What we owe you here

Tool builders, ourselves included, tend to describe sharing in warm language and leave the import side implicit. That is a small dishonesty. The honest framing is that an export is safe for the author and an import is a decision by the recipient, and the interface should say so at the moment of importing rather than in a document nobody opens.

You would read a shell script before running it. This is a shell script with your API keys already in the environment.