← Back to Articles

Building applications that integrate AI APIs — whether that's OpenAI, Anthropic, Google Gemini, or a locally hosted model — introduces a new layer of security risk that most developers aren't fully prepared for. The data flowing through these systems is often sensitive. The APIs are expensive to run. And the attack surface is larger and stranger than a traditional web application.

I've spent the past year building AI-integrated systems across a range of contexts — from enterprise chatbots to automated workflow tools — and I've made (and fixed) most of the mistakes below. This isn't academic. These are the ten things that actually matter.

01

Never hardcode API keys or secrets

This sounds obvious, but it's the most common mistake I see — especially from developers moving fast on a prototype. Hardcoded API keys end up in git repositories, Docker images, browser source, and log files. Once exposed, they can be exploited within minutes by automated scanners that watch public repos.

✅ Do: Store all secrets in environment variables or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, or even a .env file that is explicitly listed in .gitignore). In production, inject secrets at runtime — never bake them into your image or codebase.
❌ Don't: Put API keys in your source code, config files, or README.md. Not even temporarily. There is no "I'll remove it later" — later never comes.
02

Implement rate limiting on every AI endpoint

AI API calls are expensive — both in cost and latency. Without rate limiting, a single malicious user (or a runaway loop in your own code) can burn through your entire monthly budget in hours. Beyond cost, unthrottled endpoints are vulnerable to denial-of-service attacks that degrade the experience for all users.

✅ Do: Apply rate limiting at multiple layers — per IP, per user account, and per API key. Use a library like express-rate-limit (Node), slowapi (Python/FastAPI), or rate limiting middleware in your reverse proxy (nginx, Cloudflare). Set hard daily spend limits on your AI provider account.
❌ Don't: Rely only on the AI provider's own rate limits — by the time you hit those, you've already spent the money.
03

Validate and sanitise all user input before sending to the model

Prompt injection is the AI equivalent of SQL injection. A malicious user can craft input that overrides your system prompt, extracts confidential instructions, causes the model to behave unexpectedly, or exfiltrates data from your context window. This is a real, actively exploited attack vector.

✅ Do: Validate input length, format, and content before forwarding to the model. Strip or encode special characters where appropriate. Consider a dedicated input validation layer that rejects obviously malicious patterns. Treat the model as untrusted output — always validate what comes back before acting on it programmatically.
❌ Don't: Pass raw user input directly to the model, especially in automated pipelines where the model's output triggers downstream actions (sending emails, running code, making API calls).
04

Log everything — but log it safely

Comprehensive logging is essential for debugging, auditing, and detecting abuse. But AI applications handle sensitive data — user queries, personal information, internal business context — and logging naively can create new security vulnerabilities. Logs that contain PII or sensitive business data become a liability if they're not properly secured.

✅ Do: Log request metadata (timestamp, user ID, token count, response time, model used) without logging the full prompt or response content by default. When you need to log content for debugging, apply redaction or masking to sensitive fields. Store logs in a secured, access-controlled location. Set retention policies and rotate logs regularly.
❌ Don't: Log raw prompts and responses to stdout in production, or store them in unencrypted flat files accessible to all developers.
05

Authenticate and authorise every request

AI features are often bolted onto existing applications without the same authentication rigour applied to the rest of the system. This creates scenarios where an unauthenticated user can access AI endpoints, or where an authenticated user can access data via the AI that they shouldn't be able to access directly.

✅ Do: Require authentication for every AI endpoint — no exceptions. Implement authorisation checks to ensure the user's query only surfaces data they're permitted to see. Be especially careful with Retrieval-Augmented Generation (RAG) systems — the retrieval layer must enforce the same access controls as the rest of your application.
❌ Don't: Assume that because your AI endpoint is "internal" or "not yet announced," it won't be discovered. Obscurity is not security.
06

Use HTTPS everywhere — including internal services

Data sent between your application and an AI API travels over the internet. Data sent between your own internal microservices may travel across networks you don't fully control. Both need to be encrypted in transit. This is table stakes for any application, but it's worth stating explicitly because AI applications often start as quick scripts or prototypes that never get "productionised."

✅ Do: Enforce HTTPS on all external-facing endpoints. Use TLS for internal service-to-service communication. Ensure your AI provider's SDK enforces certificate verification (most do by default — don't disable it). Use a tool like Let's Encrypt for free, auto-renewing certificates on any public endpoint.
❌ Don't: Run AI APIs over plain HTTP in any environment — development habits become production habits.
07

Scope your AI provider permissions to the minimum necessary

Most AI providers allow you to create multiple API keys with different permission levels. A key used by your web application to run completions doesn't need the ability to delete your fine-tuned models, access billing data, or manage other API keys. Applying the principle of least privilege limits the blast radius if a key is compromised.

✅ Do: Create separate API keys for each environment (dev, staging, prod) and each application component. Restrict each key to only the permissions it needs. Rotate keys regularly and immediately upon any suspected compromise. Set per-key spending limits where your provider supports it.
❌ Don't: Use a single "master" API key for everything across all environments and team members.
08

Implement output filtering before returning model responses to users

Language models can produce harmful, inappropriate, or legally problematic content even when you've done everything right on the input side. Jailbreaks evolve constantly. Models hallucinate. Without output filtering, you may be serving content that violates your terms of service, exposes you to legal risk, or simply embarrasses your organisation.

✅ Do: Implement a content moderation layer on model outputs — most AI providers offer a moderation API endpoint for this purpose. Define clear policies for what content is acceptable and build automated checks against those policies. Have a human review process for flagged outputs in high-stakes contexts.
❌ Don't: Assume the model will always behave safely just because your system prompt says to. System prompts are guidelines, not guardrails.
09

Monitor costs and set hard spending alerts

A security misconfiguration — an exposed endpoint, a missing rate limit, a runaway automation — can result in a bill for thousands of dollars before you notice. AI APIs price by usage, and abuse can scale costs faster than almost any other attack vector. Cost monitoring is a security control.

✅ Do: Set billing alerts at multiple thresholds (50%, 80%, 100% of your expected monthly spend). Set hard monthly limits on your AI provider account if available. Monitor token usage per user or session and alert on anomalous patterns. Track cost per request and alert if average cost spikes unexpectedly.
❌ Don't: Check your bill once a month. By then, the damage is done.
10

Have a kill switch — and test it

Every AI-integrated system should have a clearly defined and tested procedure for disabling AI functionality quickly, without taking down the rest of the application. This matters for security incidents (a prompt injection attack, a compromised key), unexpected behaviour (the model producing harmful outputs at scale), and provider outages (so your application degrades gracefully).

✅ Do: Build a feature flag or configuration switch that can disable AI functionality in seconds — deployable without a code release. Design your application to function in a degraded state without the AI layer. Test the kill switch regularly. Document the runbook so any team member can execute it under pressure.
❌ Don't: Build an application where disabling the AI layer requires a full deployment, database migration, or senior engineer intervention at 2am.

The 10-point checklist

  1. Never hardcode API keys — use environment variables and secrets managers
  2. Rate limit every AI endpoint — per IP, per user, per key
  3. Validate and sanitise all user input before it reaches the model
  4. Log metadata, not sensitive content — store logs securely
  5. Authenticate and authorise every request — including RAG retrieval
  6. Enforce HTTPS everywhere — including between internal services
  7. Scope AI provider permissions to the minimum necessary
  8. Filter model outputs before they reach your users
  9. Set hard spending alerts and monitor cost anomalies
  10. Build a kill switch — and test it before you need it

Security in AI applications isn't fundamentally different from security in any other software — it's the same principles applied to a new attack surface. The difference is that the attack surface is larger, the cost of exploitation is higher, and the failure modes are more novel. Get the basics right first, then layer on AI-specific controls.

If you're building an AI-integrated application and want a security review or architectural guidance, reach out to MCSL Solutions. We help organisations build AI systems that are not just capable, but secure and governable.

ML

Mariano Loisso

Principal Consultant, MCSL Solutions. 20+ years in IT governance, risk, and service management across CBA, NSW Government, Woolworths, Allianz, and Mercer Super. Specialises in helping organisations build secure, scalable IT systems.