By Liew Chan Fai, Cybersecurity Strategist and Advisory, Bridgenet Solutions Sdn Bhd
In boardrooms across Malaysia, the conversation about artificial intelligence has moved from "should we" to "how fast". Copilots sit inside email and productivity suites, chatbots answer customers on public portals, and AI agents now triage service tickets. Security teams are adopting it too, using AI to summarise alerts and draft detection logic.
Yet in the security assessments I conduct, one simple question often goes unanswered: who owns the risk of the AI we have already deployed? Most organisations can produce a complete list of their firewalls. Very few can list their AI models, explain where the training data came from, or state exactly what an AI agent is permitted to do on their behalf.
Two Sides of the Same Coin
It helps to separate two ideas that are often blended together. The first is AI for security: using machine learning and language models to detect threats and speed up response. The second is security of AI: protecting the AI systems themselves from misuse, manipulation and data loss. The first attracts the headlines and the budgets. The second is where exposure is growing fastest, largely unnoticed.
A Different Kind of Attack Surface
AI systems introduce weaknesses that traditional applications do not have. Community resources such as the OWASP Top 10 for LLM Applications and MITRE ATLAS catalogue these in detail, but a few stand out in practice.
Prompt injection. A language model cannot reliably distinguish data from instructions. An attacker who plants hidden instructions in an email, web page or document can redirect the model when it processes that content. The user never sees the attack; the model simply follows it.
Data and model integrity. Tampering with training data, fine-tuning sets or the knowledge bases behind retrieval-augmented systems can quietly bias outputs. Pretrained models and plugins downloaded from public repositories raise the same supply chain questions we ask of open-source software, and model files themselves can carry malicious code.
Excessive agency. When an AI agent is connected to tools that send email, modify records or execute code, a successful injection is no longer just a wrong answer. It becomes an unauthorised action, carried out with whatever privileges the agent holds.
Shadow AI and data leakage. Employees pasting customer records or source code into public AI tools create exposure that no perimeter control will catch, with direct implications under the Personal Data Protection Act.
Why Existing Controls Fall Short
Most security controls assume deterministic systems. A web application firewall inspects syntax, not the intent behind a natural-language request. Testing is harder when the same input can produce different outputs. Access control becomes blurred when an AI acts using a service account that holds far broader permissions than any individual user. Most tellingly, many AI deployments do not log prompts, responses or tool calls at all, which leaves the security operations centre blind to misuse.
Governance First, Then Controls
The encouraging news is that organisations do not need to start from scratch. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 provide structure, and Malaysia's National Guidelines on AI Governance and Ethics set out principles for responsible use. Obligations under the Personal Data Protection Act and the Cyber Security Act 2024, along with sector-specific requirements, do not pause simply because a system happens to use AI. In practice, a workable programme comes down to six disciplines.
Know what you run. Build an inventory of every AI system, including AI features embedded in existing SaaS platforms, each with a named business owner, a stated purpose and the data it touches.
Classify by impact. An internal meeting summariser, a model supporting credit decisions and an agent with write access to production systems deserve very different levels of scrutiny.
Control the lifecycle. Verify data provenance before training, conduct adversarial testing before release, and place model updates and system prompts under the same change control as code.
Apply least agency. Limit the tools an agent can call, require human approval for high-impact actions, and give agents dedicated credentials that can be monitored and revoked.
Monitor what the AI does. Log prompts, outputs and tool calls, and feed them into the SOC so analysts can detect injection attempts, unusual tool usage and data leaving through model responses.
Scrutinise AI suppliers. Ask whether the vendor trains on your data, where that data resides, how models are updated and how quickly you will be notified of an incident.
People Remain the Deciding Control
Technology controls only go so far if staff do not understand how AI can be misused. Blanket bans on public AI tools rarely work; they simply push usage out of sight. A better approach is to provide approved tools, publish a clear acceptable use policy, and explain in plain language what data must never be shared with an AI service.
Awareness programmes also need to catch up with how attackers now operate. Phishing messages arrive in fluent English and Bahasa Malaysia, and cloned voices and video have been used to impersonate executives. Verification steps for payments and sensitive requests, such as a call-back through a known number, are simple defences that no deepfake can easily bypass.
Three Questions for the Board
Leaders do not need to understand model architectures to govern AI risk. They need clear answers to three questions. What AI are we running? Who owns the risk of each system? How would we know if it were being misused? If any answer is unclear, that is the place to begin.
The organisations that benefit most from AI will not be those that adopt it fastest. They will be those that adopt it with visibility, accountability and the discipline to secure what they build.
Latest News
