Automation Security for Business Owners: Keys, Permissions, and Offboarding

An automation is, practically speaking, an extra user in the business - one with access to several systems at once, working unsupervised, and nobody remembers who created it. That does not make it dangerous, but it does mean it needs the same decisions you make about an employee: what it may see, who owns it, and what happens when somebody leaves.

Why an automation connection is riskier than a normal user

Not because it is more vulnerable, but because it is quiet. A human user who loses access complains; an automation connection still running two months after it should have been closed complains about nothing. It also usually holds broader permissions than it needs, because granting "everything" is convenient at setup.

The cumulative result: a business running two years with a few automations typically has three or four active connections nobody can explain, at least one of them on the account of somebody who no longer works there.

The four decisions

The first row prevents the biggest problem. A connection created under an employee's personal account dies the day their account is closed - meaning the automation breaks exactly when everybody is busy with something else, and often nobody connects the two events.

Keys and passwords: what not to do

• Do not send a key over WhatsApp or email - it stays there forever.
• Do not store keys in a shared sheet - it is shared with exactly the people who should not have them.
• Do not reuse one key across several uses - you cannot revoke one without breaking the rest.
• Do not leave a key for a supplier who has finished - it still works.
• Do not issue an admin key when read-only is enough.

The first two explain most incidents. A key sent in a chat is not "hidden" - it sits in two people's history and in a messaging service's backup, and it will keep working long after nobody remembers it exists.

Least privilege in practice

The rule is simple: the connection gets exactly what the process does, and nothing more. An automation reading orders and sending a message does not need delete permission; an automation writing to one spreadsheet does not need access to the whole drive.

In practice this costs one extra minute at setup and one question: what does the process actually do. Most tools display the requested permissions at the connection step, and that is the moment to read them - not a year later, when you are trying to work out why a connection has access to a folder unrelated to it.

What gets closed the day an employee leaves

On the last day, on top of the normal accounts, three things need checking: automation connections created under their account, keys they issued, and external tools they set up. These are almost never on the standard offboarding list.

The way to avoid that search is the list: one document with every connection, which account it runs under, what it does, and who owns it. That list is needed for entirely separate reasons too - it is what lets you answer "where is our data", covered in a small business personal data map.

What about customer data moving between systems?

An automation usually moves real customer data, so three operational questions are worth asking: which fields the process genuinely needs, where they are stored on the way, and how long they stay there. It often turns out the connection is passing fields nobody needs - and removing those is risk reduction at no cost.

A second point: logs. Automation tools sometimes store message contents in run history, including personal details, and sometimes for a long period. It is worth knowing what is kept there and for how long - a setting decided once in the tool's configuration.

This is an operational description and not legal advice. For the obligations that apply to a business in Israel the source is the Privacy Protection Authority, and the practical context is in Amendment 13 and the customer spreadsheet.

What to record for each connection

The list that prevents most of these problems is deliberately short - six columns, not a security document. What goes in it: the connection name, what it does in one sentence, which account it was created under, what permissions it holds, when it was created, and who owns it today.

The fifth column looks redundant until you look at a two-year-old list. A connection created eighteen months ago for a need that no longer exists keeps appearing and keeps looking legitimate, and only the date gives away that it is a leftover. It is also what makes the annual review fast: start with the oldest.

Where the list lives matters less than there being one. A shared team sheet is enough for most businesses, provided it holds the existence of keys rather than the keys themselves - that separation is what makes it a management document instead of a risk in its own right.

A twenty-minute annual review

Once a year, open the connection list and ask of each one: still needed? Still on the right account? Still on minimum permissions? Any connection with no clear answer - close it and see what breaks. That is the fastest way to discover what is genuinely in use.

In businesses that have never done this, the review typically finds one or two connections that can be closed immediately - usually for a tool that was replaced or a supplier who finished. Every one of those closed is risk removed at no cost.

Sources

• Business automation for small businesses in Israel
• Israel Tax Authority - business information