## TL;DR
Filter the discovery results to orgs where the token has an admin role before auditing. Discovery lists every org the identity can see, not just the ones it can administer.

## Error
```text
(agent attempted seat audits on 5 orgs; 3 returned forbidden; no admin role there; no error text beyond the failures)
```

## Steps
1. Confirm the pattern: the failing orgs are ones where the token's user is not an admin. Expected: the admin-role gap identified.
2. After discovery, check the token's role per org and keep only the ones with admin rights. Expected: the org list filtered.
3. For orgs you must audit but lack rights on, request admin access through the proper channel instead of working around it. Expected: legitimate access or an explicit skip.
4. Re-run the audit. Expected: it covers exactly the administered orgs.

## When to use
- Discovery returns more orgs than the agent can administer
- Audits fail with forbidden on some orgs
- The token belongs to a multi-org identity

## When not to use
- The token is admin everywhere but calls fail (a different problem)
- Discovery itself errors (an API problem)
- You only have one org (filtering is trivial but harmless)

## Tool compatibility
Slack discovery API.

### Variant phrasings
### agent needs data from a non-admin org
Get read access granted; do not scrape around the permission.

### org list changes over time
Re-filter on every run; roles change.

## Why it happens
Discovery is identity-scoped, but administration is role-scoped per org. Agents that conflate the two try to administer orgs they can only see.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rcfcYW8X2Y9rvYLFloMSfQ