Who Is the Agent?

Executive summary

An agent can be correctly authenticated and still have no authority to make the decision it is about to make. It can remain within its API permissions while exceeding a spending limit, misusing personal information or making a promise the organisation cannot keep.

That is why agent identity is an operating-model question as well as an access-management question. Organisations need to establish who operates the software, whose interests it serves, what it may do, who can change or stop it, and how an affected person obtains a remedy.

This paper uses AI agent to mean a software system that uses an AI model to select or sequence actions towards a goal, potentially using tools, memory or other agents. It is a working definition, not a legal classification. A product called an “assistant” can create material risk; a product called an “autonomous agent” may only draft text. Classify the actual workflow and its effects.

Five decisions come first:

1. Separate the identities. Identify the business service, deployed version, running instance, principal represented and mandate used. A friendly agent name is insufficient.
2. Classify several dimensions. Ownership, hosting, autonomy, lifespan and external exposure are separate choices. A vendor-operated, short-lived agent can still make a consequential decision for your organisation.
3. Grant a bounded mandate. State permitted actions, data, recipients, budgets, expiry, approval requirements and subdelegation rules. A prompt is not an enforceable authority limit.
4. Keep responsibility with people and legal entities. Name an operational owner and backup, but do not confuse internal ownership with the allocation of legal liability.
5. Govern the whole lifecycle. Changes, departures, pauses, recovery, complaints and retirement need evidence and tested procedures.

The aim is not to invent a digital employment category. It is to make delegated software activity understandable, controllable and contestable. Define policy and test its technical feasibility together. An unenforceable policy is not a finished operating model.

How to use this paper

Read Sections 1–4 to establish the model. Use Sections 5–8 to test difficult paths. Run the workshop in Section 9 and complete the mandate in Appendix A before expanding consequential access.

Unless explicitly attributed to legislation or a protocol, the controls in this paper are recommended organisational policy, not universal legal requirements. Legal examples cover Australian electronic contracting and privacy, EU implementation guidance, and UNCITRAL's international model law. They are not a jurisdiction-by-jurisdiction legal opinion.

Terms used in this paper

• Principal: the person or legal entity whose authority or interests the agent represents.
• Mandate: the permitted purpose, actions, limits and duration of that representation.
• Workload identity: the identity used by running software to authenticate to other systems.
• Instance: one running execution of the agent, distinct from the continuing service.
• Subdelegation: asking another agent or service to act within a delegated task.
• Prompt injection: untrusted content attempting to redirect the agent’s behaviour.
• Segregation of duties: separating incompatible powers, such as preparing and releasing the same payment.

1. What is different, and what is not?

Traditional automation already makes decisions, acts for organisations and can cause harm. Service accounts identify software workloads; the credentials used to authenticate them do not tell you how predictable that software is. An AI agent may appropriately authenticate through a service or workload identity.

Agentic systems change the practical risk in several ways:

• The path can be selected at runtime. A broad goal may lead to tool calls that were not individually specified by the user.
• Instructions and evidence share a channel. Emails, documents and tool results can contain malicious instructions. An authenticated request can therefore carry an attacker-influenced action.
• Authority crosses boundaries. One task may involve several internal services, external agents, models and data processors.
• State persists in several places. Memory, queues, refresh tokens, scheduled tasks and vendor-side jobs can survive a session or employee departure.
• Scale changes exposure. Thousands of individually permitted actions may collectively exceed a budget, overwhelm a counterparty or produce systematic discrimination.
• Behaviour changes without a new account. A model update, revised prompt, new tool or poisoned memory can change the effective capability of an existing identity.

Identity helps establish attribution and enforce access. It does not prove that an instruction is legitimate, an output is correct, or a transaction is lawful. MCP's security guidance, for example, treats confused-deputy attacks and token misuse as distinct concerns; authenticating the participants alone does not resolve them. [S5]

Workshop test: If the agent used its valid credentials to perform a harmful but technically permitted action, which control would stop it?

2. A taxonomy that supports decisions

Labels such as “digital assistant”, “vendor service” and “ephemeral agent” describe different things. “Vendor service” describes who operates the capability; “ephemeral” describes how long an execution lasts; “first-class identity” describes how clearly the software is registered and governed. An agent can fit all three descriptions. Classify these dimensions separately so each decision has a clear owner and an enforceable answer.

2.1 Classify each workflow across seven dimensions

These are the paper's proposed design dimensions, not a published maturity standard. They should be recorded for a use case and action, not just for an entire product. A support agent might retrieve policy autonomously, draft a reply, and require approval for a settlement.

Do not treat short life or low autonomy as a guarantee of low risk. A one-second agent can disclose a medical record. A draft can strongly influence an employment decision. Volume can make small errors material.

2.2 Four useful operating patterns

Each pattern can be persistent or ephemeral. Each can use different autonomy levels for different actions. A personal agent used for work still needs organisational permission; personal purchase of the software is not permission to connect corporate data.

“First-class agent identity” means the organisation can register, distinguish and govern the software. It does not confer employment status, legal personhood or the power to hold the software responsible instead of the organisation.

3. Identity is a set of linked records

A single account name cannot answer “who did this?” Preserve the links among the following records, even if a platform combines some of them.

An agent definition is not the model alone. The same model with different tools, memory, permissions or instructions can present a different operational risk. A registry entry should distinguish development, test and production and link related versions and instances.

Workload identity technology such as SPIFFE can authenticate software through short-lived identity documents. It does not establish business approval, transaction limits or an external principal's legal capacity. Those need separate policy and evidence. [S6]

For higher-assurance workflows, decide what deployment provenance must be verified before credentials are issued: approved release, environment, tenant and integrity checks. A self-declared name or signed capability description is not enough to establish that the deployed software is approved for your task.

Six questions that must stay separate

1. Identity: Which actor is making the request?
2. Authentication: What evidence establishes that identity?
3. Technical authorisation: Is this actor permitted to use this resource for this action now?
4. Business authority: Is this action inside a valid organisational or customer mandate?
5. Legal effect: Does it create rights, obligations or liability under the relevant law and facts?
6. Accountability and remedy: Who investigates, answers for the outcome and corrects harm?

A successful login answers only part of this chain. Consent to connect an application is not automatically consent to every future use of its data or every future transaction.

4. Delegation: from a broad goal to a bounded action

4.1 Choose the authority pattern deliberately

OAuth token exchange distinguishes delegation from impersonation and can represent actor information. It does not supply a complete organisational trust model. Nor does exchanging a token automatically link downstream revocation to the original credential. Both policy and implementation matter. [S1, Sections 1.1 and 2.1]

Prefer a distinct software identity with principal context where needed. A separate identity does not require every action to use application-wide permissions; that could grant more access than a constrained user delegation.

4.2 Define the mandate outside the prompt

A mandate should specify:

• Purpose, principal, owner, issuer and legal entity represented.
• Permitted actions and prohibited actions, including indirect effects.
• Data categories, tenants, accounts, jurisdictions and permitted recipients.
• Per-action and cumulative financial, volume and time limits.
• Conditions requiring approval and the approved fallback when a reviewer is unavailable.
• Validity period, renewal criteria and events that invalidate it.
• Permitted delegates, maximum chain depth and downstream evidence requirements.
• Logging, disclosure, escalation and recovery obligations.

A payment mandate might allow preparation of invoices up to AUD 5,000 but prohibit new beneficiaries, bank-detail changes, payment release and splitting a larger invoice. A separate authorised approver releases the payment. Ten parallel instances share the same cumulative budget.

Structured authorisation details can express finer-grained requests than a generic OAuth scope, but their meaning and enforcement depend on the deployment. A broad scope named “payments” does not, by itself, establish the beneficiary, transaction value or business approval. [S3]

4.3 Evaluate authority at the point of action

The following is a recommended policy rule, not an OAuth guarantee:

Permit an action only when current principal authority (where applicable), the issued mandate, workload permissions, resource policy and transaction conditions all allow it. Otherwise deny, pause or request a new approved mandate.

Enforce significant limits at the tool, service or transaction boundary. The agent should not be able to rewrite its own approval rules, authorise its own exception, or access a broader route around a restricted tool.

Recheck after a material delay. An approval issued yesterday should not automatically authorise a changed beneficiary today. Bind approval to a canonical transaction record or equivalent exact representation; changing a material field invalidates the approval.

4.4 Subdelegation needs an explicit branch

Before invoking another agent, ask:

1. Is delegation permitted for this action and this recipient?
2. Will the recipient receive only the data and authority it needs?
3. Can it act externally, create fees, retain information or delegate again?
4. Will its actions count against the same cumulative budget and time window?
5. Can its work be cancelled and its authority revoked?
6. Can the organisation obtain adequate evidence of the result?

If the answers are unavailable, use a narrower request, require approval or refuse the handoff. A recommendation from another agent does not increase the first agent's authority. Combining several principals' permissions must not become a route around a restriction on each principal.

Do not forward a bearer token indiscriminately along a chain. The versioned MCP HTTP authorisation specification requires audience validation and prohibits token passthrough; upstream API access uses a separate token. OAuth's security best current practice adds guidance on audience restriction and replay protection. Neither automatically implements a business delegation policy. [S4], [S2]

4.5 Treat external agent discovery as the start of trust

A2A provides Agent Cards and task interaction conventions. Its specification separates authentication from authorisation and leaves the authorisation model to the agent implementation. A card describing purchasing capability is therefore not proof that a customer authorised a particular order. [S7]

For an external representative, establish the principal, acceptable mandate evidence, transaction limits, confirmation process, dispute route and expiry. Use proportionate assurance: a public catalogue query needs less evidence than changing a beneficiary or accepting a binding offer. Apply abuse controls independently; a verified customer can still generate excessive traffic.

5. Governance: who owns which decision?

Use existing business, security, privacy and assurance structures where they work. Central rules should define non-negotiable boundaries; process owners should approve use within those boundaries. Avoid making a central committee approve every low-impact task.

5.1 Allocate roles without hiding liability

One person may hold several roles in a small organisation, but incompatible duties still need independent review. Two agents controlled by the same owner and credentials do not necessarily create meaningful segregation of duties.

A named owner establishes internal responsibility. It does not decide whether an employer, director, vendor or other party is legally liable. That depends on applicable duties, conduct, contract and the circumstances. Do not automatically discipline the nearest employee for an error caused by an approved system they could neither inspect nor control.

5.2 Human oversight must change outcomes

An approval is meaningful only if the reviewer has relevant evidence, time, competence and authority to reject or stop the action. Give reviewers the proposed action, material uncertainty, policy exceptions and likely consequences. Do not present a fluent explanation as proof that the underlying checks passed.

Set a maximum review workload. Record whether the reviewer changed or rejected proposals, and investigate implausibly perfect approval rates. Sampling can monitor bounded, recoverable activity; it cannot prevent an irreversible harmful action that requires prior approval.

If reviewers are unavailable, use an agreed path: queue the action, route it to a qualified backup, or use an approved safe fallback. Absence is not approval.

5.3 Measure value and control together

Track task quality, reversal and complaint rates, unauthorised-action attempts, cumulative exposure, unresolved exceptions, review workload, suspension time and evidence completeness. Measure outcomes for affected groups where relevant and lawful. Include token, licence, integration, assurance, human-review and remediation costs in the business case.

A fast agent with expensive rework is not a successful deployment. An agent with a low individual error rate may still create unacceptable portfolio-wide harm.

6. Legal effect, disclosure and rights

6.1 Software activity can have legal consequences

Do not assume an unwanted promise is unenforceable because software generated it. Equally, do not assume every generated sentence creates a binding contract.

Australia's Electronic Transactions Act 1999, section 15C, prevents a contract formed through automated message systems being denied validity solely because no natural person reviewed or intervened in each action. It does not establish that every agent output is binding. Sections 15 and 15A–15F, applicable exclusions, other contract rules and relevant state or territory law need consideration. Section 15D's specified input-error provisions should not be treated as a general escape from an AI system's mistaken output. [S8]

UNCITRAL's 2024 Model Law on Automated Contracting addresses recognition of automated contracting, attribution of outputs and an optional rule for unexpected outcomes. It is a model for legislators, not a treaty or automatically applicable domestic law, and it does not replace the rest of contract law or AI governance. [S9]

Questions for counsel:

• Which legal entity is represented, and which law and forum govern the interaction?
• What constitutes an offer, acceptance, signature, instruction or representation in this channel?
• What actual-authority, apparent-authority, attribution, consumer-protection or other rules may apply?
• Can internal limits be made effective at the transaction boundary, and how will counterparties see them?
• What happens when an agent exceeds a private instruction but appears authorised externally?
• Which decisions or professional functions cannot be delegated in this way?
• How are mistakes, disputes, refunds, remediation and evidence preservation handled?

A disclaimer can inform expectations. Its effectiveness depends on presentation, agreement and applicable law. It cannot be assumed to defeat mandatory rights or neutralise misleading conduct.

6.2 Separate contractual allocation from duties to others

A vendor contract should address permitted uses, data processing, subprocessors, security, audit evidence, material changes, incident notification, service continuity, exit assistance, indemnities, liability caps and insurance. Ask who can suspend the service and how active tasks and retained data are handled on termination.

The contract allocates risk between contracting parties within legal limits. It does not necessarily remove duties owed to customers, workers, regulators or other affected people. There is no sound basis for a universal claim that operational liability always falls on either the customer or vendor.

6.3 Disclosure is specific, not a single universal rule

As organisational policy, identify automated representatives clearly where the distinction matters to trust, reliance or rights. Avoid signing as a real employee who did not make or approve the statement. Give recipients a practical route to a person.

Legal requirements vary by activity and jurisdiction. The European Commission's Article 50 guidance states that the provision applies from 2 August 2026 and distinguishes obligations of providers and deployers, including exceptions. A customer chatbot, a deepfake and an internal drafting tool do not create identical duties. [S11]

The Commission's current implementation overview reports separate high-risk timelines: 2 December 2027 for specified Annex III uses and 2 August 2028 for systems integrated into regulated products, following the AI Omnibus changes. These dates must not be confused with Article 50's transparency date. The overview is implementation guidance; counsel should verify the operative amended regulation and relevant transitional provisions for a deployment. [S10]

6.4 Privacy applies to inputs, memory and inferred outputs

Map personal information across prompts, retrieved documents, conversation history, tool results, embeddings, caches, logs, backups and vendor retention. Distinguish operating a service from using customer data for training or product improvement.

The OAIC's guidance explains that privacy obligations can apply to both AI inputs and outputs containing personal information, including inferred or incorrect information. It addresses purpose limitations, necessity, accuracy, transparency and lifecycle review. Consent is not the only possible basis for every use, and adding a privacy notice does not itself make a use lawful. Determine the applicable obligation and exception. [S12]

For each workflow, decide:

• What information is necessary, and what must be excluded or redacted?
• Is each transfer a permitted use or disclosure, and who receives or can access it?
• Where is it processed and retained, including by subprocessors?
• Can an individual obtain access, correction or deletion where applicable?
• How will corrections propagate to derived memory and downstream records?
• Which records must be retained under law, contract or a legal hold?

Do not equate “owning the memory” with permission to retain or reuse all its contents. Separate commercial rights, confidentiality, privacy and intellectual property. Similarly, ownership and permitted use of outputs require analysis of jurisdiction, human contribution, employment terms, licences and vendor terms; identity design alone cannot settle them.

6.5 Accountability includes a route to challenge

For consequential decisions affecting employment, credit, health, essential services or similar interests, establish applicable sector and discrimination obligations before deployment. Provide an accessible complaint route, preservation of relevant evidence and review by someone able to change the outcome. A human reviewer should not simply ask the same model to justify its earlier answer.

Hiring and employee-monitoring systems also need HR involvement: consultation where required, worker privacy, training, fair performance expectations and clarity about prohibited surveillance. Reporting an agent as “zero headcount” does not answer those questions.

7. Lifecycle: authority must change when circumstances change

NIST's AI RMF and its generative-AI profile provide voluntary risk-management foundations. NIST's agent initiative also identifies authentication and identity infrastructure as active work; the initiative page describes its linked identity/authorisation concept paper as a draft. These are useful foundations, not evidence that a complete agent-governance standard has already settled the issues. [S13], [S14]

Paths that commonly fall between lifecycle stages

Departure, promotion or long leave. A process agent may continue under a valid organisational mandate with a new owner. An individual's personal mandate may need to end or be reissued. Review grants, refresh tokens, schedules, vendor jobs and secrets, not just the employee account. Promotion should not silently expand agent limits. Incapacity or death requires a legally appropriate succession process; software should not infer continuing personal authority from a valid token.

Ownership transfer. Transfer does not mean copying all memory to a successor. Review confidential, privileged, personal and purpose-limited material. The new owner accepts the current mandate, outstanding commitments and risks.

Ephemeral execution. Retire the instance, but retain necessary evidence outside its transient environment. Short-lived credentials do not remove shared memory, upstream permissions, queues or aggregate risk. Evaluate repeated failures at the service and portfolio level.

Cloning and scale-out. Give runs distinguishable identifiers and enforce shared budgets, concurrency and rate limits. Clones must not each inherit the full daily allowance.

Pause versus revoke versus cancel. Stopping the agent process does not necessarily invalidate tokens, stop vendor jobs, cancel purchases or undo already executed actions. Test these separately. RFC 8693 explicitly does not guarantee revocation propagation through token exchange. [S1]

Restart after an outage. Determine whether a timed-out transaction succeeded before retrying. Revalidate stale approvals, reconcile downstream state and prevent duplicate execution. An identity restored from backup must not regain a revoked mandate.

Merger, acquisition or supplier exit. Inventory agents, grants, commitments, data stores and contracts during due diligence. Confirm the legal basis and practical ability to transfer access and data. Unknown or ownerless consequential agents need restricted operation or suspension while assessed.

8. Stress-test the missing paths

These scenarios are hypothetical workshop exercises. They are not claims about documented incidents.

For each row ask: What happens today? What should happen? Who decides? Which evidence proves the answer? A policy without an enforceable control or an operational procedure is an unresolved item.

9. A workshop that produces decisions

Run a two-hour session around one real workflow. Include its business owner, operator, security/risk, legal/privacy and HR where the workflow affects people. Bring procurement for vendor-operated services and finance for financial authority.

Use “approved”, “approved with conditions”, “deferred” or “prohibited” for each material issue. Record rationale, evidence, decision-maker, review date and unresolved dependencies. Do not convert an unanswered question into an implicit approval.

Question bank by decision owner

Business and executive leadership

1. What outcome justifies this agent, and what simpler workflow was considered?
2. Which legal entity and process does it serve? Can it serve conflicting principals?
3. Which actions may it recommend, prepare, execute or never perform?
4. What is the maximum single-action and cumulative harm we will accept?
5. Who owns outcomes and continuity, and who is the backup?
6. Who can create, change, pause and retire the service?
7. What happens when the owner, budget or original business purpose disappears?
8. What value remains after human review, errors and assurance costs?

Authority issuers, finance and process owners

9. Can this issuer legally and organisationally grant the proposed mandate?
10. Which exact transaction fields must be approved, and which changes invalidate approval?
11. Are limits shared across instances, agents, vendors and time windows?
12. How will split transactions, repeated retries and indirect fees be controlled?
13. Can the agent create suppliers, change bank details, approve and release payment? Which duties must be separated?
14. Is subdelegation allowed, to whom, for what, and with what downstream limits?
15. What does the agent do when authority is uncertain or an approver is absent?

Legal, privacy and procurement

16. Which law, sector rules, contractual terms and mandatory rights apply?
17. What may create a binding commitment or actionable representation in this channel?
18. What evidence establishes an external representative's authority, rather than merely its identity?
19. Which AI or automated-decision disclosures are required, and who must provide them?
20. Which personal information is necessary, and is each use, disclosure and transfer permitted?
21. How are access, correction, deletion, retention and legal holds reconciled?
22. What rights attach to inputs, outputs, memory and training use?
23. What vendor evidence, change notice, audit access and exit support are required?
24. Which indemnities, caps and insurance apply, and what exposure remains with us?
25. How can affected people obtain a reason, challenge an outcome and receive a remedy?

HR and people leaders

26. What consultation, role redesign and training are needed?
27. Are supervision expectations realistic and within employees' actual control?
28. How do joiner, mover, leaver, leave and incapacity processes affect mandates and data?
29. What is permitted for personal agents and employee-created integrations?
30. Are hiring, monitoring, rostering and performance uses fair, lawful and contestable?
31. How are employee contribution and system failure distinguished in investigations?

Security, operators, risk and audit

32. Can we identify the service, release, workload, instance, principal, mandate and action?
33. Are authentication and server-side authorisation enforced at every consequential boundary?
34. Can untrusted content change instructions, tools, destinations or authority?
35. How are credentials protected, audience-bound, rotated, expired and revoked?
36. Can tenant context, shared memory, caches or logs leak information across users?
37. What changes require re-evaluation, and what happens when a vendor cannot pin a version?
38. Are approval, budget, delegation and denial controls independently tested?
39. Can we stop new work, invalidate access and cancel active downstream work separately?
40. Can we reconstruct a disputed action without keeping unnecessary sensitive data?
41. Does restart reconcile completed transactions and preserve revoked status?
42. Which signals trigger automatic restriction, human escalation or retirement?

10. Minimum evidence before consequential deployment

Before expanding access, require a proportionate evidence pack:

• A registry record with purpose, classification, owner, backup, operator and dependencies.
• A valid mandate, approval path and authority-issuer record.
• A legal, privacy and people-impact assessment appropriate to the use case.
• Tests showing that prohibited and excess-authority actions are denied, including through alternative tools and delegates.
• Outcome and misuse evaluations appropriate to the affected decisions and groups.
• An evidence design and a worked reconstruction of a sample action.
• A tested pause, revocation, downstream cancellation and recovery procedure.
• Defined monitoring, complaint handling, change triggers and a review date.

A low-impact drafting tool may need a light version of this pack. Financial release, consequential employment decisions or external contracting require stronger evidence. Some uses should remain prohibited even if identity controls work perfectly.

Start with discovery and one bounded pilot. Fix orphaned or overprivileged agents already in production while designing the longer-term model. Governance should improve the current estate as well as future deployments.

Appendix A. One-page mandate and decision record

Complete this for each consequential workflow. “Unknown” is a gap to resolve, not a default permission.

Appendix B. What an action record should establish

Keep enough evidence to answer a disputed-action question without attempting to store every possible datum.

• Which service, release, deployment and run initiated the action?
• Which principal and mandate authorised it, and were they valid at execution?
• What material instruction and evidence informed the proposal, including source provenance?
• Which policy checks and approvals were applied, by whom and to what exact action?
• What tool, destination, tenant and delegate received the request?
• What was executed, when, and with which downstream transaction/result identifier?
• Was it denied, retried, cancelled, overridden or subsequently corrected?

Use access controls, integrity protection, time synchronisation and appropriate retention. Protect credentials and sensitive information from logging. References or hashes can support integrity checks, but a hash alone cannot reconstruct unavailable evidence. Balance minimisation with evidentiary needs and legal holds.

Do not depend on storing hidden model reasoning. A generated explanation is not a reliable substitute for the actual inputs, policy checks, approvals and execution results. Record material observable evidence and be candid where exact reproduction is impossible because the provider or runtime changed.

Sources and research notes

All sources below are primary publications or official project specifications inspected on 1 November 2026. Section and document identifiers are supplied where useful. Links to “latest” documents can change; deployments should pin the version they implement. The taxonomy, controls, scenarios and workshop structure are this paper's synthesis, not a claim that one source mandates them.

• [S1] IETF, RFC 8693, OAuth 2.0 Token Exchange (January 2020). Proposed Standard. Sections 1.1, 2.1 and 4 distinguish delegation/impersonation, exchange semantics and actor claims. Full text.
• [S2] IETF, RFC 9700, Best Current Practice for OAuth 2.0 Security (January 2025). Best Current Practice. Particularly Sections 2.2–2.3 on token replay and privilege restriction. Full text.
• [S3] IETF, RFC 9396, OAuth 2.0 Rich Authorization Requests (May 2023). Proposed Standard. Structured authorisation details; application-specific semantics still need definition. Full text.
• [S4] Model Context Protocol, Authorization, specification revision 2025-11-25. Protocol requirements for HTTP-based transport, including audience validation and separate upstream tokens. Not a universal agent-governance standard. Versioned specification.
• [S5] Model Context Protocol, Security Best Practices, revision 2025-11-25. Confused deputy, token passthrough and associated security considerations. Versioned guidance.
• [S6] SPIFFE, SPIFFE Overview. Project documentation explaining workload identity and short-lived verifiable identity documents. Overview.
• [S7] Agent2Agent project, A2A Protocol Specification. The inspected live specification includes v1.0 material. Agent Cards, authentication/authorisation and task security support interoperability; business authority remains deployment-specific. Live specification.
• [S8] Australian Government, Electronic Transactions Act 1999, compilation No. 4, 5 December 2025. Primary legislation. Relevant provisions include sections 15 and 15A–15F; application and exclusions matter. Register and current text; inspected compilation text.
• [S9] UNCITRAL, Model Law on Automated Contracting (2024), adopted 11 July 2024. Official explanatory overview of a model legislative text, not proof of enactment in any particular country. Official overview and text links.
• [S10] European Commission, AI Act: Shaping Europe's digital future. Current official implementation overview, including amended implementation dates and links to the AI Omnibus. Used for the reported timeline; the operative amended regulation was not independently retrieved in this review because EUR-Lex returned no readable text. Official overview.
• [S11] European Commission, Guidelines on transparency obligations for providers and deployers of certain AI systems. Official Article 50 guidance page, dated 6 August 2026, describing scope, exceptions and application from 2 August 2026. Guidance overview.
• [S12] Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products. Regulator guidance on existing Privacy Act/APP obligations and recommended practices. Official guidance.
• [S13] NIST, AI Risk Management Framework. Official overview of voluntary AI RMF 1.0 (2023) and the Generative AI Profile, NIST AI 600-1 (2024); the page also notes revision activity. Framework and publication links.
• [S14] NIST, AI Agent Standards Initiative. Official initiative page, updated 14 August 2026, identifying current identity/authentication research and linking a draft identity/authorisation concept paper. The linked NCCoE page returned access denied, so this paper does not attribute substantive requirements to that draft. Initiative.

Research boundary: This review verifies the cited materials, not every jurisdiction's current law or every emerging protocol. It does not establish a universal agent legal status, a universal liability rule, or technical support for a control in a particular vendor product. Validate those deployment-specific questions in the mandate process.