Enterprise identity environments generate a constant stream of audit questions. Which accounts are stale? Who has privileged roles? Which users bypass MFA? How many guest users exist? Which accounts haven't signed in recently? The data exists inside Microsoft Graph, but getting answers requires knowing exactly how to retrieve it.
That creates a real operational bottleneck. Most technicians do not work fluently in Microsoft Graph. They may understand the identity problem itself, but not the API structure behind it — which endpoints to call, how to authenticate, how to filter results, how to interpret nested data structures, or how to chain queries together properly. So the work falls to the handful of engineers who understand Graph deeply enough to build the query manually.
And when those engineers are busy, the audit often simply does not happen. The issue was never lack of data. The issue was query friction. Open Graph Explorer. Find the endpoint. Build the filter. Test the request. Fix the permissions issue. Parse the response. Repeat. Ad-hoc identity audits became skill-gated operational work instead of simple questions the team could ask naturally.
who understood Graph API structure
because writing the query took too long
questions they were designed to answer
AOtech built a local-LLM Graph API agent designed specifically to remove the query barrier between technicians and Entra ID visibility. The system sits in front of Microsoft Graph behind an Ollama-hosted qwen2.5:7b model running locally. Instead of requiring technicians to understand Graph query syntax, the agent accepts plain-English identity questions and handles the Graph interaction layer automatically.
When a user asks a question like "Which guest accounts haven't signed in within 90 days?" or "Who has privileged roles without MFA enabled?", the model determines which Graph API endpoints are required, structures the appropriate query, executes it against live tenant data, and returns the results in readable operational language. No PowerShell session. No Graph Explorer. No pre-authored scripts or static reports.
The architecture intentionally avoided hardcoded reporting logic. Traditional identity reporting systems answer the questions they were explicitly designed to answer. AOtech wanted something operationally flexible instead — an interface layer capable of handling ad-hoc identity questions dynamically. The local-LLM tool-calling model effectively turned Microsoft Graph from an API technicians had to program against into a system they could interrogate conversationally.
Identity auditing shifted from specialist work into operational workflow. Questions that previously required manual Graph research and scripting now get answered interactively in seconds. Technicians no longer need to understand Graph endpoint structure just to investigate identity posture inside Entra ID.
The operational impact was less about speed and more about accessibility. Before the agent existed, many audit questions simply were not asked because the effort required to retrieve the data outweighed the urgency of the request. The agent lowered the skill floor required to perform identity investigations without lowering the quality of the underlying data retrieval.
It also fundamentally changed how the team interacted with Microsoft Graph. Instead of building one-off scripts and maintaining scattered reporting logic, the organization gained a reusable operational interface sitting directly in front of live Entra ID data. The result was consistent identity visibility without requiring every technician to become a Graph API specialist first.
instead of writing Graph queries manually
instead of stale exported reports
instead of a small specialist group
"Before this, half the battle was remembering how to structure the Graph query. Now we just ask the question and move on to the actual problem."Enterprise Identity Architect · Industrial manufacturing firm