AI Agent for Jira in Slack: What Waits for You

An AI agent for Jira in Slack is the built-in Insulin assistant working through your own Atlassian connection: it searches issues with JQL, reads projects, fields and statuses, and can create, update, link and transition issues, comment and log work. Where you ask decides what waits for you. In a direct message, a Jira change runs on your word; when you @mention it in a channel, anything that isn’t a read waits for your Allow.

Updated 2026-10-23: Insulin now has a third access level, Full, which is the default; this post now covers setting Atlassian to Read-only on the built-in assistant, which the Slack bot follows.

---

“Can my team ask Jira questions in Slack, and will the AI change issues without asking?” Team leads ask both halves in one breath, and the admin asked to allow it mostly asks the second. Fours’ documentation answers them separately. Once you’ve connected your own Atlassian account, the Slack bot reads Jira through it. Whether it changes an issue without asking depends on where you asked, because the Atlassian connection has no read-only level of its own.

So this post starts with what waits where, then gives a question sheet for Jira, and ends with the setting that rules writes out: Atlassian on Read-only, in the assistant’s settings, which the Slack bot follows, or on a personal agent running a weekly job that reports to you in Slack.

Will an AI agent for Jira change issues without asking?

In a Slack direct message, yes: a create, update or transition runs on your word, because in a DM only posting a Slack message waits for approval. When you @mention it in a channel, anything Insulin can’t recognize as a read waits for your Allow, but the answer, and whatever your connections read to write it, is visible to everyone in the channel.

It’s the rule Fours applies to its own records, minus the cap. Fours’ Slack bot page is explicit: in a direct message, “changes to your own records are not gated this way. Ask the bot to update an offer and it updates it, the same as a teammate would on your instruction.” For Fours records, the access level on your Fours MCP connection bounds that: Read by default, then Read & write, then Read, write & delete. The Atlassian connection has no such level. Fours’ Atlassian page has you authorize your Atlassian account and return, and from then on the Fours AI agent “can create and update Jira issues.”

The rest of what waits comes down to four answers:

What you need to know	The short answer
Whose Jira access answers in Slack?	The asker’s. Atlassian connects per user only, through each person’s own OAuth sign-in: the same connection that lets your own agents read and edit Confluence pages live. Two people asking in one channel each get their own access.
What waits in a Slack DM?	Only posting a Slack message. A Jira create, update or transition runs when you ask.
What waits when you @mention it in a channel?	Anything it can’t recognize as a read, on the Slack bot’s approval card, which only you can answer. Unanswered for three minutes, the card expires and the action is abandoned.
What waits in Microsoft Teams, Insulin channels, jobs and goals?	Nothing. They can’t show the card, so actions aren’t held back. Teams reaches the built-in assistant, so the Atlassian level in its settings is the boundary; elsewhere, an agent’s Read-only setting is.

Nothing is set per channel: Slack inherits what each person connected in the console. Two details matter more for Jira than for most systems:

• A DM write shows no card. You see progress while it works, then the answer. By the time you read that ACME-142 moved to Done, it has moved.
• A channel answer belongs to the channel. It can draw on anything your connections can read, so an issue from a Jira project only you can open is posted where everyone in the channel can read it, including members of another company in a Slack Connect channel. Ask in a DM about anything you wouldn’t post there yourself.

Which Jira questions can an AI agent answer in Slack?

Questions about what’s already in Jira: which issues match a search, what one issue says, and how your projects are set up, across the Atlassian sites your account can reach. Fours’ Atlassian page counts 78 actions across Jira and Confluence, grouped by capability with a few tools named as examples. Here is the Jira half, as questions:

Ask it	What answers it (Fours’ Atlassian page)	A tool the page names	Changes Jira?
Which open ACME bugs have no assignee?	Searching issues with JQL	jira-search-issues	No: it reads
What’s the status of ACME-142, and who has it?	Reading an issue	None named	No: it reads
Which projects can I see, and what are their keys?	Reading projects	jira-list-projects	No: it reads
Which fields, priorities and issue types does ACME use?	Reading fields, statuses, priorities and issue types	jira-list-fields, jira-get-create-issue-metadata	No: it reads
Which Atlassian sites can you reach for me?	Reading the connected user and accessible sites	get-account, get-accessible-resources	No: it reads
File this thread as an ACME bug.	Creating an issue	jira-create-issue	Yes
Raise ACME-142 to High priority.	Updating an issue	None named	Yes
Link ACME-142 to ACME-98.	Linking issues	jira-create-issue-link	Yes
Move ACME-142 to Done.	Transitioning an issue	jira-transition-issue	Yes
Comment on ACME-142 that the fix has shipped.	Adding a comment	jira-add-comment	Yes
Log two hours on ACME-142.	Adding a worklog	jira-add-worklog	Yes
Add me as a watcher on ACME-142.	Adding watchers and attachments	None named	Yes

None named means the page describes the capability without naming its tool. Ask an agent to list the actions Atlassian supports and it returns each one with a description and whether it is read-only.

Four things shape the answers:

• Every read runs on your connection. Multi-site access is resolved “via the connected account’s accessible resources,” so the agent works across the Atlassian sites your account can reach, and a teammate asking the same question gets answers from their own connection.
• Threads are context. @mention it inside a thread and it reads that thread’s first message and latest replies, so “file this thread as an ACME bug” needs no pasting. In a channel, the create still waits for your Allow.
• Long lists arrive as a file. A table longer than about 8,000 characters is attached as a CSV file with its links kept, so each issue opens from the spreadsheet. Ask for the count instead when the count is what you want.
• Some lookups wait in a channel too. Fours says a lookup whose tool isn’t recognized as a read waits for your Allow there, and the Atlassian page doesn’t mark which Jira tools those are. In a DM, reads never wait.

How do you keep an AI agent for Jira from changing issues?

Set Atlassian to Read-only, either in the Insulin assistant’s own settings, which the Slack bot follows, or on a personal agent you use in the console. Slack reaches only the built-in Insulin assistant, which “cannot be edited or deleted,” but you can narrow what it may do with each integration: open a chat with Insulin, click the pencil in the conversation header, and set Atlassian in the panel’s Integrations section. The level is yours alone: it narrows Insulin for you, not for anyone else in the organization. An integration you leave alone stays at Full, so once your Atlassian account is connected, the assistant has the Jira tools that create, update and transition, in Slack and in the console alike, until you narrow it.

Read-only is one of three access levels on each integration, the same on a custom agent as on the assistant. Fours’ agents page says an agent with an integration on Read-only can “use only that integration’s read tools — listing, searching, fetching.” Its write tools are removed for that agent, and “a tool Fours does not recognise as a read is treated as a write.” Edit also creates and changes records but never deletes them, and Full, which adds deleting, is the default. If Fours can’t read your levels when a turn starts, the assistant runs that turn with every integration at Read-only.

To set it on a personal agent instead, used in the console:

1. Connect Atlassian to your own account, if you haven’t: open Settings → Integrations → User Integrations and click Connect Now in the Atlassian section. Authorize in Atlassian, then return to Fours to confirm.
2. Create a personal agent. In Agents, click Create Agent, set Ownership to Personal (only you), name it (say, Jira reader) and add Atlassian under Integrations.
3. Set Atlassian to Read-only in the select beside it.
4. Ask it what it kept. An agent can list the actions an integration supports, each with whether it is read-only, so you can see which Jira reads it has before you rely on it.
5. Use it in the console. Click the agent name at the top of the chat area, or start a new conversation, and choose it. Tool calls expand to show their inputs and outputs, so you can see the search behind each answer.

Three limits come with it:

• It stays out of Slack. Personal agents work in console chat, personal channels and jobs; Slack and Teams reach only the built-in assistant. To keep Slack to reads as well, set Atlassian to Read-only in the assistant’s settings; the bot follows it.
• It’s yours alone. Only organization agents can be shared, and organization agents can use only organization-level integrations, while Atlassian connects per user only. Each person who wants a read-only Jira agent builds their own.
• One connection serves everything that runs as you. The assistant and your personal agents use the same Atlassian connection, so Read-only on one agent doesn’t change what the assistant can do. Deleting the connection “immediately revokes access to Atlassian” for all of them, and since editing isn’t supported, changing it means deleting it and connecting again. Deleting doesn’t clean up what was created: Fours’ page points you to Atlassian’s documentation for issues and pages created by Fours.

For the systems an org admin connects, where read-only access for AI agents is set goes system by system.

How do you get a weekly Jira status in Slack without write access?

Have the Read-only agent run it as a job: ask for the job in a console chat with that agent. A job runs as the agent you asked, with that agent’s access (see how jobs are created); ask the built-in assistant instead and the job runs as the built-in assistant.

Don’t ask the Slack bot for this one. A job set up by asking the Slack bot runs as the built-in assistant, with your full Jira access, and job runs never pause: a run can’t show an approval card, so nothing is held back. On a job, the agent’s Read-only setting keeps Jira unchanged, not a card.

In a console chat with Jira reader, an Acme team lead might ask:

Every Monday at 8:00, list the open ACME issues by status with each one’s assignee, and flag any with no assignee.

The agent sets it up as a cron job on 0 8 * * 1. There’s no timezone field, so 08:00 is on the service’s clock; the job’s Next timestamp shows when it lands for you. Then:

• Check the agent before the first run. The job’s detail page shows the agent’s name under its header. If it names the built-in agent, the runs have your full Jira tools.
• Runs keep Read-only. A run works with its agent’s integrations, so with Atlassian on Read-only it has no Jira write tools, whatever the instructions say. The first run’s Steps tab lists every tool call in order, with its Args and its Result or Error.
• The result reaches you in Slack. If your organization has connected Slack, Fours sends you a direct message when a run finishes, for single-turn manual and scheduled jobs you own, with the result or error and an Open in Fours Insulin console link. It finds you by your Fours account’s email in that workspace; event-triggered, goal and channel-owned jobs send none.
• A reply to that DM goes to the built-in assistant. Follow up in the message’s thread and the bot answers with the result in view. It’s a DM, so a Jira change you ask for there runs on your word.
• Only you can see it. A job is private to its owner, organization administrators included.

Already asked the Slack bot for one? Its runs have your full Jira tools. Delete the job, which removes its run history too, and ask for it again in a chat with the Read-only agent.

Frequently asked questions

Can an AI agent for Jira change issues from a Slack DM without asking?

Yes, unless you narrow it. In a Slack direct message, only posting a Slack message waits for approval, so a Jira create, update or transition runs on your word. Setting Atlassian to Read-only in the Insulin assistant’s settings, which the bot follows, rules writes out.

What happens when I @mention the bot in a channel and ask it to move an issue?

It stops and posts an approval card that only you can answer. Allow, and the transition runs; Deny, and it’s dropped. If nobody answers within three minutes, the card expires and nothing changes. Everyone in the channel can see the card and the answer.

Whose Jira access does the Slack bot use?

The asker’s. Atlassian connects at the user level only, through each person’s own OAuth sign-in, and the bot runs on the asker’s connections. Two people asking in one channel each get answers from their own Atlassian access.

Can I use a read-only Jira agent in Slack?

Yes, by narrowing the built-in Insulin assistant, the only agent Slack reaches. Open a chat with Insulin in the console, click the pencil in the conversation header and set Atlassian to Read-only; the Slack bot follows that level. Left alone, Atlassian stays at Full.

Does a scheduled Jira job ask before it changes an issue?

No. Job runs never pause for approval. A job set up by asking the Slack bot runs as the built-in assistant, with your full Jira access; one created in a chat with a personal agent that has Atlassian on Read-only has no Jira write tools.

Can people in a channel see Jira issues they can’t open themselves?

They can see what the answer says. The bot reads Jira with the asker’s Atlassian access, and its answer in a channel is visible to everyone there, including members of another company in a Slack Connect channel. Ask in a DM about projects the channel shouldn’t see.

Takeaways

• Where you ask decides what waits. In a Slack DM, a Jira create, update or transition runs on your word; in a channel @mention, anything that isn’t a read waits for your Allow; in Teams, Insulin channels, jobs and goals, nothing waits.
• The Atlassian connection has no read-only level. Fours records are capped by your Fours MCP access level; for Jira, the cap is an agent’s Read-only setting.
• A channel answer is everyone’s, drawn from the asker’s own Atlassian access.
• Read-only is set per integration, on the assistant or on a personal agent. The Slack bot is the built-in assistant, so it follows the level in the assistant’s settings; a personal agent is used in the console.
• A read-only weekly status is a job created from that agent. Ask the Slack bot instead and the job runs with your full Jira access, and never pauses.

In Slack, the built-in assistant works on each asker’s own access and levels; in the console, specialist agents keep each integration on Read-only, Edit or Full. AI agents for business workflows shows both, with what waits for your Allow on each surface.