Quick take: The most important security question to ask is how API keys and secrets are managed. Hardcoded keys in source code cause 60% of AI security breaches. Your team should use environment variables or secret management services like AWS Secrets Manager, never commit keys to Git, and rotate keys regularly.
AI projects handle sensitive data, expensive API keys, and user information. A security mistake can cost you hundreds of thousands in leaked API credits, expose customer data, or violate regulations like GDPR and HIPAA. Most founders don’t know what to ask until something goes wrong.
You don’t need deep security expertise to ask the right questions. These seven questions reveal whether your development team takes security seriously or is cutting corners that will hurt you later.
Critical Security Questions
| Question | Why It Matters | Red Flag Answer | Good Answer |
|---|---|---|---|
| How are API keys managed? | Leaked keys cost thousands | ”In the code" | "Environment variables with rotation” |
| Is data encrypted in transit and at rest? | Compliance and breach prevention | ”I think so" | "TLS 1.3 and AES-256 with details” |
| How do you handle PII and training data? | GDPR/CCPA compliance | ”We store everything" | "Documented retention and deletion” |
| Who has production access? | Insider threat and audit trails | ”The whole team" | "Role-based access with logging” |
| What third-party services access our data? | Supply chain risk | ”Not sure of all of them" | "Documented list with DPAs” |
| How are model inputs and outputs logged? | Debugging vs. privacy | ”We log everything" | "Sanitized logs with PII removed” |
| What’s the incident response plan? | Breach containment | ”We’ll figure it out" | "Documented runbook with contacts” |
1. How Are API Keys and Secrets Managed?
API keys for OpenAI, Anthropic, and cloud services are worth thousands of dollars if leaked. Hardcoding them in source code or committing them to Git is the number one security mistake in AI projects. Yet it happens constantly because it’s the easiest way to get things working.
Your team should use environment variables or secret management services like AWS Secrets Manager, HashiCorp Vault, or Google Secret Manager. Keys should never appear in code, configuration files checked into Git, or shared in Slack messages. They should be rotated regularly and have the minimum necessary permissions.
Ask to see how a developer adds a new API key to the project. If they say they edit a config file or paste it into the code, that’s a critical problem. The correct answer involves setting environment variables on servers or retrieving secrets from a secure vault at runtime.
Also ask about key rotation. Keys should be rotated every 90 days or when anyone with access leaves the company. If your team has never rotated keys or doesn’t know how, you’re vulnerable. One compromised laptop or disgruntled ex-employee can leak active credentials.
The financial risk is real. We’ve seen cases where leaked OpenAI keys racked up $50k in charges in 48 hours before anyone noticed. Some API providers will forgive these charges once, but you’re not guaranteed relief. Prevention is much cheaper than dealing with a leak.
2. Is Data Encrypted in Transit and at Rest?
Data should be encrypted while moving between services (in transit) and while stored on disk (at rest). In transit encryption prevents network eavesdropping. At rest encryption protects data if disks are stolen or improperly decommissioned. Both are table stakes for any modern application.
Ask specifically what encryption standards are used. Good answers include TLS 1.3 for transit and AES-256 for at rest. If your team can’t name specific protocols or says “whatever the default is,” they haven’t thought about it carefully.
For AI applications, encryption matters even more because you’re often handling training data, user conversations, or proprietary information flowing through LLM APIs. If someone intercepts traffic between your application and OpenAI, they see every prompt and response unless it’s encrypted.
Cloud providers like AWS, GCP, and Azure offer encryption by default for most services, but it’s not automatic everywhere. S3 buckets can be unencrypted. Databases can be configured without encryption. Your team needs to explicitly verify and enable encryption across all data stores.
Ask to see evidence that encryption is enabled. In AWS, that means checking S3 bucket settings, RDS encryption status, and load balancer SSL configuration. This should take your team 10 minutes to demonstrate. If they can’t show you, it might not be configured correctly.
3. How Do You Handle PII and Training Data?
Personal Identifiable Information like names, emails, addresses, and conversation history requires special handling under GDPR, CCPA, and other privacy regulations. AI applications often collect this data for training or improving models, creating compliance risks if not managed properly.
Your team should have documented policies for what PII is collected, how long it’s retained, where it’s stored, and how users can request deletion. If you’re using customer data to train or fine-tune models, you need explicit consent. If you’re sending data to third-party APIs like OpenAI, you need to understand their data policies.
Many LLM providers use your data to improve their models unless you opt out. OpenAI’s API has a “do not train” option that must be explicitly configured. If your team doesn’t know whether they’ve opted out, you might be inadvertently sharing customer data with your AI provider.
Ask how a user could request deletion of their data. If the answer is vague or involves manually searching through databases, you’re not GDPR compliant. You need automated systems or at minimum clear procedures for handling data subject access requests.
The penalty for getting this wrong is severe. GDPR fines can reach 4% of annual revenue. CCPA allows $7,500 per intentional violation. Even if you’re small enough to avoid regulatory attention, customer trust matters. One data mishandling story can kill your reputation.
4. Who Has Production Access?
Production access means the ability to view, modify, or delete live customer data and systems. Too many people with production access increases risk from mistakes, insider threats, and compromised accounts. Best practice is role-based access with the minimum necessary permissions.
Ask for a list of who has production database access, admin access to your cloud account, and the ability to deploy code. If the answer is “the whole development team,” that’s too broad. Junior developers don’t need production database access. Contractors working on front-end features don’t need AWS admin rights.
Good access control follows the principle of least privilege. Developers get access to what they need for their specific work. Production access requires justification and approval. All access is logged and reviewed periodically. When someone leaves the company or changes roles, access is revoked immediately.
Also ask about multi-factor authentication. Every account with production access should require MFA. Password-only access is unacceptable for systems that can affect customers or cost you money. If your team isn’t using MFA, implement it immediately.
We’ve seen multiple cases where former contractors retained production access months after their engagement ended. In one case, a disgruntled ex-contractor deleted production databases. In another, a contractor’s compromised laptop was used to access AWS and mine cryptocurrency on the company’s bill.
5. What Third-Party Services Access Our Data?
Modern AI applications integrate with dozens of third-party services: LLM APIs, vector databases, analytics tools, error monitoring, customer support platforms, and payment processors. Each one is a potential security and privacy risk if they’re breached or misuse data.
Ask for a complete list of third-party services that receive or store your customer data. For each one, you should know what data they receive, whether they’re GDPR-compliant, and whether you have a Data Processing Agreement in place. If your team can’t provide this list, they don’t have visibility into your attack surface.
Pay special attention to LLM APIs. When you send a prompt to OpenAI or Anthropic, you’re transmitting data to their servers. If those prompts contain customer PII, trade secrets, or sensitive information, you’re creating risk. Some AI providers offer SOC 2 compliance and private deployments. Others don’t.
Also ask about development and testing services. Do you use tools like LogRocket or FullStory that record user sessions? Are customer support tools like Intercom or Zendesk receiving conversation transcripts? Each integration needs security review.
The right answer is a documented list maintained in a security wiki or spreadsheet, including the service name, what data it receives, its security certifications, and the date of the last security review. If this doesn’t exist, create it before adding more integrations.
6. How Are Model Inputs and Outputs Logged?
Logging is essential for debugging and improving AI systems, but logs often contain sensitive data. If you log every LLM prompt and response, you’re storing copies of customer conversations, potentially including PII, passwords, or confidential information.
Ask what gets logged and where logs are stored. Good answers involve sanitizing logs to remove PII, storing them securely with encryption and access controls, and automatically deleting old logs after a defined retention period like 30 or 90 days.
Many teams log everything during development for debugging and forget to reduce logging in production. This creates sprawling log files full of sensitive data that might live in easily accessible locations, backed up indefinitely, and viewable by anyone who can SSH into a server.
Also ask who can view logs and how they’re accessed. Logs should require authentication and authorization. Sensitive logs should be further restricted to security personnel or senior engineers with documented justification for access.
The balance is logging enough to diagnose issues without creating privacy risks. User IDs, timestamps, and error codes are usually fine. Full conversation transcripts, API keys, and authentication tokens should never be logged in plaintext.
7. What’s the Incident Response Plan?
Security incidents will happen. Someone will click a phishing link, a dependency will have a critical vulnerability, or a misconfigured S3 bucket will be discovered. How your team responds determines whether an incident is a minor issue or a company-ending disaster.
Ask what happens if a security issue is discovered at 2am on Saturday. Who gets notified? What’s the escalation process? How do you communicate with affected customers? If the answer is “we’ll figure it out when it happens,” you’re not prepared.
A basic incident response plan includes contact information for key people, steps for common scenarios like leaked API keys or data breaches, communication templates for customers and regulators, and a list of external resources like security consultants or legal counsel.
Also ask about your breach notification obligations. Under GDPR, you have 72 hours to report certain breaches to regulators. Under CCPA and state laws, customer notification requirements vary. Your team should know these deadlines and have draft notification templates ready.
The plan doesn’t need to be perfect, but it needs to exist. Review it annually and after any security incident to incorporate lessons learned. The difference between a contained incident and a catastrophic breach often comes down to having a plan and practiced procedures.
How We Chose These Questions
We analyzed 30+ security audits of AI startups and identified the most common vulnerabilities that non-technical founders could have prevented with better oversight. We excluded highly technical issues that require specialized expertise to evaluate.
We prioritized questions that reveal systematic security problems versus one-off mistakes. A development team that can’t explain API key management probably has other security gaps. These questions act as proxies for overall security maturity.
Frequently Asked Questions
Should I hire a security auditor?
Yes, especially before launch or when handling sensitive data like healthcare or financial information. A professional security audit costs $10k-$50k and identifies issues your team missed. Consider it insurance against much larger breach costs.
How often should I ask these questions?
Ask during initial development, before launch, and quarterly after that. Security isn’t one-time. As your team adds features and integrations, new risks emerge. Regular check-ins ensure security keeps up with changes.
What if my development team gets defensive about security questions?
Professional developers welcome security oversight. If your team treats questions as mistrust rather than due diligence, that’s a cultural red flag. Security should be a shared priority, not an adversarial topic.
Are there certifications I should require?
SOC 2 Type II certification is the gold standard for SaaS companies. ISO 27001 is also respected. These certifications are expensive to obtain, so they’re not realistic for very early-stage startups, but they should be on your roadmap.
What security controls are overkill for a small startup?
You don’t need a full Security Operations Center or dedicated security staff when you’re pre-revenue. But the basics, API key management, encryption, access controls, and incident response planning cost almost nothing and prevent the most common problems.
Key Takeaways
- API key management is the highest-priority security concern for AI projects, with leaked keys causing the majority of security incidents
- Data encryption in transit and at rest should use modern standards like TLS 1.3 and AES-256 across all systems
- PII handling requires documented policies for retention, deletion, and compliance with GDPR, CCPA, and other regulations
- Production access should follow least-privilege principles with role-based controls and multi-factor authentication required
- Third-party services create supply chain risks and should be inventoried with security reviews and Data Processing Agreements
- Logging is necessary for debugging but should exclude PII and have defined retention periods to avoid privacy risks
- Incident response plans should exist before incidents happen, including contact procedures and breach notification templates
SFAI Labs provides security audits and compliance reviews for AI startups. We identify vulnerabilities before they become breaches and help you implement security best practices. Get a security assessment before you launch.
SFAI Labs