Treat an automation as an independent operator. Give it its own identity, grant only the actions and resources required for its job, and make every privileged action attributable. Sharing an administrator credential across workflows makes access hard to review and a compromise hard to contain.
Inventory actions before granting access
List what the workflow must read, create, change, delete, approve, or send. Include the exact systems, environments, accounts, folders, repositories, and data classes. Separate setup permissions from day-to-day runtime permissions. A deployment automation may need permission to release an approved artifact but not permission to change billing, create new administrators, or read unrelated customer data.
NIST SP 800-53 Revision 5 includes access-control, identification, audit, configuration, incident-response, and least-privilege controls. The least-privilege principle assigns a component enough access to perform its specified functions, but no more.
Use a distinct nonhuman identity
Avoid personal user tokens for routine automation. Use a service identity supported by the platform and name it for the workflow and environment. Production and test automations should not silently share credentials. Where available, prefer short-lived credentials or workload identity over long-lived copied secrets.
Store credentials in an approved secret store, not in source code, task descriptions, logs, or exported configuration. Define who can change the secret and how rotation works. A secret that cannot be rotated without an outage creates operational pressure to leave excessive access in place.
Deny by default and narrow every dimension
The OWASP Authorization Cheat Sheet recommends least privilege, deny-by-default behavior, validation of authorization on every request, and periodic permission review. Apply those ideas to the workflow's identity:
- allow only required operations;
- scope access to named resources and environments;
- restrict when and from where the identity may run when the platform supports it;
- require a separate approval for exceptional actions; and
- expire temporary grants automatically.
Read access also matters. A workflow that only publishes a report may not need access to raw personal data. Limit the input fields exposed to it and the destinations it can write to.
Put control around consequential actions
For deletion, payments, external messages, permission changes, or production releases, add a policy gate. The gate may require an approved artifact, signed change, second identity, bounded amount, target allowlist, or human confirmation. The automation should fail closed when the policy cannot be evaluated.
Do not rely on the user interface to enforce access. Authorization must be checked by the service that performs the action. Test that the workflow cannot reach an unapproved resource, change its own role, use another environment's credentials, or continue after its access is revoked.
Log use and rehearse revocation
Record the service identity, requested operation, target, decision, outcome, and correlation identifier. Protect logs from alteration by the same identity they monitor. Alert on denied operations, new resource scopes, unusual execution locations, and use outside the expected schedule.
Review permissions after workflow changes and on a recurring schedule. Remove unused grants. Then test the emergency path: disable the identity, revoke its active credentials, stop queued executions, and confirm dependent workflows fail safely.
Good automation access control is intentionally boring. Each workflow has a small, reviewable permission set; exceptional authority is explicit; and operators can answer who acted, what it touched, and how to stop it.
Sources
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology, Sept. 23, 2020
- Authorization Cheat Sheet — OWASP Foundation