AI in Identity and Access Management: How SaaS Identity Discovery Is Changing

An unfamiliar account appears in your team’s project management platform. Nobody remembers creating it. It could belong to a contractor who left months ago, an employee using another email address, a service account, or an AI assistant connected to the application.

Finding the account is easy. Understanding who or what controls it is harder.

Identity discovery and account correlation already exist in traditional identity and access management (IAM) systems. AI is increasingly being added to these workflows to help analyze fragmented identity data, prioritize suspicious accounts, and investigate matches that are difficult to resolve using exact identifiers alone.

But AI does not remove the need for verification. A suggested match is evidence to investigate, not automatic proof that two accounts belong to the same person or that access should immediately be removed.

What Does Identity Discovery Mean in SaaS?

In a SaaS security context, identity discovery means finding the human and non-human accounts that can access business applications and determining who or what those accounts belong to.

In a small organization, this may be straightforward. An administrator can compare the users in a SaaS application against the company’s employee directory.

Things become harder as the environment grows.

A business may have employees, freelancers, vendors, temporary workers, service accounts, integrations, automation scripts, and AI agents spread across dozens or hundreds of cloud applications. Some accounts may use personal email addresses. Others may remain active after the original owner leaves.

The real challenge is not simply discovering accounts. It is connecting each account to a reliable owner, purpose, and access policy.

It Starts With Scattered Identity Clues

You may sometimes have only an email address or phone number when investigating an unfamiliar account. If you search that detail on Searqle, treat any possible connection as a starting point rather than proof of account ownership.

Inside a business, stronger evidence usually comes from sources such as employee directories, contractor records, provisioning data, invitation history, and application logs. Each source can answer a different part of the ownership question.

The employee directory may confirm that someone still works for the company. An invitation record may show who originally gave the person access. Authentication and activity logs can reveal whether the account is still being used.

These records do not always match cleanly.

A contractor might use a personal email address in one application and a company address in another. An employee may have duplicate accounts after changing departments. A service account created for a temporary project may remain active long after the project ends.

How SaaS Account Discovery Works

A practical identity discovery process usually involves several stages.

Stage	What Happens	Example
Discover	Collect identities from applications and directories.	Find accounts across CRM, project management, and file-sharing tools.
Correlate	Connect application accounts with known identities.	Match an app account to an employee using a corporate email or employee ID.
Classify	Determine what type of identity it is.	Employee, contractor, service account, integration, or AI agent.
Review	Check whether its access still matches its purpose.	Determine whether a former contractor still needs access.
Remediate	Remove, reduce, reassign, or expire unnecessary access.	Disable an abandoned account or reduce excessive privileges.
Monitor	Watch for new accounts and permission changes.	Flag an inactive service account that suddenly becomes active.

This process also supports the broader identity lifecycle. Security teams often describe this as the Joiners, Movers and Leavers process: access must change when someone joins a company, changes roles, or leaves.

Deterministic Matching vs. AI-Assisted Identity Matching

Not every identity match requires AI.

The simplest cases use deterministic matching. This means comparing identifiers that should consistently refer to the same person across different systems.

Common examples include:

• employee ID
• corporate email address
• username or user principal name
• a stable directory or application identifier, where both systems support it

Microsoft Entra provisioning, for example, can use configured matching attributes to determine whether a user in one system corresponds to a user in another system. Administrators can define matching attributes and their order of precedence based on what the target application supports.

You can read more in Microsoft’s application provisioning documentation.

But exact identifiers are not always available.

Imagine that a project management application contains an account named “Alex Morgan,” while a file-sharing platform contains “A. Morgain.” The names look similar, but that alone is not enough to conclude that they belong to the same person.

Additional evidence might include:

• related email addresses
• the same department or project
• the same manager
• the same person sending both invitations
• matching contractor records
• similar application activity

When exact identifiers are unavailable, some AI-assisted identity systems can use multiple signals to prioritize possible matches for human review.

This should not replace reliable identifiers where they are available. A weak or ambiguous match should remain unresolved until an administrator has enough evidence to verify it.

How Much Confidence Should You Place in a Match?

Identity matching should not be treated as a simple yes-or-no decision when the underlying evidence is incomplete.

Confidence	Example	Recommended Action
High	Matching employee ID and corporate email	Likely safe to correlate after normal validation
Medium	Similar email, same manager, and same project	Review supporting records manually
Low	Similar name only	Keep the identities unresolved

This matters because identity matching can fail in two directions.

A false positive happens when a system combines accounts that actually belong to different people. A false negative happens when it fails to connect accounts that belong to the same person.

Both can create security problems.

A false positive could cause an administrator to revoke legitimate access or attribute someone’s activity to the wrong employee. A false negative could leave an abandoned or excessive-access account undiscovered.

Administrators should therefore be able to inspect the records behind an AI-generated recommendation rather than relying only on a generated summary.

Do Not Automate High-Impact Actions From Weak Matches

High-impact remediation should not be triggered solely by a low-confidence AI match.

Automatically disabling an account, revoking privileges, or reassigning ownership can interrupt legitimate work if the underlying correlation is wrong.

Organizations should define confidence thresholds and require human review for ambiguous or high-impact cases.

AI Agents Create a New Identity Challenge

People are no longer the only identities accessing SaaS applications.

AI agents may read customer information, query databases, create support tickets, schedule meetings, update CRM records, call APIs, or perform multi-step workflows across several applications.

That creates an important identity question: who or what is actually performing the action?

An AI scheduling assistant may act on behalf of an employee using delegated access to a calendar. A support agent may instead operate using its own workload or service identity.

Some systems combine both approaches. An agent can have its own identity while receiving temporary authority to perform a particular task for a person.

This makes ownership and attribution especially important.

If an AI assistant changes a meeting for an employee, the audit trail should ideally show that the agent performed the action on behalf of that employee rather than making the activity appear as though the employee performed it directly.

Human, Service, and AI-Agent Identities Compared

Identity Type	Typical Purpose	Example	Key Security Question
Employee identity	Human access to business systems	Developer accessing a Git repository	Does access match the person’s role?
Contractor identity	Temporary human access	Freelancer accessing a project workspace	Does the access have a clear expiration date?
Service account	Application-to-application automation	Backup service accessing cloud storage	Who owns and maintains the account?
AI agent	Software performing tasks or making decisions	Support agent reading orders and updating tickets	What can the agent decide and execute?

What Permissions Should an AI Agent Receive?

Access should start with the task the agent needs to perform.

Suppose a support assistant needs to answer customer questions about deliveries. It may require access to order status and shipping information.

That does not automatically mean it should also be able to issue refunds, change payment details, export customer databases, or modify user accounts.

A useful principle is to give the agent only the access required for its approved tasks.

For higher-risk actions, an additional control may be appropriate.

For example, an AI assistant could prepare a refund request but require an employee to approve it before money is returned.

Authentication and Authorization Still Matter

Authentication answers the question, “Who or what is making this request?” Authorization answers, “What is that identity allowed to do?”

An AI agent may authenticate successfully and still be denied an action that falls outside its assigned permissions.

This distinction becomes particularly important as agents gain access to multiple APIs, applications, and business systems.

Human administrator accounts need protection too. If an application still relies on password-based authentication, administrators should use a unique, high-entropy password rather than a reused or predictable credential. CodeItBro’s Password Generator can create random passwords locally in the browser, while the Password Strength Checker can help evaluate the strength of a proposed password.

Password strength alone is not enough for sensitive accounts. Multi-factor authentication adds another verification step and can reduce the impact of a stolen password. Developers implementing or testing TOTP-based authentication flows can use CodeItBro’s 2FA Code Generator to generate RFC 6238-compatible test codes.

These password and 2FA tools are most relevant to human authentication and development testing. Production AI agents and service workloads should normally use appropriately managed machine identities, delegated tokens, certificates, or other application-specific credentials rather than manually created human passwords.

AI Agent Access-Control Checklist

Before connecting an AI agent to business applications, review the following:

• Does the agent have a clearly identifiable identity?
• Is a person or team responsible for it?
• Which applications can it access?
• Which records can it read?
• Which records can it create, modify, or delete?
• Can it perform financial or other high-impact actions?
• Are its credentials appropriately protected?
• Are credentials or tokens short-lived where practical?
• Can permissions expire automatically?
• Can access be revoked quickly?
• Are the agent’s actions logged separately from human activity?
• Do sensitive actions require human approval?
• Are permissions reviewed when the agent’s responsibilities change?

Zero Trust Still Applies to AI Agents

Running an AI agent on a company-owned device, corporate server, or internal network should not automatically make it trusted.

The identity still needs to be authenticated, its request needs to be authorized, and the resource being accessed should be covered by the organization’s access policies.

The same principle applies to service accounts and other non-human identities.

Location alone is not identity.

This becomes especially important when an agent can dynamically choose tools or interact with several services while completing a task.

The Cloud Security Alliance discusses these challenges in its guidance on agentic AI identity and access management, including agent identities, delegation, fine-grained authorization, policy enforcement, and continuous verification.

Common SaaS Identity Discovery Problems

Even a good identity discovery system has limitations.

• Unsupported applications: An identity platform cannot reliably discover accounts in applications it cannot connect to or collect data from.
• Stale directory records: Outdated HR or identity-provider data can produce incorrect conclusions.
• Personal email addresses: Contractors and temporary workers may create accounts outside the company’s normal email structure.
• Duplicate accounts: One employee may have multiple identities in the same application.
• Orphaned accounts: An account may remain active after the original owner leaves.
• Shared accounts: Multiple people using the same credentials makes individual attribution difficult.
• Service accounts without owners: Automated identities can remain active long after the original project or integration ends.
• Long-lived permissions: Temporary experiments can quietly turn into permanent access paths.
• Incomplete logs: Investigation becomes harder when an application exposes limited identity or activity information.

How to Test AI Identity-Matching Results

Do not begin by allowing an automated system to make access decisions across every SaaS application.

Start with accounts whose ownership your team already understands.

A useful test set could include:

1. A contractor account belonging to someone who has already left.
2. Two accounts with different email addresses that belong to the same employee.
3. Two people with similar names who should not be merged.
4. An application service account.
5. An account used by an AI assistant.

Then review the results.

Did the system correctly identify the responsible owner? Did it distinguish human accounts from non-human identities? Did it leave uncertain matches unresolved? Can administrators inspect the records supporting each recommendation?

Testing should look for both false positives and false negatives.

A Practical SaaS Identity Review Workflow

1. Inventory applications. Identify the SaaS platforms that store business data or provide access to important workflows.
2. Collect identities. Pull user, service-account, integration, and agent identities from those applications where supported.
3. Match known identities first. Use reliable attributes such as employee IDs and corporate email addresses where possible.
4. Investigate uncertain accounts. Compare directory records, invitation history, ownership information, and relevant activity.
5. Classify non-human identities. Separate service accounts, automation, integrations, and AI agents from normal employee accounts.
6. Review privileges. Check whether each identity has only the permissions needed for its purpose.
7. Resolve abandoned access. Disable, expire, reassign, or reduce access where appropriate.
8. Document ownership. Important service accounts and AI agents should have a responsible person or team.
9. Monitor changes. Repeat discovery and access reviews as employees, applications, agents, and business processes change.

AI Can Improve Identity Discovery, but It Does Not Replace Governance

AI can make identity investigations faster by correlating fragmented records, highlighting suspicious accounts, and helping administrators investigate matches that are difficult to resolve using exact identifiers.

That becomes increasingly useful as SaaS environments include not only employees and contractors but also service identities, integrations, and autonomous AI agents.

But discovering a likely identity is only one part of the problem.

Organizations still need to determine who owns the account, why it exists, what it should be allowed to access, how long that access should last, and who is responsible when its purpose changes.

The most useful identity systems do not simply produce confident answers. They give administrators enough evidence to verify those answers and make safer access decisions.