RoleGPSThe free map to your AI job
All capabilities · Cloud, deployment & production

Secure keys, auth and data in AI apps

Secrets management, IAM least privilege, OAuth, tenant isolation, audit logs.

~8 focused hoursintermediate
Explore 3 tools for this project
Market relevance

Which roles ask for this — and how often

Share of job postings in India, per role, that name this capability.

AI Security Engineer98%
What employers mean

You should be able to…

  1. Store API keys/DB credentials in a secrets manager, never in code or plaintext env files in git
  2. Set up least-privilege IAM roles so a service can only do what it needs to
  3. Add OAuth2/JWT auth to an API and validate tokens on every protected route
  4. Isolate tenant data in a multi-tenant system so one customer can't see another's data
  5. Log security-relevant events (auth failures, data access) for audit without logging secrets/PII
  6. Sanitize/validate user input to prevent injection attacks, including prompt injection in LLM inputs
  7. Rotate a leaked API key and confirm the old one is fully revoked

Needs first: Deploy an AI service to the cloud

Learn — free, link-checked

The few resources that matter

Read · beginner · 25 min · docs.aws.amazon.com

What is IAM?

Least-privilege IAM is the single most-tested security concept in Indian AI interviews; the canonical explanation of roles vs policies. — AWS
Read · intermediate · 25 min · docs.docker.com

Dockerfile best practices

Multi-stage builds, layer caching and running as non-root — the difference between a Dockerfile that works and one that's production- and security-ready. — Docker
Read · intermediate · 35 min · api-security.owasp.org

OWASP API Security Project

API-specific risks (broken object auth, excessive data exposure) that generic web security lists miss — directly relevant to LLM API wrappers. — OWASP
Read · intermediate · 40 min · owasp.org

OWASP Top 10

The industry-standard checklist of web app vulnerabilities (injection, broken auth, etc.) every AI backend must be reviewed against. — OWASP
Read · intermediate · 40 min · docs.aws.amazon.com

AWS Well-Architected — Security Pillar

A structured framework (identity, detection, data protection, incident response) for reasoning about security end to end, not just individual fixes. — AWS
Read · intermediate · 45 min · fastapi.tiangolo.com

FastAPI — Security (OAuth2, JWT)

Shows how to add real OAuth2/JWT auth to an API — the exact gap between a toy endpoint and one that's safe to ship. — FastAPI (tiangolo)
Tools for practice

Choose a tool for the job

Start with one tool for each part of your project. You don’t need to learn them all.

Go to the practice brief

3 tools to explore

Presidio

Data · Test

Detect and anonymise sensitive entities in sample text before it enters a model workflow.

Visit toolGetting started

Practices & references

Selected for practice by RoleGPS. No paid placements or affiliate links.
Access can change; check the details before starting.

Think your tool is a good fit? Let us know

Practice

Tenant isolation and secret-hygiene pass on the ticket API

Harden your FastAPI ticket service for multiple tenants. Add JWT auth with a tenant claim, filter every data query by the tenant in the token, and seed two tenants' worth of rows so isolation is testable rather than assumed. Move every secret to environment-injected config and prove none ever reached git history with a secret scanner. Add structured audit logging for auth failures and data access, carrying timestamp, tenant and outcome but no secrets or PII.

Start from

Your FastAPI ticket API from build-apis, seeded with two tenants' worth of rows you generate yourself

Milestones
  1. Add JWT auth and put a tenant claim in the token · ~1.5h
  2. Filter every data query by the token's tenant and seed two tenants to test against · ~1.5h
  3. Write the crafted cross-tenant request test and make it fail loudly · ~1.5h
  4. Move secrets to env config, add audit logging, and run a secret scanner over full history · ~1.5h
Done when
  • Every data-access endpoint requires a valid JWT and filters results by the token's tenant ID
  • A test explicitly proves cross-tenant access is blocked (Tenant A's token can't read Tenant B's rows)
  • No secrets appear in the git history — verified with a secret-scanning tool run over the repo
  • Audit log records auth failures and data-access events with timestamp, tenant, and outcome, excluding secrets/PII
Prove it

Evidence a recruiter can check

  • The cross-tenant test: Tenant A's token requesting a row id belonging to Tenant B, asserted to be refused rather than leaked
  • A gitleaks or trufflehog run over the full commit history with zero findings, output pasted in the README
  • Redacted audit-log lines for one auth failure and one successful read, showing timestamp, tenant and outcome and no PII
  • The one query you found that was not tenant-filtered, and the commit that closed it
Signal it

Hardened a multi-tenant FastAPI service with JWT tenant scoping, env-injected secrets and PII-free audit logging — with a regression test proving one tenant cannot read another tenant's data.

Interview

Questions you'll get asked

  1. How would you design tenant isolation so Customer A's data can never leak to Customer B?
  2. Where do you store a third-party API key, and what's wrong with putting it in a .env committed to git?
  3. How do you set up least-privilege IAM for a service that only reads from one S3 bucket?
  4. What's prompt injection, and how would you defend an LLM-backed app against it?
  5. How would you rotate a leaked API key in production with zero downtime?
  6. What would you log for a security audit without accidentally logging PII or secrets?
  7. Walk me through validating a JWT on an incoming request — what can go wrong if you skip a step?
See where you stand for AI Security Engineer