On 9 December 2025, OWASP published the Top 10 for Agentic Applications 2026. It is the first peer-reviewed, industry-standard security framework for AI systems that do not just respond to prompts but plan, decide, and take actions. More than 100 contributors worked on it, drawn from AWS, Microsoft, Palo Alto Networks, and a range of security research organisations.
This is not a research paper. It is a control framework. If your organisation is deploying autonomous AI agents, and the number of fintechs and financial services firms across Sub-Saharan Africa that now are is larger than many CISOs realise, this document will be referenced by auditors, regulators, and cyber insurers within 12 months. It is worth reading now, not after the first incident.
I wrote a short note on LinkedIn earlier this year about how “agentic AI systems are running in production with keys in the lock.” The OWASP publication is the formal version of that concern. This post applies it to the specific context I see most often: an African fintech with 50 to 300 employees, running on AWS or Azure, that has begun to deploy AI agents for customer support, internal operations, or product features, with security considerations arriving well after the first agent went live.
Why this framework exists
The existing OWASP Top 10 for LLM Applications covers vulnerabilities in systems that use language models: prompt injection, insecure output handling, training data poisoning, and related concerns. Those risks still apply to agentic systems. They are not sufficient.
An LLM application takes input, generates output, and the transaction ends. An agent is different. It decides autonomously which actions to take. It calls external tools: APIs, databases, email systems, cloud infrastructure. It maintains state across sessions through memory. It often communicates with other agents. It chains actions together, where the combination can be dangerous even when each individual action is benign.
The enterprise machine-to-human identity ratio is now roughly 82 to 1, according to Palo Alto Networks’ analysis of the new framework. Most of those non-human identities were not designed for autonomous decision-making, and most of them have permissions that were scoped before anyone imagined an AI agent would use them.
The OWASP Agentic Top 10 addresses the risks that emerge from that reality.
The ten risks, and what they look like in an African fintech
I will not reproduce the full framework, it is freely available at genai.owasp.org. What is useful is to translate each risk into a concrete scenario in the operating context most of my clients actually work in.
Risk 1: Excessive Agency and Privilege Escalation. An AI agent is given broad permissions because scoping them precisely was too much work. The agent has a tool that can read files and a tool that can make API calls. A prompt injection in a customer support ticket causes the agent to read an environment variable containing an AWS access key and exfiltrate it via an API call to an external domain. Every individual permission was defensible. The composite was a data exfiltration capability.
Risk 2: Uncontrolled Tool Use. An agent designed to help with cloud operations is asked to “clean up old test resources.” The agent interprets the scope broadly and deletes resources in staging environments that were actively in use. No confirmation step. No dry-run. No environment scope check. The bill is reputational as well as financial.
Risk 3: Memory Poisoning. An AI assistant deployed for finance team members maintains memory of user preferences. An attacker sends an email with hidden instructions styled as a system note. The assistant, summarising the email, writes the instruction into its memory as a preference. Weeks later, when the user asks for a financial report, the assistant includes a link to an attacker-controlled phishing site as a “trusted source.”
Risk 4: Insecure Inter-Agent Communication. Multiple agents collaborate on a workflow: one researches, one analyses, one writes. An attacker plants a webpage with embedded instructions. The research agent passes the instructions along. Neither of the downstream agents verifies the source. The chain executes the attacker’s intent.
Risk 5: Identity and Authentication Gaps. The organisation’s AI agents authenticate with a single shared service account that has organisation-wide read access. A user in marketing asks their agent for a document. The agent, acting under the shared service account, retrieves confidential board papers from the finance directory. The audit trail shows the service account, not the user.
Risk 6: Unmonitored Autonomous Actions. A DevOps agent is authorised to scale infrastructure. An anomalous traffic pattern causes it to spin up GPU instances aggressively. The agent is operating within its permissions. By the time anyone notices, the cloud bill has grown by an order of magnitude. No action budget, no anomaly alert, no kill switch.
Risk 7: Data Exfiltration Through Agent Chains. A research agent summarises internal documents and passes the summary to a writing agent. A prompt injection causes the writing agent to include confidential content in an external-facing report. Neither agent violated its individual permissions. The chain did.
Risk 8: Supply Chain Risks in Agent Frameworks. A team uses a community-contributed plugin from an agent framework’s marketplace. The plugin silently logs all inputs to an external endpoint for “analytics.” The team trusted the marketplace rating. The source code was never reviewed.
Risk 9: Lack of Human Oversight Mechanisms. A customer service agent can issue refunds autonomously for “routine” requests. Attackers discover that framing requests in specific language bypasses the complexity heuristic. Unauthorised refunds are issued before anyone notices the pattern.
Risk 10: Insufficient Logging and Auditability. A data breach occurs involving an AI agent. The logs show the user’s initial prompt and the agent’s final response. What happens in between, the tool calls, the intermediate decisions, the data accessed, the memory writes, is not logged. The investigation stalls because there is no audit trail to follow.
The three risks I am most concerned about for African fintechs
All ten risks matter. In practice, three of them are disproportionately relevant to the fintech and financial services context I work in, and I would focus scarce security attention on these first.
Identity and Authentication (Risk 5). Under Joint Standard 2, South African financial institutions must be able to demonstrate that access to information is limited to authorised users and devices. A fleet of AI agents operating under shared service accounts violates this control in a way that is visible to a regulator on the first audit question. The remediation is per-agent identity, scoped OAuth delegation, and action attribution logging. Every AI agent should have its own identity, distinct from the user it serves and distinct from other agents. This is the single most important architectural decision in deploying agents in a regulated environment.
Unmonitored Autonomous Actions (Risk 6). Fintechs run lean. The appeal of agentic automation, customer service, reconciliation, fraud triage, operational workflows, is exactly that it scales without linear headcount growth. The risk is that actions happen faster than humans can observe them, and the financial consequences of a misbehaving agent in a payments context are direct. The mitigation is structural: action budgets, anomaly detection, hard limits on financial exposure per session, and kill switches that actually work under load.
Data Exfiltration Through Agent Chains (Risk 7). POPIA and the equivalent data protection frameworks across the continent are strict on personal data leaving authorised boundaries. Agent chains create exfiltration paths that traditional DLP tools do not see, because the data leaves the organisation through what looks like normal agent activity. A research agent browsing the web on behalf of a user, where the URL contains base64-encoded customer data, will not trip most DLP systems. The mitigation is data flow mapping across agent chains, output filtering at each trust boundary, and network-level allow-lists for agent outbound traffic.
Five concrete steps for a CTO starting today
If you are responsible for an organisation that has begun to deploy AI agents and you have not yet formally addressed the OWASP framework, here is the order I would work in. This assumes a resource-constrained environment: one security-aware engineer, not a dedicated AI security team.
- Inventory the agents you actually have. Most organisations underestimate this count. Include Copilot, Salesforce Agentforce, custom GPTs, MCP integrations, and any internal agent built on a framework like LangChain, LangGraph, CrewAI, or AutoGen. If you cannot list them, you cannot secure them.
- Map the identities each agent uses. For each agent, record: the identity it authenticates as, the scope of permissions that identity holds, the downstream systems it can access, and whether its actions are logged as the agent or as the underlying service account. This inventory will likely reveal that the same service account is doing six different jobs with permissions for all six.
- Scope permissions down to least privilege. This is tedious work. It is also the highest-leverage control in the framework. Every agent should have only the permissions required for its specific function. Most do not.
- Instrument the logging before the next deployment, not after. Structured logging that captures decision traces, tool calls, and data access is the difference between a recoverable incident and an unrecoverable one. Implementing it retroactively is painful. Implementing it now, before the next agent goes live, is straightforward.
- Define action budgets and kill switches for any agent that touches money, customer data, or production infrastructure. This is non-negotiable for any fintech. The question is not whether you need it. The question is whether you have it documented and tested.
What the framework does not do
The OWASP Agentic Top 10 is a framework, not a tool. It tells you what to think about. It does not configure your agents for you, and it does not replace the judgement calls that a skilled security practitioner brings to a specific deployment.
It is also not a compliance requirement today. No regulator in the markets I work in has yet cited it in formal guidance. That is a matter of time, not of probability. By the time it is formally referenced, the institutions that treated it as a strategic reference earlier will be ahead of the institutions that waited.
The point of the framework is to make the security conversation about agents concrete. Before December 2025, the conversation was about “AI risks” in the abstract. Now it is about ten specific risks, with specific mitigation patterns, agreed by a peer-reviewed body of practitioners. That is a meaningful step forward. Treat it accordingly.
The OWASP Top 10 for Agentic Applications 2026 is available at genai.owasp.org.
