An action is refused as forbidden

Symptom

You are signed in — reads work — and one action comes back 403. Or every request comes back 401 and the dashboard sends you to sign in again. The two are different problems and the difference is in the number.

Diagnose

1. 401 or 403? 401 means the platform does not know who you are: the token is missing, malformed or expired. 403 means it knows exactly who you are and the answer is still no.
2. For a 401 from the API: check the request carries Authorization: Bearer <token> and that the token has not expired. odysseus auth whoami and odysseus auth status answer both.
3. For a 403: which role are you acting as? Running and building are separate rights on purpose — see what an agent principal cannot do, which states the same separation for automated callers.
4. Is the resource in your tenant? Every record belongs to exactly one tenant, and a request that reaches another tenant’s record is refused rather than answered emptily. That refusal looks like a permissions problem and is an isolation boundary — see tenancy and isolation.

Resolve

• 401: sign in again, or refresh the token. odysseus auth login re-issues one.
• 403 on an action your role does not carry: ask your tenant’s administrator for the right, naming the action rather than the role — the roles differ in what they may do, not in seniority.
• 403 on another tenant’s record: there is no fix on this side; the record is not yours.

Prevent

Give automated callers a principal with exactly the rights their job needs. One principal holding both the build right and the run right defeats the separation quietly, and nothing reports it.