What MITRE ATLAS and OWASP LLM Top 10 Mean for Nonprofit AI Procurement
Two security frameworks have quietly become the common vocabulary for evaluating AI systems. MITRE ATLAS catalogs how AI gets attacked. The OWASP LLM Top 10 ranks the risks of language-model applications. Neither was written for nonprofits, but both can be turned into practical procurement questions that protect your organization before you sign a contract. This guide explains what they are and how to use them.
Most nonprofit AI procurement decisions are made the same way: a program leader sees a demo, the price looks affordable on the nonprofit tier, a few staff try it out, and the contract gets signed. Security rarely enters the conversation, because the people in the room are program experts, not security engineers, and the vendor's marketing materials use words like "enterprise-grade" and "SOC 2 compliant" that sound reassuring without meaning anything specific about how the AI itself behaves.
That gap matters more than it used to. AI systems are not ordinary software. They can be manipulated through their inputs, they can leak the data they were trained on or given access to, they can be tricked into taking actions their designers never intended, and they can fail in ways that look like success. A nonprofit deploying an AI chatbot, an AI-powered CRM feature, or an automated intake assistant is taking on a category of risk that traditional vendor questionnaires were never designed to catch.
This is where two frameworks become genuinely useful. MITRE ATLAS is a structured catalog of the tactics and techniques used to attack AI systems, maintained by the same organization behind the widely used MITRE ATT&CK framework for general cybersecurity. The OWASP LLM Top 10, maintained by the Open Worldwide Application Security Project, is a ranked list of the most critical security risks specific to applications built on large language models. Together they give non-technical decision-makers a shared vocabulary for asking vendors the right questions.
You do not need to become a security expert to use either framework. You need to understand what each one is for, which parts apply to the kind of AI you are buying, and how to translate them into a handful of concrete questions and contract clauses. This article walks through exactly that, with nonprofit procurement as the lens throughout. For the broader context on stress-testing AI before launch, see our guide to AI red teaming for nonprofits.
Two Frameworks, Two Jobs
The first thing to understand is that ATLAS and the OWASP LLM Top 10 are not competitors or alternatives. They answer different questions, and a thorough procurement process uses both. Confusing them, or assuming a vendor who mentions one has addressed the other, is a common mistake.
MITRE ATLAS: How AI Gets Attacked
A knowledge base of adversary behavior against AI systems.
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It documents the real-world tactics attackers use against machine learning and AI, organized into stages such as reconnaissance, initial access, and impact. It is descriptive: it tells you what can go wrong and how, drawn from documented incidents and security research. Think of it as a map of the threat landscape.
OWASP LLM Top 10: What to Prioritize
A ranked list of the most critical LLM application risks.
The OWASP LLM Top 10 narrows the field to the ten risks that matter most for applications built on large language models specifically. It is prioritized and prescriptive: it tells you which risks deserve attention first and offers mitigation guidance for each. Think of it as a triage list for the chatbot, copilot, or AI feature you are actually buying.
A useful way to hold the distinction: ATLAS is broad and covers all kinds of AI, including image recognition, predictive models, and recommendation engines. The OWASP LLM Top 10 is narrow and focuses on the conversational and generative AI that most nonprofits are actually adopting in 2026. If you are buying a chatbot, the OWASP list is your day-one priority. If you are buying or building something more ambitious, ATLAS gives you the wider field of view.
Both frameworks are free, publicly maintained, and updated as the threat landscape evolves. Neither requires a license, a consultant, or a security certification to read. That accessibility is precisely why they are valuable to resource-constrained nonprofits: they encode expertise that would otherwise cost a great deal to acquire.
The OWASP LLM Top 10, Translated for Nonprofit Buyers
You do not need to memorize the full technical list. What matters is recognizing which risks are most relevant to the kind of AI a nonprofit typically buys, and what each one means in plain terms. Here are the risks that come up most often in nonprofit deployments, grouped by the harm they cause.
Risks That Expose Your Data
- Sensitive information disclosure: The AI reveals private data it was given access to, such as donor records, beneficiary case notes, or internal documents, to someone who should not see it. For a nonprofit handling protected populations, this is often the single highest-stakes risk.
- System prompt leakage: The hidden instructions that shape how the AI behaves get extracted by a user, potentially exposing internal logic, security rules, or embedded credentials.
- Vector and embedding weaknesses: When an AI is connected to your documents through a retrieval system, flaws in how that knowledge base is built can let one user's query surface another user's confidential content.
Risks That Let the AI Be Manipulated
- Prompt injection: A user, or content the AI reads, contains hidden instructions that override the AI's intended behavior. This is the most common and most underestimated risk in conversational AI.
- Excessive agency: The AI has been given more permissions or autonomy than it needs, so a manipulation that should be harmless instead lets the system send emails, change records, or trigger payments.
- Improper output handling: The AI's response is passed to another system without being checked, so a malicious output becomes a malicious action somewhere downstream.
Risks That Degrade Trust and Reliability
- Misinformation: The AI confidently states something false. For a nonprofit answering questions about benefits, eligibility, or services, a fluent wrong answer can do real harm to the person who trusted it.
- Supply chain vulnerabilities: The AI depends on third-party models, datasets, or components that may themselves be compromised, outdated, or unmaintained.
- Unbounded consumption: The AI can be made to consume excessive resources, driving up your usage-based bill or denying service to legitimate users.
We cover several of these risks in depth in our security series, including prompt injection, sensitive information disclosure, and excessive agency. For procurement purposes, you do not need that depth on every risk. You need enough to recognize which ones apply to your use case and to ask the vendor about them directly.
Matching the Framework to What You Are Actually Buying
Not every risk applies to every purchase. A useful procurement process starts by classifying the AI you are buying, then focusing on the risks that classification raises. Here are the most common nonprofit AI categories and the risks that deserve attention in each.
Public-Facing Chatbots and Service Assistants
A chatbot on your website that answers questions from the public, helps with intake, or supports beneficiaries faces the widest exposure because anyone can interact with it. Prioritize prompt injection, misinformation, sensitive information disclosure, and unbounded consumption. Ask specifically how the system prevents a stranger from extracting confidential information or steering the bot off-topic into harmful territory.
AI Connected to Your Documents (Retrieval Systems)
When an AI tool searches your internal documents, donor files, or case records to answer questions, the knowledge base itself becomes an attack surface. Prioritize vector and embedding weaknesses, sensitive information disclosure, and access controls. Ask how the system ensures a user only sees content they are authorized to see, and whether one user's query can ever surface another's data.
AI Agents That Take Actions
Agentic tools that can send emails, update CRM records, schedule meetings, or process transactions carry the highest stakes because a manipulation becomes a real-world action. Prioritize excessive agency, improper output handling, and prompt injection. Ask what the agent is permitted to do without human approval, and where the human-in-the-loop checkpoints sit. Our piece on excessive agency covers this in detail.
AI Features Bundled Into Existing Software
When your CRM, email platform, or grants system adds an AI feature, the procurement question shifts. You are not choosing the underlying model, the vendor is. Prioritize supply chain vulnerabilities and data handling. Ask which third-party model powers the feature, where your data is processed, and whether your information is used to train models. Our article on evaluating AI vendor security claims expands on this.
Turning the Frameworks Into Procurement Questions
The practical value of ATLAS and the OWASP LLM Top 10 is that they let you ask precise questions instead of vague ones. A vendor can deflect "Is your AI secure?" with marketing language. It is much harder to deflect a question grounded in a named, public framework. Here is a set of procurement questions, organized by what they protect against.
Questions About Data Protection
- How does your system prevent sensitive information disclosure as defined in the OWASP LLM Top 10? Can you describe the access controls between users?
- Is our organization's data used to train your models or any third-party models? If so, can we opt out, and is that opt-out the default?
- Where is our data processed and stored geographically, and who has access to it?
Questions About Manipulation Resistance
- What testing have you done against prompt injection, and can you share the results or methodology?
- What actions can the system take without human approval, and how do we configure those permissions?
- Have you conducted red team testing or adversarial evaluation against your AI? Was it internal, external, or both?
Questions About Reliability and Supply Chain
- Which underlying AI models power this product, and what is your process when a model is deprecated or updated?
- How does the system handle situations where it does not know an answer? Does it acknowledge uncertainty or guess?
- What controls exist to prevent unbounded resource consumption that could spike our costs?
Questions About the Vendor's Own Practices
- Are you familiar with MITRE ATLAS and the OWASP LLM Top 10? How do they inform your development process?
- What is your incident response process if an AI security issue is discovered, and how would we be notified?
- Do you have a published security or trust page, and a way for researchers to report vulnerabilities?
How to Read the Answers You Get Back
Asking the questions is only half the work. The more important skill is interpreting the responses, because a confident answer is not the same as a good one. Here is how to evaluate what vendors tell you.
Strong Signals
A vendor who recognizes the frameworks by name, describes specific mitigations rather than general assurances, can name the models they depend on, has a published security page, and can describe their red team or adversarial testing process is showing genuine maturity. So is a vendor who answers "we have not fully addressed that yet, here is our roadmap." Honesty about limitations is a better signal than blanket confidence.
Warning Signs
Be cautious when a vendor responds only with compliance certifications that are unrelated to AI behavior, treats every question as already solved without specifics, cannot say which models power their product, deflects security questions to a sales contact who never follows up, or claims their AI "cannot be manipulated" or "never makes mistakes." No honest vendor makes absolute claims about AI behavior, because no AI system is immune to these risks. Overconfidence is itself a red flag.
The Proportionality Test
Calibrate your scrutiny to the stakes. A small AI tool that drafts internal meeting notes does not need the same depth of review as a public-facing intake chatbot handling sensitive disclosures. Spend your limited procurement time where the consequences of failure are highest. The frameworks help you make that judgment because they make the risks explicit instead of leaving them invisible.
For a structured way to bring these criteria together, our nonprofit AI vendor evaluation checklist and our guide to red flags in AI vendor pitches give you complementary tools for the full procurement conversation.
Writing the Frameworks Into Your Contracts
The strongest use of ATLAS and the OWASP LLM Top 10 is not in the sales conversation but in the contract itself. Verbal assurances are easy to give and hard to enforce. Contract language creates accountability. You do not need a specialist law firm to do this; a few well-chosen clauses, reviewed by your usual counsel, go a long way.
Reference the Frameworks Explicitly
Name the OWASP LLM Top 10 and, where relevant, MITRE ATLAS in your contract or in an attached security exhibit. A clause stating that the vendor maintains controls addressing the risks described in the current OWASP LLM Top 10 gives you a defined, evolving standard rather than a one-time snapshot. Because both frameworks are publicly maintained and updated, this language stays current as the threat landscape changes.
Require Notification of AI Security Incidents
Many breach-notification clauses were written before AI and only cover traditional data breaches. Expand the definition to include AI-specific incidents: a prompt injection that exposed data, a model behaving in an unintended way, or a discovered vulnerability in the AI layer. Specify a notification timeline so you are not the last to know.
Lock Down Data Use and Training Rights
State clearly that your organization's data, and the data of the people you serve, will not be used to train the vendor's models or any third-party models without explicit written consent. This single clause prevents one of the most common and least visible ways nonprofit data leaks into systems beyond your control. Our guidance on AI contract review covers the surrounding language.
Preserve a Right to Test and an Exit Path
Where stakes are high, negotiate a right to conduct or commission your own security testing of the AI, and a clear exit clause that lets you leave and recover your data if a serious unaddressed vulnerability emerges. A vendor confident in their security will rarely object to a reasonable testing provision. Resistance to it is itself informative.
Making This a Repeatable Part of Procurement
A framework used once and forgotten provides little protection. The organizations that get the most value build a lightweight, repeatable process so every AI purchase gets the same baseline scrutiny without slowing everything down.
- Create a standard AI procurement worksheet. A one-page document that classifies the AI being bought, lists the relevant OWASP risks, and records the vendor's answers. Reusable across every purchase, it ensures consistency even when different staff lead different procurements.
- Assign a single reviewer. One person, often an operations or IT lead, who owns the AI security review for every purchase. They do not need to be a security expert, only familiar enough with the frameworks to ask the questions and flag concerns.
- Scale scrutiny to risk tier. Define two or three tiers, from low-risk internal tools to high-risk public or sensitive systems, and apply proportional review depth. This keeps the process fast where speed is fine and thorough where it matters.
- Revisit annually. The OWASP list and ATLAS both evolve, and so do the AI tools you already use. An annual review of existing AI vendors against the current frameworks catches risks that did not exist when you first signed.
- Connect it to your AI policy. Procurement scrutiny works best as part of a broader governance approach. If your organization does not yet have an AI policy, our guide to creating an AI policy in one day is a practical starting point.
The goal is not to turn every staff member into a security analyst. It is to ensure that no AI system enters your organization without someone having asked, in a structured way, what could go wrong and what the vendor has done about it. That single habit closes the most dangerous gap in nonprofit AI adoption: the gap between buying a tool and understanding it.
Conclusion
MITRE ATLAS and the OWASP LLM Top 10 were created by security professionals for security professionals, but their value to nonprofits comes from something simpler than technical depth. They provide a shared, public, evolving vocabulary for a conversation that nonprofits have mostly not been having. Without that vocabulary, AI procurement is a leap of faith built on demos and marketing language. With it, procurement becomes a structured inquiry where the buyer asks specific questions and can tell a substantive answer from a deflection.
The frameworks do different jobs. ATLAS gives you the wide view of how AI systems get attacked across every category of AI. The OWASP LLM Top 10 gives you the focused, prioritized list of risks for the conversational and generative tools most nonprofits are buying right now. You do not need to master either one. You need to know which risks apply to your purchase, ask the vendor about them by name, read the answers critically, and write the important commitments into the contract.
None of this requires a security team or a large budget. It requires a worksheet, an assigned reviewer, and the discipline to apply the same baseline questions to every AI tool before it touches your data or your constituents. That is well within reach of even a small nonprofit, and it is far cheaper than the alternative: discovering a serious flaw after a chatbot has already leaked beneficiary data or an agent has already taken an action no one authorized.
AI adoption in the nonprofit sector is accelerating, and the tools are genuinely useful. The frameworks do not exist to slow that adoption down. They exist to make it survivable, so that the organizations embracing AI today are not the ones learning hard lessons tomorrow. Treat ATLAS and the OWASP LLM Top 10 as procurement allies, and they will do exactly that.
Evaluating an AI Tool Before You Buy?
We help nonprofits build practical AI procurement processes, turning security frameworks into the right questions, contract language, and review steps for your organization.