Non-human identity management, including the agents
Service accounts, keys and workload identities outnumber people and are governed less. What non-human identity management covers, and what an agent adds that credential hygiene does not reach.
The problem
What this is actually about
A non-human identity has no lifecycle to hang governance on. Nothing equivalent to an employee leaving triggers deprovisioning, the creator moves on and accountability evaporates, credentials get copied into config and CI, and permissions granted for the hardest case the software might ever face are never reduced.
Agents make the harder version of the problem. A batch job’s behaviour is a narrow, stable distribution, so least privilege can be derived from observation. An agent decides what to do — it may call a tool it has never called, or act on content it just read — so behavioural baselining weakens exactly where the authority is widest. It also acts on behalf of someone, which makes its delegation chain part of its effective authority.
What the platform does about it
Read from the product architecture rather than written here, so this page cannot promise something no module ships.
Which non-human identities exist, and what are they holding?
- Read-only discovery across Entra, AWS, Google Cloud, Kubernetes, GitHub and databases, so onboarding never starts by asking for write access to an identity provider
- A graph rather than a list: owner to agent to workload identity to credential to resource, each link searchable
- A credential inventory that separates short-lived and federated credentials from long-lived bearer secrets, and says when each last rotated
- Effective permissions computed from roles, groups and resource policies together, rather than the assigned roles a console happens to show
- Least-privilege analysis against observed use, so an identity granted 132 actions and using 17 can be right-sized on evidence
- Findings that persist rather than pass: dormant, ownerless, overprivileged, shared, and credential expiring
- Toxic permission combinations and segregation-of-duties rules that only exist across identities, never within one
- A migration path off static secrets — federation first, then credentials brokered per action and expired after it
What AI agents exist here?
- Connectors across AI platforms, cloud, identity providers, source control, enterprise applications and infrastructure
- Shadow agent discovery from model API traffic, AI keys, MCP configuration, SDK dependencies and automation credentials
- An inventory record per agent: owner, purpose, model, framework, tools, MCP servers, data sources, permissions and secrets
- Ten lifecycle statuses from Discovered through Quarantined and Retired
What is this agent allowed to reach?
- Role and attribute rules evaluated with agent, user, tenant, data, tool, environment, time, risk and declared purpose in context
- Action-level permissions, so reading a supplier and changing its bank details are separate grants
- Five sensitive action classes from read through draft, reversible execution, human approval and dual approval
- Just-in-time privileges that are issued for one action and expire rather than accumulating
- A credential broker that issues scoped, short-lived secrets on request, so an agent never holds a permanent key
What is the record, and can it be trusted?
- An append-only record of agent, user, session, resource, action, policy, decision, tool, model, result and risk
- Customer-configurable retention from 30 days to seven years
- Tenant isolation on every record, so no agent can read across the boundary
- Event-driven telemetry that keeps the authorization path fast and synchronous while analytics runs behind it
What it leaves behind
The artefacts these modules produce. Evidence generated by a decision, rather than assembled for an audit afterwards.
- A count of long-lived credentials, and which workloads could stop using them
- A blast radius per credential: what it reaches, and which agents depend on it
- An ownership figure an auditor can check, with the gap named
- A first-day discovery report naming agents nobody had registered
- An unregistered-agent alert with provider, data reach and risk
- A permission inventory showing where an agent exceeds its purpose
- An expiry on every elevated grant
- A credential ledger: which agent held what, against which system, and when it lapsed
- The evidence every other module cites
- A retention position the auditor can check
See it working
Every claim above has somewhere on this site you can go and check it.
- A worked estate of machine identities
Every identity that authenticates without a person present, with the credentials it holds and the permissions it never uses.
- The questions a reviewer actually asks
Which identities hold a secret that never expires, cross accounts, or can create other identities.
- The Machine Identity module
What it inventories, what it derives, and where it stops.
Common questions
- What counts as a non-human identity?
- Service accounts, API keys, OAuth clients, workload identities, certificates and tokens — any identity used by software rather than a person.
- Is an AI agent just another non-human identity?
- It is one, but an unusual one. A traditional non-human identity behaves predictably, so least privilege can be derived from observation. An agent decides what to do and acts on behalf of a person or another agent, so its effective authority includes a delegation chain the identity record does not show.
- Where does credential hygiene stop being enough?
- At the grant. Discovery, ownership and rotation answer what an identity is permitted to do. They do not answer whether a specific action should proceed now, given who asked, what the agent just read, and whether the action is reversible.