As enterprises across Asia Pacific move from generative AI assistants toward increasingly autonomous agents, security and data-governance teams are having to manage a wider set of questions around access, data movement and accountability. Those questions become more complicated when the same organization operates across markets with different privacy, residency and sovereignty requirements.

Proofpoint’s 2026 AI and Human Risk Landscape report found that 87 percent of surveyed organizations had deployed AI assistants beyond the pilot stage, while 76 percent were piloting or rolling out autonomous agents. The survey covered more than 1,400 security professionals across 12 countries, including Singapore, India, Australia and Japan.

In this TNGlobal Q&A, Sumit Dhawan, Chief Executive Officer of Proofpoint, discusses how enterprises can approach AI security across different APAC jurisdictions, why data residency does not by itself establish data sovereignty, how agents change identity and insider-risk models, and where traditional data-loss controls can become less effective as AI changes the way information is accessed and combined.

Sumit Dhawan, Chief Executive Officer of Proofpoint

Asia is currently moving through the phased implementation of many privacy and data protection frameworks, e.g. India’s Digital Personal Data Protection framework, at the same time that enterprise AI adoption is accelerating. What should organizations be doing during this transition period rather than waiting until every requirement is fully in force?

Standing still and waiting for complete regulatory clarity before acting on AI security is one of the biggest risks an enterprise can take today. AI adoption is a board-level and CEO-level priority. The risk of inaction far outweighs the uncertainty of evolving regional frameworks because the business is already moving fast. According to Proofpoint’s latest AI and Human Risk Landscape report, 87% of organizations have deployed AI assistants beyond the pilot stage, while three in four are piloting or rolling out autonomous agents.

Rather than attempting to manage this transition through manual processes and governance committees, organizations must encode those controls directly into technology platforms that dynamically enforce policy, access boundaries, and intent in real time.

The immediate focus should be addressing what we call the “reachability” perimeter. Over 90% of threats enter through the human layer, and AI has completely eliminated historical barriers like language. Attackers are leveraging AI to launch highly convincing social engineering and prompt injection campaigns across non-English-speaking markets in Asia that historically saw fewer targeted attacks. Tightening that front door is essential before scaling AI. Finally, organizations should adopt sovereign-ready architectures that adapt to localized compliance, data residency, and operational telemetry needs without disrupting day-to-day operations.

Generative AI changes how enterprise data moves. Employees may send information to copilots, AI applications may retrieve data from multiple systems, and agents may take actions across them. Where are traditional approaches to data classification, DLP and access control most likely to break down in this environment?

Traditional DLP and access controls were built for a deterministic world—one defined by static network perimeters, known file structures, and predictable human behavior. Generative AI completely disrupts those assumptions because AI applications and autonomous agents operate non-deterministically across heterogeneous platforms.

Where legacy systems fail is in evaluating intent, context, and speed. Traditional DLP can flag a file transfer or a specific keyword pattern, but it cannot assess the underlying intent behind a natural language prompt or a retrieved context payload.

Access control breaks down similarly. If an employee asks an AI copilot a complex question, the AI agent aggregates data across multiple connected repositories to build an answer. If that employee has broad read access across the network, the agent might pull confidential M&A files or sensitive customer records into a conversational workspace. Because copilots, vector embeddings, and agentic workflows transform and move data in seconds, relying purely on static signatures or endpoint rules is no longer sufficient; security teams must shift toward intent-based behavioral detection paired with dynamic access controls.

We already see how significant this challenge is. In Singapore, 91% of CISOs told us they experienced material data loss in the past year, while organizations reported an average of 10 such incidents annually. At the same time, 49% of Singapore organizations said they lack adequate visibility and controls over their GenAI tools.

The answer isn’t to block AI. It’s to have continuous visibility across the data lifecycle and combine data protection with identity, behavioral and intent-based controls. That gives employees the freedom to use AI while giving security teams the ability to intervene when behavior actually becomes risky.

Terms such as data sovereignty, data residency and localization are often used interchangeably. From a security and compliance perspective, what distinctions should enterprises make between them, particularly when data may pass through cloud services, SaaS platforms, AI models and infrastructure operating across several jurisdictions?

Data residency simply refers to where data physically resides at rest within a specific cloud region. Data localization goes further by imposing legal mandates that require specific data to be created, processed, and kept within national borders, restricting cross-border transfers. Data sovereignty, however, is a much higher bar. It dictates that data—and the operational systems processing it—remain under the exclusive legal jurisdiction and operational control of the host nation.

That distinction becomes much more important with AI because data can move through many different layers—applications, models, APIs, cloud infrastructure, telemetry and agents.

So putting your data in a local data center is important for certain regulatory and sovereignty requirements, but it doesn’t solve the entire security problem. You can still have compromised identities, excessive permissions or an AI agent moving sensitive information across systems.

This is why we see sovereignty as a broader architectural requirement. Local infrastructure, local innovation and local compliance capabilities are important, but they need to combine with strong identity, data protection and behavioral controls.

For multinational organizations operating in Asia, how difficult is it to establish where sensitive information actually goes once AI is introduced? Beyond the original dataset, should organizations also be mapping prompts, retrieved context, model outputs, logs, embeddings, agent memory and other derivative information?

Establishing data lineage post-AI adoption is extraordinarily complex because data no longer remains neatly inside structured databases. It is continuously ingested, vectorized, and transformed into dynamic conversational context.

The important thing is to establish visibility before you try to govern everything. You need to know where sensitive information is, which AI systems can access it, where it goes and what happens to it afterwards.

This is particularly important in Asia because organizations are operating across different regulatory environments. You may have one global AI architecture, but different requirements around data handling, privacy and sovereignty in Singapore, India, Japan or Australia.

The objective shouldn’t be to build five completely different security architectures. It should be to have a common security foundation with the ability to apply the appropriate local requirements on top.

AI agents introduce non-human identities that may be granted credentials, tokens and permission to access enterprise systems. How should organizations determine what an agent is authorized to access or do, and how should those privileges differ from conventional service accounts or application identities?

An agent is becoming an active participant in the workforce. It can make decisions, interact with multiple systems, use credentials and take actions on behalf of a person or an organization. That’s fundamentally different from a deterministic service account.

The traditional model has been least privilege—give an identity only the permissions it needs. With agents, I think we need to go a step further and think about intent. Is what the agent is doing right now consistent with why it was given that access?

An agent might have legitimate credentials and legitimate permissions and still be manipulated through prompt injection or another form of attack into doing something it wasn’t intended to do.

That’s why access and intent have to be considered together. We need permissions that are contextual—based on who or what is requesting the action, what the task is and how sensitive the information is—combined with continuous monitoring of behavior.

This is a very different security model from simply issuing an agent a credential and assuming that because the credential is valid, the behavior is safe.

Does AI also change the nature of insider risk? An employee with legitimate access can potentially use AI to search, summarize, transform or move much larger amounts of information than before. How can security teams identify genuinely risky behavior without treating every use of AI as suspicious or creating excessive employee monitoring?

AI completely alters insider risk because it acts as a massive force multiplier for data movement. An employee with legitimate clearance no longer needs to spend days downloading files; they can ask an AI copilot to query, summarize, and aggregate vast volumes of sensitive data in seconds. The employee essentially becomes an “AI-assisted insider,” making it harder to distinguish productive work from unauthorized data movement.

AI isn’t just amplifying risk for attackers, though—it’s already being adopted by defenders too. Specialized behavioral models can analyze contextual signals and surrounding intent to determine whether an action represents legitimate work or risky exfiltration.

Furthermore, using agentic triage capabilities—such as Proofpoint’s Satori agents—allows security operations to automatically filter out the majority of harmless false positives. This keeps human security teams in a governance role, stepping in only on high-severity, high-intent risks while preserving trust across the workforce.

Many evolving frameworks across Asia place greater emphasis on knowing what personal data is being processed and applying appropriate technical and organizational safeguards. How should data-protection, cybersecurity, legal and AI-governance teams divide responsibility when an AI system touches sensitive information? Where do you see accountability becoming unclear in practice?

Clear alignment is essential. Legal and compliance teams define regulatory interpretations, data localization boundaries, and contractual guardrails. AI governance committees establish acceptable use policies, ethical guidelines, and model operational frameworks. Cybersecurity and data protection engineering teams provide and manage the runtime technology platforms that enforce access controls, protect reachability, and prevent unauthorized data loss.

In practice, accountability breaks down in the gap between policy design and runtime enforcement. Governance committees draft thorough policy documents, but without unified technology to dynamically enforce intent, access controls, and data loss prevention at the endpoint, browser, and network layers, those policies remain unexecuted paper promises. Security operations must be equipped with platforms that automatically turn governance policies into real-time enforcement.

Some organizations respond to sovereignty concerns primarily by moving workloads or data into local infrastructure. What risks does local hosting actually address, and what risks remain unchanged? Can an organization satisfy a residency requirement yet still have weak control over identities, permissions, data movement or third-party access?

Local infrastructure can address an important question: where the data physically resides. But it doesn’t automatically answer the broader question of whether that data is secure.

If someone has stolen credentials, excessive permissions or a compromised identity, it doesn’t matter whether the server is in Singapore, India or somewhere else. The attacker can still potentially access the information.

In fact, AI makes this even more important because the attack surface increasingly includes not just people, but agents acting on behalf of people.

A large majority of malicious activity reaches organizations through the human layer, and increasingly we’re going to see that extend to the agent layer. That risk doesn’t disappear simply because the underlying infrastructure is local.

So for organizations with strict sovereignty or localization requirements, local infrastructure should be viewed as one layer of the architecture. It needs to be combined with strong identity protection, appropriate access controls, continuous monitoring and visibility into how data moves.

Otherwise, you may satisfy the geographic requirement while leaving the actual security risk largely unchanged.

Third-party AI and cloud providers add another layer of jurisdictional complexity. What should enterprises examine in provider architecture and contracts around data access, retention, model training, subprocessors, incident response and government or legal requests for data?

Enterprises need to go beyond the traditional vendor questionnaire. They need to understand the actual architecture: where data goes, what is retained, who can access it, whether it is used for model training, which subprocessors are involved and what happens if there is a security incident or a government request for access.

AI is not going to be a world where one vendor provides everything. Enterprises will use different models, applications, data platforms and cloud services. The question is how you secure that heterogeneous environment without creating an even bigger collection of disconnected security tools.

Our research found that 94% of organizations say managing multiple security tools is at least moderately challenging. That’s why I think the direction of travel has to be toward more integrated security architectures.

The value of a platform isn’t simply having fewer logos on a slide. It’s that when you learn something about a new threat or a new form of malicious behavior, that intelligence can be applied consistently across the environment.

India is one of several APAC markets developing its own approach to privacy, AI governance and data sovereignty. For a multinational enterprise operating across India, Singapore, Australia, Japan and other regional markets, which controls can realistically be standardized across the organization, and which decisions still need to remain jurisdiction-specific?

Organizations should standardize the security architecture, but they should not try to standardize every regulatory requirement.

The underlying technical controls can be common: protecting data, securing identities, monitoring insider risk, understanding AI behavior and controlling how sensitive information moves across the environment. Standardize the technology foundation and the security principles, while localizing the policy and compliance requirements. That gives enterprises the consistency they need to operate securely across the region, while still respecting the requirements of each individual market.

Ultimately, this is what secure AI adoption comes down to. You can’t stand in the way of AI. You need to build the security foundation that allows the business to move with it.


Sumit Dhawan is Chief Executive Officer of Proofpoint. He leads the company’s global workforce focused on human- and agent-centric security. Dhawan has more than 25 years of enterprise software experience. Before joining Proofpoint, he served as President of VMware and previously held roles including VMware Chief Customer Experience Officer, Chief Executive Officer of Instart, and senior executive and general-management positions at Citrix.

Editor’s note: This Q&A has been lightly edited for clarity and TNGlobal house style. The substance of the interviewee’s responses has been preserved.

Share your perspective: TNGlobal welcomes contributed insights and expert commentary from across Asia’s technology and innovation ecosystem. Submit a contribution for editorial consideration, or explore more conversations in our TNGlobal INSIDER and TNGlobal Q&A and Interviews archive.