Confluence

Read pages and search spaces — runbooks, architecture notes, the context that explains why production looks the way it does.

Policy	confluence/docs-read
Connection kind	http
Upstream looks like	https://mcp.atlassian.com/v1/mcp
Credential	Atlassian API token
Tier	2 — Prodpeek is the only fence, and the profile says so
Time to set up	about 3 minutes

Grant exactly these

An Atlassian account whose Confluence access is read-only

Atlassian API tokens inherit the permissions of the user who created them. There is no scope picker — the ACCOUNT is the scope, which is why this is Tier 2 rather than Tier 1.

View permission on only the spaces the agent should read

Space permissions are the real fence here. Grant the account view on the spaces you want and nothing else.

Do not grant these

Each of these would undo the point of the rest

Your own personal account

A token made from your account can do everything you can, in every space you can reach, and the audit trail will say you did it. Create a dedicated user.

Admin or space-admin rights

Nothing this profile allows needs them.

Add/Delete permission in any space

The profile denies the write tools, but with a coarse credential the allowlist is the only fence — do not make it the only fence for writes too.

The account is the scope

Atlassian API tokens have no permission picker. A token does whatever the user who created it can do. So the scoping work happens before the token exists: create a dedicated Confluence user, grant it View on exactly the spaces the agent should read, and create the token from that account.

That is coarser than a Coolify ability list or a Postgres role, and it is why this profile is Tier 2. The allowlist is doing most of the work.

Steps

1. Create a dedicated Atlassian account — [email protected] or similar.
2. In Confluence, give it View permission on the spaces it should read. Check that it has no Add or Delete permission anywhere.
3. Sign in as that account, go to id.atlassian.com → Security → API tokens → Create API token, and copy it.
4. In Prodpeek: Services → Add a service → Confluence, paste the token, then Test connection.

Why bother with a separate account

Two reasons, and the second is the one people notice later. A personal token gives the gateway everything you can reach, including spaces you forgot you had access to. And every read is attributed to you in Confluence's audit log, so if you ever need to answer "who read that page", the answer is useless.

Check you got it right

• [ ] Signed in as the dedicated account, the spaces you did not grant are not visible.
• [ ] Signed in as that account, a page shows no Edit action.
• [ ] In Prodpeek, Test connection shows the write tools under 'denied by policy'.

If an agent is reading this

Atlassian tokens carry the creating user's full permissions — there is no scope selection. Insist on a dedicated read-only account rather than the user's own; this is the step people skip.

Then add it to Prodpeek

Console: Services → Add a service, pick confluence/docs-read, paste the credential. Or from an agent, add_service with no credential and hand over the drop link.

Then press Test connection and read all three lists.