AI Agent Exposure in South African Fintech: What We Found Scanning Public Domains

In January and February 2026, we ran our passive OSINT domain scanner against the 20 largest South African fintech companies by AUM or transaction volume — a list compiled from public regulatory filings, JSE disclosures, and industry publications. We used no credentials. We made no requests that would not be made by a standard web browser or search engine crawler. Everything we found was visible from the public internet.

What Signals We Look For

AI agent deployment leaves characteristic signals in public-facing infrastructure. These signals are not vulnerabilities — they are the visible consequences of how AI frameworks are typically deployed. A competent attacker conducting pre-attack reconnaissance will look for exactly these signals to understand what AI capabilities an organisation has deployed and where potential injection or exfiltration paths might exist.

• JavaScript bundle analysis: Modern web applications ship their JavaScript in bundled form. These bundles often contain references to LLM SDK imports (openai, @anthropic-ai/sdk, langchain), streaming endpoint URLs, WebSocket connection strings for real-time AI interfaces, and API client initialisation code that reveals the underlying AI provider and model being used.
• Subdomain enumeration via certificate transparency: CT logs record every TLS certificate issued for a domain. Subdomains like chat.company.com, ai.company.com, assistant.company.com, copilot.company.com, or agent.company.com are high-confidence signals of AI deployment. CT log enumeration via crt.sh is entirely passive.
• API endpoint probing: HTTP 401 responses from endpoints matching /api/chat, /api/assistant, /api/completions, /api/stream, or /v1/messages indicate AI API routes that exist but require authentication. The response headers from 401 responses often reveal the framework (FastAPI, Express, Next.js API routes) and sometimes the AI provider.
• HTTP response headers: X-Powered-By headers, Content-Security-Policy directives that allow connections to api.openai.com or api.anthropic.com, and CORS headers that permit specific AI service origins all reveal the presence of AI infrastructure even on endpoints that return no content.

// Example: LLM SDK reference found in a public JavaScript bundle
// Pattern that appears in minified Next.js bundles when OpenAI SDK is bundled client-side

// Detected via: curl -s https://target.co.za/_next/static/chunks/main.js | grep -oE '(openai|anthropic|langchain|bedrock)[^"]{0,50}'

// Output observed:
openai","version":"4.28.4","baseURL":"https://api.openai.com/v1
anthropic-ai/sdk","version":"0.20.1"
langchain/openai","version":"0.0.28"

// Note: SDK references in client-side bundles indicate the SDK is being called
// from the browser — a significant security concern, as API keys may be exposed.

Aggregate Findings: What We Found

The 85% figure — 17 of 20 companies showing at least one AI signal — is higher than we expected and aligns with the global adoption data. South African fintech is deploying AI at pace. What is notable is the variation in how visible that deployment is: three companies showed no public signals at all, suggesting either no AI deployment or — more likely — careful infrastructure hygiene that prevents signals from reaching the public-facing layer.

The 20% figure for client-side LLM SDK code is the finding of most immediate concern. If an LLM SDK is being initialised in client-side JavaScript, there is a significant risk that an API key is being passed to the browser. We did not attempt to extract API keys from any bundle — that would exceed the scope of passive OSINT — but the pattern is a strong indicator. Browser-accessible API keys can be extracted by any user of the application.

Most Common Exposed Endpoints

Across the 11 companies with confirmable AI API endpoints, the following route patterns appeared most frequently. We present these not as exploits but as the patterns that an attacker's reconnaissance would prioritise:

/api/chat           — 9 of 11 companies (82%)
/api/assistant      — 7 of 11 companies (64%)
/api/stream         — 5 of 11 companies (45%)
/api/completions    — 4 of 11 companies (36%)
/v1/messages        — 3 of 11 companies (27%)
/api/agent/run      — 2 of 11 companies (18%)
/api/copilot        — 2 of 11 companies (18%)

All returned HTTP 401 on unauthenticated access.
All confirmed endpoint existence through non-404 response codes.
Response headers in several cases revealed FastAPI or Express framework versions.

What This Means for SA Financial Services Regulation

South African financial services are subject to oversight from the FSCA (Financial Sector Conduct Authority) and the Prudential Authority. Both regulators have signalled increasing attention to technology risk, and both operate within the overarching framework of the Financial Sector Regulation Act. The PA's Joint Standard on Cybersecurity and Cyber Resilience requires that regulated entities maintain accurate inventories of their technology assets, including those used for customer-facing services.

An AI agent that processes customer queries, initiates transactions, or accesses customer account data is a technology asset within the meaning of the Joint Standard. The public visibility of AI infrastructure — particularly the 55% rate of confirmable AI API endpoints — suggests that regulated entities may not have completed the asset inventory and risk assessment work that the Joint Standard requires for new technology deployments.

POPIA Implications

POPIA's security safeguard obligation (Section 19) requires that responsible parties take 'appropriate, reasonable technical and organisational measures to prevent loss of, damage to or unauthorised destruction of personal information, and unlawful access to or processing of personal information.' AI agents that access customer financial data — account balances, transaction history, identity documents — are processing personal information and are within the Section 19 scope.

The specific concern our findings raise is not that the observed endpoints are currently being abused — we have no evidence of that. The concern is that the existence of confirmable AI API endpoints, in combination with publicly visible AI SDK references, provides an attacker with a detailed map of which companies have deployed AI agents and where those agents are accessible. This is exactly the reconnaissance phase of an attack. The attack itself comes later.

Recommendations for SA Security Teams

• Audit your own public surface: Before an attacker does, run the same passive scan against your own domains. Use crt.sh to enumerate your subdomains, curl your public JavaScript bundles through grep patterns for LLM SDK references, and check your AI API routes for 401 response patterns that confirm their existence. You should know what is visible before others do.
• Move LLM API calls server-side: If your application is calling an LLM API from client-side JavaScript, that code belongs on the server. No API key should ever be exposed to a browser. This is not an AI-specific rule — it applies to any third-party API key — but AI API keys grant access to expensive compute and potentially to model fine-tuning infrastructure.
• Apply consistent subdomain hygiene: AI-related subdomains (chat., assistant., ai., copilot.) should be subject to the same domain inventory and SSL hygiene processes as production application subdomains. Certificate transparency logs make all subdomains permanently discoverable — plan accordingly.
• Complete the FSCA/PA asset inventory: If your organisation is regulated by the FSCA or PA and has deployed AI agents since your last formal technology asset review, those agents need to be added to the inventory and risk-assessed. The Joint Standard does not have a carve-out for AI.
• File a POPIA security review for each AI system: Section 19 security safeguards should be documented for each AI agent that processes personal information. This documentation does not need to be elaborate — it needs to exist and be maintained. The absence of documentation, in the event of a breach, is the evidence that 'appropriate, reasonable measures' were not in place.