1. The question has moved to execution

An AI system that drafts a reply creates one kind of risk. An agent that sends it, amends a customer record, approves a payment or pushes code to production creates another.

The model is the visible part of the system. The consequence sits in the action path: the identity the agent uses, the tools it can reach, the state it relies on, and the point at which someone, or something, lets the operation proceed.

Regulators have noticed. In 2026 the EU enacted new application dates for its high-risk AI regime¹. Australia's prudential regulator wrote to every regulated entity that AI governance, risk management and assurance are not keeping pace with adoption². Singapore updated the agentic AI framework it describes as the first of its kind^3,4. A review commissioned by the UK's Financial Conduct Authority concluded that firms and individuals remain accountable for AI outcomes, even where model behaviour sits outside their direct control⁵. None of them created a single "agent law". All of them point at the same place.

Policy can be well written while the authority to act remains poorly controlled. That gap is where agent risk lives.

This review covers twelve instruments across the EU, the UK, Singapore, Australia and the US, sets out what is fixed and what is expected through 2028, then maps what the instruments ask for to an engineering design that can carry it. It is the Global Focus edition; an Australian Focus edition will follow.

2. How to read this paper

The twelve instruments carry very different force. Some are binding law for a defined class of organisation or use case. Some are supervisory expectations. Some are voluntary frameworks, and one is a proposal not yet finalised. We state the force of each plainly and do not treat them as equivalent.

Every factual statement about an instrument is referenced to the issuing body's own text wherever that text was accessible, and all sources were checked in September 2026. Where a primary source restricts automated access, we say so and identify the secondary source used to confirm its content.

The mapping from requirements to engineering controls is our analysis. Cogna8 builds controls of the kind described in Section 6. Product descriptions are identified separately from regulatory findings, in the note on the author and Cogna8 after the conclusion. No regulator reviewed here mandates a particular technical architecture, and nothing in this paper is legal advice. Whether an instrument applies depends on jurisdiction, sector, role in the AI supply chain, the data processed and the use case. A read-only internal assistant and an agent that can change a customer's financial position will not have the same control case.

3. Twelve instruments, with different force

These are twelve sources of obligation and design signal, not twelve "agent regulations". Reading them as equivalent is the first mistake.

4. The dates that matter

The calendar splits three ways: what has already taken effect or been published, what is fixed in law or official instruments for the next two years, and what regulators and governments have signalled but not yet fixed. Only the first two are dates an organisation can plan against with confidence.

The EU AI Act needs particular care. Regulation (EU) 2026/1744 was adopted on 8 July 2026, published on 24 July 2026 and entered into force on the third day after publication¹. It sets the application date of Chapter III Sections 1, 2 and 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems classified under Article 6(1) and Annex I¹. Those are the dates behind the Article 26 deployer duties discussed here. Presenting them as enforceable from August 2026 is now wrong. The Regulation also gives providers of generative systems already on the market before 2 August 2026 a four-month transitional period for the Article 50(2) marking obligation¹.

The voluntary frameworks, NIST AI RMF, ISO/IEC 42001, the Australian Guidance for AI Adoption and IMDA's framework, have no enforcement clock. An enterprise may adopt them or commit to them in contracts; publication does not make them law. MAS's proposal is not final guidance¹².

The United States is moving in two directions at once. Colorado replaced its 2024 AI Act with a narrower automated-decision law that applies from 1 January 2027^31,32, while a December 2025 executive order directs federal challenges to state AI laws considered inconsistent with national policy²⁹. Organisations operating in the US should plan for state obligations while expecting them to be contested.

5. What supervisors are saying about agents

Across four jurisdictions, supervisors used different words in 2026 for a similar observation.

APRA observed boards relying on vendor presentations without sufficient examination of risks such as unpredictable model behaviour, identity and access management that has not adjusted to AI agents, and controls over staff AI use that detect problems after the fact rather than prevent them². IMDA recommends bounding an agent's autonomy and access to tools and data before deployment, and defining the checkpoints at which a person must approve³. The Mills Review states that firms and individuals remain accountable for outcomes as AI systems move towards more autonomous modes⁵. The EU assigns deployer oversight to people with the competence, training, authority and support to exercise it⁷.

The message is consistent: an organisation must be able to show control over what its agents do, not just describe it.

That is an engineering problem as much as a policy one.

6. Where policy meets an agent's authority

The instruments do not say "install an action gate". Their requirements and expectations concern oversight, risk, records, security, continuity and accountability. The engineering question is how to make those outcomes credible when an agent can initiate side effects.

Consider an accounts-payable agent. It reads an invoice, checks a supplier record and proposes a payment. A useful system may reason flexibly about a discrepancy. It should not be able to change the supplier's bank account and release the payment simply because its own plan says the step is necessary. The organisation needs a point at which the proposed operation is checked against authority and current evidence, and is then allowed, held for approval or refused.

Article 26 requires deployers of applicable high-risk systems to assign competent human oversight and retain certain automatically generated logs. It does not require a human approver for every tool call, or any particular storage technology for logs. For deployers that are financial institutions, Article 26 also lets certain monitoring and log-keeping duties be met through the governance and documentation requirements of Union financial services law⁷. The right design follows the consequence of the action and the legal context.

Determinism at the boundary

The model's reasoning need not be deterministic. The permission decision for a particular operation should be. Given the same action, authority, policy and state snapshot, the gate should return the same answer every time. If an agent proposes a payment above its limit, the gateway declines it, however persuasive the surrounding text. If supplier details conflict, the action is held until the conflict is resolved.

The critical distinction is between instructions to an agent and controls on what its tools will execute. A prompt can tell an agent to seek approval. The payment service can refuse to release funds without a valid, action-specific approval. The updated IMDA framework makes the same distinction, encouraging structural, rule-based controls that operate at the system level over model-based or prompt-layer controls¹³.

A prompt is a request. A control is a constraint. Only one of them holds when the agent is wrong.

Oversight that can change the outcome

An operator watching a dashboard after execution has visibility. Oversight, where required, also needs authority: to understand the proposed action, intervene in time, and prevent or suspend it. The EU AI Act assigns high-risk deployer oversight to people with competence, training, authority and support⁷. In the UK, a decision is "based solely on automated processing" if there is no meaningful human involvement in taking it²³, so the quality of human involvement matters, not its mere presence. Neither regime means a person must click "approve" on every low-risk search.

Records that answer an investigation

For a consequential action, the record should connect the request, agent identity, applicable policy, relevant state, decision, any approval, tool invocation and actual result. That is far more useful than a transcript holding only the final response. Append-only or tamper-evident storage can strengthen assurance where the risk justifies it; it is a design recommendation, not a universal legal requirement. Retention must also respect data-protection and sector rules. Article 26's six-month minimum applies to automatically generated logs under the deployer's control, unless other applicable law provides otherwise^7,8.

State is part of the risk

An agent may rely on a memory entry saying a supplier is approved, a retrieved document containing altered instructions, or a stale permission inherited from an earlier workflow. No model update is needed for the action to go wrong. State therefore needs ownership, access control, source tracking, versioning, expiry and a way to surface conflict. None of the twelve instruments names "state integrity" as a requirement. The connection between governed state and action authority is our engineering conclusion from the risks they address.

7. The compliance gap

Many enterprises have model assessments, procurement reviews and responsible-AI principles. The hard part begins when an agent crosses from advice into execution. An inventory may name the model provider but omit the agent's tool credentials. A policy may require human oversight without saying which operations pause. A trace may show that a tool was called but not which policy authorised it or which account it changed.

An inventory that lists the model but not the agent's credentials is a list, not a control.

A workable review starts with six concrete questions:

An organisation that cannot answer these should narrow the agent's action space before expanding its autonomy. That is a risk-based engineering recommendation, not a claim that every deployment falls under the EU's high-risk provisions.

8. Conclusion

The 2026 landscape is uneven. The EU has an AI-specific law with phased application and newly enacted high-risk dates. Financial regulators in Europe and Australia already impose operational-resilience requirements that can reach agent deployments, and APRA has now told regulated entities that AI governance is not keeping pace with adoption. Singapore has published guidance written specifically for agents, while its financial-sector AI guidelines remain proposed. The UK continues to apply existing data and conduct rules, with statutory AI guidance still to come. In the US, state laws are arriving while the federal government moves to contest them.

What joins these instruments is the need to show control over consequences. The test is specific. For a material action, can the organisation establish who gave the agent authority, what it was permitted to do, which information and policy it used, whether a person could intervene, what was executed, and how the result can be investigated?

If the answer exists only in a policy document, the execution system is carrying more authority than the governance system can account for.

About the author and Cogna8

AI use: research and drafting for this review were supported by AI tools. Multiple models were used for research and to cross-check facts, and every factual statement was verified by the author against the cited sources. The author is responsible for the content.

References