The internal helpdesk nobody wanted to staff
Internal helpdesk email is an unusually good first agent: your colleagues are forgiving, the questions repeat, the documentation exists somewhere, and nobody churns because a reply was slightly stiff. It is also the place where an over-helpful agent does the most damage, because a large share of internal requests are asking for access to something.
4 min read
Two piles that look the same
Answerable. How do I connect to the VPN, where is the expenses policy, how do I set up my new laptop, what is the wifi password for the meeting room, how do I request a monitor. Documented, repetitive, and currently eating someone's afternoon.
Access. Please add me to the finance drive, reset my password, give me admin on this tool, approve my request for the production database. These arrive in the same inbox, in the same casual tone, from people the agent recognises, and they are the ones an attacker imitates.
The distinguishing feature is not the wording. It is whether the outcome grants someone a capability they did not have.
The rule for the second pile
An email agent must never grant access, and must never be the thing that decides who gets it.
Not because the model would be careless, but because email is the wrong channel for the decision. The From header is a claim, an internal address can be compromised, and an agent that can be persuaded by a plausible message is a privilege escalation path with a friendly tone, per prompt injection by email.
What the agent can do with an access request is genuinely useful: recognise it, tell the person exactly where to make it, and route it to the right queue with the details already gathered. That is faster than what happens today and grants nothing.
| Request | Agent | Person or system |
|---|---|---|
| Documented how-to | Answers | |
| Status of an existing ticket | Answers from your system | |
| Hardware or software request | Collects details, routes | Approval workflow |
| Password reset | Points at self-service | Identity system, never email |
| Access to a system or drive | Collects, routes | Named approver |
| Anything about an incident | Escalates immediately | On-call |
Password resets deserve their own paragraph
A password reset over email is a well-known attack path, and an agent that helpfully triggers one is worse than a human doing it, because it does not hesitate at 3am on a Sunday.
The correct behaviour is a link to self-service and nothing else. If self-service does not exist, the answer is still not the agent: it is a person verifying the requester through a channel that is not the inbox the attacker already has.
Where it genuinely shines
Out of hours. The first question at 6am has an answer at 6am. For distributed teams this is most of the value, since "wait for the London team" is otherwise the answer to everything.
During onboarding. New joiners ask twenty documented questions in their first week and feel awkward asking any of them. An agent that answers instantly and without judgement is better than a colleague they have not met yet.
Finding the answer that exists. Most internal questions are answered somewhere in a wiki nobody can search. An agent that retrieves and cites is doing search that actually works, and the citation matters: it teaches people where the answer lives, so they ask once rather than forever.
Internal does not mean unmonitored
Two habits that internal deployments skip and should not.
Block your own agent addresses in the mail rules, because internal inboxes are full of other automation and two systems will correspond politely forever, per deciding what reaches your agent.
Keep the audit trail meaningful. Internal requests turn into "who approved this" questions surprisingly often, and a per-identity record of what was asked, what was answered, and what was routed is worth having before you need it, per what to monitor in production.
The wiki problem, honestly
If your documentation is bad, an agent surfaces that immediately: it answers wrongly from a stale page, or escalates constantly because nothing is written down. That is useful information rather than an agent failure.
The cheapest fix is to treat the escalation log as a documentation backlog. Every question the agent could not ground is a page somebody needs to write, prioritised by frequency, which is a better prioritisation than any wiki cleanup project has ever had.
Questions
- Is internal helpdesk a good first agent?
- Yes. The questions repeat, the audience is forgiving, and out-of-hours coverage is immediately valuable. It is also where an over-helpful agent does the most damage, because many requests are asking for access.
- Can it handle password resets?
- No. Point at self-service, and where that does not exist, route to a person who verifies the requester through a channel other than the inbox. Email resets are a known attack path.
- Can it grant access to systems?
- Never. It can recognise the request, gather the details, and route it to the approver. Granting is a decision that must not depend on an email being genuine.
- How do I stop it looping with other internal automation?
- Block your own agent and notification addresses in the mail rules, and cap turns per thread. Internal inboxes are full of other systems that reply.
- What if our documentation is bad?
- The agent will surface that immediately through wrong answers or constant escalation. Treat the escalation log as a documentation backlog ordered by frequency.
- What is the best test for a risky request?
- Ask what would happen if this exact message came from a compromised colleague's account. Anything with an uncomfortable answer belongs behind a person or an identity system.
Give your agent an address it can answer from.
Create an inbox