How AI agents route employee access requests to approvers

Agent Swarm can prepare, route, and track an employee software access request, then pause for a named person's decision, but a person authorizes the access and IT provisions it through its own process, so no agent grants or changes permissions. Agent Swarm is an open-source system for running a team of AI agents that take work from Slack or a ticket tracker, and hand context to each other through a shared drive. Placed in the middle of an access request, it is a coordination layer between the person asking, the manager, the system owner, and the person in IT who provisions. The decision stays with the humans the request names.

That layer is where small companies lose track. At 20 to 100 engineers, access requests arrive as Slack messages, get approved in a thread nobody can find three months later, and leave IT holding a screenshot as its only evidence. The usual fix is a form nobody fills in properly, or an agent given API access to the identity provider, which is the expensive mistake: you traded a messy process for an unaccountable one.

The short answer

1. Write the request as a record: which tool, what level of access, the business reason, and how long the person needs it.
2. Name both approvers in the record itself: the requester's manager and the owner of the system being opened.
3. Let an agent check the record for the missing fields and route it to those two people, with a summary and a link to the full record.
4. Let each approver decide, and store the decision with the reason and the date.
5. Send the approved request to IT, which provisions in the tool it already uses and records what it granted.
6. Close the record, link the provisioning ticket to it, and set the review date for time-bound access.

An illustrative access request

This section is an illustration of how the documented pieces fit together. It is not a customer deployment. Applying these patterns to employee access needs custom integration and configuration in your own systems, and Agent Swarm ships no ready-made HR or identity integration.

A support engineer needs read access to the billing dashboard for six weeks to work through a backlog of refund disputes. She writes the request in Slack with four fields filled: the tool, read access rather than write, the refund disputes as the reason, and six weeks as the duration.

An agent picks the request up, checks that all four fields are present, and looks up who owns the billing dashboard. The request is complete, so the agent posts it to the requester's manager and to that system owner in one thread, with the four fields and a link to the full record.

The manager reads it, knows the refund backlog is real, and approves. The system owner approves too, at read level and for six weeks, because a read-only dashboard cannot change a charge. Had either of them rejected it, the request would have stopped there.

IT then provisions read access in the billing tool, following whatever process IT already uses, and writes the outcome back to the record: who granted it, at what level, and when it expires.

The agent closes the record, links the provisioning ticket, and sets a review date six weeks out. Nobody had to reconstruct the chain of decisions later, because the chain was the record.

Evidence each step needs

Step	Who acts	What evidence is recorded
Request written	Requester	Tool, access level, business reason, duration, date
Completeness check and routing	Agent	Both approvers named, link to the record, routing time
Authorization	Manager and system owner	Each decision, its reason, the decider's name and the date
Provisioning	IT	What was granted, at what level, the person who granted it, and the ticket reference
Closure	Agent	Link between request and provisioning ticket, final state
Review	System owner, then IT	Keep or remove decision, and the date it was taken; the removal record when access is cut

Two of those rows are the ones an audit asks for, and they are the two a chat thread loses: who authorized the access, and what was granted.

When something is missing or rejected

A missing system owner. The request stops. It does not get approved by a manager alone, and an agent does not pick the likeliest owner from a directory and carry on. The record goes to a fallback person named in advance for each system, usually the owner's manager or a named deputy, and the record states that it was routed there and why. A request that cannot name an owner is a gap in the company's ownership map, and the honest outcome is to surface that gap rather than paper over it.

A rejection. The requester gets the reason in the same thread, and nothing is provisioned. The record keeps the rejection with its reason instead of being deleted, so the next person who asks for the same access can see that it was considered and why it was declined.

An incomplete request. The agent asks the requester for the missing field, in the thread where the request started. It does not guess the access level, and it does not fill the duration with a default that quietly turns a six-week need into permanent access.

The guidance in the human-in-the-loop pattern applies to all three: define both the approve and the reject branch, and set a timeout or fallback so a forgotten request does not wedge the workflow forever.

Expiry review

Time-bound access needs a date on the record from the moment it is written, and a review before that date. The agent prepares the review from what it already has: what was requested, when it was approved, who approved it, and when the access lapses. It asks the system owner one question, keep the access or remove it, and gives them the summary and the record.

The owner decides. IT removes the access in its own tool and records the removal. A review nobody answers escalates to the fallback person for that system rather than renewing by default, because silent renewal is how a six-week exception becomes a permanent permission.

Data minimization

The request carries only what the decision needs: the tool, the access level, the reason, the duration, the two approver names, and the dates. That is enough for a manager to judge the business need and for a system owner to judge the risk.

It carries no passwords and no API keys. It leaves out personal data that has nothing to do with the decision, such as a home address or a salary. An agent never collects or handles a password or a credential. Where a workflow does need a credential, Agent Swarm's documented route is a config question that puts the value straight into encrypted swarm config and tells the agent only that it was set, so the value never reaches the agent's context.

That rule also shapes how the request talks about access. Name the level in the words the target system uses, and skip "the usual access". Ambiguity at the request stage becomes over-provisioning at the IT stage.

What the agent never does

• Grant or change a permission in any system.
• Handle a password or an API key.
• Make an authorization decision, or record a decision a person did not make.
• Touch the identity system directly.

Each of those is a boundary you can write into the workflow and check in review. The HITL gates pattern puts the same line in product terms: the agent does the work, and the human owns the irreversible step. The wider set of controls, including what happens when an approval is rejected or times out, is in AI operations governance.

When identity-management software or a simple ticket is the better fit

An identity or access-governance product already runs your approvals. Then it owns the workflow and the provisioning, and it should keep them. An agent adds value at the edges, chasing a stale request or drafting the summary, and only where that product's own API allows it. Rebuilding an approval chain that already exists adds a second place where access can be granted.

Your volume is low, or one tool covers it. A ticket form with two approver fields and a required duration is enough for a handful of requests a month. The failure mode to avoid is a form with no owner field, because that is the same missing-owner problem with more typing.

Nobody owns the systems. Fix ownership first. Route a request to a named person or a named fallback, and if neither exists, the request cannot be completed by a person, and an agent should not complete it either. AI operations governance starts from the same place: one named owner per workflow, and a separate operator for credentials.

For the smaller-company version of this pattern, including how approval thresholds fit a written control record, the small companies AI operations field guide is the companion piece.

The documented pieces you can build this on

Agent Swarm workflows have a human-in-the-loop node that blocks execution, posts to Slack, and resumes only when a person responds. The same documentation tells you to gate the irreversible steps, give the approver a summary plus a link to the full record, define the approve and reject branches, and set a timeout or fallback. Agents can also ask a person for a decision with the request-human-input tool, which is separate from the workflow node.

The feature-development playbook shows the intake half under a different name: a request arrives in Slack or as a Linear ticket, a lead agent triages it and routes it to specialist agents, and the work moves between agents through a shared drive. Swap the request type, keep the shape, and the access request has somewhere to live.

The human-in-the-loop pattern covers the approval half, and both are for a system you run yourself: Agent Swarm is open source.

Two caveats belong at the end where they are hard to miss. This access-request walkthrough is an illustration, not a description of a shipped integration, and adapting it to your HR and identity systems is configuration and integration work you or your team does. The authorization decision stays with the people your process names.