A discussion started when @Susan Hauth _Jira Queen_ raised a challenge many administrators are beginning to face:
Our developers keep asking for API tokens because they're hitting limitations with MCP and AI tools. We don't allow personal API tokens. What are others doing?
The responses quickly moved beyond MCP and into a broader conversation about security, governance, and how organizations should manage machine-to-machine access in the age of AI.
Short Answer
Many organizations are moving away from personal API tokens and toward service accounts with governed token management. While this introduces additional administrative overhead, it provides stronger security controls, better auditing, and clearer ownership.
Why Personal API Tokens Are Becoming a Problem
Historically, developers often created personal API tokens to connect applications, scripts, and integrations. The challenge is that personal tokens:
- Are tied to individual users
- Often have broad permissions
- Can be difficult to track
- May remain active after roles change
- Create audit and compliance concerns
For organizations operating in regulated industries such as finance, healthcare, and government, these concerns are increasingly driving policy decisions. As Susan explained, the issue wasn't technical capability—it was meeting security requirements.
Why Developers Keep Asking for Them
The reality is that developers often encounter limitations with newer authentication methods. Examples raised during the discussion included:
- Attachment access limitations
- API rate constraints
- Incomplete functionality in some AI workflows
- Features available through APIs but not yet available through newer interfaces
When teams encounter those limitations, the immediate response is often:
Can I just get an API token?
From a developer's perspective, that's understandable. From a governance perspective, it's rarely the preferred solution.
The Emerging Alternative: Service Accounts
Several Champions pointed to Atlassian Service Accounts as a practical middle ground. Instead of granting personal tokens, organizations can:
- Create dedicated service accounts
- Limit permissions to specific projects or use cases
- Issue scoped tokens
- Track ownership
- Apply approval workflows
- Rotate credentials on a defined schedule
This creates a much cleaner security model than relying on personal credentials.
How Teams Are Managing Them
One interesting part of the discussion was how different organizations are handling scale. A common pattern emerged:
- One service account per team or use case
- Separate tokens for individual integrations
- Shared ownership within the responsible team
- Secrets stored in an approved password vault
Champions mentioned tools such as:
- Keeper
- Secret Server
- Other enterprise credential vaults
Notably, nobody recommended storing actual tokens in Jira, Assets, or documentation systems. Instead, organizations are storing references to where credentials are managed.
The Governance Challenge
The biggest concern wasn't security. It was administration.
As Susan pointed out:
The more service accounts and tokens you create, the more maintenance you inherit.
Organizations must track:
- Owners
- Permissions
- Expiration dates
- Business purpose
- Approval status
- Scope requirements
Without a governance process, service accounts can quickly become as difficult to manage as personal tokens.
Where Assets and Rovo May Help
Several Champions discussed using Assets to track:
- Service accounts
- Token ownership
- Expiration dates
- Systems connected
- Approval status
Combined with automation and Rovo, organizations could potentially surface:
- Upcoming expirations
- Missing ownership
- Dormant credentials
- Overly broad permissions
AI doesn't solve governance by itself, but it can help make governance more manageable.
Champion Takeaway
This discussion highlighted a trend that's becoming increasingly common across enterprises - organizations aren't trying to eliminate API access. They're trying to govern it.
For many teams, the question is no longer:
Should developers have API tokens?
Instead it's:
How do we provide the access they need while maintaining security, compliance, and accountability?
Right now, service accounts paired with strong credential management practices appear to be the most common answer.
