Requests
An employee asks their AI client for something, the client calls a tool their Group does not grant, and the call fails. The ask does not stop there: it lands in Requests with the reason the employee gave. This is what lets you run a tight default and grant the long tail on demand, instead of provisioning everything up front and hoping.
Requests has two tabs, each with a count of what is waiting. Tools is access to a Connector’s tools. Skills is a skill an employee wants published. Both tabs are always visible; the permission decides what is inside one. Tool requests need the user-management permission and skill submissions need the manage-skills permission, so a reviewer who holds one and not the other sees a queue on one tab and a permission notice on the other.
Tool requests
Each row carries the employee, the tools they asked for, the reason they gave, and when the request was made, with the Groups they belong to on a tooltip beside their name, so you can see whether the answer is a grant to one person or a change to a Group. Three decisions:
- Approve, with a duration: 1 hour, 1 day, 1 week, or no limit. The approved tools are added to that employee’s effective access.
- Deny, with an optional note back to the employee.
- Revoke an approval that is still in force, when the need has passed.
An approval with a duration lapses on its own. It stops granting access and stops counting as approved, so the approved list holds only grants still in force and Expired shows you what is worth renewing. Filter by status, filter by employee, or search across the requester, the reason, the reviewer’s note, and the tools on the request. Select more than one row and the approve, deny, and revoke actions apply to all of them.
An approval grants one person. When several people in the same Group keep asking for the same tool, the Group is what is wrong: widen it in Groups and access and the requests stop.
Every approval, denial, and revocation is recorded in the Audit trail, alongside the reason the employee gave.
Skill requests
An employee who writes a skill submits it for review rather than publishing it themselves. Submissions wait here with their author, their description, and the Connectors they call.
- Approve publishes the skill at the reach its author chose, which is the whole organization or the Groups they picked.
- Reject, with an optional reason, returns it to its author to revise.
The queue holds pending submissions only. A rejected skill goes back to its author and does not reappear here, so an empty tab means nothing is waiting on you. As with tools, selecting several submissions applies one decision to all of them. Reviewing submissions covers what to look for before you approve.
Next
Set the baseline that decides how many requests you get in Groups and access.