How Can Your Own AI Become Part of Indonesia’s Fraud Attack Surface?
Indonesia recorded 1,379 fraud reports flagged as AI-assisted between the Indonesia Anti Scam Center’s launch in November 2024 and the end of June 2026. Deepfakes of public figures were the most common reported tactic. Your organization cannot firewall a criminal’s synthetic video, but it can control whether its own AI systems expose the personal data that makes those scams more convincing.
TL;DR: AI fraud in Indonesia is also a data-governance problem. Customer names, NIK, voice samples, photographs, and identity documents can leak through public chatbots, internal copilots, and application programming interface (API) calls to overseas large language model (LLM) providers. A guarded LLM gateway gives security teams one control point for PII masking, sovereign routing, prompt-injection defense, virtual keys, and audit logging.
Key Takeaways The Indonesia Anti Scam Center and Otoritas Jasa Keuangan (OJK) logged 1,379 reports identified as AI-assisted between November 2024 and June 2026, according to reporting on OJK/IASC data. AI fraud depends on personal data, including names, National Identity Numbers (NIK), photographs, and voice recordings, not only on the model that generates the deepfake. A sanctioned AI path is more effective than an outright ban: route every approved AI call through one guarded gateway with policy enforcement and logging. Indonesia’s Law No. 27 of 2022 on Personal Data Protection, commonly called UU PDP, makes data location, processing purpose, and protection controls material governance questions. Anoman provides one OpenAI- and Anthropic-compatible gateway for routing AI traffic through guardrails, data residency controls, and observability.
What is AI fraud, and why is it an AI attack-surface problem?
AI fraud is fraud that uses generative artificial intelligence to create or automate deception, such as synthetic video, cloned audio, fabricated documents, phishing content, or impersonation. It becomes an AI attack-surface problem when an organization’s own applications, employees, data, and model integrations provide the source material or access needed to scale that deception.
The distinction matters. An LLM does not need to generate a deepfake to create risk. A customer-service assistant that sends unmasked names and identity details to a third-party provider may contribute data to a broader fraud ecosystem. An employee who uploads a spreadsheet to an unsanctioned chatbot creates a separate exposure. An agent with access to internal systems can also be manipulated through prompt injection, where hostile instructions embedded in content alter the model’s behavior.
The complete guide to AI gateways for Southeast Asian developers describes the gateway pattern: applications send requests to one policy and routing layer instead of integrating independently with every model provider. That architecture creates a control boundary for data handling, model selection, authentication, and auditability.
Indonesia’s context is specific. UU PDP governs personal-data processing and creates obligations around protecting personal data. A Personal Data Identifier such as an NIK, a phone number, an email address, a face image, or a voice sample can become materially more dangerous when combined with generative AI. Singapore teams face a similar governance question under the Personal Data Protection Act (PDPA), particularly when AI traffic crosses jurisdictions.
AI fraud is therefore not only a content-moderation issue. It is also a data-loss prevention (DLP), access-control, residency, and third-party-risk issue.
Uncontrolled AI traffic increases fraud exposure because security teams cannot see or govern it
The core problem is not that employees or applications use AI; it is that AI calls often bypass a consistent security and compliance control point. Without centralized governance, teams cannot reliably determine what data left the organization, which provider processed it, whether the request was manipulated, or whether the response contained sensitive information.
The reported Indonesian figures show why this deserves executive attention. OJK/IASC reporting cited 13 AI-assisted cases in late 2024 and 1,379 cumulative reports by the end of June 2026. The FBI’s Internet Crime Complaint Center reported more than 22,000 AI-related fraud complaints in 2025, with reported losses of US$893 million. The FBI figure covers complaints received in the United States and is not directly comparable with the Indonesian OJK/IASC count, but both indicate that AI-assisted fraud is being measured at operational scale.
A widely reported incident also illustrates the business impact. In 2024, engineering firm Arup confirmed a loss of approximately US$25.6 million after an employee joined a video call with deepfaked versions of colleagues, including the chief financial officer. The incident was not caused by an LLM gateway failure, and a gateway cannot prevent every social-engineering attack. It demonstrates why identity verification, payment controls, and data protection must work together.
Uncontrolled or shadow AI | Governed AI through a guarded gateway |
|---|---|
Employees use personal accounts or unmanaged API keys. | Applications and users use centrally issued virtual keys with scoped permissions and budgets. |
Prompts may contain NIK, customer records, contracts, or source code. | Personally identifiable information (PII) is detected and masked before the model call. |
Security teams lack a complete inventory of providers and requests. | Requests, responses, policy decisions, and model routes are available through centralized observability. |
Data may be routed to a provider outside Indonesia without an explicit policy decision. | Sovereign routing can keep configured traffic in Jakarta or Singapore, with a deny response when the policy cannot be met. |
Prompt injection can manipulate an agent into revealing data or calling tools. | Input and output guardrails inspect requests, completions, and tool-call arguments. |
Model switching requires application changes and creates new vendor risk. | One OpenAI-compatible endpoint can route to approved models while preserving the same policy layer. |
The shadow AI analysis from Anoman explains why visibility is difficult when staff adopt AI outside approved channels. Banning tools does not remove the underlying demand for faster writing, analysis, coding, and customer support. It usually moves the activity beyond the security team’s line of sight.
Why does AI fraud exposure keep growing inside otherwise mature organizations?
AI fraud exposure persists because data, identity, model access, and business processes are usually governed by separate teams and separate tools. The following root causes repeatedly create gaps.
Personal data is available in too many systems. Customer-service platforms, identity repositories, documents, CRM exports, and call recordings contain the raw material used for impersonation. The fraud risk increases when teams copy this data into AI tools without classification or masking. IBM’s Cost of a Data Breach Report 2025 continues to identify compromised data and weak controls as major contributors to breach impact.
Employees have a sanctioned need but no sanctioned path. A support analyst may need to summarize a complaint, while a developer may need coding assistance. If the approved workflow is slow or unavailable, they may use a personal chatbot or API key. LayerX’s Enterprise AI and SaaS Security Report 2025 documented widespread employee use of unsanctioned generative AI services, reinforcing that the issue is an operational governance gap, not simply a training problem.
Model providers are integrated one by one. Each direct integration can introduce separate API keys, retention terms, locations, logging formats, and access-control decisions. This fragmentation makes it difficult to enforce a common policy across models and environments.
Agents combine untrusted input with privileged tools. An agent may read an email, web page, ticket, or document and then call a database, send a message, or execute code. The OWASP Top 10 for Large Language Model Applications identifies prompt injection and excessive agency as core application risks. A model’s output should not be treated as an authorization decision.
Cross-border processing is discovered after deployment. Teams often know which application they deployed but not where every prompt, completion, embedding, or tool argument is processed. Under UU PDP and Singapore PDPA, data residency and international-transfer analysis need to be designed into the AI architecture, not reconstructed during an audit.
The practical consequence is a control-plane problem. Security teams need a consistent place to authenticate AI clients, classify sensitive data, apply policy, select an approved route, inspect responses, and retain evidence.
How can organizations close the AI fraud and compliance gap?
The best-practice approach is to provide a fast, sanctioned AI path and enforce it through one control point, rather than attempting to ban all AI use. The control point should sit between users or applications and model providers, with policy applied before and after every call.
A vendor-neutral implementation should include:
Inventory and classify AI traffic. Identify employee chat, application APIs, coding agents, retrieval systems, and autonomous agents. Classify NIK, NRIC, MyKad, account numbers, payment data, credentials, source code, and regulated records.
Issue scoped credentials. Replace shared provider keys with virtual keys mapped to a team, application, environment, or workload. Apply role-based access control (RBAC), per-key budgets, rate limits, and model allowlists.
Mask before transmission. Detect PII in prompts, documents, completions, and tool arguments. Use reversible tokenization where the application needs to restore values after a safe model response.
Enforce data residency. Define which traffic must remain in Indonesia or Singapore. A sovereign-lock failure should be explicit, such as an HTTP 403 response, rather than silently routing to an unapproved region.
Inspect for attacks and harmful output. Run prompt-injection, jailbreak, content-moderation, secret-detection, and data-exfiltration checks. Treat tool-call arguments as untrusted input.
Log decisions, not only requests. Record the client identity, model route, policy result, masked entities, latency, token usage, and response disposition. Logs should be protected from tampering and access-controlled.
Test the controls continuously. Use red-team prompts, synthetic PII, malicious documents, and agent tool-abuse scenarios. Measure false positives and user friction, then tune policy by workload.
Anoman maps to this architecture as a guarded LLM gateway. Anoman AI provides one OpenAI- and Anthropic-compatible API for routing to more than 400 models, so teams can change models without scattering new security integrations across their applications. Its guardrail pipeline supports prompt-injection detection, PII masking, content moderation, outbound credential and secret DLP, and inspection of tool-call arguments.
For Indonesia and Singapore deployments, Anoman’s AI compliance controls support data-residency policies for Jakarta and Singapore, with policy enforcement per API key and append-only audit logging. These controls support compliance engineering, but they do not replace a legal assessment of a specific processing activity, transfer mechanism, retention policy, or controller-processor relationship.
Anoman also provides smart routing, virtual keys, usage controls, and observability through the gateway. The gateway adds approximately 30 milliseconds of policy-processing latency in typical configurations, but teams should measure end-to-end latency for their own payload sizes, regions, and guardrail settings. Anoman’s pricing position is zero token markup, while provider charges and infrastructure costs remain subject to the selected deployment and model.
The LLM guardrails platform documents a defense-in-depth approach with pre-call and post-call checks. That is a product capability. The broader requirement, namely identity, approval, data classification, audit retention, and human review for high-impact actions, remains an architectural and governance responsibility for the customer.
What “good” looks like: a checklist
A security or platform lead can use this checklist this week:
[ ] Inventory every employee-facing AI tool, API integration, coding agent, and model provider.
[ ] Route production AI calls through one approved gateway or documented equivalent.
[ ] Remove shared provider credentials and issue scoped virtual keys.
[ ] Set model allowlists, per-key budgets, rate limits, and environment-specific permissions.
[ ] Detect and mask PII, including NIK, NRIC, MyKad, phone numbers, email addresses, and payment data.
[ ] Scan prompts, responses, documents, and tool-call arguments for secrets and prompt injection.
[ ] Define Indonesia and Singapore data-residency requirements before selecting model routes.
[ ] Test that a sovereign-lock violation fails closed, rather than silently changing region.
[ ] Retain an append-only audit trail for requests, policy decisions, routes, and blocked content.
[ ] Require human approval for payments, account changes, credential actions, and other irreversible operations.
[ ] Provide employees with a compliant chat and coding workflow so sanctioned use is practical.
See how Anoman can govern your AI traffic
If your teams cannot answer which AI provider processed a customer prompt, whether the prompt contained PII, or why an agent was allowed to call a tool, the next step is a control-plane review. Contact Anoman to discuss a guarded gateway for AI applications, coding agents, and governed employee access in Indonesia or Singapore.
Frequently Asked Questions
How many AI fraud cases were reported in Indonesia?
OJK and the Indonesia Anti Scam Center reported 1,379 fraud reports flagged as AI-assisted between the center’s launch in November 2024 and the end of June 2026, based on figures reported by Indonesian media. The most common reported tactic was a deepfake of a public figure promoting a fraudulent investment. The figure is a reported case count, not an estimate of all AI-enabled fraud.
Can an LLM gateway prevent deepfake fraud?
No. An LLM gateway cannot prevent every deepfake, cloned voice, social-engineering call, or fraudulent transaction. It can reduce the organization’s contribution to the attack surface by masking PII, blocking prompt injection, restricting model and tool access, enforcing data residency, and recording AI activity. Deepfake defense also requires identity verification, transaction controls, employee procedures, and incident response.
How does AI create UU PDP compliance risk?
AI creates UU PDP risk when an organization sends personal data to a model provider without a documented purpose, protection control, retention position, or approved transfer path. Examples include NIK, names, contact details, identity images, and voice recordings in prompts or documents. PII masking and Indonesia data residency can reduce exposure, but they must be combined with a formal legal and privacy assessment.
What is the safest way to stop shadow AI?
The safest approach is to govern rather than rely on prohibition. Provide a sanctioned AI service that is easy to use, then route it through centralized authentication, PII masking, model allowlists, DLP, logging, and budget controls. Monitor for unsanctioned API keys and browser use, but avoid forcing legitimate work into personal tools by making the approved path impractical.
Should AI agents be allowed to call business tools?
AI agents should call business tools only through explicit allowlists, scoped credentials, input validation, and approval workflows for high-impact actions. A model should not independently authorize payments, identity changes, credential use, or irreversible data deletion. Inspect tool-call arguments for secrets and malicious instructions, and log both the model decision and the resulting tool action.
Conclusion
AI-assisted fraud is growing in Indonesia, but the immediate security decision for enterprises is not whether criminals will use generative AI. It is whether the organization’s own AI systems are exposing the data, credentials, and workflows that make abuse easier.
The practical priorities are:
Put every AI call behind one governed control point.
Mask PII and enforce Jakarta or Singapore data residency where required.
Use scoped virtual keys, tool policies, prompt-injection defense, and append-only audit logs.
A guarded LLM gateway does not replace fraud operations, identity controls, or legal advice. It gives those teams a reliable enforcement boundary for AI traffic. For the next implementation step, review why every AI agent needs a guardrail layer. Kedaulatan digital and kepatuhan become engineering properties when they are enforced in the request pipeline.