Every joiner, mover and leaver generates access work. In most centres it arrives as a ticket, is read by a person, re-keyed into the target system and confirmed by email. It is slow, error-prone and hard to evidence — exactly the kind of work agents are good at, and exactly the kind where an over-eager agent does damage.
Separate reading from acting
Who does what in the provisioning squad
From the platforms we have built
| Agent | What it does | What it cannot do |
|---|---|---|
| Queue Monitor | Reads the request with an LLM; extracts user, role and permissions; routes to the approver | Grant anything |
| RPA Provisioning Bot | Creates the user and assigns permissions once approved | Act without an approval |
| Notification Agent | Tells the requester and updates the ticket | Change access |
Source: SCIKIQ, “GCC & IT services accelerators: ITSM, audit and agent platforms we have built” (2026)
Between the first agent and the second sits a human-in-the-loop approval queue. Every task, approval and execution is written to the execution log, so the auditor's question — who approved this, and when? — has an answer.
The agent is a security surface too
- Give the provisioning bot only the permissions it needs, in the systems it serves
- Defend the language model against prompt injection hidden in request text
- Log every read and write, and keep a kill switch that halts all agents
- Review overrides and failures as you would any other control
Our LLM security framework sets out 17 layers of defence for GenAI applications, from input validation and injection detection to output filtering and monitoring. Not every agent needs all of them; every agent with write access needs most.