How to Secure Your AI Agents and Data at Scale: Common Vulnerabilities and Best Practices

I’m Denis Shokhirev, Enterprise AI architect in Erlangen, Germany. Over the last six months, I’ve shipped 14 production AI agents for DACH B2B clients on a stack of Claude, Supabase, n8n, Doppler, and self-hosted Postgres. Here’s a reality check: a single leaked Claude API key in a public repo cost one fintech client two days of downtime for credential rotation—plus a frantic vendor compliance call at 2am.

Where AI Agent Security Fails in Production

I see the same security pitfalls in most client codebases:

• Secrets (Claude/OpenAI/Supabase keys) kept in .env files, accessible to every developer
• No prompt validation—agents can be tricked into executing SQL injection or data deletion
• No audit logging, no rollback path if things go wrong
• LLM-generated code merged with minimal review
• Customer data stored in plaintext, no table-level encryption

Real example: on three recent agent launches, I caught SQL injection patterns in LLM-generated Python code for the DB layer. Bandit flagged these before prod. Without static scanning, at least one would’ve shipped with a critical vulnerability.

Common Vulnerabilities in AI-Driven Systems

1. SQL Injection in LLM-Generated Code

LLMs like Claude and GPT-4 often suggest unsafe DB queries. The 2024 Stanford CodeML paper found that 38% of LLM-generated Python samples contained CWE-89 SQL injection patterns (source).

# Unsafe LLM-generated code
def get_user(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    cursor.execute(query)
# Safe version with parameterized queries
def get_user(email):
    query = "SELECT * FROM users WHERE email = %s"
    cursor.execute(query, (email,))

2. Secret Leakage (API Keys, Tokens)

Storing secrets in code or unencrypted .env files is still common. Gitleaks uncovers exposed secrets in about half of all codebases I audit.

# Scan git repo for secrets
gitleaks detect --source .

3. Prompt Injection and RAG Data Leakage

Without strict input validation, attackers can manipulate prompts to change agent behavior or exfiltrate data. In Retrieval-Augmented Generation (RAG) setups, misconfigured vector search can expose private documents.

Best Practices for Securing AI Agents at Scale

1. Static and Dynamic Code Analysis

Bandit and semgrep are non-negotiable for Python/JS; for TypeScript, use eslint and snyk. I run them on every commit, not just release.

# Python: bandit
bandit -r .
# JS/TS: semgrep
semgrep --config=auto .

2. Centralized Secret Management

Never store secrets in code or .env. Use Doppler or HashiCorp Vault. In n8n, pass secrets via environment variables, not hardcoded fields.

# Fetch secrets from Doppler CLI
doppler secrets download --no-file --format env

3. Access Control and Audit Logging

Supabase makes it easy to enforce Row Level Security (RLS). Every agent action goes to an audit log table in Postgres, with syslog integration for critical events.

-- Enable RLS
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
-- Set up audit log table
CREATE TABLE audit_log (
    id serial PRIMARY KEY,
    agent_id text,
    action text,
    ts timestamp DEFAULT now()
);

4. Prompt Validation and Output Sandboxing

I use regex-based filtering on incoming prompts to block blacklisted commands (DROP, DELETE, etc). Output sandboxing: restrict agent-initiated queries to SELECT only, or limit available functions at runtime.

5. Data Encryption—At Rest and In Transit

For Postgres, use disk encryption (LUKS or fscrypt). For especially sensitive tables, apply pgcrypto for field-level encryption.

Table: Vulnerabilities vs. Mitigation Techniques

FAQ

Where do security issues most often appear in AI agent stacks?

In 70% of production incidents I’ve seen, the DB layer—especially LLM-generated code not scanned by bandit or semgrep—was the weak point.

Is gitleaks alone enough?

No. Gitleaks only flags secrets in git, but secrets can leak in logs or CI/CD. Doppler alerting on secret access is a must.

How do you validate prompts for LLM agents?

Regex blacklists for dangerous commands (DROP, DELETE), plus prompt length and context limits. Output is sandboxed by default.

What’s your preferred audit log stack?

Postgres audit log table for most projects, with syslog integration for high-risk actions.

Can you trust LLM-generated code in production?

No. Always static-scan and human-review LLM output. LLMs speed up dev, but don’t guarantee security.

Which stage in your LLM pipeline catches the most issues in prod—static analysis, runtime sandbox, or human review? I’d genuinely like to know.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.