DEV Community: Munagala Karthik

Why LLM Engineering Is a Cloud Security Problem Nobody Is Talking About

Munagala Karthik — Sat, 16 May 2026 03:05:14 +0000

Everyone wants to be an LLM engineer right now.

And I get it. The space is moving fast and the opportunities are real.

But here is what most people getting into it are skipping.

LLMs are powerful. They are also unpredictable; expensive to run and surprisingly easy to break if your infrastructure is not solid underneath them.

Prompt injection is real. If your application takes user input and passes it directly to a model without sanitization; you have already built a vulnerability. Not a bug. A vulnerability.

Your API keys are sitting in environment variables. Your model endpoints have no rate limiting. Your logs are capturing sensitive user inputs. Your cost per token is scaling faster than your revenue.

These are not AI problems. These are cloud security and engineering problems that happen to live inside an AI product.

The best LLM engineers I have seen are not just good at prompting. They understand IAM; secrets management; rate limiting; observability and cost controls. They treat the model like any other production service.

Because it is.

If you are building with LLMs and not thinking about security; you are not building a product. You are building a liability.

Secure the infrastructure first. Then ship the intelligence.

Zero Trust Is Not a Product — It Is a Discipline You Build

Munagala Karthik — Mon, 11 May 2026 08:41:00 +0000

Zero Trust is the most talked about security model in 2026.
It is also the most misunderstood.
Most teams think Zero Trust means adding MFA and calling it a day. It is not. MFA is one layer. Zero Trust is an entire mindset.
Never trust. Always verify. Every single time.
It means every user; every service; every machine; every API call is treated as a potential threat until proven otherwise. No free passes. No assumed trust based on network location or past logins.
Here is what actual Zero Trust looks like in practice.
Your developers cannot access production just because they are on the company network. Access is granted per request; per task; time limited and automatically revoked.
Your service accounts have exactly the permissions they need for one job. Nothing more. The moment that job is done; access is gone.
Your CI/CD pipeline is not trusted by default. Every deployment is verified; scanned and validated before it touches production.
This is not paranoia. This is engineering.
Most breaches in 2026 are not happening because attackers are breaking through walls. They are walking through doors that were left open by assumed trust.
Stop assuming. Start verifying.
Zero Trust is not a product you buy. It is a discipline you build.

OCI Wouldn't Let Me Delete My KMS Keys — So I Stopped Trying to Delete Them

Munagala Karthik — Thu, 07 May 2026 04:30:00 +0000

The obvious solution is not always the right one.
When we hit a problem in OCI where KMS keys were refusing to delete; the obvious move was to force delete them. Try harder. Debug the script. Fix the error.
We tried that. It kept failing.
So we stopped and asked a different question.
What if we stop trying to delete them where they are; and move them somewhere else first?
We wrote a script that moves the keys to a separate isolated compartment. No active resources. No dependencies. Clean environment. Then we delete them there.
It worked immediately.
Same problem. Different angle. Completely different result.
This is something I keep learning over and over in cloud engineering. When something is not working; the answer is rarely to push harder in the same direction. Sometimes you need to zoom out; question your assumptions and ask what else is possible.
The cloud does not always behave the way you expect. Neither do real problems.
The engineers who solve hard problems fastest are not the ones who know the most commands. They are the ones who think differently when the obvious path is blocked.
When the door is locked; look for the window.

Attackers Are Not Breaking In Anymore — They Are Logging In as Your Machines

Munagala Karthik — Mon, 04 May 2026 08:40:31 +0000

We spend so much time securing human identities in the cloud.
MFA. Strong passwords. Role based access. All important.
But here is what most teams are missing completely.
Machine identities now outnumber human identities by 82 to 1.
Every service account. Every AI agent. Every API. Every Lambda function calling another service. Every container pulling from a registry. Every automated pipeline running in your CI/CD.
All of them have credentials. All of them have permissions. Most of them are never audited.
And attackers know this.
A compromised service account with standing admin privileges is a dream entry point. No MFA to bypass. No human to notice the login alert. Just silent; persistent access.
I started treating every machine identity in our environment the same way I treat human identities.
Least privilege. Regular audits. Automatic rotation of credentials. Immediate revocation when no longer needed.
It sounds obvious. But most teams are not doing it.
The identity perimeter is not just your employees anymore. It is everything in your environment that has a credential.
Secure the machines. Not just the people.

Two clouds. Two KMS services. Same goal; very different experience.

Munagala Karthik — Thu, 30 Apr 2026 04:43:03 +0000

Two clouds. Two KMS services. Same goal; very different experience.
I work across AWS and OCI daily so I get to compare these things firsthand.
AWS KMS feels mature. You create a key, attach a policy, integrate with S3, Lambda, EBS in minutes. IAM controls everything. It just works.
OCI Vault is powerful but the setup feels heavier. Key management, secret management and vaults are separate concepts you need to understand before you start. It takes more planning upfront.
A few real differences I noticed;
AWS KMS integrates natively with almost every AWS service out of the box. OCI Vault requires more manual wiring to connect with other OCI services.
AWS gives you automatic key rotation with one toggle. OCI supports rotation but the process needs more configuration.
AWS KMS pricing is per API call. OCI Vault pricing is per key version stored; different mental model for cost planning.
Neither is better. They just think differently.
AWS optimizes for speed and simplicity. OCI optimizes for control and structure.
Know which one you are working with before you start designing your encryption strategy.

OCI Service Limits, What You Need to Know Before You Start Building

Munagala Karthik — Sun, 26 Apr 2026 16:25:55 +0000

Have you ever been surprised by cloud limits in the middle of a deployment?
One thing I didn't expect when working on OCI was how limit-aware you need to be.
Coming from AWS where most things just work within generous defaults, OCI taught me to plan differently.
Need more than 2 identity domains? You'll need to upgrade your account and submit a request. Need more VM capacity? Same process; submit and wait for approval.
It's not a bad thing honestly. It just means you need to think ahead.
In AWS I never thought about limits until I hit them. In OCI I learned to check limits before I even start building.
Every resource has a ceiling. And raising that ceiling requires a conversation with Oracle first.
Once I changed my mindset from "just deploy and figure it out" to "plan your limits before you start", working in OCI became much smoother.
OCI is powerful. But it rewards engineers who plan ahead, not those who move fast and fix later.
Know your limits before your deployment does.

Why Your AI Prompts Are Getting Generic Answers (And How to Fix It)

Munagala Karthik — Thu, 23 Apr 2026 13:23:19 +0000

Most engineers treat AI like a search engine.
Type a question; hope for a good answer; get frustrated when it's generic.
That's not how it works.
AI responds to context. The more specific you are, the better the output. Think of it like briefing a new team member who knows everything, but has no idea about your environment.
Here is what changed my results completely.
Give it a role; "You are a cloud security engineer working on AWS" instantly shifts the tone and depth of the response.
Give it context; mention the service, the environment, the constraint. "Write an IAM policy for a Lambda function that only reads from one S3 bucket" beats "write an IAM policy" every single time.
Give it a format; tell it exactly what you want back, a policy document, a checklist, a Terraform block. Be specific.
Tell it what to avoid; "no broad permissions, no wildcards, follow least privilege" saves you from cleaning up a messy output.
I now use this for IAM policies, security checklists, Terraform reviews, incident response drafts and boto3 scripts.
Same AI, better prompts, completely different results.
Prompt engineering is not a skill for AI people. It is a skill for anyone who wants to stop wasting time.

I Gave a Service Account Full Admin Access, Here's What Happened Next

Munagala Karthik — Sun, 19 Apr 2026 15:54:53 +0000

I gave a service account full admin access once.
Just to get things working quickly. I told myself I'd restrict it later.
Later never came.
Three months passed. That service account was still sitting there with more permissions than it needed. Quietly. Invisibly. A ticking time box nobody was watching.
This is how most cloud environments get messy. Not from big mistakes. From small shortcuts that never get cleaned up.
The "I'll fix it later" culture in cloud security is more dangerous than any misconfiguration.
Because later feels responsible in the moment. You acknowledged the problem. You just didn't solve it.
What actually helped me was treating every temporary fix like a bug. Log it. Track it. Set a deadline.
If it doesn't have a deadline it doesn't exist.
Don't let your shortcuts outlive your memory of why you made them.

CloudTrail Is Not Just a Log, It's Your AWS Security Camera

Munagala Karthik — Wed, 15 Apr 2026 03:26:45 +0000

Nobody told me AWS CloudTrail was this important until something went wrong.
An unexpected API call showed up in our environment. No one on the team claimed it.
That one moment changed how I think about cloud monitoring forever.
Before that I treated CloudTrail like a checkbox. Enabled it because best practices said so. Never actually looked at the logs.
After that I started treating it like a security camera. Always on. Always watching. And you better know how to read what it's recording.
The fix wasn't complicated. Set up proper log filtering. Created alerts for suspicious API calls. Made it a habit to review weekly.
But the lesson hit hard.
Enabling a security tool is not the same as using it. Most breaches don't happen because the tool wasn't there. They happen because nobody was watching.
Turn it on. Then actually look at it.

Vibe Coders

Munagala Karthik — Sun, 12 Apr 2026 06:45:59 +0000

Vibe coding is fun until it isn't.
You're flying through features. AI is writing everything. It feels like a superpower.
Then you hit the context limit.
The model forgets what it built. Starts contradicting itself. Code breaks in ways that make no sense. And suddenly you're spending more time fixing AI mistakes than you would have spent just writing it yourself.
I've been there.
The problem isn't vibe coding itself. The problem is depending on it completely.
If you don't understand what the code is doing you can't fix it when the AI loses the plot. And it will lose the plot.
Use it as a tool. Not a replacement for thinking.
Let AI handle the boilerplate. You handle the logic. You review every line. You stay in control.
The engineers who will win with AI are not the ones who prompt the best. They're the ones who know enough to catch when the AI is wrong.
Don't outsource your understanding. That's the one thing AI can't give back to you.

DevOps #CloudSecurity

Things kept breaking in my OCI lab… until I fixed IAM

Munagala Karthik — Wed, 08 Apr 2026 12:35:03 +0000

Things kept breaking, and it wasn’t because I wrote bad code.

It was IAM.
I was setting up a cloud lab in OCI and everything looked fine on the surface, instances, networking, policies.
But every time I tried to launch or manage resources, something failed.

Not loudly. Just enough to slow everything down.
At first, I assumed it was a config issue.

So I kept switching between tasks, checking networking, then compute, then scripts.

That made it worse.
I wasn’t losing time… I was losing context.

What finally worked was slowing down and tracing the failure properly.
I started reading the exact error messages and mapping them back to IAM policies.
That’s when I finally saw it.

A small missing permission:
Allow group to read instance-images in tenancy
Once I added it, everything started working instantly.
No changes to code. No changes to architecture.
Just IAM.
Nothing else changed.

The biggest lesson?
Most cloud failures aren’t about what you built, they’re about what you forgot to allow.

If something feels randomly broken in the cloud, start with IAM first.