Discover
See every identity you have.
Connect one system read-only and Amberlock returns your first meaningful findings within the hour — not a finished inventory, which would take as long as your estate is large, but the accounts and privileges that matter most, first.
The model
Six things, and how they connect.
Most tools store a list of accounts. Amberlock stores a graph, because every question worth asking is a question about a relationship.
- IdentityA person, a workload or an agent. The thing that persists when accounts come and go.
- AccountOne login in one system. A single identity usually has a dozen, spelled differently in each.
- EntitlementWhat that account can actually do. The admin role, the permission set, the group nesting.
- ResourceWhat the entitlement reaches — the object, the repository, the ledger, the bucket.
- OwnerThe human accountable for it. Absent far more often than anyone expects.
- ActivityWhether any of it has been used, and when. Dormancy is a finding all by itself.
Why the graph is the point.
“Who can approve a payment in NetSuite?” is not a question about accounts. It is a question about which identities hold which entitlements over which resources, through which nested group, and whether any of them left the company in March. A list cannot answer it. A graph answers it in one hop.
Identity types
Five populations, five reasons they hide.
Ant — the employee. Ordered, countable, mapped to an org chart.
Employees
Hard because: the directory record is accurate and the access is not. Roles change; entitlements accumulate. Nothing in a joiner–mover–leaver flow removes what a previous role granted inside an application.
We surface: entitlements that no longer match the current role, access granted outside any request, and privilege that survived a transfer.
Worker bee — the contractor. Brought in to do a job, belongs to another hive, should leave when the work is done.
Contractors and non-employees
Hard because: they are rarely in the HR system, so there is no authoritative leaver event. The engagement ends in someone’s inbox, not in a workflow.
We surface: non-employee accounts with no end date, access still live past the engagement, and contractors holding standing privilege.
Scorpion — the service account. Ancient, over-privileged, still venomous.
Service accounts
Hard because: nobody provisioned them through an identity provider, so no identity provider governs them. They were created to make something work, at a moment when making it work was the only priority.
We surface: unowned service accounts, standing domain privilege, credentials that have never rotated, and accounts whose last interactive login predates the current CISO.
Spider and web — the API key. Sticky, spread everywhere, threading across systems.
API keys and secrets
Hard because: they are not accounts, so account-shaped tools do not see them. They live in repositories, CI configuration and vendor consoles, each with its own idea of what a credential is.
We surface: keys with no rotation history, tokens tied to departed employees, and credentials with far broader scope than the job they were minted for.
Butterfly — the AI agent. Newly emerged, moves fast, looks more fragile than it is.
AI agents
Hard because: most run on a human’s credentials. Your directory sees the human, your logs attribute the action to the human, and the actual actor is a process that never sleeps and never gets offboarded.
We surface: agent activity separated from the human it borrows, agents holding privilege beyond their task, and agents still running after their owner left.
Correlation
One person. Eleven accounts. Four spellings.
The same person is j.smith in Active Directory,
jsmith@ in Google Workspace, Jennifer S. in
Salesforce and an unlabelled numeric ID in Snowflake. Until those resolve to
one identity, every count you have is wrong and every review is incomplete.
Amberlock correlates on the signals that actually hold — directory linkage, employee identifiers, mail routing, device and session overlap, provisioning lineage — and unifies them into a single identity with all its accounts, entitlements and activity attached.
Where it is ambiguous, a human decides. We do not silently merge two records because they look similar, and we do not quote you an accuracy percentage — there is no industry benchmark to measure one against, and a number without a benchmark is decoration. Ambiguous matches surface as a short review queue, and every resolution is recorded so it never has to be made twice.
The boundary
What your identity provider cannot do here.
This is not a criticism of Okta or Entra. It is a description of what they are for. They are the front door, and they are good at being the front door.
Structurally cannot
- Read entitlements inside an application it federates
- See a local account that never used SSO
- Govern a service account it never provisioned
- Inventory an API key, which is not an account
- Tell an AI agent apart from the human whose credentials it holds
- Confirm that a revocation propagated downstream
Amberlock adds
- Entitlement-level reads on the systems where reviews fail
- Local and non-federated accounts, found and attributed
- On-prem Active Directory via a read-only collector
- Keys and secrets as first-class identities
- Agents separated from their borrowed credentials
- Verified remediation — a re-scan, not a checkbox
Find out what is in your amber.
Register for early access. Connect one system read-only, and see your first findings within the hour — the accounts nobody owns, the privilege nobody granted, the access that was never actually removed.
Scorpion — the service account. Ancient, over-privileged, still venomous. Real scorpions turn up in real amber, which makes this the most literally accurate specimen in the set.