Identity investigation comes down to two questions, and they show up as two different jobs.
The activity, a contractor exports thousands of customer records on a valid account with an approved permission. Nothing is blocked, nothing fails. The only question that matters is whether the activity is legitimate: does it fit this person, this device, and this assignment, or is it an incident wearing valid credentials?
The access, a service account with admin rights to production has not been used in ninety days. Nothing has happened at all. The question is whether that access is still needed, and whether it is safe to remove, or whether some undocumented quarterly job still depends on it.
One is activity that looks wrong. The other is access that looks wrong. They feel like different problems, but they stall in exactly the same place.
The context that answers either one rarely lives in a security tool. It lives in people's heads, in a ticket someone closed months ago, in a Slack thread, in a spreadsheet a team quietly owns, in an approval a manager gave out loud in a meeting. Whether that export was justified, whether the stale account still runs a job, whether a live service depends on the credentials you are about to revoke, these answers are scattered across the business, not recorded in the identity provider.
So the real test of an identity investigation tool is whether it can reach that scattered, human context and pull it into the case, so you can answer both questions: whether the activity made sense, and whether the access is still needed and safe to change. A tool that reads only structured system data will always be missing the half of the story that explains intent and makes remediation safe.
This guide covers the six capabilities that separate a tool that explains a problem from one that resolves it.
1. Connected identity and business context
Both questions from the opening come down to the same move: connect the identity to everything around it.
Take the activity case. A contractor downloads sensitive records on a valid account with an approved permission. Nothing is blocked. It becomes an incident only when you add the rest: the device is unmanaged, the assignment needed a handful of records, and no ticket or project explains the bulk export. Now take the access case. A service account holds broad rights to production. Whether that is fine or dangerous depends entirely on what still runs on it and who owns it. Neither answer comes from entitlements alone.
A strong tool assembles the full picture around the identity:
- Identity and account information
- Effective permissions
- Authentication and session activity
- Device posture
- Ownership and organizational role
- Business justification
- Relevant tickets, projects, and policies
The first items live in your systems, the last two rarely do. The reason access exists, the project that justified it, the person who actually understands a service account, these sit in tickets, documents, and people's heads. Pull them in and you can tell whether an action made sense and whether access is still needed. Skip them and a tool can only confirm what was technically permitted, which is the one thing you already knew.
Reaching that context is an operational problem, not a data model one. A tool has to connect to ticketing, HR, and the channels where work actually happens, and infer the likely owner from who created an identity, who uses it, and who is named on related tickets. When the record still is not there, it should ask that owner a specific question in the tools they already use and fold the answer back into the case. Ownership is usually the missing piece, so a tool that cannot infer and confirm it will stall on the exact accounts you most need answered.
2. A graph the agent reasons over, not another visualization
Enterprise access is rarely a flat list. An identity can gain access through direct permissions, nested groups, inherited cloud roles, delegated administration, OAuth grants, trust relationships, or service account associations. Mapping those relationships is essential. The real question is who does the reading.
Most tools turn that graph into a picture and hand it to you. A dense, impressive diagram is not an answer. It is one more screen to interpret while the actual questions stay open:
- How did this identity gain access to this resource?
- Which group or role created the access?
- What sensitive systems could a compromised identity reach?
- Which identities can escalate to a privileged role?
- What would be exposed if this account were compromised?
The graph should power the investigation, not become it. The stronger approach uses the access graph as the substrate an AI agent reasons over. The agent traverses those relationships, ties them to activity and context, and returns a clear conclusion, instead of handing you a visualization and leaving the analysis to you. Judge a graph by the answers it produces, not by how it looks.
3. Coverage across hybrid environments
Most organizations run identity across several worlds at once: Active Directory for legacy apps, Okta or Microsoft Entra ID for the workforce, cloud IAM for infrastructure, and dozens of SaaS apps with their own permission models. A tool has to connect those into one identity story, across hundreds of applications and tens of thousands of identities, without a team babysitting connectors to keep it current.
Evaluate:
- Which integrations are native
- What each one actually collects
- How fresh the data is
- Whether historical activity is available
- How identities are correlated across systems
- How much upkeep custom integrations demand
Availability is not depth. A connector that imports account names is not the same as one that understands permissions, activity, ownership, and how they relate. Ask what each integration knows, not just what it connects to.
4. Non-human identity investigation
Service accounts, API keys, OAuth apps, workload identities, automation credentials, and AI agents need the same depth as human users, and they usually get less. They run continuously, hold broad permissions, and often have no clear owner. At most organizations they outnumber human identities many times over, so discovering and understanding them cannot be a manual census.
A strong solution can:
- Discover non-human identities
- Identify their owners
- Understand what they are for
- Map their effective access
- Analyze how permissions are actually used
- Flag access that exceeds their purpose
- Pull them into remediation
Put it to the test. Hand the vendor a real service account and ask what it does, who owns it, what it can reach, and whether those permissions are still needed. The distance between a confident answer and a shrug tells you most of what you need to know.
5. Safe remediation you can trust
Finding excess access is easy. Removing it safely is the hard part, and it is exactly where autonomy makes practitioners nervous, correctly. A permission that looks unused might run a monthly job. A service account might hold broad rights for critical automation. A contractor's odd-looking privileges might belong to a live project. Get it wrong and you have turned a cleanup into an outage.
Safe removal depends on knowing:
- How the permission is used
- Which process depends on it
- Who owns the identity
- What removing it would affect
- Whether approval is required
- Whether the change actually worked
As with detection, the evidence that settles this usually is not in the identity system. It is in a ticket, a runbook, or the head of whoever set the access up.
The harder question is why you would let a tool act on any of it. The answer cannot be "trust the model." It has to be an operating model around every change. Capture the prior state so the action is reversible. Bind the agent to explicit policy and permission limits. Size the decision by blast radius: a clearly unused, policy-cleared permission can be handled automatically, while anything touching production, standing privilege, separation of duties, or customer data goes to a human with the full case attached. After the change, verify both the security outcome and the business process, and roll back on a defined trigger if either breaks. And the reasoning behind every conclusion should be inspectable, so you see the evidence and the intended path before you approve, not a verdict from a black box.
Evaluate the autonomy the way you would evaluate a new hire with production access. Ask what state it preserves, what policy bounds it, what it will not do without you, how it proves success, and how it backs out. A tool that cannot answer those does not get to touch production. The goal is not to automate every decision. It is to hand the right person a decision instead of a research project, and to let the safe, boring changes take care of themselves.
6. Audit evidence and operational integration
Every investigation and every change should leave a record that shows:
- What triggered it
- What evidence was reviewed
- What was concluded
- Who owned or approved it
- Which policy supported it
- What was remediated
- Whether the result was verified
That record is what carries you through compliance reviews, access certifications, and incident reports. And the tool has to live inside your stack, not beside it. Look at how it connects to your SIEM, SOAR, identity governance, privileged access, ticketing, collaboration, HR, and cloud security systems, and whether it works in both directions: taking context in, and pushing findings, decisions, and outcomes back out.
How to run an effective evaluation
Do not start with a vendor's feature list. Start with the questions your team cannot answer today. Pick a few real ones:
- A former contractor who still has privileged access
- A user who became an admin through nested groups
- An unexplained bulk download
- A service account with no known owner
- An identity with a quiet path to sensitive data
Hand each vendor your data and those scenarios, and score them on outcomes, not demos:
- Did it reach a clear conclusion?
- Did it show the evidence?
- Did it find the real owner?
- Did it recommend a safe next step?
- Would you trust that action enough to approve it, and could you see the reasoning behind it?
- Could it move that step through your workflow?
- Did it verify the risk was actually resolved?
This is how you avoid investigation theater: impressive graphs and risk scores that still leave your team doing all the analysis and coordination.
Investigation is not the final outcome
An investigation is worth something only when it moves the work forward, and it only moves when it answers both questions we started with: is the activity legitimate, and is the access safe to change. Every step toward those answers depends on context that lives outside the identity system. Reaching it is what separates a tool that explains a problem from one that closes it.
This is the approach we take at Offroad. Offroad is an AI-native identity security team. Its agents continuously investigate identity risk across human identities, non-human identities, service accounts, OAuth apps, and AI agents. They connect access, activity, ownership, and business context into the full identity story, reason over it, act where policy allows, and bring a human the completed case when judgment is required.
The goal is not another place to investigate identity risk.
The goal is completed identity security work.
Frequently asked questions
What is the difference between identity governance and identity investigation?
Identity governance manages access through provisioning, certification, approvals, and policy enforcement. Identity investigation explains what happened when suspicious activity or an access risk appears, connecting permissions with behavior, ownership, and business context.
Do identity investigation tools replace SIEM or SOAR tools?
No, they add deeper identity context to the existing stack. A strong solution takes signals from your security tools, runs the investigation, and pushes findings and outcomes back into established workflows.
Can I trust an agent to change access on its own?
Only inside limits you set. Safe autonomy means the agent captures the prior state, stays within explicit policy and permission bounds, handles only low-risk, policy-cleared changes by itself, and routes anything high-impact to a human with the full case attached. It verifies the result and has the ability to roll back. High-impact identity changes should always keep a human gate. If a tool cannot show you those controls, it should not act unattended.
How is this different from an access review or a posture tool?
Access reviews and posture tools tell you access exists and flag what looks risky, but they are point in time. A certification is a snapshot taken once a quarter, and risk accumulates in the gaps between them: access granted the day after a review, a service account that goes stale in month two, a contractor who changes roles and keeps the old permissions. By the next review the picture has already drifted. Investigation is continuous, and it answers the questions that come next: is this activity legitimate, is this access still needed, and is it safe to change. Those answers depend on context that certification and posture tools do not hold. Investigation is the layer between finding a risk and actually resolving it.
