Agents on AWS that reach Jira under a name you can review.
Amazon Bedrock runs foundation models and agents inside an AWS account. Atlas Bench designs how those agents authenticate through AgentCore Identity and reach Jira and Confluence through Atlassian's Remote MCP Server, so every call is attributable on both sides.
A Bedrock agent earns its keep once it can read a Jira issue or update a Confluence page. That reach runs through AgentCore Identity and Atlassian's Remote MCP Server, and both deserve design before the agent ships.
What it is
Bedrock supplies the models, and AgentCore supplies the agent around them: its runtime, its memory, the tools it can call, and the identity it presents when it calls them. For an agent working an Atlassian estate, the tool that matters is Atlassian's Remote MCP Server, which lets it search, read, and write in Jira and Confluence.
The design question is whose permissions each call carries. Atlassian's server acts with the permissions of the user who authorised it, and AgentCore Identity holds that grant in its token vault instead of in the agent's code. Done well, an agent sees only what its user could. Done badly, a production agent is still running on the token of whoever built the prototype.
What it does
AgentCore Identity holds the grant
Outbound OAuth tokens live in AgentCore's vault, so the agent requests access when it calls a tool instead of carrying a secret.
Atlassian's server enforces user permissions
An agent reaching Jira through it sees exactly what the authorising user sees, which makes that user's access the ceiling worth reviewing.
Two records of one action
CloudTrail captures the AWS side and Atlassian keeps the history of the change, and they reconcile only when both point at the same principal.
Where it fits
L4, agents and automation. How far the agent reaches into Atlassian is an L1 decision, made in AgentCore Identity and in the grant behind it, and the trail proving what it did belongs to L3.
What we do with it
Designing the outbound grant
Which user an agent acts for when it calls the Atlassian MCP server, and how that grant is issued, rotated, and revoked.
Connecting agents to Jira and Confluence
The MCP server wired in as a tool, with the actions an agent may take narrowed to the ones its use case needs.
Attribution across both systems
CloudTrail and the Atlassian side configured so a change can be followed from the model call to the issue it edited.
Where it earns its place
A service desk agent built on Bedrock
It triages Jira Service Management requests, and every update it writes traces back to an identity someone owns.
A prototype agent heading to production
It was demonstrated with a developer's personal Atlassian token, which is the first thing to replace.
Proof
AI Innovator Finalist, 2026
Atlassian Partner Awards, 2026