AI agents need an identity before they receive authority

The control boundary changes when software can act

An AI assistant that drafts text creates a review problem. An AI agent that can retrieve records, call software tools, send instructions or change a system creates an authority problem as well. A May 2026 analysis by the US National Institute of Standards and Technology summarised responses to its consultation on AI-agent security. Respondents widely agreed that agents present novel security threats and that those concerns are a barrier to adoption. They also said established cybersecurity principles remain relevant but need adaptation for agent systems [1].

That evidence is a synthesis of consultation responses, not a measured incident rate or proof that every agent deployment is unsafe. Its value is narrower: experienced respondents did not regard model quality alone as the security boundary. NIST’s separate identity and authorisation concept paper focuses on the risks created when agents receive access to diverse data, tools and applications. It specifically raises identification, authorisation, auditing, non-repudiation and prompt-injection controls [2]. The operating question is therefore not only whether the agent can complete a task, but who or what it is allowed to act as.

Identity is the first layer of accountable delegation

Traditional access control often assumes a human signs in and software acts inside that person’s session. Reusing that pattern for autonomous workflows can blur which actions were initiated by the person, selected by the agent or permitted by the surrounding application. Our inference from the NIST work is that each material agent or agent workload should have a distinguishable identity, a named human or business owner and a recorded purpose. Its credentials should be no broader than the systems, data and actions required for that purpose [1][2].

Identity alone is not a safeguard. A uniquely named agent with excessive privileges can still cause damage, and a detailed log does not prevent an unauthorised transaction. The useful control chain connects identity to scoped authority, separates preparation from execution, records the evidence used, and creates a reliable way to suspend or revoke access. This is an adaptation of familiar identity and access management rather than a reason to discard it. The strongest alternative to a new governance layer is that existing cyber controls are sufficient; NIST’s evidence supports retaining those controls, but not assuming they transfer unchanged [1].

Australian transparency requirements make inventory urgent

Australian organisations also face a more immediate disclosure question. From 10 December 2026, Australian Privacy Principle entities that use personal information in automated decision-making with the potential to affect an individual’s rights or interests will be required to include specified information in their privacy policies. The Office of the Australian Information Commissioner says this includes the kinds of personal information used and the kinds of decisions made. The OAIC is developing guidance on the scope of the obligation [3].

This is not a general ban on automated decisions, nor is every AI agent necessarily an automated decision-making system covered by the obligation. Coverage depends on the entity, the personal information handled and the effect of the decision. The practical implication is that organisations need an inventory detailed enough to make that assessment. If an agent’s purpose, data inputs, decision role and downstream actions are not documented, privacy, legal and operating teams will struggle to determine whether disclosure, review or additional controls are required.

Policy direction is widening beyond technical security

The Australian Government’s AI consumer-safety priorities, released on 20 July 2026, span a proposed digital duty of care, further privacy reform, workplace AI safety, consumer-law options addressing agentic commerce and a framework for automated decision-making in federal agencies [4]. These are workstreams and policy priorities at different stages, not one enacted agent-regulation package. Organisations should not describe them as settled law.

They do show that an agent may sit inside several control domains at once. The same system could raise cybersecurity questions because it uses privileged tools, privacy questions because it processes personal information, workplace questions because it reallocates tasks, and consumer questions because it influences or executes a purchase. Our inference is that a single technology-owner approval will often be too narrow. Release decisions should be linked to the action, data and affected party, with the accountable business owner visible.

Trust is an operating constraint, not a communications problem

The OAIC’s 2026 Australian Community Attitudes to Privacy Survey found that 87% of respondents were more concerned about privacy than five years earlier and only 4% regarded AI companies as worthy of trust. It also found that 68% would be more likely to use digital services requiring personal information if they knew their data was handled fairly and responsibly [5]. These are survey attitudes, not a forecast of customer behaviour in every market, but they challenge the assumption that adoption will overcome weak controls by itself.

A disclosure written after deployment cannot compensate for unclear data use or untraceable authority. Trust is more likely to be earned through observable operating choices: collecting only necessary data, explaining where automation materially affects a person, preserving an escalation route and being able to reconstruct what the system did. For commercial operators, those controls can also reduce investigation time, limit the scope of incidents and make customer and counterparty assurance more credible.

A practical release gate for agent workflows

The immediate task is not to predict the final global standard. It is to prevent useful automation from receiving ambiguous authority. A proportionate release gate can be built around a small set of records and technical controls.

• Register the agent’s identity, owner, purpose, approved systems, data classes and prohibited actions.
• Use scoped and preferably short-lived credentials; do not conceal agent activity inside shared human accounts.
• Separate research, preparation, approval and execution, with human approval for material external, financial, legal or safety consequences.
• Record tool calls, approvals, material inputs and outcomes so an action can be reconstructed and attributed.
• Test indirect prompt injection, hostile documents, excessive data access and failure of downstream tools before release.
• Map any use of personal information and assess whether the December 2026 automated decision-making transparency obligation applies.
• Define suspension, credential revocation, incident ownership and fallback procedures before the agent enters production.

What remains uncertain

Agent identity standards and interoperable controls are still developing. NIST’s identity project was presented as a concept paper, while its security report summarises stakeholder views rather than prescribing a finished control framework [1][2]. The OAIC’s automated decision-making guidance is also still being developed, and the Australian Government’s wider safety priorities include proposals and future work [3][4]. Product architectures, enforcement detail and sector-specific expectations may change.

The strongest current conclusion is deliberately bounded. Low-risk agents do not all require the same controls as systems that move money, change customer records or make consequential decisions. Existing cybersecurity and privacy practices remain the starting point. Once software can act across tools and data, however, identity, limited authority, audit evidence and a clear human owner become part of the operating design. Autonomy should expand only as those controls are demonstrated, not merely as model capability improves.