Authorization audit
On this page
Managed services. This capability is available with Polyant managed services.
Settings → Organization → Authorization audit (/organizations/{org}/settings/organization/audit) is the trail of who changed who could do what. It is separate from Audit Logs, which record what agents and their tools did.
It requires org.audit:read and the advanced-audit feature; without the feature the endpoint is refused outright even for an Owner. The permission is the organization-tier one, deliberately not the workspace-tier audit_log:read that governs tool audit - an org-addressed route has no workspace to resolve a workspace-tier permission against.
What is recorded
A closed, explicit table of management mutations - not everything that touches authorization, but exactly these:
| Action | Emitted by |
|---|---|
role_binding.create | Assigning an organization role, or a workspace role |
role_binding.delete | Removing a workspace role binding |
member.remove | Removing a member from the organization |
role.create | Creating a custom role |
role.update | Editing a custom role |
role.delete | Deleting a custom role |
Seven audited routes produce those six actions - an organization role assignment and a workspace one both record role_binding.create, distinguished by whether the row carries a workspace.
The list is a static route table rather than something inferred from the URL at request time, which has one consequence worth understanding both ways: a crafted URL can never fake an audit row, and adding a newly audited route is a deliberate code change. So treat this as an authoritative record of the six actions above, not as a complete record of every authorization-relevant event.
What each row holds
Organization, acting user, action, target type and id, IP address, timestamp, and a small metadata object - for a workspace binding, the workspace id.
Rows are scoped to the organization, and a caller from another organization is refused before the query runs. Filter by action; results are paginated.
How the workspace narrows it
The page shows the trail from the point of view of the workspace you are acting in, and it says so on screen rather than leaving you to guess. That means:
- rows about another workspace drop out;
- organization-level rows are always kept, because they carry no workspace at all.
That second rule is the important one. Only two of the audited actions carry a workspace; role definitions and organization membership carry none. Reading the filter strictly would therefore hide almost the entire trail - including who granted Owner to whom - and an audit log that answers “almost nothing” when scoped is worse than one that is not scoped.
There is no workspace picker here: it would compete with the tenant switcher, which is the product’s one answer to “which workspace am I in”. Change the scope by changing workspace.
What is audited elsewhere
- Agent-side tool activity → Audit Logs.
- Management writes, including an agent’s configuration, retention policy changes, purge runs, and mutations to installation accounts → the management audit trail, readable in the Admin Console. See the three audit tiers.
- Opt-out transitions (a contact sending a stop or resume keyword) → audited by the engine and visible in the conversation itself. See Privacy.
Nothing here records reads: viewing a member list or a role definition leaves no row.