AI in Cloud Security A Talk
Date 16.05.2026
A real-world case study from the field

AI in
Cloud Security.

Practical. Real-world. Secure the cloud with AI — told through one breach chain that actually happened.

Speaker · About

About me.

Lohith Gowda M
Staff Application Security Engineer ·

I lead application security programs — building the practice, the people, and the tooling around real engineering teams. My day-to-day spans AppSec, cloud, AI red teaming and MCP security. The rest of the time I'm chasing bugs in the wild.

★ Security researcher · Published CVEs · Featured in TechCrunch
01
Application Security
02
Cloud Security
03
AI Red Teaming & MCP
04
Mobile Security
05
Compliance & GRC
AgendaWhat we'll cover

A real, honest talk.

01
My story

How I got into cybersecurity — the honest path.

02
Beginner start

How to start today — practically, not theoretically.

03
Real case study

Why cloud security matters — a real breach chain.

04
The prevention

How to prevent it — practical guardrails with AI.

Section IThe honest path

My story.

How I got into cybersecurity. What worked. What didn't.

01
The Beginning
Started with a data entry job after college. Drawn to ethical hacking — did CEH for the resume.
02
CEH Reality Check
CEH gave me HR calls, not a security job. The first real role came through persistence + LinkedIn Premium outreach.
03
COVID Pivot
Lockdown gave me time. Learned from Rohit Gautam's content. Started bug bounty for the profile, not the money.
04
Building Credibility
VDP programs first → Hall of Fame credits → blog posts. Showing the work publicly is what built the profile.
05
The Breakthrough
One Flipkart blog reached the Airmeet CTO on LinkedIn → senior role offer. Consistency compounds.
Section IIPractical roadmap

How beginners can start today.

The order matters more than the inputs.

The Wrong Order
  • Certifications first
  • Theory dumps first
  • Waiting to feel "ready"
The Right Order
  • Pick one area, go deep
  • Learn practically
  • Show your work publicly
Section IIThe five steps

The roadmap.

  1. Pick one area first

    Web, Mobile, Cloud, API, or AI. Go deep before going wide. Specialists become generalists faster than generalists become specialists.

  2. Learn fundamentals practically

    Auth, sessions, APIs, real apps you use daily. Use LLMs to learn faster — but verify everything in a lab.

  3. Start with VDP programs

    Hall of Fame credits build credibility. Bounties come later. Disclosure discipline matters more than payouts.

  4. Show your work

    Blog after coordinated disclosure. Share on LinkedIn and Twitter. Consistently. The internet has a long memory.

  5. Choose product-based companies

    Touch AppSec, Cloud, Mobile, API, DevSecOps, Compliance, AI/LLM/MCP. That breadth is what global roles hire for.

Section IIIA real case study

Why cloud security matters.

One small application bug ended with full database access — every user record in the system. This is not a hypothetical. This happened. The chain is real.

App Bug → Leaked Credentials → Overpermissioned IAM → Secret Bucket → Full DB Access
TargetA startup platform in Bangalore
Exhibit AThe chain, step by step

The chain — step by step.

Step01

The upload API leaked S3 credentials

A profile upload endpoint was returning the working AccessKeyId and SecretAccessKey in its JSON response body — visible to any authenticated user from the browser's network tab.

Step02

The keys had wildcard permissions

Those credentials weren't scoped to the upload bucket. The IAM policy allowed listing every bucket in the account — the entire S3 surface laid bare from a single leaked key.

Step03

A secret-keys bucket appeared in the list

Inside secret-keys-staging sat a plain secrets.json — Postgres credentials, a SendGrid API key, and a few other tokens. No KMS. No vault. Just a file.

Step04

RDS was publicly reachable — psql connected

The RDS instance was set to Publicly Accessible. With the credentials from secrets.json, psql connected on the first try and SELECT * FROM user_user returned every user record. Without the public RDS, even leaked credentials wouldn't have reached the database.

Resolution
Reported to CTO → fix shipped → read the full blog ↗
$250
Exhibit BThe proof · 1 of 3

Step 01 & 02 — credentials leaked, IAM wide open.

Step 01

The upload API response contained working AccessKeyId and SecretAccessKey in the JSON body — visible to any authenticated user from the browser's network tab.

Burp Suite showing AWS credentials leaked in JSON response
Step 02

aws s3 ls --profile with the leaked key listed every bucket in the account — wildcard IAM. The secret-keys-staging bucket appears in the list.

aws s3 ls listing every bucket in the AWS account
Exhibit BThe proof · 2 of 3

Step 03 & 04 — secrets bucket, then psql in.

Step 03

Inside secret-keys-staging sat secrets.json — Postgres credentials, RDS host, and a SendGrid API key in plaintext. No KMS, no vault.

secrets.json contents - Postgres credentials and SendGrid API key
Step 04 · A

RDS was set to Publicly Accessible. psql connected over TLS on the first try and listed databases and roles.

psql connection to RDS, list of databases and roles
Exhibit BThe proof · 3 of 3

Step 04 continued — full database access.

Step 04 · B

Switched into the library database. 16 tables visible — Django auth, services, user_user, the full schema.

Connected to library database, listing all 16 tables
Step 04 · C

SELECT * FROM user_user returned every user record. Names, emails, password hashes, phone numbers. Game over.

SELECT * FROM user_user returning full user data
AnalysisTwo root causes

Two root causes — not one.

The app bug leaked the key. The cloud misconfiguration made the key dangerous. Both layers have to be fixed — fixing one without the other just buys you time.

Application Layer
Credentials in the response body.
Working AWS keys were serialized straight into a JSON API response — a developer convenience that became a production-grade key leak.
The Fix

Code review with secrets-in-response checks. SAST and response scanning in CI. Move all credentials out of application code and responses, into a real secrets manager.

Cloud Layer
Wildcard everything — no scoping.
The IAM policy used wildcard actions and wildcard resources. One leaked key opened every bucket in the account, including the one with the database credentials.
The Fix

Least-privilege IAM scoped per role and per resource. Permission boundaries. Real-time monitoring for risky policy changes — before the credentials are ever used.

Application security and cloud security are not the same team's problem, but they are the same attacker's playground.

Section IVHow to prevent it

How to prevent it.

The obvious fix

App-layer fixes are clear — get secrets out of responses, into a secrets manager. SAST catches this in CI/CD.

The harder question

How do you catch the cloud-layer mistakes — the overpermissioned IAM policies — before they become dangerous?

Era One — Before Agentic AI
Custom Lambda was the brain.
2023
01
CloudTrail event
02
EventBridge filter
03
Custom Lambda
04
Claude API (prompt)
05
Slack & Jira
How it worked
  1. CloudTrail emitted events — PutRolePolicy, S3 PutBucketPolicy, RDS ModifyDBInstance, and similar.
  2. EventBridge filtered the firehose down to a static list of risky API calls.
  3. A custom Lambda parsed the event, looked up severity from hand-built mappings, and built a handcrafted prompt.
  4. Claude formatted the Jira ticket and Slack alert from that prompt.
  5. The ticket landed on the developer who made the change.
The role of AI
  • The AI was the formatter, not the reasoner.
  • The Lambda and prompt did the thinking. AI made it readable.
  • Event lists, severity mappings, and template rules all had to be hand-maintained.
Outcome

SRE team out of routine triage. Clean tickets with who, what, where, when. Compliance trail built in.

Era OneInside the Lambda

The filter, the prompt, the alert.

EventBridge filter

A static list of risky CloudTrail API calls. Anything matching this pattern is forwarded to the Lambda.

{
  "source": ["aws.s3", "aws.iam", "aws.rds",
             "aws.cloudtrail", "aws.guardduty",
             "aws.kms", "aws.secretsmanager", ...],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "DeleteBucket", "PutBucketAcl",
      "DeleteBucketPolicy",
      "PutBucketPublicAccessBlock",
      "CreateUser", "CreateAccessKey",
      "AuthorizeSecurityGroupIngress",
      "ModifyDBInstance",
      "StopLogging", "DeleteTrail",
      "DisableKey", "ConsoleLogin", ...
    ]
  }
}
The handcrafted prompt

Excerpt from the Lambda. Roughly 80 lines of persona, structure, formatting rules and examples — handwritten and tuned by trial and error.

prompt = f"""
You are a highly skilled security analyst with
over 15 years of experience in cloud security,
specializing in AWS environments...

Title: Create a descriptive title that clearly
identifies the type of event. Always include
the account name. DO NOT include resource
names, role names, or bucket names...

Summary: Provide a clear description of:
- What was modified or added
- Who made the change (format sensitive values
  in code blocks using backticks):
    - Security Group IDs as `sg-xxxxx`
    - Port numbers as `port XX`
    - IP/IPv6 addresses as `X.X.X.X` or `::/0`
    - Email addresses as `{user_email}`
    - SSO roles as `{role}`

Details (in code block format):
  Event Type, Account ID, Account Name,
  Region, Source IP, Timestamp (convert to IST)

Here is the CloudTrail event to analyze:
{json.dumps(event_data, indent=2)}
"""
And around it 3,000+ lines of Lambda — alert routing, severity mapping, Slack block-kit formatting, JIRA ticket creation, DynamoDB de-dup, failed-login attempt tracking. Every new event type needed a new template.
Era Two — The Agentic Era
The agent is the brain.
2026
01
CloudTrail event
02
EventBridge filter
03
Lambda
04
AI agent
05
Slack & Jira
What's inside the Lambda
  • The Claude Agent SDK runs the agent loop in-process.
  • A short markdown brief (~30 lines) defines the agent's role, severity guide and decision rules.
  • Two tools wired as Python functions: post_slack and create_jira.
  • The agent reads the raw CloudTrail event — no field-by-field parsing in Python.
  • It decides severity, owner, and message — then calls the tools.
  • DynamoDB ledger and the weekly digest Lambda stay unchanged.
What's gone
The Brain Moved

The 80-line prompt and 3,000-line Lambda became a 30-line markdown brief and two small tool functions. The Lambda told you what happened. The agent decides whether it matters.

For our case study Risky IAM changes like PutRolePolicy with s3:* on Resource: *, an S3 PutBucketPolicy opening a bucket to the public, or an RDS ModifyDBInstance flipping PubliclyAccessible to true — all caught in seconds, before they ever become a chain.

That's how I got in.

Cloud, AI, MCP — the surfaces change. The fundamentals don't.

Questions?
Stay in touch
01 / 17