Ninety-One Per Cent of Your Identities Are Not People: Zero Trust for the Machine Majority

EA Thursday

20 Aug

Written By

Navigation Links: not applicable for this article (no live internal URLs captured yet; consistent with Chapters 26 and 27's convention).

Part Five: Defensive Engineering

On 4 August 2026, an identity security vendor published a count that should change what your next quarterly access review looks like.

ClearVector's 2026 Identity Intelligence Report found that 91 per cent of identities active in production are non-human: service accounts, execution roles, managed identities and third-party vendor credentials. Read the scope before you quote the number, because it matters. This is the report's first edition and it covers production activity across Amazon Web Services and Google Cloud Platform only. ClearVector states that later editions will extend to Microsoft Azure, GitHub, Okta and AI-driven identity activity specifically. So this is a measurement of two cloud providers, not a platform-agnostic constant for the whole enterprise estate.

Inside that scope, the second number is the one that changes control design. Only 20 per cent of non-human activity happens during standard business hours. Roughly four fifths of it happens when nobody is rostered to look at it.

The Question Your Identity Platform Was Never Asked

Most identity dashboards answer "who logged in". For every dashboard anyone has ever built, "who" quietly meant "which person". That assumption is invisible until you ask the platform for a population share rather than a user list, at which point the query takes longer than you expect, because it was never an intended use.

The report's more granular activity breakdown, still pending confirmation into the standing cross-series data register, is where the engineering argument lives. Ninety-nine per cent of observed human activity in production consists of Describe, List, Get and similar read-only calls. People look. Around 3 per cent of machine activity involves destructive operations such as Delete and Terminate. Machines act. Third-party vendor credentials account for roughly 4 per cent of the total identity population, which is small until you consider that each one is a standing grant to an organisation whose change control you do not run.

Weekend traffic stays under 5 per cent across all identity types. That figure gets read as reassurance. It is better understood as the cleanest available signal window: a period when almost nothing legitimate happens, in an estate where almost nothing is watching.

John Laliberte, ClearVector's founder and chief executive, puts the control problem in one sentence: "Authentication tells you who or what has access, but it doesn't tell you whether the activity that follows is legitimate." Identity-driven attacks increasingly use credentials that were properly issued and are properly valid. Access stopped being a sufficient trust signal some time ago. Behaviour after authentication is where the remaining signal is.

Why This Breaks the Control and Not Only the Metric

NIST SP 800-207 does not say "human identity" anywhere. It says identity verification is the control point regardless of network location. The specification was right. Implementations built on top of it inherited an assumption the specification never made.

Look at where the human-hours assumption is actually load-bearing in a working estate. Alert routing and on-call rosters are tuned to a working day. Anomaly baselines are trained on traffic whose rhythm is set by people arriving and leaving. Review cadence is quarterly because that is how often a manager can be asked to re-approve a person's access. Joiner, mover and leaver processes are triggered by employment events, and a service account has no employment events. None of that is wrong for the 9 per cent. All of it is unhelpful for the rest.

Chapter 16, "The Non-Human Identity Crisis: Why Your Zero Trust Architecture Has a Blind Spot", diagnosed this as a blind spot in the architecture. What was missing then was the size of the thing in the blind spot. This is the first dataset this series has used that measures the identity population directly, as a share of the whole, in live production, rather than as a ratio between two counts.

That distinction is worth holding onto. This book has carried several non-human identity ratios from several studies, and this chapter deliberately restates none of them. A ratio between two populations and a share of one population are different measurements with different methods. Averaging them, or presenting them as one number that keeps growing, produces a figure that describes nothing.

Confidence Is Not Control

The measurement lands alongside a survey finding that explains why nobody noticed. Gravitee's State of AI Agent Security 2026 report, from more than 900 executives and technical practitioners, found 82 per cent of executives confident that existing policy protects against unauthorised agent actions. In the same survey, 14.4 per cent of organisations send an agent to production with full security and information technology approval. Gravitee calls the gap the Confidence Paradox. On average, 47.1 per cent of deployed agents are actively monitored or secured.

Three further figures from the same survey, independently fetched from Gravitee's primary release but likewise still pending confirmation into the standing register, are the ones an architect can act on. Only 21.9 per cent of teams treat agents as independent identities, so most agent activity is authenticating as something else. Some 45.6 per cent rely on shared application programming interface keys for agent-to-agent authentication rather than unique scoped credentials. And 25.5 per cent of deployed agents can create or task other agents.

Put those together and you get a population that is uncountable by construction. A shared key used by four agents is one identity in your directory and four actors in your environment. If a quarter of those actors can spawn further actors, the count you produce on Monday is not the count that runs on Friday. This is not a monitoring shortfall. It is a modelling error, and no amount of log volume fixes it.

Chapter 24, "Sixteen Hundred Agents and No Inventory: The Identity Layer Zero Trust Forgot", already reported the Cloud Security Alliance survey findings on undiscovered agents and on the absence of decommissioning processes, and this chapter does not restate them as new. The point of difference is worth being precise about. That chapter asked how many agents you have and whether you can find them. This one asks what proportion of everything authenticating into your production environment was never a person to begin with.

The vendors have noticed. On 4 August 2026, the same day the identity report landed, Microsoft extended its Zero Trust for AI guidance from six pillars to seven, adding a DevSecOps pillar of fifteen control groups and ninety-one tasks alongside an extended artificial intelligence pillar built on its AI Memory concept, which treats agent memory as a governed boundary with defined intent, provenance and lifecycle visibility. This is Microsoft's own account of its own product and no independent assessment of it exists at the time of writing, so treat the detail as vendor-stated. What it demonstrates is a pattern rather than a validation: a chapter of this book published a fortnight ago described a different major platform vendor building discovery and governance tooling for the same reason. Two of the largest enterprise software vendors placed the same bet inside eight weeks. They are selling the map because their customers cannot draw one.

Rebuilding the Access Review

Here is the part you can act on. The quarterly access review is the artefact worth changing first, because it already exists, it already has an owner, and it is already on a calendar. It just asks the wrong questions.

Every field in a conventional review answers something about a person. Last login date assumes a login is a session someone chose to start. Manager sign-off assumes a reporting line. Inactive for ninety days assumes absence means the access is unused rather than seasonal. Replace them.

Conventional field (human)	Machine-majority replacement	Why it changes the answer
Last login date	Last privileged call, by action class	A credential calling Describe daily and Delete once a quarter is not "active"; it is two different risks
Manager sign-off	Named accountable owner and owning team, refreshed on team change	Service accounts outlive the people who created them; a manager field decays to a leaver
Role assignment	Declared purpose plus the action set actually used in the period	Grants drift upward and are almost never walked back; the gap between granted and used is the finding
Inactive over 90 days	No activity in two consecutive review periods, plus no scheduled dependency	Batch identities look dormant between runs; dependency check stops you disabling quarter-end
Access expiry	Credential age, rotation date and issuance method	Shared keys have no expiry semantics at all; age is the only available signal
Not present	Activity distribution across business hours, out of hours and weekend	This is the field the report says is missing everywhere; it is also the cheapest to populate
Not present	Destructive-action count in the period	Roughly 3 per cent of machine activity, and effectively all of the blast radius
Not present	Third-party or vendor-issued flag, with contract reference	Around 4 per cent of the population is governed by someone else's change control

Two review cadences, not one. Human identities keep the quarterly cycle, because a quarter is a reasonable period over which a person's role changes. Non-human identities need a monthly cycle on the last two rows and an event-driven trigger on the rest, fired by credential creation, permission change, and any first-observed destructive action.

Give each entry an owner as a governance object rather than a spreadsheet column. Chapter 9, "The Identity Layer: When Every Agent Needs a Badge", set out the Agent Personas model for exactly this: minimal, auditable, role-specific identity assigned as a defined governance object. ALEA is the book's AI-era enterprise architecture model, and Agent Personas is its first pillar. A persona record turns "who owns this key" from an archaeology exercise into a lookup.

The Out-of-Hours Baseline

The second artefact is the control the 80 per cent figure implies. Treat time of day as an attribute of the identity rather than a property of the alert queue.

# Non-human identity behavioural baseline# Field names use hyphens deliberately: the LinkedIn editor strips underscores.baseline-window: 30devaluate-per: identityidentity-class: non-humanprofile:action-classes: [read, write, config, destructive]hours-observed:business: 0800-1800 local, Mon-Friout-of-hours: all other weekday timeweekend: Sat-Sunexpected:# Derived per identity from its own 30-day history, not from a global default.distribution: learneddestructive-actions: 0new-action-class: falsenew-source-region: falsealert-on:- first-destructive-action-by-identity- action-class-not-in-baseline- weekend-activity-where-baseline-weekend-volume: 0- vendor-credential-outside-declared-contract-window- shared-credential-concurrent-use-from-distinct-sourcessuppress:# Volume alone is not signal for machines. Do not page on it.- volume-deviation-only- out-of-hours-activity-where-baseline-is-out-of-hours

The suppression block matters as much as the alerts. Out-of-hours activity is normal for four fifths of this population, so paging on it produces noise that trains the on-call engineer to ignore the channel. What is not normal is an identity doing something outside its own learned profile, and the weekend is where that stands out, because baseline weekend volume for most non-human identities is zero.

The last alert condition is the one that catches the shared-key problem. If a single credential is used concurrently from two distinct sources, you have at least two actors wearing one identity, and your population count is wrong by an unknown amount.

New Zealand, Honestly

There is no New Zealand version of this measurement, and saying so is more useful than reaching for a substitute.

No local dataset states what proportion of identities in New Zealand production environments are non-human. The international figures in this chapter come from an identity security vendor, an application programming interface management vendor and a hyperscale platform vendor, none of them New Zealand sources and none of them government. Chapter 17, "When Five Governments Tell You to Slow Down", covered the joint agentic artificial intelligence guidance and its risk categories in full, and this chapter does not re-source it; the risk framing established there applies without restatement, and its behavioural and structural categories map onto the out-of-hours finding without needing to be quoted again.

The New Zealand Information Security Manual v3.9 access-control provisions apply in principle to non-human identities and, as this book has noted before, they do not address the credential lifecycle of an autonomous agent directly. That is not a criticism of the manual. It is a description of a document written for a population that has since inverted.

So the gap is the finding. If you want a New Zealand number, nobody is going to hand it to you. The query in this chapter is how you produce your own, and an organisation that runs it this quarter will know something about its own estate that no published source currently knows about the country.

What to Run This Week

Three things, in order, none of which needs a budget.

Run the population query. Count distinct identities that authenticated to production in the last thirty days, split human and non-human. Expect it to be slow and expect the first answer to be wrong, because the split is usually inferred from a naming convention rather than recorded as an attribute.

Plot the same set by hour of day and by day of week. You are looking for whether your monitoring window and your activity window overlap at all.

Then take the eight-row table above to whoever owns the access review and ask which of the four new fields they can populate from data they already hold. In most estates the answer is three of the four, and the missing one is ownership.

Chapter 27, "Governance Without Architecture Is Incomplete: The Security Manager Becomes an Architect", argued that a security manager who cannot reason about architecture is no longer fully qualified. This chapter is a small worked example of what that reasoning has to cover now. The estate is not the one the controls were designed for, and the evidence is a query away.

Executive Takeaway

91 per cent of identities active in production AWS and Google Cloud environments are non-human, and only 20 per cent of that non-human activity happens during standard business hours (ClearVector, 2026).
The access review built for people asks the wrong four questions of a machine-majority population; replace last login, manager sign-off, role assignment and 90-day inactivity with ownership, purpose, hours distribution and destructive-action count.
A shared credential used concurrently from more than one source means the identity count is wrong by an unknown amount; treat that as the population's structural limit, not a monitoring gap.
Run the population query this week. There is no New Zealand-specific number yet, so whoever runs it first will know something about their own estate that no published source currently knows about the country.

The tooling problem this chapter describes is already being solved twice: once by vendors selling governance dashboards, and once, more quietly, by an open-source community that has spent years building the plumbing non-human identity actually runs on. Cert-manager, the certificate lifecycle project the Cloud Native Computing Foundation promoted to its top Graduated tier in November 2024, issues and rotates the short-lived credentials most Kubernetes workloads authenticate with, maintained by a small, rotating group of volunteer contributors rather than any single vendor's product team. That maintainer-sustainability question matters as much as a governance dashboard does: a dashboard can be replaced in a procurement cycle, and a maintainer team cannot. The open-source dimension of the machine-identity problem is not a licensing footnote. It leads into a harder question: what happens when that same non-human population has to be trusted inside a defence environment.

The architecture question this chapter raises, a governed population reviewed on a cadence matching how it actually behaves, is one defence programmes answered first. The US Department of Defense's Continuous Authorization to Operate model, introduced by the DoD Chief Information Officer in February 2022, replaced a system authorisation typically valid for up to three years with ongoing verification tied to an Authorizing Official who can suspend authorisation the moment risk posture shifts. That is the same move this chapter makes for the access review: away from a calendar-driven sign-off and towards verification triggered by what the identity population actually does. The analogy should not be overstated; Continuous Authorization to Operate was built for systems, not identities specifically. But the underlying judgement, that a population changing faster than a review cycle needs a cadence that changes with it, is the same one, reached independently, in a very different governance context.

What did your access review template turn out to have been designed for? I would like to hear the number, and whether it took as long to produce as it did for everyone else.

The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.

Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.

I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.

References

[1] ClearVector. "ClearVector Report Finds 91% of Production Identities Are Non-Human, Exposing Critical Identity Intelligence Gap." PR Newswire, 4 August 2026. https://www.prnewswire.com/news-releases/clearvector-report-finds-91-of-production-identities-are-non-human-exposing-critical-identity-intelligence-gap-302840404.html

[2] Help Net Security. "Non-human identities are 91% of everything active in production." 6 August 2026. https://www.helpnetsecurity.com/2026/08/06/non-human-identities-active-in-production/

[3] Gravitee. "State of AI Agent Security 2026 Report: When Adoption Outpaces Control." gravitee.io, 4 February 2026. https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control

[4] Microsoft Security Blog. "Advance Zero Trust for AI: New tools and guidance to secure AI agents and DevSecOps." microsoft.com, 4 August 2026. https://www.microsoft.com/en-us/security/blog/2026/08/04/advance-zero-trust-for-ai-new-tools-and-guidance-to-secure-ai-agents-and-devsecops/

[5] National Institute of Standards and Technology. SP 800-207, Zero Trust Architecture. 2020. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf

[6] New Zealand Information Security Manual (NZISM) v3.9, access control provisions.

[7] Hamberger, Andreas. Chapter 9, "The Identity Layer: When Every Agent Needs a Badge." EA Thursday, April 2026.

[8] Hamberger, Andreas. Chapter 16, "The Non-Human Identity Crisis: Why Your Zero Trust Architecture Has a Blind Spot." EA Thursday, 28 May 2026.

[9] Hamberger, Andreas. Chapter 17, "When Five Governments Tell You to Slow Down." EA Thursday, 4 June 2026.

[10] Hamberger, Andreas. Chapter 24, "Sixteen Hundred Agents and No Inventory: The Identity Layer Zero Trust Forgot." EA Thursday, 23 July 2026.

[11] Hamberger, Andreas. Chapter 27, "Governance Without Architecture Is Incomplete: The Security Manager Becomes an Architect." EA Thursday, 13 August 2026.

[12] Hamberger, Andreas. The Hamberger Report: Artificial Intelligence and Enterprise Architecture. (Agent Personas.)

[13] Office of the DoD Chief Information Officer. "Continuous Authorization To Operate (cATO)." Memorandum, 3 February 2022. Independently verified via direct web fetch, 13 August 2026. https://dodcio.defense.gov/Portals/0/Documents/Library/20220204-cATO-memo-Signed-Cleared.pdf

[14] Cloud Native Computing Foundation. "Cloud Native Computing Foundation Announces cert-manager Graduation." 12 November 2024. Independently verified via direct web fetch, 13 August 2026. https://www.cncf.io/announcements/2024/11/12/cloud-native-computing-foundation-announces-cert-manager-graduation/

Zero Trust Architecture for the Agentic Enterprise