The AI security checklist for SaaS CTOs
Every layer of your AI stack has its own way of getting breached. This is the walkthrough we use when we test AI applications: the models, the prompts, the agents, the data, and the vendors behind them, in the order that matters.
In short. An AI security checklist is a layer-by-layer set of controls for an app that uses a model, copilot, or agent. Each item below is tagged Required, Recommended, or Optional, and maps to the OWASP LLM Top 10, MITRE ATLAS, or the NIST AI Risk Management Framework.
Map your AI ecosystem
You cannot secure what you have not mapped. Start with the full picture, then work inward.
List each feature, the models behind it, the agents you run, the retrieval sources feeding them, the plugins and Model Context Protocol servers they reach, and the third-party AI vendors in the path. Record what each can read and what each can do.
Mark where untrusted input enters (a message, a fetched page, an uploaded file, a retrieved record) and where the system can act (a shell call, a write, an email, a payment). The paths that connect the two are where your testing goes.
The model layer
Read the data terms before you route a customer record anywhere. Confirm in writing that inputs and outputs are not used for training by default, and know the retention window and region.
Pin model and framework versions so a silent update cannot change behaviour under you. Treat a downloaded model as untrusted code until you know its provenance. The model and vendor are now part of your supply chain.
Put per-tenant and global rate limits and budget ceilings in front of every model endpoint. Denial of wallet, where an attacker or a runaway loop runs up an unbounded bill, is a real outage mode.
The application and prompt layer
Work this layer against the OWASP Top 10 for Large Language Model Applications.
The moment untrusted text reaches a model that can act, you have an exposure. Assume the model will follow injected instructions, and design so the blast radius stays small even when it does. It does not show up in a normal code review.
Model output is untrusted input to whatever consumes it. Do not let a response flow into a shell, a query, rendered HTML, or another system without validation and encoding.
Assume a determined user can extract your system prompt and tool definitions. Keep real secrets out of the prompt entirely, and do not treat a “do not reveal this” line as a control.
The agent and tool layer
Scope every tool, credential, and data source to the minimum the task requires, and give each agent its own tightly scoped identity. Excessive agency is what turns one successful injection into an incident.
Any irreversible or high-impact action (moving money, deleting data, emailing customers, changing access, deploying) should need explicit human confirmation, not run on the model’s say-so.
Run agent actions with isolated execution, egress limits, and no ambient access to secrets. Log every tool call, input, and output so a manipulated agent leaves a trail you can reconstruct.
The data layer
Your RAG pipeline holds the same sensitive content as your primary datastore. Apply per-tenant access rules to retrieval, and make embeddings and indexes inherit the same isolation as the source records.
The fastest path to a breach in multi-tenant SaaS is one customer’s session, agent, or retrieval reaching another’s data. Test authorization on every AI endpoint, and scope agent memory and history per tenant.
Decide deliberately what may leave your boundary. Redact secrets and personal data before anything is logged, and confirm nothing sensitive is captured in provider-side traces you do not control.
Test, monitor, and respond
Test the application end to end against the OWASP LLM Top 10 and MITRE ATLAS: jailbreaks, indirect injection through retrieved content, data exfiltration, excessive agency, denial of wallet. A scanner finds the known; testing finds the exploitable.
Watch for injection attempts, spikes in tool calls or spend, outputs that leak data, and prompts probing for your instructions. Route those signals to a human.
Decide now how you contain a manipulated agent (revoke its credentials, disable the tool), who talks to customers and regulators, and how you reach them at 2am. Write and rehearse it while you are calm.
Govern and comply
Shadow AI, where staff paste source code or customer data into whatever assistant is open, is now a leading way sensitive data leaves a company. State what is approved and what may never go into a public tool. Cover it in onboarding.
SOC 2 and ISO 27001 remain the baseline, and frameworks like the NIST AI RMF reward being able to show what your models do and what data they use. Keep half an eye on these as you build.
The fundamentals still apply
An AI application is still a web application. Before the AI-specific work, confirm the basics are in place:
- Domain names locked with registrar transfer locks and two-factor
- Lookalike-domain and Certificate Transparency monitoring
- Two-factor enforced across every third-party service through your identity provider
- A public responsible-disclosure page and an internal security policy
- A vulnerability disclosure or bug bounty program with someone inside to action it
- A full asset inventory, kept current
- A culture where reporting a mistake is safe
Frequently asked questions
What is an AI security checklist?
A structured set of controls for securing an application that uses a model, copilot, or agent, worked through layer by layer: the AI ecosystem, the model, prompts, agents and tools, data and tenancy, testing, and governance. It complements a traditional application security checklist with the risks unique to models, most notably prompt injection and excessive agent permissions.
What is prompt injection?
When untrusted text reaching a model carries instructions that hijack its behaviour, either directly from a user or indirectly through a page, document, or record the model reads. It is the defining vulnerability class of AI applications and has to be tested directly.
Which framework should I use to secure an LLM application?
Start with the OWASP Top 10 for Large Language Model Applications for the vulnerability classes, MITRE ATLAS for adversarial techniques, and the NIST AI Risk Management Framework for governance.
Do I still need a penetration test if I use an AI security scanner?
Yes. A scanner tells you what is known to be broken; a scoped penetration test tells you what is actually exploitable, including business logic, chained paths, broken tenant isolation, and the prompt-injection and agent-abuse paths a scanner cannot reason about.
Where SecureLayer7 fits
Most of this list is work only your team can do. Where an outside offensive perspective helps most is proving what an attacker could actually do to your AI application.
We probe your models, copilots, and agents for prompt injection, data exfiltration, tool abuse, excessive agency, and broken tenant isolation, mapped to the OWASP LLM Top 10 and MITRE ATLAS, and hand your developers working proof-of-exploit with remediation guidance.
The AI feature sits on an application, a network, and a cloud. CREST-accredited and CERT-In empanelled testers who publish their own CVEs test all of it, with a re-test included to confirm the fix.
BugDazz maps your external footprint and keeps testing it as you ship, so the forgotten subdomain and the freshly exposed model endpoint surface as findings, not as an incident.
Sources