Most zero trust programmes were designed around human identities — employees, contractors, their devices. AI agents, service accounts, and automation now routinely outnumber human identities in a modern environment, and a disproportionate share of them still run on standing, broad, rarely-reviewed access.
A service account or AI agent typically has none of the natural friction that limits human access…
An agent given standing access to systems or data “in case it needs it,” rather than…
The same core zero trust disciplines that apply to human identity — strong authentication,…
A service account or AI agent typically has none of the natural friction that limits human access risk — no login session that times out, no obvious anomaly when it’s active at 3am, and often credentials that were provisioned once, worked, and were never revisited. Combined with how often these identities are granted broad permissions upfront (to avoid breaking something later) rather than the least privilege they actually need, a compromised non-human identity can be a quieter, longer-lived foothold than a compromised human account.
The same core zero trust disciplines that apply to human identity — strong authentication, least privilege, continuous verification — apply directly, with implementation specifics suited to machine identities: short-lived, automatically rotated credentials instead of long-lived static keys; scoped, workflow-specific permissions instead of broad standing access; and a named human owner for every agent and service account, the same way the approval-checkpoint framework for agentic AI calls for a named owner on every human approval gate.
This isn’t a separate initiative from an organization’s existing zero trust roadmap or its agentic AI governance work — it’s the overlap between them, and treating non-human identity as a third pillar alongside both (rather than an afterthought in either) is what closes a gap that both programmes, run independently, tend to leave open.
The core principles are the same — least privilege, strong authentication, auditability — but AI agents often have more dynamic, less predictable access patterns than a traditional service account performing one fixed function, which makes static permission grants a worse fit and makes the audit trail requirement more important, not less.
Distinct identities per agent, scoped to that agent’s specific function, are strongly preferable — shared credentials across multiple agents make it impossible to attribute a specific action to a specific agent during an audit or incident investigation, which defeats much of the purpose of having an audit trail at all.
Start with a discovery pass across identity and access management systems, cloud IAM, and any agent orchestration platforms in use, cross-referenced against what has actually authenticated or made API calls recently — stale, provisioned-but-unused accounts are exactly the ones most likely to have been forgotten and over-permissioned.