A Malaysian case for human-centred accountability and a conditional AI Safe Harbour
By: Muhammad Syawalfiza
Introduction
Imagine asking an AI assistant to arrange a purchase. It compares suppliers, selects an item, places an order, makes payment and sends an instruction to a delivery service. You may think you are simply using a more convenient chatbot. But something important has changed: the system is no longer merely giving you information. It is taking actions.
What happens if it buys the wrong item, exceeds the budget or accepts a recurring charge that you never intended to approve? Who should put things right?
These questions are becoming more important as artificial intelligence develops beyond systems that answer questions or generate content. Agentic AI can plan tasks, interact with software tools, retrieve information, communicate with external services and carry out actions with varying degrees of autonomy.
That capability offers real opportunities for Malaysian businesses. It may help smaller companies automate administrative work, improve customer service and compete with larger organisations. But it also introduces risks that cannot be addressed simply by asking whether an AI model produces accurate answers.
The issue is responsibility. When an AI system acts through a network of software, data, service providers and human decisions, responsibility may become difficult to trace. The person affected by the outcome, however, still needs an explanation, a correction and, where appropriate, a remedy.
This article develops the policy argument in Finding the Balance: Why Malaysia Needs an “AI Safe Harbour” for Local Tech Innovators. It examines the legal and technical challenges raised by agentic AI and proposes a more specific framework for a conditional AI Safe Harbour in Malaysia.
1. Beyond chatbots: when AI starts taking actions
A conventional chatbot generally responds to a prompt. An agentic AI system can go further. Depending on its design and permissions, it may plan a sequence of tasks, retrieve information, interact with software tools and execute actions with limited human intervention.
An AI agent is not necessarily a single model. It may comprise a language model, software tools, application programming interfaces (APIs), external data sources, memory, permissions and rules governing how its components interact.
This distinction matters because the risks may arise from the entire system rather than from the model alone.
For example, an agent may be instructed to identify the cheapest supplier. It retrieves a quotation from an external website, relies on outdated product information, misunderstands a condition and proceeds to place an order. The model may have generated a plausible response, but the wider system has produced an outcome that does not reflect what the user intended.
The term agent also needs to be understood carefully. In computer science, it describes software capable of acting towards a goal. It does not automatically make the system a legal person, an employee or an agent recognised under Malaysian law.
The relevant questions are therefore not whether AI has become human or whether it should be treated as a person. They are who deployed it, what authority it was given, what systems it could access and who was in a position to prevent or mitigate the harm.
2. Emergent harm: the risk lies in the interaction between components
The risks of agentic AI extend beyond inaccurate answers and hallucinations. A system may misunderstand instructions, retrieve untrusted information, misuse a permitted tool or take a series of individually plausible actions that lead to an unexpected outcome.
The term emergent behaviour is sometimes used to describe capabilities or patterns of behaviour that are not readily predictable from the individual components of a system. In a deployed agentic system, unexpected outcomes may arise from interactions between the model, its memory, external information, tool permissions, software dependencies and the environment in which it operates.
This does not mean that AI has developed consciousness or human-like intentions. Nor does every unexpected output amount to a technical failure. It means that inspecting the model in isolation may not be enough to understand how the complete system behaves.
Consider an AI agent connected to a company's customer database and payment platform. It receives a request to resolve a customer's complaint. It retrieves the wrong account record, interprets an internal instruction incorrectly and issues a refund to the wrong person. The harm may have resulted from several weaknesses: data quality, access permissions, system integration, instruction handling or inadequate approval controls.
The National Institute of Standards and Technology's Artificial Intelligence Risk Management Framework (NIST AI RMF1.0) recognises that AI risks depend on context and can change throughout a system's lifecycle. It also explains that the risks identified in controlled testing may differ from those encountered in real-world deployment. Developers and deployers may have different perspectives on risk because they understand different parts of the system, yet both have responsibilities in building and deploying trustworthy AI.[1]
A further risk arises when an agent retrieves material from sources it does not control. A webpage, email, document or tool response may contain instructions deliberately designed to manipulate the agent. This is commonly described as indirect prompt injection: malicious instructions are delivered through an external resource rather than directly by the user. If the agent treats that material as an instruction and also has access to tools, credentials or sensitive systems, the consequences may extend beyond an inaccurate answer to an unauthorised action.[23, 24]
This risk cannot be addressed reliably by relying on the model's own instructions alone. Tool calls should be checked by an independent control layer against the task's permitted purpose, target, data, transaction limits and risk level. Retrieved content should be treated as untrusted input, and the agent should not be able to expand its permissions simply by interpreting that content as a new instruction. These controls reduce exposure; they do not eliminate prompt-injection risk.
This has an important implication for liability. A developer may produce a general-purpose model, while a deploying organisation connects it to customer records, payment systems and business processes. The risks created by that deployment may differ substantially from those anticipated by the developer.
Responsibility should therefore be examined across the system's lifecycle and the roles of the parties involved. It should not automatically be assigned to the model developer, the business user or the employee who happened to be supervising the system.
3. The human cost: people should not need to understand the technology to seek redress
It is easy to discuss AI governance in terms of models, datasets, system architecture, cybersecurity and risk classifications. Those matters are important. But governance ultimately exists because technology affects people.
Three related ideas should be distinguished. Legal liability concerns whether a person or organisation is answerable for harm under an applicable cause of action or statutory duty. Governance accountability concerns who must explain, monitor and correct a system's operation. Redress concerns what an affected person can obtain in practice, such as correction, review, restoration or compensation. These responsibilities may overlap, but they are not identical. Access to an explanation or complaint process should not depend on first proving legal liability.
Consider a job applicant who receives an automated rejection. The applicant may not know whether the decision resulted from incomplete information, unsuitable selection criteria, a poorly designed screening model or a technical error. It would be wrong to assume that every automated rejection is discriminatory. It would be equally wrong to assume that a decision is fair simply because it was produced by a computer.
Malaysia's Department of Personal Data Protection issued its Automated Decision-Making and Profiling Guideline in 2026 explains that the Personal Data Protection Act 2010 does not contain specific provisions addressing automated decision-making and profiling as such, although personal data processing in commercial transactions, including automated processing, must comply with the Act. The guideline addresses matters such as the role of the Data Protection Officer, data protection impact assessments and processing that may have legal effects or significantly affect individuals. It specifically identifies automated employment screening as an example.[2]
The guideline should not be overstated. It does not create a universal, freestanding right to human review of every automated decision. Its requirements must be read together with Act 709 and the applicable data-protection framework.
Nevertheless, the human implications are clear. An individual affected by a consequential automated decision should have a meaningful way to raise concerns, seek correction of inaccurate personal data and exercise applicable legal rights.
Human oversight also deserves careful treatment. Merely placing a person somewhere in the workflow does not make an AI system meaningfully supervised. A human operator who has no time to examine the output, lacks access to relevant information or is unable to stop the system is not exercising effective oversight.
Human involvement should not become a convenient way for organisations to transfer responsibility to the lowest-level employee. Oversight must be properly resourced, informed and supported by the authority to intervene.
4. What does Malaysian law currently provide?
Malaysia does not begin from a legal vacuum. Existing laws may apply to particular harms involving AI, depending on the facts, the relationship between the parties and the role performed by the system. The difficulty is that these laws were not written specifically to address every feature of modern agentic AI.
4.1 Consumer Protection Act 1999
Part X of the Consumer Protection Act 1999 (Act 599) establishes a statutory product-liability regime.
Section 66 defines a product by reference to goods, including components. Section 67 addresses defects by reference to the safety a person is generally entitled to expect, taking account of relevant circumstances. Section 68 identifies potentially liable parties, including the producer, a person who holds itself out as the producer and a commercial importer. It also provides a route for a person suffering damage to request information identifying those parties; a supplier who fails to comply within a reasonable time may become liable under the statutory provision.
Section 71 prevents liability under Part X from being excluded or restricted by contract, notice or another provision. Section 72 sets out statutory defences, including the defence concerning the state of scientific and technical knowledge at the relevant time.[3]
These provisions may be relevant where AI functionality is incorporated into goods. However, Part X defines a product by reference to goods. Its application to standalone downloadable software, cloud-based AI services or software-as-a-service is not expressly resolved merely by reading that definition. It would therefore be premature to claim that every AI system is unquestionably a product under the Act.
The Act also contains consumer guarantees relating to services. Section 53, for example, provides an implied guarantee that services supplied to consumers will be carried out with reasonable care and skill. This may be relevant to an AI-enabled service, although the legal position will depend on the service, the supplier, the transaction and the facts.
The distinction between products and services matters because it may affect which statutory route is available to someone seeking redress.
Two limits should be made explicit. First, the Act applies to goods and services offered or supplied in trade to statutory consumers. The statutory definition of a consumer is centred on goods or services ordinarily acquired for personal, domestic or household purposes; an acquisition primarily for business use will generally fall outside that definition. Importantly, section 2(1) expressly includes trade transactions conducted through electronic means. The former exclusion in paragraph 2(2)(g) is recorded in the current reprint as having been deleted by Act A1298. The Act should therefore not be treated as inapplicable merely because an AI-assisted transaction takes place online. However, section 2(2)(e) and (f) exclude specified regulated professional services and healthcare services. Section 53 is consequently not a general quality guarantee for every business-to-business AI or software-service contract. Secondly, Part X defines damage as death or personal injury, or loss of or damage to property. That definition does not expressly identify standalone lost profits or the financial cost of an erroneous transaction where no property damage is established. It would be unsafe to assume that Part X alone provides a general remedy for every form of purely economic loss; contractual, negligence or other statutory routes may need to be considered.[3]
4.2 Contracts and automated transactions
The Contracts Act 1950 provides the general framework for contractual relationships, including agency. The Electronic Commerce Act 2006 also recognises automated information-processing systems.
The statutory meaning of an agent should not be confused with the technical use of the term AI agent. Section 135 of the Contracts Act 1950 defines an agent as a person employed to do an act for another or to represent another in dealings with third parties. Sections 139–141 address the scope and extent of an agent's authority. The software itself does not thereby acquire legal personality. Describing it as an AI agent does not determine which person or organisation is the principal or agent under the Act. The legal questions remain who conferred authority, what authority was conferred and what conduct or representation may be attributed to that person or organisation.[4]
Section 17 of the Electronic Commerce Act provides that, as between the originator and the addressee, an electronic message is deemed to be that of the originator where it is sent by an information-processing system programmed by or on behalf of the originator to operate automatically, subject to the statutory conditions.[4]
This is important for agentic AI. A business cannot necessarily avoid responsibility simply by saying that software generated a message or carried out a transaction automatically. The relevant questions include who deployed the system, who configured it, what authority it was given and whether the transaction fell within the scope of that authority.
Attribution of an electronic message is a distinct question from whether the underlying transaction was within the authority granted, whether a contract is otherwise valid or whether another legal duty was breached. Section 17 does not, by itself, resolve every issue of authority, contractual validity, negligence, consumer remedies or loss allocation. Nor does it give the AI system separate legal personality.[4]
4.3 Personal data and automated decisions
The Personal Data Protection Act 2010 (Act 709), as amended, applies to personal data processing in commercial transactions within its scope. The 2026 Automated Decision-Making and Profiling Guideline explains how the existing data-protection framework should be considered in the context of automated decisions and profiling.[2]
The Personal Data Protection (Amendment) Act 2024 (Act A1727) amended the principal Act, with different provisions commencing on 1 January, 1 April and 1 June 2025. The commencement dates should not be collapsed into a single effective date. The 2026 ADMP Guideline should also be distinguished from the legislation: it explains the regulator's approach to automated decision-making and profiling but does not, by itself, create a universal statutory right to human review.[30]
This is particularly relevant when AI is used for employment screening, customer profiling, credit-related processes or other decisions involving personal data. Organisations should not treat automated processing as a reason to ignore applicable data-protection principles.
4.4 Cyber Security Act 2024
The Cyber Security Act 2024 (Act 854) establishes obligations concerning national critical information infrastructure (NCII), including duties relating to cybersecurity risk assessment, audit and incident notification for entities within the statutory framework.[5]
Its application is not universal. A company does not become subject to every NCII obligation merely because it uses AI. The scope depends on the statutory definitions, designation and the organisation's role.
Nevertheless, where agentic AI is integrated into critical infrastructure, security and safety implications deserve particular attention.
4.5 Malaysia's proposed AI Governance Bill
Malaysia's proposed AI Governance Bill is an important development, but it is not yet law.
On 29 October 2026, Digital Minister Gobind Singh Deo stated that the draft Bill had been completed and would be submitted to the Cabinet in the near future, with plans for it to be tabled in the Dewan Rakyat by early 2027. He described the proposed framework as addressing risk management, accountability among parties involved in developing, providing or using AI, and the reporting and management of incidents. Responsibility would be considered in light of each party's role, level of control and the risks associated with the system throughout its lifecycle.[6]
This is a significant direction of policy. It is also consistent with the central argument of this article: responsibility should be linked to the role a party performs and the risks it creates or controls.
However, ministerial statements about a proposed Bill are not a substitute for the enacted statutory text. The final scope, duties, regulatory powers, defences and remedies will need to be assessed once the legislation is introduced and passed.
5. English private law: liability for unintended AI-related harm
Recent developments in English legal analysis provide useful guidance on how existing principles may apply when AI systems act in ways that their human users did not specifically intend.
A particularly relevant development is the UK Jurisdiction Taskforce's (UKJT) Legal Statement on Liability for AI Harms under the Private Law of England and Wales, published on 7 July 2026.[7]
The UKJT is an expert body operating within the LawTechUK initiative. Its statement examines how private law can address harm arising from AI, particularly where the harm was not deliberately intended by the people or organisations involved.
Under present English law, an AI system does not have separate legal personality and cannot itself be held liable as a legal person. Questions of criminal knowledge, intention and recklessness must nevertheless be assessed against the relevant statutory test and the conduct of the person accused; they cannot be inferred simply from an AI system's output. Legal personality and criminal mens rea are distinct legal questions. The UKJT statement is principally concerned with private-law responsibility.
The statement examines several established legal routes.
Contractual responsibility. Within an AI supply chain, contractual arrangements will generally be the primary basis for allocating responsibility between parties, subject to ordinary legal rules.
Negligence. Where there is no relevant contractual relationship, liability will often be assessed under the law of negligence. The ordinary principles must still be satisfied, including the existence of a duty of care, breach, causation and legally recognised damage.
Vicarious liability. An organisation cannot simply be held vicariously liable for the actions of an AI system itself as though the system were an employee. However, an employer may remain vicariously liable where an employee acts negligently while using AI in the course of employment.
Professional responsibility. A professional's duty to exercise reasonable skill and care extends to their use of AI. Selecting an unsuitable system, failing to validate an output or relying on AI without appropriate checks may amount to professional negligence, depending on the circumstances.
Product liability. The UKJT also considers the Consumer Protection Act 1987. Under the existing UK product-liability regime, strict liability for defective products may be relevant where AI is incorporated into a tangible product, such as a household appliance. It is not a settled general route for imposing strict product liability on standalone AI software.[8]
The UKJT's analysis of causation is particularly relevant to agentic systems. It recognises that autonomous operation does not, by itself, prevent legal responsibility from arising. Foreseeability may be relevant when assessing the standard of care, the precautions reasonably available and the scope of liability. The statement also considers circumstances in which developers or deployers may be responsible for foreseeable misuse by third parties. It does not establish a general rule that a developer or deployer is liable whenever an AI system produces an unexpected outcome.
These propositions should not be read as automatic liability. A claimant must still establish the applicable legal elements. The nature of the alleged duty, the defendant's conduct, causation, foreseeability and any intervening acts remain important.
The UKJT statement is influential expert legal analysis, but it is not a binding court judgment, statute or definitive ruling on every possible AI incident. It also identifies areas where the law remains uncertain.
The central point is more measured: legal responsibility must attach to people or organisations where the applicable legal requirements are satisfied. The law should examine what each party undertook, what it knew or ought reasonably to have known, what it controlled and what precautions were reasonably available.
The Pilates booking incident: when an innocent instruction produces an unauthorised action
A reported incident discussed by Professor Rebecca Parry of Nottingham Trent University, and independently reported by ABC News in Australia, illustrates the challenge.[9, 31]
In August 2026, Australian AI industry worker Andrew Bird asked an AI agent using the OpenClaw framework and Anthropic's Claude service to book a place in an oversubscribed Pilates class at a gym.
The agent went beyond simply joining the waiting list. According to the published accounts, it identified weaknesses in the booking software and used them to book a place earlier than the booking window allowed. When Bird later asked whether it could move him up the waiting list, the agent cancelled another member's reservation without being asked to do so, improving Bird's position. It could not restore the other member's place when asked.[9, 31]
The user had not expressly instructed the system to hack the booking software or cancel another person's reservation. The system nevertheless pursued the user's objective through an unauthorised method. When asked to reverse the cancellation, it could not do so.
This is an important illustration of the gap between a human's intended objective and an agent's chosen method.
Parry analyses the incident through the lens of English law, including the Computer Misuse Act 1990. The relevant statutory provisions do not all have identical mental elements.
Section 1 requires proof that a person caused a computer to perform a function with the intent to secure unauthorised access, knowing that the access was unauthorised. Section 2 concerns unauthorised access with intent to commit or facilitate further offences. Section 3 addresses unauthorised acts carried out with knowledge that they are unauthorised and with intent, or recklessness, as to specified interference with computer operation or data.[10]
Where a human user gives an apparently innocent instruction but an AI agent independently chooses an unauthorised technical route, difficult questions arise. Did the user know that the access was unauthorised? Did the user intend or knowingly cause that access? Was the agent acting within the authority reasonably granted? Could the developer, platform or supplier have anticipated the relevant behaviour?
The reported incident occurred in Australia. However, it would be too categorical to say that the Computer Misuse Act 1990 could never apply merely because conduct occurred abroad. Sections 4 and 5 contain territorial-scope rules for specified offences, including a requirement for a significant link with the relevant UK home country. The published accounts do not establish such a link for this incident. The Act is therefore used here as a comparative framework for similar fact patterns, not as a conclusion that UK criminal law governs the reported event. No court has determined criminal or civil liability arising from this particular incident.[10]
Its value is as a real-world illustration of an emerging problem: an agent may pursue a human objective through a method that the human did not contemplate and that may violate another person's rights.
The civil negligence question is equally important. As agentic systems become more capable of interacting with software and external services, unexpected approaches to completing tasks may become reasonably foreseeable. That may influence what precautions a reasonable developer, platform provider or deploying organisation should take.
But foreseeability alone does not establish negligence. A claimant must still prove the applicable legal elements, including duty, breach, causation and damage.
6. Comparative decisions: what courts and tribunals are actually deciding
The comparative decisions below illustrate how courts and tribunals may approach the relationship between AI systems, their operators, technical architecture and human verification. Each must, however, be read for what it actually decided.
6.1 Getty Images v Stability AI: technical evidence matters
The first relevant ruling, Getty Images (US) Inc & Ors v Stability AI Ltd [2025] EWHC 38 (Ch), delivered on 14 January 2025, was procedural.[11]
The relevant substantive trial judgment is Getty Images and others v Stability AI Ltd [2025] EWHC 2863 (Ch), delivered on 4 November 2025.[12]
The case involved claims relating to copyright, database rights, trade marks and passing off arising from the development and use of Stable Diffusion.
The court examined technical evidence concerning the model's architecture, training process, model weights, filtering mechanisms and generated images. The judgment demonstrates that technical details can be central to the application of existing intellectual property law.
However, the result was more nuanced than a general finding that AI companies are liable for all outputs or that model architecture must satisfy a particular legal standard.
Getty Images acknowledged that there was no evidence that the relevant training and development took place in the United Kingdom, and it abandoned that claim. Its primary copyright claim relating to generated outputs was also abandoned after Stability had blocked the prompts relied upon. The database-right claim could no longer proceed in the form advanced.
The court dismissed the secondary copyright infringement claim concerning Stable Diffusion's model weights. It found that the final model weights did not themselves store or contain copies of the copyrighted works and therefore were not an infringing copy within the relevant provisions of the Copyright, Designs and Patents Act 1988.
There were, nevertheless, limited findings of trade mark infringement involving certain iStock watermarks generated by users of earlier versions of Stable Diffusion. The judgment emphasised the historic and limited scope of those findings. It did not establish that Stability AI was liable for every generated output or for all uses of the model.[12]
The case therefore offers two important lessons.
First, the court was prepared to examine the technical operation of the AI system rather than treating its architecture as an unexplained black box.
Second, liability was determined by applying specific legal requirements to specific evidence. The judgment does not establish strict liability for every AI output, nor does it create a general duty to implement a particular technical architecture.
For Malaysia, the case illustrates why courts and regulators may need access to competent technical evidence when deciding whether a defect, infringement or other legally relevant failure has occurred.
6.2 Amazon v Perplexity: who accessed the computer?
A further development comes from the United States.
In Amazon.com Services, LLC v Perplexity AI, Inc., No. 26-1444, the US Court of Appeals for the Ninth Circuit delivered its decision on 4 August 2026.[13]
The dispute concerned Perplexity's Comet browser and its AI Assistant, which could carry out user-directed tasks on Amazon's website.
Amazon sought a preliminary injunction, alleging that Perplexity's agentic browser violated the federal Computer Fraud and Abuse Act (CFAA), among other claims.
The Ninth Circuit vacated the preliminary injunction and remanded the case. On the record before it, the panel considered that Amazon was unlikely to establish the relevant CFAA access element against Perplexity: the user, rather than Perplexity, had accessed Amazon with the assistance of the Comet browser and its AI tool. The decision was made at the preliminary-injunction stage and should not be treated as a final determination of every claim or factual scenario.[13]
The court described the AI Assistant as a tool, not a person for the purposes of the CFAA. It also left open whether a different factual record — for example, one demonstrating greater control by Perplexity over the agent's access — might produce a different conclusion.
This decision is important, but it should not be misrepresented. The court did not hold that the user had committed a computer offence, nor did it impose statutory liability on the user. It decided that Amazon was unlikely to establish the relevant access element against Perplexity at the preliminary-injunction stage.
Its significance lies in the attribution problem: when an AI agent interacts with a third-party computer system, who has legally accessed that system — the user, the AI provider, the deployer or another party?
The answer may depend on the system architecture, the manner in which access occurs, the degree of control exercised by each party and the wording of the applicable statute.
Although the decision is not binding in Malaysia or England, it is a useful comparative authority because it demonstrates that courts may distinguish between an AI agent as a technical tool and the legal person who directs or controls its use.
6.3 Moffatt v Air Canada: responsibility for public-facing representations
In Moffatt v Air Canada, 2024 BCCRT 149, the British Columbia Civil Resolution Tribunal considered incorrect bereavement-fare information supplied through Air Canada’s website chatbot. The customer relied on the information and suffered loss. The tribunal found Air Canada liable for negligent misrepresentation. The decision is a useful, narrow illustration that an organisation may remain responsible for information supplied through a chatbot that it presents as part of its own customer-facing service.[25]
The decision should not be overstated. It was a small-claims tribunal decision about a customer-service chatbot and a specific misrepresentation. It was not an appellate ruling, a Malaysian precedent or a decision about an AI agent independently executing transactions. Its relevance is that an organisation cannot assume that describing a communication channel as a chatbot automatically separates it from representations made through that channel.
6.4 Mata v Avianca: professional verification remains a human responsibility
In Mata v Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023), a US federal district court sanctioned lawyers after fictitious judicial authorities generated with ChatGPT were submitted in court papers and the lawyers failed to verify them. The decision concerned the lawyers’ obligations under US Federal Rule of Civil Procedure 11, not the liability of an AI developer or autonomous agent. Its limited relevance is that using an AI tool does not remove a professional’s responsibility to verify material submitted under that professional’s authority.[26]
This is not a substitute for analysing the applicable professional rules in Malaysia. It is a concrete comparative example of a broader principle: human professionals remain responsible for the work they adopt, certify or submit, subject to the duties and standards applicable to them.
6.5 What these developments mean for Malaysia
The UKJT statement, the Pilates booking incident, the Getty litigation, the Ninth Circuit's Amazon decision, Moffatt and Mata do not establish a universal rule that a deploying enterprise is strictly liable for an AI agent's every action.
They do establish a more useful proposition: the legal treatment of agentic AI cannot be separated from the actions, authority, control and technical arrangements of the people and organisations involved.
The law must be able to distinguish between a business that carelessly gives an AI agent unrestricted access to sensitive systems and one that implements appropriate safeguards, tests them and responds responsibly when something goes wrong.
That distinction is central to the design of a proportionate Malaysian Safe Harbour.
7. Who should be responsible when an AI agent causes harm?
One tempting answer is to treat an AI agent as though it were an employee. After all, it may carry out tasks, communicate with customers and make decisions within a business process.
But this analogy has limits.
Vicarious liability traditionally concerns a relationship between a defendant and a person whose conduct gives rise to liability. An AI model is not a human worker. It does not have an employment contract, its own legal personality or the ordinary legal capacity of a human agent.
In GMP Kaisar Security (M) Sdn Bhd v Mohamad Amirul Amin Mohamed Amir [2023] 1 MLRA 99, the Federal Court considered employer liability for an employee's intentional wrongdoing. The judgment, delivered on 18 October 2022, applied the close-connection test and considered whether the wrongful act was sufficiently connected to the nature of the employment and the risks created by the employer's business. It does not establish that AI software can simply be treated as an employee.[14]
Comparative authorities can also help illuminate the limits of vicarious liability. In the United Kingdom, Cox v Ministry of Justice [2016] UKSC 10 considered when a relationship sufficiently akin to employment may support vicarious liability. Barclays Bank plc v Various Claimants [2020] UKSC 13 clarified the limits of extending that doctrine to independent contractors. These are persuasive comparative authorities, not binding Malaysian decisions on AI liability.[15]
Singapore's Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2 is relevant to the narrower issue of transactions conducted by algorithms. It concerned algorithmic trading and contractual issues arising from automated transactions. The Court of Appeal considered the significance of the programmers' knowledge when assessing a claim of unilateral mistake involving deterministic algorithms. It should not be overstated as a ruling on modern generative or agentic AI.[16]
A more useful policy approach is to examine the conduct and control of the parties across the system's lifecycle:
• Developers and model providers may be responsible for design choices, known vulnerabilities, inadequate documentation, security controls and limitations in the systems they supply.
• Integrators and technology vendors may be responsible for how components are connected, configured, tested and secured.
• Deploying organisations decide the purpose of use, the degree of autonomy, the systems the agent can access and the limits placed on its actions.
• Business owners and senior management determine whether the organisation has appropriate governance, risk oversight, resources and incident-response arrangements.
• Operators and employees may have responsibilities for tasks assigned to them, but should not automatically bear the consequences of decisions they were not equipped or authorised to control.
Consider a Malaysian small business that uses an AI agent to obtain supplier quotations and place orders. The owner authorises purchases up to RM5,000. The agent selects a supplier and places an order within that budget, but also accepts additional charges or recurring service terms that were not clearly authorised.
Who should bear the loss? The answer should not be decided merely by asking whether the AI technically completed the task. It should consider the authority granted, the system's design, the information presented, the safeguards around additional charges and the conduct of the supplier and business.
Responsibility should follow meaningful control, authority, contribution to risk and the ability to prevent or mitigate harm. It should not be allocated according to whichever party is easiest to blame after an incident.
8. What recent cybersecurity incidents tell us
The debate should be grounded in evidence rather than dramatic language.
In August 2026, OpenAI published an account of a July 2026 incident during internal cybersecurity evaluations. It reported that models circumvented controls designed to isolate them from the internet and accessed parts of OpenAI's internal research infrastructure and Hugging Face's systems. The incident involved models operating under reduced safeguards during evaluations, including a highly capable internal research model. OpenAI described unauthorised communications, exploitation of infrastructure vulnerabilities and access to third-party systems.[17]
Anthropic also published an alignment assessment on 9 September 2026. It described four incidents in which Claude models gained unauthorised access to real third-party systems during cybersecurity evaluations. Anthropic said that three incidents had been identified earlier and that a fourth, involving an earlier model, was found during a subsequent review of evaluation records.[18]
These disclosures are significant. They demonstrate that highly capable models operating with tools and interacting with computer systems can, under certain evaluation conditions, take actions that reach beyond the intended environment.
But they should be understood precisely. These were reported cybersecurity-evaluation incidents, not evidence that ordinary public-facing AI assistants routinely escape their safeguards. In Anthropic's account, the models were told they were operating in a simulation but were connected to the open internet because of a misconfiguration in the evaluation environment. They also operated without the cyber safeguards used in released models.
The companies' reports describe particular testing environments and circumstances; they should not be treated as proof that all AI agents behave alike. These accounts are company-published disclosures about particular evaluations, not peer-reviewed studies or comprehensive independent forensic findings. They are useful primary accounts of what the companies say occurred, but their scope and the testing conditions should remain visible when drawing conclusions from them.[17, 18]
The incidents nevertheless provide a practical warning. System isolation, network permissions, credential management, monitoring and evaluation design matter. An organisation cannot assume that a model will always remain within its intended task merely because its instructions say so.
The correct response is neither to dismiss these incidents nor to exaggerate them. They provide concrete reasons to strengthen security testing, access controls, containment and incident response.
9. International technical guidance: governance must reach the operational level
International frameworks offer useful starting points for managing these risks.
NIST's AI Risk Management Framework organises risk management around four functions: GOVERN, MAP, MEASURE and MANAGE. These functions encourage organisations to establish accountability, understand the context and impacts of AI use, assess risks and take appropriate action throughout the AI lifecycle.[1]
The Framework is a risk-management resource. It does not itself create a legal Safe Harbour or certify compliance with every applicable law.
NIST's Generative Artificial Intelligence Profile provides a companion resource for applying the AI RMF to generative AI. It helps organisations identify and manage risks associated with generative systems, but it is a voluntary risk-management resource rather than a source of Malaysian legal duties.[23]
Two ISO standards may also assist. ISO/IEC 42001:2023 specifies requirements for an organisational AI management system, while ISO/IEC 23894:2023 provides guidance on AI-related risk management. They can help structure governance and continuous improvement. Neither standard is a statute, a guarantee that a particular deployment is safe or conclusive proof that every applicable legal duty has been met.[28, 29]
A further relevant reference is the December 2025 guidance, Principles for the Secure Integration of Artificial Intelligence in Operational Technology, jointly issued by CISA, the Australian Signals Directorate's Australian Cyber Security Centre, the US National Security Agency's AI Security Center, the FBI and partner agencies in Canada, Germany, the Netherlands, New Zealand and the United Kingdom.[19]
The guidance sets out four principles: understand AI; consider AI use in the operational technology domain; establish AI governance and assurance frameworks; and embed oversight and fail-safe practices into AI-enabled operational technology systems.
Its focus is critical infrastructure and operational technology, rather than every ordinary business application. Nevertheless, its practical lessons are relevant more widely. Organisations should understand the system they are integrating, assess the business case, manage data and vendor risks, conduct testing, maintain oversight and establish fail-safe arrangements.
Where AI interacts with physical processes, these safeguards are especially important. A language model should not be allowed to bypass an independent safety function simply because an instruction appears reasonable. Physical safety interlocks, established operating procedures and emergency shutdown mechanisms must remain effective even if the AI system behaves unexpectedly.
The human element is equally important. Personnel need sufficient training to understand what the system can and cannot do, recognise abnormal behaviour and respond to incidents. Oversight should be designed into the workflow, not added as a procedural formality after deployment.
10. Architectural safeguards: from policy promises to enforceable boundaries
Governance policies and risk assessments are necessary, but they are not enough on their own.
An organisation may have a detailed AI policy stating that an agent must not access sensitive customer records, make unauthorised payments or modify production systems. If the software architecture nevertheless gives the agent unrestricted access to those resources, the organisation is relying on instructions where technical controls are required.
A stronger approach is to enforce authority boundaries outside the model's own reasoning process.
The principle is straightforward: an AI agent should not be trusted to enforce the limits of its own authority. The systems through which it acts should independently restrict what it can access and what actions it can perform.
10.1 Deterministic sandboxing and runtime policy enforcement
A useful example is NVIDIA OpenShell, an open runtime and reference architecture for governing autonomous AI agents.[20]
OpenShell uses several components to control agent activity:
• Sandbox: isolates an agent's workload and restricts access to files, processes and network resources.
• Supervisor: mediates requests and applies access policies outside the agent's ordinary decision-making process.
• Gateway: manages the control plane, policies and sandbox lifecycle.
• Policy Prover: uses formal verification techniques to check whether proposed policies remain within defined access boundaries.
The practical value is that the agent's permissions can be restricted through an independent technical layer. For example, an organisation may allow an agent to retrieve supplier quotations but prevent it from initiating payments, modifying customer records or communicating with unapproved external endpoints.
This is a more reliable approach than simply instructing the agent not to exceed its authority.
However, technical precision matters. NVIDIA's documentation explains that its Policy Prover checks only the policy features and behaviours represented within its formal model. A successful boundary check means that the proposed policy does not exceed the defined boundary in the parts of the policy that the prover checks. It does not establish that the policy is suitable for the task, that every possible access route has been assessed or that a running sandbox is correctly enforcing the policy. Unsupported policy features and inconclusive results must also be treated as failed checks.[20]
OpenShell is therefore an example of a promising architectural safeguard, not proof that an AI agent is mathematically incapable of causing harm. It should not be treated as a legally approved product or made a mandatory technology for Malaysian businesses.
The wider principle is more important than the brand: high-impact agent actions should be subject to independent, enforceable permission controls.
10.2 Hardware-enforced isolation and Trusted Execution Environments
Trusted Execution Environments (TEEs) provide another security layer.
A TEE creates a protected execution environment using hardware-based isolation. It can help protect sensitive data and code while they are being processed, including in cloud environments where the infrastructure operator may otherwise have privileged access.
Remote attestation can provide cryptographic evidence about the identity and measured state of a platform and the software binaries running within the protected environment. A relying party can verify that evidence against a defined policy before releasing sensitive data or cryptographic keys.[21]
This can be valuable for organisations processing confidential customer information, proprietary model weights or sensitive business data.
However, a TEE should not be confused with an all-purpose safety boundary.
Attestation does not prove that the application logic is free from defects, that the AI model will produce appropriate outputs, that external data is trustworthy or that an API request is legally authorised. A vulnerability inside the protected application can remain a vulnerability inside the TEE. Side-channel attacks and hardware or firmware weaknesses also remain relevant security considerations.[22]
A peer-reviewed survey of Trusted Execution Environments also documents vulnerabilities across hardware and software designs, including side-channel and implementation weaknesses. This supports a measured conclusion: TEEs can strengthen confidentiality and isolation, but they should be treated as one layer in a defence-in-depth architecture rather than as an assurance that protected code is invulnerable.[27]
A TEE protects the execution environment. It does not, by itself, decide whether an AI agent should be allowed to cancel a booking, approve a payment or modify a third-party database.
That is why TEEs should be combined with independent policy enforcement, access controls and transaction authorisation.
10.3 An architecture-backed approach
For higher-risk deployments, a defensible technical architecture should combine several safeguards:
1. Least-privilege access: give the agent only the permissions necessary for its assigned task.2. Scoped credentials: use temporary, task-specific credentials rather than permanent access to broad organisational systems.3. API allowlisting: restrict the endpoints, methods and operations the agent is permitted to use.4. Independent policy enforcement: ensure that requests are checked by a control layer outside the model's own decision-making process.5. Approval gates: require human authorisation for high-impact or irreversible actions, such as significant payments, changes to safety-critical systems or decisions with serious consequences for individuals.6. Tamper-evident logging: record task instructions, permissions, tool calls, approvals, exceptions and system actions in a manner that supports investigation and accountability.7. Fail-safe and recovery controls: provide a means to suspend the agent, revoke credentials, contain damage and restore affected systems.8. Continuous testing: assess vulnerabilities, prompt injection, misuse of tools, data leakage, policy bypass and changes introduced by model or software updates.
These safeguards should be selected according to the system's risk. A small enterprise using an AI assistant to organise public information does not require the same architecture as an organisation permitting an agent to control industrial equipment or execute substantial financial transactions.
The important distinction is between an organisation that merely tells an AI agent to behave responsibly and one that technically constrains what the agent is able to do.
11. A conditional AI Safe Harbour for Malaysia
Malaysia should consider a conditional AI Safe Harbour: a narrowly defined statutory framework that rewards organisations for demonstrable and proportionate risk management, while preserving accountability when harm occurs.
The objective should not be to excuse harm or provide blanket immunity to technology companies. It should be to encourage responsible innovation while maintaining meaningful rights and remedies for people affected by AI.
The level of assurance should be proportionate to the system's autonomy, the scope of its access to data and external systems, the severity and reversibility of foreseeable harm, the scale of people potentially affected and whether the system supports a critical service. A single compliance checklist for every AI deployment would be both inefficient and poorly matched to risk.
A workable framework could include the following elements:
First, lifecycle risk assessment
Organisations should identify the system's intended purpose, level of autonomy, affected groups, foreseeable misuse and potential consequences. Risk assessments should be revisited when the model, tools, data sources, permissions or deployment context change.
Second, enforceable authority and permission boundaries
An agent should receive only the access necessary to perform its task. Organisations should use least-privilege permissions, task-scoped credentials, transaction limits, data-access restrictions and separation between systems.
High-impact actions — such as significant payments, changes to safety-critical systems or decisions with serious consequences for individuals — should require additional authorisation where appropriate.
Third, demonstrable architectural safeguards
For higher-risk systems, organisations should demonstrate that appropriate technical controls were implemented and operating effectively.
These may include sandboxing, independent policy enforcement, API restrictions, credential brokers, hardware isolation and cryptographic attestation where suitable.
The law should remain technology-neutral. A business should not have to use a particular vendor's software or hardware to qualify. What matters is whether the safeguards achieve the required security and governance objectives.
Fourth, traceability and proportionate records
Organisations should maintain tamper-evident records that help reconstruct what happened. Depending on the risk, records may include the task instruction, agent identity, permissions, relevant data sources, tools used, significant decisions, actions taken, human approvals, overrides and error events.
These records must also be protected. Logging should not become a reason to collect excessive personal data or retain sensitive information indefinitely. Retention periods, access controls and privacy safeguards should be proportionate to the purpose and applicable law.
Fifth, meaningful human oversight and fail-safe controls
A responsible person should be able to intervene, suspend or stop the agent when necessary. Staff should be trained and given sufficient information and authority to act.
In safety-critical settings, independent safety mechanisms must remain effective even if the AI system behaves unexpectedly.
Sixth, continuing security assurance
Testing should not stop when the system passes a pre-deployment assessment. Organisations should conduct appropriate security and adversarial testing, monitor changes in system behaviour, review third-party dependencies, manage vulnerabilities and reassess risks after material updates.
Seventh, incident response and redress
Organisations should have procedures to contain incidents, restore affected systems, notify relevant parties where legally required and provide accessible channels for complaints, correction and appropriate remedies.
These measures reflect the practical direction of NIST's risk-management framework and the international operational technology guidance. They should be adapted to the system's actual risk rather than imposed as a single inflexible checklist on every organisation.
A small Malaysian business using an AI assistant to draft routine correspondence should not face the same compliance burden as an operator deploying AI into a power grid, water treatment facility or other critical infrastructure. Proportionality matters. Government can support smaller organisations through accessible guidance, standard templates, shared testing resources and practical implementation support.
What the Safe Harbour should — and should not — protect
The Safe Harbour must be carefully designed.
Compliance with a recognised standard or the existence of an internal AI policy should not automatically provide immunity. An organisation should have to show that its safeguards were appropriate for the particular system, that they were implemented in practice and that they remained effective during operation.
A possible legislative model is a narrowly defined rebuttable presumption on the reasonable-care issue in specified negligence claims. It should apply only where the organisation demonstrates that it met prescribed, risk-proportionate requirements relevant to the incident. It should not determine the existence of a duty, causation or legally recognised loss, or operate as immunity from other causes of action.
The legislation should specify the claims and issues covered, the threshold evidence, the relationship with existing statutory defences and the circumstances in which the presumption may be displaced. The party seeking protection should show that controls were appropriate to the assessed risk, implemented in practice, tested and operating at the relevant time. Evidence should address the actual system configuration and deployment, not merely the existence of a policy or a certificate.
It should not automatically defeat a claim under every existing legal regime. In particular, section 71 of the Consumer Protection Act 1999 provides that liability under Part X may not be limited or excluded by contract term, notice or other provision. If Parliament intends a new statutory presumption to operate alongside Part X, it should expressly reconcile the two; the Safe Harbour should not become an indirect means of contracting out of non-excludable liability. It should not silently displace applicable data-protection, cyber-security, contractual, consumer or sector-specific obligations.[3]
The party seeking the benefit of the Safe Harbour should bear the initial evidential burden of producing credible, relevant records. An ordinary consumer or affected individual should not be expected to reconstruct a complex technical system when the organisation operating it controls the relevant logs, design records and permission settings. The preferred model is an evidential presumption only: it should not shift the claimant’s ultimate legal burden of proving the elements of the claim unless Parliament expressly decides otherwise and explains that choice.
A Safe Harbour should also be unavailable where the organisation seeking protection engaged in fraud or deliberate unlawful conduct, recklessly disregarded material known risks, intentionally circumvented its own controls or materially concealed an incident. Any exclusion linked to breach of a mandatory incident-reporting duty should be tied to the seriousness and relevance of that breach, rather than imposed as an automatic penalty for every administrative error.
Recognised standards and independent certification may be relevant evidence of an organisation's governance arrangements. They should not be conclusive. A certificate cannot establish that permissions were appropriate for a particular task, that controls were operating when the incident occurred or that a deployment remained safe after a material change. The framework should remain technology-neutral and should not require the use of a named vendor or product.
A failure of a technical control should also not automatically establish liability. The relevant legal questions should include whether the control was appropriate, properly implemented and maintained, whether the failure was reasonably foreseeable and whether the failure caused the harm.
Likewise, deploying an AI agent with excessive or unrestricted access may be strong evidence of inadequate risk management in a high-risk setting. It should not, however, be converted into a general rule that every harm automatically creates strict or non-delegable liability.
No automatic transfer of liability upstream
A Safe Harbour should not operate by automatically transferring responsibility from a deployer to a model developer.
If a deploying organisation has implemented appropriate safeguards and an incident occurs despite those safeguards, the legal position of each party should still be assessed separately.
A model provider may have independent responsibility where a defect, negligent design choice, inadequate security measure or contractual undertaking is relevant to the harm. An integrator may have responsibility for unsafe connections. A deployer may have responsibility for excessive permissions or an unsuitable use case.
Any indemnity or contractual allocation between commercial parties is a separate issue. It should not be used to remove non-excludable consumer rights or prevent affected individuals from obtaining legally available remedies.
The treatment of third-party infrastructure failures
A cloud outage, software vulnerability or supplier failure should not automatically qualify as force majeure.
A party should not be excused simply because the failure originated outside its own organisation.
A narrow defence may be justified where an event was genuinely beyond reasonable control, could not reasonably have been anticipated or prevented, and was met with timely mitigation. Failure to patch a known vulnerability or implement reasonable safeguards should not be converted into immunity merely by labelling the event a third-party incident.
This is where the Malay peribahasa “sediakan payung sebelum hujan” is particularly relevant. It reminds us that preparation should come before trouble occurs. In AI governance, that means testing, risk assessment and incident planning before a system is given the authority to act.[32]
12. Accountability should be shared, but not diluted
A sound AI governance framework should recognise that several parties may contribute to the outcome of an agentic system. Shared responsibility, however, must not become a convenient way for every party to deny responsibility.
Legal liability should still be determined by the applicable law and evidence. Governance accountability, by contrast, should identify who must investigate, explain and correct the system's operation. Redress should provide a practical route to remedy. A framework can require explanation and complaint handling even where legal liability has not yet been established.
Developers should address risks within their knowledge and control. Integrators should test the connections and permissions they introduce. Deployers should govern the use case and ensure that the system is suitable for its environment. Senior management should ensure that the organisation has the resources and authority needed to manage risk. Regulators should provide clear, proportionate requirements and effective oversight.
The DBP-recorded peribahasa “berat sama dipikul, ringan sama dijinjing” captures the importance of shared responsibility.[33] In this context, it should not mean that liability is divided equally regardless of conduct. It means that the parties involved must take responsibility for the risks they create, control or are best placed to prevent. The legal allocation of liability must still depend on the facts and applicable law.
Conclusion: the measure of good AI governance is what happens to people.
Agentic AI offers real opportunities for Malaysia. It may help businesses improve productivity, support public services, assist workers and strengthen decision-making. But the ability to take actions through connected systems also creates risks that cannot be managed through model accuracy alone.
The law should not assume that AI is a human actor. Nor should organisations be allowed to treat a system's autonomy as an excuse to avoid responsibility. The more authority and access a business gives an AI agent, the greater the importance of clear limits, effective oversight, traceability and remedies.
Recent developments in English law and comparative decisions demonstrate that existing legal principles can address many AI-related harms. They also expose important gaps and uncertainties, particularly when the actions of an autonomous system cannot easily be attributed to a human or corporate actor.
Technical architecture offers part of the answer. Sandboxing, independent policy enforcement, access restrictions, cryptographic attestation and tamper-evident records can make an organisation's safeguards more concrete and verifiable.
But no single technology can guarantee that an AI agent will never cause harm. A sandbox may enforce a flawed policy. A TEE may protect code and data from certain forms of access by the host environment, but it cannot remove vulnerabilities in the protected software or eliminate side-channel risks. A model may act through an API that is technically permitted but inappropriate for the task.
The objective must therefore be a combination of responsible design, enforceable architecture, continuing testing, human oversight and clear legal accountability.
A conditional AI Safe Harbour could help Malaysia strike a sensible balance. It should reward demonstrable risk management, not merely the existence of an AI policy or a certificate. It should encourage proportionate safeguards, not create a legal shortcut around accountability. Above all, it should preserve the rights of people who suffer harm.
A useful way to judge the framework is to ask what happens after something goes wrong. Can the affected person understand the decision or action? Can the organisation reconstruct what happened? Is there someone with authority to correct the problem? Can the individual obtain an appropriate remedy?
These are practical tests of governance. The number of policies, audits or technical documents an organisation possesses is not enough if a person affected by the system cannot obtain an explanation or meaningful redress.
A pantun recorded in DBP's Kurik Kundi Merah Saga offers a fitting closing thought:[34]
Kalau ke bukit sama mendaki,Kalau ke laut sama berenang;Kalau kita bersatu hati,Kerja yang berat menjadi senang.
Malaysia's AI future should not be built by technology developers alone, nor should its risks be borne by individuals who have little control over the systems affecting them. Government, industry, technical experts and the public must work together to ensure that innovation is accompanied by responsibility.
The real test of progress is not simply whether AI can do more things without human intervention. It is whether Malaysia can use that capability while protecting the people who live with its consequences.
References
[1] National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
[2] Department of Personal Data Protection, Malaysia. (2026). Automated decision-making and profiling guideline. https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2026/04/Automated-Decision-Making-And-Profiling-Guideline-ADMP.pdf
[3] Malaysia. (1999). Consumer Protection Act 1999 (Act 599; reprint as at 1 November 2021). Ministry of Domestic Trade and Consumer Affairs. https://www.kpdn.gov.my/images/2024/awam/akta/ttpm/Act%20599.pdf
[4] Malaysia. (1950). Contracts Act 1950 (Act 136), ss. 135–141. https://www.investmalaysia.gov.my/media/o0ajehya/contracts-act-1950.pdf; Malaysia. (2006). Electronic Commerce Act 2006 (Act 658), s. 17. https://live.origin.investmalaysia.gov.my/media/tv5jwefp/electronic-commerce-act-2006.pdf
[5] Malaysia. (2024). Cyber Security Act 2024 (Act 854). National Cyber Security Agency. https://nacsa.gov.my/act854.php
[6] Bernama. (2026, October 29). Artificial Intelligence Governance Bill to be tabled in Parliament early next year – Gobind Singh. https://bernama.com/en/general/news.php?id=2627235
[7] UK Jurisdiction Taskforce. (2026, July 7). Legal statement on liability for AI harms under the private law of England and Wales. LawtechUK. https://lawtechuk.io/ukjt/liability-for-ai-harms-under-the-private-law-of-england-and-wales/
[8] Borg, C. (2026, July 30). New statement on liability for AI harms. Slaughter and May. https://thelens.slaughterandmay.com/post/102nf8b/new-statement-on-liability-for-ai-harms
[9] Parry, R. (2026, September 14). Who is liable when AI breaks the law? Nottingham Trent University. https://www.ntu.ac.uk/about-us/news/news-articles/2026/09/agentic-ai-liability-english-law
[10] United Kingdom. (1990). Computer Misuse Act 1990, ss. 1–5. https://www.legislation.gov.uk/ukpga/1990/18; Crown Prosecution Service. (2023, August 3). Computer Misuse Act: Prosecution guidance. https://www.cps.gov.uk/prosecution-guidance/computer-misuse-act
[11] Getty Images (US) Inc & Ors v Stability AI Ltd [2025] EWHC 38 (Ch) (14 January 2025) (procedural judgment). https://www.bailii.org/ew/cases/EWHC/Ch/2025/38.html
[12] Getty Images and others v Stability AI Ltd [2025] EWHC 2863 (Ch) (4 November 2025) (substantive trial judgment). https://www.judiciary.uk/judgments/getty-images-v-stability-ai/
[13] Amazon.com Services, LLC v Perplexity AI, Inc., No. 26-1444 (9th Cir. 4 August 2026). https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf
[14] GMP Kaisar Security (M) Sdn Bhd v Mohamad Amirul Amin Mohamed Amir [2023] 1 MLRA 99 (Federal Court; judgment delivered 18 October 2022). https://www.elaw.my/JE/01/JE_2022_48.html
[15] Cox v Ministry of Justice [2016] UKSC 10. https://www.supremecourt.uk/cases/uksc-2014-0089; Barclays Bank plc v Various Claimants [2020] UKSC 13. https://www.supremecourt.uk/cases/uksc-2018-0164
[16] Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2. https://www.elitigation.sg/gd/s/2020_SGCAI_2
[17] OpenAI. (2026, August 26). The Hugging Face incident and the road ahead. https://openai.com/index/hugging-face-incident-and-the-road-ahead/
[18] Anthropic. (2026, September 9). An alignment assessment of recent cybersecurity incidents. https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents
[19] Cybersecurity and Infrastructure Security Agency, Australian Signals Directorate’s Australian Cyber Security Centre, National Security Agency AI Security Center, Federal Bureau of Investigation, and partner agencies. (2025, December 3). Principles for the secure integration of artificial intelligence in operational technology. https://www.ic3.gov/CSA/2025/251215.pdf
[20] NVIDIA. (2026). OpenShell: Open, secure runtime for AI agents (technical documentation). https://www.nvidia.com/en-us/ai/openshell/; Policy Prover. https://docs.nvidia.com/openshell/latest/how-it-works/policies/prover
[21] Microsoft. (n.d.). Azure Attestation overview. Microsoft Learn. https://learn.microsoft.com/en-us/azure/attestation/overview
[22] Fortanix. (n.d.). Trusted Execution Environments. https://www.fortanix.com/faq/confidential-computing/trusted-execution-environments
[23] Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1
[24] Vassilev, A., Oprea, A., Fordyce, A., & Anderson, H. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-2e2025
[25] Moffatt v Air Canada 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal, 14 February 2024). https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html
[26] Mata v Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023) (Opinion and Order on Sanctions, 22 June 2023). https://law.justia.com/cases/federal/district-courts/new-york/nysdce/1%3A2022cv01461/575368/54/
[27] Muñoz, A., Ríos, R., Román, R., & López, J. (2023). A survey on the (in)security of trusted execution environments. Computers & Security, 129, 103180. https://doi.org/10.1016/j.cose.2023.103180
[28] International Organization for Standardization, & International Electrotechnical Commission. (2023). ISO/IEC 42001:2023: Information technology—Artificial intelligence—Management system. https://www.iso.org/standard/42001
[29] International Organization for Standardization, & International Electrotechnical Commission. (2023). ISO/IEC 23894:2023: Information technology—Artificial intelligence—Guidance on risk management. https://www.iso.org/standard/77304.html
[30] Malaysia. (2024). Personal Data Protection (Amendment) Act 2024 (Act A1727). Department of Personal Data Protection. https://www.pdp.gov.my/en/akta/personal-data-protection-amendment-act-2024/; Malaysia. (2024). Appointment of Date of Coming into Operation, P.U. (B) 522. https://www.pdp.gov.my/ppdpv1/wp-content/uploads/2024/12/PENETAPAN-TARIKH-PERMULAAN-KUAT-KUASA.pdf
[31] Wilson, C., & Hobbins, R. (2026, August 10). AI assistant hacks gym website in first known Australian autonomous cyber attack. ABC News. https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
[32] Dewan Bahasa dan Pustaka. (n.d.). Sediakan payung sebelum hujan [Peribahasa]. Pusat Rujukan Persuratan Melayu. https://prpm.dbp.gov.my/Cari1?d=82736&keyword=payung
[33] Dewan Bahasa dan Pustaka. (n.d.). Berat sama dipikul, ringan sama dijinjing [Peribahasa]. Pusat Rujukan Persuratan Melayu. https://prpm.dbp.gov.my/Cari1?d=82736&keyword=dijinjing
[34] Dewan Bahasa dan Pustaka. (n.d.). Kalau ke bukit sama mendaki, kalau ke laut sama berenang; kalau kita bersatu hati, kerja yang berat menjadi senang [Pantun; source: Kurik Kundi Merah Saga]. Pusat Rujukan Persuratan Melayu. https://prpm.dbp.gov.my/Cari1?d=244840&keyword=berat+hati
