Can Service Accounts Replace Personal API Tokens for AI? [Champions Slack Insider]

[#1]

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.

[Rebekka Heilmann _viadee_]

You can't really use Service Accounts for MCP or CLI access yet though. Service Accounts always require scoped tokens. The token scopes available for selection in the Admin UI are not the ones that the Teamwork Graph API is requiring though.

So even if you select all possible scopes for one App, only a hand full of tools will actually work.