Automation security: credentials, permissions and the audit trail

An automation is another user: it signs into systems, reads information and executes operations. The difference is that it does not forget, does not tire, and nobody watches it work. Its credentials, permissions and trail deserve the same governance as a person's, and frequently receive far less.

Below: the embedded credential problem, what permissions belong, separating who orders from who executes, the trail an audit expects, shadow automations, and what to review.

When an organisation goes from three automations to thirty, a question surfaces that nobody asked at the beginning: which user do they sign in as? The usual answer, and the uncomfortable one, is the person who built them.

That arrangement works until that person changes role, rotates their password or leaves. Several automations then stop at once and nobody knows which or why — at once an operational incident and the symptom of a deeper control problem.

The embedded credential, which is the central problem

Writing a username and password inside the process is the most widespread practice and the one with the most consequences. Beyond the obvious risk — it sits in readable text for anyone who can open the project — it guarantees an interruption every time the security policy does its job and rotates the password.

The perverse effect is familiar: teams ask for automation credentials to be exempted from rotation, and a correct policy ends up weakened so the robots do not break.

The alternative is a secrets store the automation reads from at run time. It is neither exotic nor expensive, and it solves both problems at once: the password leaves the project and can rotate without breaking anything.

What permissions belong

The criterion is the same as for a person, applied more strictly because the reach is greater. An automation should be able to do exactly what its process requires and nothing else.

In practice this is broken for convenience. Requesting a broad profile is faster than enumerating operations, and whoever grants the access rarely has the context to argue. The result is a technical user with administrator rights running a read-only task.

It is also worth having one identity per automation rather than one shared across all of them. It costs a little more administration and returns something unobtainable later: knowing which process did what. With a shared credential, the audit log says "the robot" modified a record, which answers no useful question.

Separating who orders from who executes

There is a category of risk specific to automation that does not exist with manual work: whoever can modify the process can, in practice, execute any operation that process is permitted.

If a payments automation is allowed to issue transfers, anybody who can edit its logic holds that same power without passing an approval. No bad intent is required for that to be a control problem: it is enough that an auditor asks who can do what.

The design that resolves it separates environments — building is not publishing — and requires a second pair of eyes to promote to production. It is the same discipline applied to any software, and automations routinely fall outside it because they are perceived as configuration rather than code.

The trail an audit expects

Three records answer almost any reasonable question. What it did: each operation with its result and timestamp. With what input: which case it processed and where it came from. And who changed it: a modification history of the automation itself, with author and date.

The third almost never exists and is the one most often requested. When a figure comes out wrong, the question is not what the robot did yesterday but since when it has behaved that way, and without a change history there is no way to answer.

It is also worth deciding how long these are kept. In operations subject to review, logs touching financial or personal data carry their own requirements, and the retention decision is taken alongside cybersecurity rather than left to a system default.

The automations a team built on its own

Low-code tools put the ability to automate in the hands of people outside IT, and that is good: whoever knows the process is often best placed to automate it. It brings a control problem worth naming before it grows.

An automation built by a team usually runs under the personal credential of whoever made it, lives on their machine or in their account, and appears in no inventory. It works perfectly until that person changes role, and then nobody knows it existed until something stops arriving.

The answer that works is not prohibition, because they will reappear without permission. It is offering a path: somewhere to register them, technical identities available without a three-week request, and a light review before they touch sensitive data or production systems. Governance that costs less than hiding is governance that gets followed.

What to review, and how often

Four things, in a review that can be quarterly and take little time if the inventory exists. Active automations against the inventory: what is running that nobody registered. Permissions against need: which access was granted for something no longer done. Credentials: which remain embedded and which do not rotate. And owners: which pieces lost theirs in a team change.

The first tends to produce surprises. In organisations without automation governance it is common to find processes running whose purpose nobody remembers, and that is a retirement decision before a security one.

The review should produce decisions rather than a report. Each finding should leave with one of three labels — fixed, accepted with written justification, or the piece retired — and a date. A list of observations with no owner and no deadline reappears identically next quarter, and by the third time the exercise loses credibility and stops happening.

What happens when an automation is compromised

The scenario is rarely planned for and is worth thinking through once, because the answer differs from the equivalent for a person. If a staff account is compromised you disable it and the human notices immediately. If an automation credential is compromised, nothing notices.

Three things make the difference between a contained incident and a long one. Being able to disable a single automation without stopping the rest, which is impossible with a shared credential. Knowing exactly what that identity could reach, which is what least-privilege buys you at the moment it matters. And having a log of what it actually did, so the blast radius is a fact rather than an assumption.

None of the three can be arranged after the fact. They are the same three decisions described above, which is why they are worth taking as design rather than as compliance.

Where this discipline belongs

These decisions do not belong to the project building one automation: they belong to the standard under which all of them are built. Defining them case by case produces thirty different criteria and no control.

The starting point is assessed by a cybersecurity assessment, which reviews access and identity control among its domains and reads the posture against the data protection framework that applies in Colombia or Mexico.

Frequently asked questions

Which user should automations sign in as?

An identity of their own, one per automation — never the credential of the person who built it and never one shared across all of them. One identity per piece is the only thing that lets you know afterwards which process did what.

Where are the credentials kept?

In a secrets store the automation reads at run time, not written inside the process. That way the password can rotate without breaking anything and stops sitting in readable text in the project.

What permissions should an automation hold?

Exactly what its process requires. In practice broad profiles get granted for convenience, and it is common to find a technical user with administrator rights running a read-only task.

What risk is specific to automation?

Whoever can modify the process can execute any operation that process is permitted, without passing an approval. It is controlled by separating building from publishing and requiring a second pair of eyes for production.

What records have to be kept?

What the automation did and when, with what input, and who modified it. The third almost never exists and is the one most requested: when a figure is wrong, the question is since when it has behaved that way.

What about automations a business team built themselves?

Prohibiting them does not work; they reappear unregistered. Offer a path instead — somewhere to register, technical identities available quickly, and a light review before they touch production. Governance that costs less than hiding is the kind that gets followed.