Authorization audit
Enterprise feature. This capability is available on Polyant Enterprise deployments.
The Authorization audit screen (/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 audit_log:read and the advanced-audit feature; without the feature the endpoint is refused outright even for an Owner.
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 |
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.
What is audited elsewhere
- Agent-side tool activity → Audit Logs.
- Management writes to an agent’s configuration, including retention policy changes and purge runs → the management audit trail, also surfaced under Audit Logs.
- 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.