Ask Your IAM System Why: Read-Only AI on One Identity Manager

September 29, 2026 · InfraScout Team

Your identity platform knows what should exist and who holds which rights. Getting that knowledge out of it is another matter. Questions like "why does this person have access to that group?" or "what did yesterday's department change actually do?" usually mean clicking through object histories, process logs and role assignments, then checking Active Directory to see whether it matches. A first-party integration from ITDESIGN lets InfraScout read One Identity Manager directly, so you can ask those questions in chat. It is read-only by construction. The AI can look at everything and change nothing.

How It Connects

The integration is an MCP server, so it plugs into InfraScout the same way any other external system does. It is governed by the same tool groups and role tiers as every other tool. It reads the One Identity Manager database, while InfraScout's own agents check the directory and servers on the other side.

The pairing matters. One Identity Manager tells you what should be true, and an agent can go and check whether Active Directory agrees.

What You Can Ask

The integration offers 27 tools (as of September 29, 2026), grouped into four families.

The data and identity tools cover inventory, object lookup and object history: who changed what, and when. Two of them answer the questions IAM teams get asked most often. The entitlement origin tool explains why a person holds a right, and the entitlement trace shows which role carries it. The process tools look at process errors, trace what a change set off, and diagnose the job queue. The health tools inspect the database queue, locks, waits, deadlocks, storage and indexes. The schema tools search, describe and relate tables, so the AI finds its way around a customized data model instead of guessing at it.

The inventory tool is a good first question. It gives an overview of identities, AD accounts, requests, attestation cases and memberships. It also flags AD accounts that no identity owns, and says plainly that these can be service accounts, sync leftovers or genuine orphans. Deciding which is which stays with you.

What It Looks Like in Practice

The scenarios below come from running the integration against a real One Identity Manager environment. Names and identifying details are left out.

Why did this person get these rights?

An employee moved to a new department and picked up access to a new set of groups. The question was why. The object history showed a manual department change early in the morning. The process trace showed everything that change set off: several AD account updates, an automatic notification mail, org and role recalculation, and new group memberships inherited from the department role. A live check in Active Directory through an InfraScout agent confirmed that One Identity Manager and AD agreed.

That used to mean correlating AD event logs by hand. Now it is one question and a few minutes.

The job that failed silently

A look into the job queue found a provisioning job that had been frozen for months. One Identity Manager had marked an admin account as deleted, but the delete in the target AD had ended with "Access is denied", so the real account may still exist. Nothing had alerted on it. The AI reported the job, explained what it meant, and printed the statement to reactivate it for a person to review and run. It didn't run it.

Two automations fighting each other

A local-admin group kept disappearing and coming back. The object history showed the One Identity Manager service account recreating it. On the AD side, a scheduled hygiene script kept deleting it, and the two went back and forth for several cycles. The root cause turned out to be an empty operating-system attribute on a Linux computer object. Neither tool would have shown this on its own. It took the identity platform's history and the directory's current state side by side.

Read-Only by Construction

Letting an AI read your production IAM system only works if it can't write to it. The integration enforces that in the server, not through a promise in the AI's instructions.

It connects with a database account that holds read rights only. On top of that, a query gate rejects anything that isn't a plain query: procedure calls, queries that write their results into a table, and schema changes are all refused, whatever the database account itself could do. Results come back with row and size limits, and the tool always says when a limit cut something off.

The AI doesn't fix what it finds, either. A frozen job is not reactivated and a permission is not granted. When a fix is obvious, the tool prints the statement for a person to run. Everything that comes back is treated as data, never as instructions. That matters in an IAM system full of free-text fields, such as descriptions, comments and request reasons, which anyone can type into.

Honest About Blind Spots

Some health checks need a server-level permission that the read-only database account doesn't have. When that permission is missing, the tools for blocking, waits and deadlocks refuse to answer instead of reporting "all clear", and the overall diagnosis lists them as not checked. A missing permission is reported as a gap, never as an all-clear. If you want those checks, grant the permission deliberately. If you don't, you still know exactly what wasn't looked at.

Start with a question you already ask

Pick a question your IAM team answers by hand every week, like "why does this person have this access?" or "what did last night's department changes trigger?", and ask it in chat. Then ask the AI to check the result in Active Directory.

Next Steps

If you run One Identity Manager, contact us to connect it to your tenant. MCP as the extension layer explains the model behind external integrations, MCP Servers covers registration and the tool allowlist, and Tool Groups is where you decide who gets to use it. To connect your monitoring the same way, see WATCH IT in Chat.