AI for Security · Solutions

Check who holds access to what.

AI Identity and Access Analytics reads sign-in records, roles and permission lists, and flags odd logins and accounts that nobody has used for months. Each flag is decided by a reviewer. This is decision support only. It gives no security or employment advice, and a flag never proves that anyone has done anything wrong, only that someone should ask.

Share your requirements

What it is

People change roles and keep old access. A contractor’s account still works, a leaver’s email still signs in, and an accounts clerk can open the payroll folder because someone once asked.

The software compares who has access with who actually uses it, and watches sign-ins for patterns that do not fit the person. It lists what it finds. A named reviewer decides what to remove or check. The reviewer’s name, the reason and the date are saved beside each decision.

Where it goes wrong today

The problems this is meant to ease.

Old access outlives the job

A contractor’s account still works, a leaver’s email still signs in, and a clerk who moved teams still opens the payroll folder. Nobody removed anything because nobody was asked.

Reviews are painful, so they slip

The yearly access review is a spreadsheet mailed to managers who cannot tell what half the entries mean, so they tick every line to close it. The review exists on paper only.

Powerful accounts are shared

Several people use the same administrator login, so a change made late in the evening carries no name, and the team spends the next morning guessing. Nobody can say who acted.

Strange sign-ins pass unseen

A login from a new device in another city is one line among thousands, and no one reads the sign-in log unless something has already gone wrong. Questions come too late.

Nobody owns the shared and spare accounts

Test logins, service accounts and shared mailboxes have no named owner, so they never appear in a review and never get a password change. They simply linger on.

Inside the module

What AI identity and access analytics does.

Access list per person

Who holds what, in one view. Each person’s accounts, roles, groups and permissions are listed beside their job and manager, so a reviewer can read it without asking five administrators.

Access and authentication patterns

Sign-ins are watched. Time, device, place and method are recorded for each authentication, so the usual pattern for each person becomes visible to a reviewer.

Unusual logins and permission use

Odd use is flagged for a question. A login far from the usual place, a rarely used permission suddenly exercised or a burst of failed attempts is marked, with the reason shown and no conclusion drawn.

Periodic access reviews

Reviews run on a schedule. Each manager receives the list for their team with last-used dates beside every access, confirms or challenges each line, and the responses are collected in one place.

Excessive and unused privileges

Unused access stands out. Rights not used for a stretch you set, and rights beyond what others in the same role hold, are listed as candidates for removal, which a reviewer approves.

Privileged access watched

Powerful accounts get closer attention. Administrator and shared accounts are tracked for who used them, when and for what, and an unusual use is escalated to a named security reviewer.

Leavers, movers and spare accounts

Leavers and movers are checked. HR dates are compared with live accounts, so the contractor whose account still works and the clerk who moved departments but kept old rights are listed for action.

Connected to identity and access systems

It reads your identity systems. The directory, single sign-on tool, access-control system and employee database are read through connections set up with you, and the data available depends on what each system exports.

Where it gets used

What this looks like in a working week.

An accounting firm with seasonal staff

Temporary staff join and leave. When they leave, the HR dates are compared with live accounts and each leftover access is listed for the administrator to remove once a reviewer approves.

A hospital with ward rotations

Nurses rotate between wards. The software shows which ward systems each nurse can still open, and the department manager confirms only the access that matches the current rota.

A managed service provider with client admins

A managed service provider holds administrator rights on many client systems, and each right that has gone unused for a stretch it sets is listed under the client name. The security reviewer decides.

A law firm checking matter access

A law firm compares who can open each client matter with the team assigned to it and lists anyone outside the team who still holds access for the partner. Each line gets an answer.

A bank branch with payment approvers

A regional bank keeps a short list of staff allowed to approve payments, and a use of that right from an unusual device is flagged to the security reviewer. The reviewer asks the user first.

Who touches it

The people who open this every day.

IT administrator

Removes or changes access once a reviewer has approved the change, and records the ticket that carried it out, so the audit trail shows both steps.

Department manager

Confirms each team member’s access during the review, and flags what is no longer needed for the job they now do, however long ago it was granted.

Security reviewer

Works through the sign-in flags, asks the user when a login looks odd, and marks each one as real or harmless, with the reason written beside it.

HR

Sends leaver and transfer dates, so the access list can be checked against who still works here, in which role, and from which date.

How it is set up

From first conversation to daily use.

Walk through who has access today
Start with the systems that matter. With the IT administrator and HR, list who owns each system and where its access list lives, whether in a directory, a sign-on tool or a spreadsheet.
Link accounts to people
Every account needs a person. Match accounts to employee records, find accounts that match nobody, and name an owner for each shared or service account before any flag is trusted.
Trial on one system’s past logs
Test on one system first. Compare the unused-access and unusual-login lists from its past logs with what the administrator already knows, and note which entries were wrong or already known.
Check the output with managers and reviewers
Managers read their own team’s list. The security reviewer and a few department managers say what they could not judge from the screen, and the wording and layout change until they can.
Go live with one review round
Go live with one review round. Send the lists to managers, collect confirmations and removals through the helpdesk or ticket system, and keep the old spreadsheet beside it for the first round.
Review the first round
Look back at the first round. Count completed reviews, exceptions raised and questions investigated, compare them with the earlier spreadsheet round, then adjust the rules for unused access and the places the data was incomplete.

Measuring it

How you would know it is working.

Record where you stand before it goes live, so the change is measured against your own figures.

Access review completion is the share of review lines answered by a manager, and the baseline is the last spreadsheet review, counted from the returned sheets.
Privilege exceptions count rights held beyond the role norm or unused for the chosen stretch, and the baseline is the first full scan before any removals are made.
Time to investigate runs from the moment a flag is raised until the reviewer logs a decision. The starting figure comes from helpdesk tickets that dealt with such questions before launch.
Leaver accounts still active are counted by comparing HR dates with live accounts on the day of the first scan, and again at each later review.
Ownerless accounts are counted.

Used responsibly

Where a person stays in charge.

Flags are questions, not verdicts

Flags raise questions, nothing more. A flag never proves that an identity is compromised or that anyone did wrong, and it shows only an access pattern that deserves a look. A reviewer decides what follows.

Removal needs human approval

Nothing is switched off automatically. A reviewer approves each removal, the administrator carries it out through a ticket, and the date, reason and names are stored with the record.

Privacy of sign-in data

Sign-in logs reveal movements. Place and device details are visible only to named reviewers, kept for the period your policy states, and used for access review alone, not for judging performance.

Data quality sets the limit

Muddy records give muddy flags. If employee records are out of date or accounts match nobody, the results are poor, so the first stage is cleaning the list of people and accounts.

How it fits

It is one part of a system, not an island.

A module earns its place by what it passes to the next one. These are the connections we set up most often.

Roles and permissions
Employee database
Exit and offboarding
Audit trail
Cybersecurity threat detection
Helpdesk automation

Already built in

Products that include it.

Built for you

How we would put it in.

Common questions

Questions owners ask about AI identity and access analytics.

Does it name risky people?

No, it does not. It shows unusual logins and unused access, then a person asks the user, checks the facts and decides what, if anything, follows. A flag is a question only. Nothing here is employment or legal advice.

What do we need first?

You need a fairly accurate list of employees and their accounts, plus sign-in logs from your main systems, and an owner for each shared account. Without that, the results stay weak.

Will it remove access itself?

No, a person does. Approval of each removal comes from a reviewer and the administrator carries it out. We can raise the ticket automatically, but the decision always stays with a person.

Is it useful in a small office?

Only slightly, at ten people. One manager can read the access list in an afternoon, and it fits better with many systems, contractors and frequent joiners and leavers.

Does it satisfy an audit rule?

That depends on the country. Local law and your auditor decide. Only the review records are prepared by the software. It gives no compliance view or promise.

What does it connect to?

The usual links are your directory, sign-on tool, access-control systems, employee database and helpdesk, each connected through its own export or interface. Some systems give less data.

How accurate are the flags?

Accuracy depends on clean records. Expect some flags to turn out harmless because people travel, change phones and take on temporary duties, and a reviewer marks those so they stop returning.

What effort and cost are involved?

Most of the effort goes into matching accounts to people and agreeing who reviews what, and the software setup is the smaller part. Cost follows systems and users. We quote after seeing your lists.

Who needs it most

Businesses that ask for this.

Next to it

Modules that work with it.

Talk to us

Tell us how you handle AI identity and access analytics today.

A spreadsheet, a register or another system: say which, and we will tell you plainly what is worth changing.

No obligation
A reply within one business day
Your details stay private

Start with your requirements

Seven short steps that tell us what you need. An engineer reads them before getting in touch.