Accounts, passwords, and permissions for a software robot
A software robot signs in to email, portals, accounting systems, or databases in a way that resembles a person, but it often works without direct supervision and outside business hours. If it uses a colleague’s account or a password embedded in a script, an incident makes it difficult to determine who performed a particular change and where access must be removed. A safe design therefore starts with identity and permissions before the first click is automated.
A shared human account obscures accountability
A robot running under an accountant’s account inherits all of that person’s permissions even if it only needs to read one mailbox and record approved invoices. If the colleague changes their password or leaves the company, the automation stops working. Manual and automated steps also look like activity by the same person in audit logs.
The opposite extreme is one technical account for every robot. A compromised password then opens several systems, while revoking it stops unrelated processes. The appropriate model depends on what the target applications support, but the objective remains the same: identify the automation separately, limit its reach, and be able to revoke access promptly.
A realistic example: moving an invoice from email to the accounting system
Consider a robot that monitors a dedicated mailbox, checks basic data in a received invoice, saves the document in the process folder, and creates a draft record in the accounting system. It returns the draft number to a work queue where a person reviews the invoice. The robot does not change suppliers, approve the payment, or transfer money; those decisions remain outside its role.
The mailbox is therefore read by an identity restricted to that single address, with no permission to send mail. In storage it can write only to the process folder. In the accounting system it creates a draft and reads its status, but has no role for supplier management, approval, or payment. The scheduler may retrieve the required secret for a run, but cannot administer the whole vault. The same run identifier is recorded in the scheduler log and on the invoice draft.
If a required field is absent, the supplier is not on the allowlist, or the amount exceeds an agreed threshold, the robot moves the item to a review queue. It does not request broader access or continue under an employee’s account. This kind of invalid case shows whether the identity design works outside the ideal scenario.
1. Give the robot a dedicated identity
If a system supports a service account, application identity, managed identity, or OAuth client, use the mechanism intended for non-interactive access. A legacy portal may require a dedicated user account named for the process. It should not belong to a particular employee or be used for ordinary human work.
Record the process owner, technical custodian, purpose, environment, and accessed systems for the identity. Production and test environments should use separate identities and secrets. If the platform does not allow separate accounts, document the constraint and agree on compensating controls; automation is not a reason to bypass the provider’s authentication rules.
Multi-factor authentication (MFA) cannot be safely “solved” by sharing a phone or automatically approving every prompt. A platform-supported application authentication method or an explicitly approved policy for a particular technical identity is more appropriate. The identity administrator and owner of the target system must assess the specific solution.
2. Grant only the permissions required for the task
The principle of least privilege means restricting an identity to the resources and operations needed for its assigned task. A robot that downloads attachments from one mailbox does not need to read personal mail or send messages on behalf of the whole organisation. A robot recording invoices does not need to change suppliers or approve payments unless that is part of the process.
Design access step by step: reading the input, creating a record, changing a particular state, and saving the output. Risky operations such as payment, deletion, or a bulk change can remain behind human approval. What happens when a software robot encounters an error? expands on handling ordinary and invalid inputs.
Regularly compare access with the real process. A permission needed during implementation may no longer be necessary after stabilisation, and a new robot step should not silently depend on an administrator role that happens to be available.
How to choose the identity type and degree of separation
When the target offers a supported API and application identity, that is generally preferable to simulating a human sign-in. A portal available only through its user interface may require a dedicated user account. The choice should be based on supported system capabilities, revocation, and auditability, not on whichever sign-in was quickest to place in a script.
Always separate production from test. Separate identities for two processes make particular sense when they have different owners or permissions, or when one must be stopped without disrupting the other. One global account needlessly increases the impact of an incident; the opposite extreme of many nearly identical accounts makes ownership and revocation harder. Document the decision for every identity together with its owner, scope, and revocation method.
3. Keep passwords and tokens out of code
A password, API key, client secret, or certificate does not belong in a script, repository, ordinary configuration file, or run output. Store it in a secrets-management system or approved vault and make it available to the robot only at runtime. Where the environment permits, access to the secret should be separate from the ability to change the robot’s code.
Outputs must mask sensitive values. Hiding only a variable called PASSWORD is insufficient: a token may appear in a URL, request header, error message, or screenshot. At the same time, the audit trail should show who retrieved, changed, or revoked a secret without storing the secret value itself. The OWASP Secrets Management Cheat Sheet provides practical guidance on lifecycle, auditing, and rotation.
Rotation is more than a scheduled password change. You need to know every consumer, introduce the new value safely, verify a run, and then invalidate the old value. Short-lived dynamic credentials may be preferable to a long-lived password when the target system and operating model support them. The type of secret, risk, and capabilities of the particular platform therefore determine the frequency and rotation procedure.
4. Connect the audit trail across systems
A useful record identifies which robot and process version ran, who or what initiated the run, which business items it processed, and which operations succeeded or failed. A unique run identifier connects the scheduler log, the technical identity’s sign-in, and the record in the target application.
The audit log should not copy complete invoices or secrets. It retains the required identifiers, results, and timestamps according to internal rules, and access to the logs is restricted too. An unusual sign-in, use outside the planned schedule, or repeated permission denial may trigger an alert.
5. Prepare emergency access and revocation
An emergency or “break-glass” procedure may exist for a vault or identity outage. It is not a second password embedded in a configuration file or a routine fallback for every failure. Emergency access should have named approvers, secure separate storage, an alert on use, and a subsequent review and rotation. Its exact implementation depends on the identity platform and organisational rules.
Revocation is equally important. When a process is retired, a leak is suspected, or a supplier changes, responsibilities must be clear: who stops the scheduler, revokes tokens and accounts, removes roles, and verifies that the robot can no longer connect. A tested kill switch limits how long a faulty or compromised process can continue.
How to verify the design before production
Start with an ordinary test case using the minimum set of permissions and retain evidence that the robot read the intended input, created only a draft, and recorded the run identifier. Then deliberately attempt a prohibited operation, such as changing a supplier, deleting a record, or approving a payment. The expected result is denial by the target system and a clear log entry, not success made possible by a broader role.
Separately simulate a missing, expired, and revoked secret. The robot should end with a controlled error without exposing the value in a log, screenshot, or incident attachment. For a rotation test, make the new value available, verify one run, and only then invalidate the old value; a subsequent attempt with the old credential must fail. This checks both the procedure and the inventory of actual secret consumers.
Finally, connect the scheduler entry, secret retrieval, and target-application operation through the run identifier. Activate the kill switch and verify that the next run does not start or can no longer sign in, that no item remains in an ambiguous in-progress state, and that the responsible team receives an alert. Restoring access should require a deliberate decision by the named owner. Record the date, environment, tested roles, results of negative scenarios, and reviewer in the test report; a list of configured rights alone is not evidence that the restrictions work.
The boundary of this design
These steps support safer operation of a robot, but they are not a penetration test, security audit, or compliance assessment. Sensitive systems, payments, and regulated information may require a separate review by security, legal, or compliance specialists.
What you gain
A dedicated identity and audit trail improve the traceability of every run. Minimal permissions and separate secrets reduce the potential impact of an error or leak. A rotation and revocation plan also makes it possible to change access without searching scripts for passwords or disabling unrelated robots.
Next step
Before a pilot, create an identity table containing the process, account, owner, target system, required operations, secret location, and revocation method. In one test run, verify least-privilege access, log redaction, rotation, and the kill switch. Only then enable scheduled production runs.