A security automation token should belong to its own service account and carry only the permissions its job needs: for example create and comment on tickets, but not delete projects or change workflows. Scope it narrowly, give it an expiry, and rotate it.
Start from the job, not the platform
List what the automation actually does, then grant exactly that.
| Automation job | Needs | Does not need |
|---|---|---|
| Create tickets from findings | Create issue, add comment, read project | Delete issue, edit workflow, admin |
| Post alerts to chat | Post to named channels | Read private channels, manage users |
| Open fix pull requests | Write to a branch, open a pull request | Merge, change branch protection |
| Read scan results | Read findings | Write anything |
| Update ticket status | Transition issues | Change permissions |
Rules to apply
- One identity per automation. Do not reuse a person's account or a shared admin token, because you lose accountability and a leaver breaks the integration.
- Narrow scope. Use the smallest scope your platform offers, and limit it to specific projects, repositories or channels.
- Short life. Prefer tokens with an expiry. If the platform cannot expire them, set a calendar rotation.
- Separate environments. Test automation should not hold production credentials.
- No merging by bots. A pull request opened by automation should still need a human review and passing checks. Keep branch protection that the bot cannot change.
- Store secrets in a secrets manager, never in a repository, a ticket or a chat message.
Plan for rotation
Rotation breaks things when nobody remembers where a token is used. Keep an inventory: token name, owner, systems that use it, scope, expiry. When you rotate, create the new token first, switch the consumer, then revoke the old one.
Watch for signs of misuse
Alert on actions outside the normal pattern, such as a ticket automation suddenly reading many projects, or running at an unusual hour. Combine this with the audit record described in what audit trail security automation should keep.
If a token leaks
Revoke it first, then review what it did during the exposure window, then issue a replacement. See the first hour after leaking an API key.
Quick check
Can I reuse my own personal token for an integration?
Avoid it. If you leave or change role, the integration breaks, and its actions are attributed to you.
Should an automation be allowed to merge its own pull requests?
No. Keep human review and required checks. The bot opens the pull request, people approve it.
Safeguard supports agent identity and an MCP Guardrail for governing tool access, with a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
