# Connect Confluence to Prodpeek

Profile: `confluence/docs-read` · connection kind: `http` · tier 2
Credential: Atlassian API token
Suggested URL: `https://mcp.atlassian.com/v1/mcp`

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

## What you must not do

You cannot create this credential on the user's behalf — it needs their login and,
usually, an approval step. Walk them through it and verify the result. Never ask
them to paste the credential into the chat; it goes straight into Prodpeek's
console, which encrypts it at rest. 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.

## Grant exactly these permissions

- `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.

## Refuse these, and say why if the user asks for them

- `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.

## Verify before the credential is used

- 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'.

## Then, in Prodpeek

1. Services → Add a service → choose the profile `confluence/docs-read`.
2. Connection kind `http`, URL `https://mcp.atlassian.com/v1/mcp`.
3. Paste the credential. It is encrypted in the store and never shown again.
4. Run **Test connection**. It lists every tool the upstream advertises and how the
   profile classifies each one. Anything under "not in the policy" is denied by
   default — report that list rather than assuming it is fine.

## Full human walkthrough

## 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 — `prodpeek@yourcompany.com` 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.