The machine identity gap putting public sector data at risk

Every federal budget brings machinery-of-government (MoG) changes, and the visible elements of those transitions tend to be documented carefully. Departments merge, functions transfer, hundreds of staff move into new roles and new agencies, and the org charts are updated accordingly. Yet transition planning rarely accounts for the access those changes leave behind or applies the same precision to access as it does to people, functions and reporting lines.

The instinct during restructures is to lift and shift, to move people and systems across without pausing to review what access travels with them. Staff carry entitlements into new roles that persist long after they remain appropriate, contractor credentials outlive the projects that created them, and service accounts set up years earlier remain active in systems that have since moved on. Restructures also bring uncertainty, and uncertainty increases the risk of human error in security practices. Each transition adds to this exposure, widening the governance gap that puts public sector data at risk.

Of course, there are multiple frameworks for managing this risk. Federal guidance on MoG transitions covers joiner-mover-leaver processes and non-employee risk management in detail. Locally, the ASD’s Essential Eight serves as a vital baseline, while the Information Security Manual (ISM) and the Protective Security Policy Framework (PSPF) set clear, broader expectations around data access, identity governance and lifecycle management.

However, to function as intended these frameworks require agencies to have a clear, continuous picture of who or what has access to systems, and whether that access remains appropriate. That picture, for most agencies, is still incomplete. This is not only a question of user access to applications; it is also a data access problem. Sensitive information now sits across shared drives, cloud platforms and legacy repositories, where permissions can be easily inherited, duplicated or simply forgotten.

The accounts nobody owns

Government knows its headcount well. It has payroll systems, HR databases and organisational hierarchies that account for employees and most contractors. Its identity estate is a different matter. Service accounts, API keys, automation accounts and application integrations accumulate over years of operation, often without clear ownership or any formal review cycle. SailPoint research puts 75% of machine identities in enterprise environments as having no owner, and in government, where legacy systems are common and institutional knowledge turns over regularly through attrition and structural change, that proportion is likely conservative.

Security practitioners working inside government understand this gap. At a recent roundtable I hosted on Zero Trust implementation with public sector security leads, the conversation was not about whether to modernise. Everyone in the room understood that identity had replaced the network perimeter as the primary control point, and that access decisions should be continuous and context-based rather than granted once and left. The challenge was in translating that understanding into practice inside environments carrying the accumulated residue of every previous restructure, cloud migration and system integration that preceded them.

The accounts that most often fall through the gaps are not human. Machine identities accumulate in ways no single governance process fully captures, often created to serve a specific purpose, rarely reviewed when that purpose changes, and seldom deprovisioned when it ends. Practitioners at the roundtable were clear about the order of priority: the foundational work on existing machine identities needs to happen before agencies turn their attention to AI agent governance. Agencies that have not established ownership, lifecycle management and monitoring for their existing machine identities are already carrying a vulnerability that bad actors can exploit without any AI agent involved.

AI deployment sharpens the urgency without changing the nature of the problem. An AI agent accessing government data through cloud repositories or collaboration platforms like SharePoint is a non-human identity that needs the same governance treatment as any service account. It requires a named owner, access proportionate to its function and monitoring capable of detecting when its behaviour changes.

A principle that came through clearly at the roundtable was identity provenance. Every action in a system, whether initiated by a human, a service account or an AI agent, should be traceable back to a named, accountable owner. Without that chain of accountability, governance becomes retrospective and largely ineffective. You cannot manage access you cannot see, and you cannot see access you have never catalogued. Agencies deploying AI tools into environments where the existing identity estate is ungoverned are adding to the problem they have not yet resolved.

What’s driving progress

The right technology is naturally important, but in my experience, it is often people who make the real difference when it comes to getting identity security right. The agencies finding the most traction have invested in explaining the reasoning behind access controls rather than simply deploying them, in directing staff towards approved alternatives when they reach for unsanctioned tools, and in building internal advocates who can translate security requirements into language that business units recognise. Access reviews become meaningful when they happen continuously rather than only when an audit approaches.

Progress in reducing risk also tends to accelerate when identity work is tied to existing governance milestones, including audits, accreditation requirements, risk reviews and executive reporting cycles. These moments give agencies a practical reason to move from intent to action, whether that means using microsegmentation to create more granular boundaries around critical systems, cataloguing their non-human identity estate, implementing lifecycle management for contractor access, or using MoG transitions as opportunities to reset permissions rather than carry them forward.

As the public sector faces growing governance obligations around safe and responsible AI deployment, data sovereignty and access control under the Security of Critical Infrastructure (SOCI) Act, it’s vital to determine what identities exist, who owns them, and whether their access remains appropriate. For those yet to map this out, the cost of not knowing will continue to multiply.

Image credit: iStock.com/da-kuk