DEV Community: P VIKRAM KISHORE

Building a Cloud Security Home Lab: Learning AWS Security Through Attack, Detection, and Remediation

P VIKRAM KISHORE — Wed, 01 Jul 2026 15:18:23 +0000

Cloud security isn't something you truly learn by reading documentation.

You learn it by building infrastructure, attacking it, detecting the attack, and then fixing what made the attack possible.

That idea became the foundation of my Cloud Security Home Lab.

Why I Built It

Most cloud labs focus on deploying resources.

I wanted something different.

I wanted a lab that helped me answer questions like:

How do attackers exploit AWS misconfigurations?
What logs are generated during an attack?
How would a SOC analyst detect this activity?
How can Terraform be used to prevent it from happening again?

Rather than treating offensive and defensive security separately, I wanted to connect them into a single workflow.

The Workflow

Every exercise follows the same cycle:

Terraform Infrastructure
        │
        ▼
CloudGoat Attack Scenario
        │
        ▼
CloudTrail / CloudWatch Telemetry
        │
        ▼
Detection Rules
        │
        ▼
Investigation
        │
        ▼
Terraform Remediation
        │
        ▼
Validation

The goal isn't simply to exploit a vulnerable configuration.

The goal is to understand the complete security lifecycle.

What the Lab Contains

The project currently includes:

AWS infrastructure managed with Terraform
CloudGoat attack scenarios
Attack runbooks documenting each exercise
Detection rules using Sigma, Athena, and CloudWatch
Terraform-based remediations
AI-assisted log analysis
Daily engineering notes documenting each lesson

What CloudGoat Taught Me

One of the biggest lessons from CloudGoat is that many cloud attacks don't involve traditional software vulnerabilities.

Instead, they rely on:

Overly permissive IAM policies
Insecure trust relationships
Publicly exposed cloud resources
Weak identity configurations
Privilege escalation through misconfigured permissions

Understanding these attack paths helped me appreciate why IAM is often considered the most critical security boundary in AWS.

Challenges I Faced

The biggest challenge wasn't launching attacks.

It was validating that every attack produced useful telemetry.

I wanted to answer questions like:

Did CloudTrail capture the event?
Would CloudWatch generate an alert?
Could a Sigma rule detect it?
Would Athena queries surface the activity?
Would the Terraform remediation actually prevent the same attack?

Another challenge was balancing realism with cost.

I wanted the lab to resemble production environments while still staying within the AWS Free Tier. That meant carefully designing the infrastructure, destroying resources when they were no longer needed, and documenting everything so scenarios could be recreated later.

Finally, I realized that cloud security isn't just about exploiting misconfigurations—it's about understanding the entire lifecycle from infrastructure to detection and finally remediation.

Why AI Is Included

The lab also includes AI-assisted tooling.

However, I intentionally limited its responsibilities.

The AI can:

Explain security findings
Summarize cloud logs
Suggest detection rules
Assist with log triage

It cannot:

Modify infrastructure
Apply Terraform
Execute attacks
Make security decisions automatically

Every operational change requires human approval.

I wanted AI to function as a security assistant rather than an autonomous operator.

What I Learned

This project helped me connect several disciplines that are often learned independently:

Infrastructure as Code
AWS Security
IAM
Cloud Detection Engineering
Purple Teaming
Threat Detection
Defensive Security
AI-assisted Security Analysis

Instead of seeing attacks and defenses as separate topics, I now think of them as different stages of the same security workflow.

One of the biggest takeaways was that deploying infrastructure is only the beginning.

The real learning starts when you understand how attackers abuse cloud services, how defenders detect those actions, and how to prevent them from happening again.

What's Next?

As I continue expanding the lab, I plan to add:

More CloudGoat attack scenarios
Additional AWS services
Stronger detection engineering content
More Terraform guardrails
Automated validation of detections
More AI-assisted workflows while keeping humans in control of every security decision

The goal isn't just to build another AWS lab.

It's to build a repeatable cloud security learning environment that covers the entire attack and defense lifecycle.

If you're learning cloud security, I highly recommend building a home lab that lets you deploy, attack, detect, investigate, and remediate. Seeing the full lifecycle has been one of the most valuable learning experiences of my vacation.

Building an Agentic AI Customer Support Platform with LangGraph, RAG, and Gemini

P VIKRAM KISHORE — Tue, 30 Jun 2026 16:21:17 +0000

When most people think about AI applications, they imagine a simple workflow:

User
   ↓
LLM
   ↓
Answer

That works well for demonstrations.

It doesn't work well for production systems.

Real AI applications need memory, retrieval, guardrails, tool calling, validation, observability, and graceful failure handling.

I wanted to understand how those pieces fit together.

So I built Cloudob Security, an end-to-end agentic AI customer support platform designed to resemble a production enterprise system rather than a chatbot demo.

The Goal

The objective wasn't simply to answer customer questions.

The objective was to design an AI system capable of:

Understanding user intent
Retrieving relevant documentation
Calling external business tools
Validating responses
Detecting unsafe inputs
Escalating conversations when appropriate
Maintaining conversation state

The Architecture

The application consists of several layers.

User
    │
    ▼
Next.js Enterprise Console
    │
    ▼
FastAPI Backend
    │
    ▼
LangGraph Workflow
    │
    ├── Input Validation
    ├── Guardrails
    ├── Intent Classification
    ├── Hybrid RAG Retrieval
    ├── Tool Calling
    ├── Response Validation
    └── Human Escalation

Each node has a specific responsibility, making the workflow deterministic, observable, and easier to maintain.

Why LangGraph?

Traditional prompt chains are linear.

Customer support rarely is.

A conversation may require:

Multiple retrieval steps
External tool calls
Retry logic
Conditional routing
Human escalation

LangGraph provided a natural way to model these workflows as a stateful graph instead of a sequence of prompts.

Building Reliable RAG

One thing I learned quickly is that retrieval quality matters as much as model quality.

Instead of simple semantic search, the project implements:

Hybrid search
Parent-child chunking
Contextual compression
Metadata filtering
Configurable vector stores

This significantly improves the relevance of retrieved information before generation begins.

Guardrails

A production AI system must defend itself.

The platform includes deterministic checks for:

Prompt injection
Jailbreak attempts
SQL injection patterns
Sensitive requests
Personally identifiable information
Toxicity
Groundedness

If the system determines that a response isn't sufficiently grounded in retrieved documents, it retries or escalates instead of generating potentially misleading information.

Building Beyond the Model

Another design goal was provider independence.

Models, embeddings, and vector databases are abstracted behind factories.

Changing providers becomes a configuration change rather than a rewrite.

The same principle applies to business tools, making them straightforward to expose through MCP or similar protocols later.

What I Learned

This project changed how I think about AI engineering.

The LLM isn't the application.

It's one component within a much larger system.

The engineering around the model determines whether an AI application is reliable enough for production.

That includes:

Retrieval
Guardrails
Validation
Tool orchestration
Observability
Evaluation
Error handling
User experience

Building Cloudob Security gave me practical experience designing stateful AI systems rather than simple chatbot interfaces.

What's Next?

There are still several improvements I'd like to make, including:

Live telemetry dashboards
Full MCP server integration
Additional enterprise tools
Expanded evaluation pipelines
Production deployment with Pinecone and LangSmith

The project reinforced an idea that has shaped many of my recent projects:

The future of AI engineering isn't about writing better prompts.

It's about building better systems around language models.

Building an Agentic SOC Analyst with Microsoft Sentinel, Azure Log Analytics, and Gemini

P VIKRAM KISHORE — Mon, 29 Jun 2026 16:10:50 +0000

Security Operations Centers generate an enormous amount of telemetry every day.

Finding meaningful threats isn't usually limited by data.

It's limited by how quickly an analyst can ask the right questions.

That observation led me to build an Agentic SOC Analyst.

The goal wasn't to replace analysts.

The goal was to reduce the time between an investigation idea and actionable findings.

The Problem

A threat hunter often starts with a vague hypothesis.

For example:

"Something unusual happened with this user during the past two weeks."

Turning that into an investigation usually requires:

Choosing the correct log source
Understanding the schema
Writing Kusto Query Language (KQL)
Running the query
Reviewing hundreds or thousands of events
Mapping activity to known attack techniques

I wanted to automate as much of that workflow as possible while keeping humans in control.

The Architecture

The pipeline looks like this:

Natural Language Request
            │
            ▼
Gemini selects table, fields and filters
            │
            ▼
Guardrails validate every selection
            │
            ▼
Generate scoped KQL
            │
            ▼
Query Azure Log Analytics
            │
            ▼
Gemini analyzes results
            │
            ▼
Structured Findings + MITRE ATT&CK Mapping

Every table and field selected by the model is validated against an allow-list before any query is executed.

This prevents hallucinated tables or unsupported fields from reaching Azure.

Features

The current implementation includes:

Natural-language threat hunting
Dynamic KQL generation
Azure Log Analytics integration
Microsoft Sentinel compatibility
Table and field allow-list validation
Structured threat findings
MITRE ATT&CK mapping
IOC extraction
Confidence scoring
Token usage and cost estimation
Synthetic dataset generation
Automated log ingestion into test workspaces

Why Guardrails Matter

One lesson I learned while building AI agents is that models shouldn't have unrestricted access to external systems.

Before any KQL query is executed, the agent validates:

Requested tables
Available fields
Entity filters
Query scope

Anything outside the approved allow-list is discarded.

The model assists with decision-making, but deterministic code enforces safety.

Building a Test Environment

Testing SOC tooling against production logs isn't practical.

To solve this, I built utilities that generate synthetic Azure Activity, Entra ID sign-in, network, and device log datasets.

These datasets can be ingested into Azure Log Analytics, allowing the entire threat-hunting workflow to be tested safely without exposing sensitive information.

What I Learned

This project taught me that effective AI agents are more than prompt engineering.

They require:

Clear system design
Strong guardrails
Deterministic validation
Safe tool execution
Transparent outputs

It also gave me hands-on experience with Microsoft Sentinel, Azure Log Analytics, Kusto Query Language, and designing LLM-powered workflows for cybersecurity.

What's Next?

I'm continuing to improve the agent by exploring:

Multi-step investigation planning
Additional Sentinel tables
Better evidence correlation
Memory across investigations
Support for additional SIEM platforms

Building this project reinforced something I've come to believe about AI engineering.

The most valuable AI systems don't replace experts.

They help experts investigate faster while remaining transparent, predictable, and safe.

Building docapi: A Reliable Document Extraction Platform for AI Agents

P VIKRAM KISHORE — Sun, 28 Jun 2026 17:27:47 +0000

GITHUB : https://github.com/Waterbottles792/docapi

Large Language Models have made document understanding incredibly accessible.

Give an LLM an invoice, receipt, résumé, or contract, and it can usually tell you what's inside.

The problem begins when you need reliability.

Production systems don't need "usually."

They need predictable outputs, validation, and error handling.

That observation led me to build docapi.

The Problem

Most document extraction pipelines follow a simple pattern:

Document
    ↓
LLM
    ↓
JSON

This works well until the model:

Returns invalid JSON
Hallucinates values
Misinterprets dates
Omits required fields
Produces inconsistent output formats

For AI agents, those failures become difficult to recover from.

I wanted to build something that treated reliability as the primary goal.

The Idea

Instead of prompting an LLM and hoping for the best, docapi works like this:

Document
      │
      ▼
Text Extraction
      │
      ▼
LLM Understanding
      │
      ▼
Schema Validation
      │
      ▼
Grounding Verification
      │
      ▼
Deterministic Normalization
      │
      ▼
Confidence Scoring
      │
      ▼
Schema-Validated JSON

If the system cannot confidently produce valid output, it returns a structured error instead of silently returning incorrect data.

Features

The current version includes:

REST API
MCP server for AI agents
Local inference with Ollama
Cloud inference with Claude
Schema validation
Grounding checks to reduce hallucinations
Deterministic date normalization
Long-document chunking
Confidence scoring
Automated evaluation harness
More than 80 automated tests

Why Deterministic Code Matters

One example I encountered was date parsing.

A language model occasionally interpreted:

26-05-2025

as the year 2605.

That's not an AI problem.

It's a software engineering problem.

Instead of trying to improve the prompt, docapi normalizes dates deterministically after extraction.

The same philosophy applies throughout the project.

Whenever a problem can be solved reliably with code, it shouldn't be delegated to the model.

Building for AI Agents

Another goal was making the system easy for agents to use.

Besides a REST API, docapi also exposes an MCP server, allowing AI assistants to call document extraction as a tool without additional integration code.

The extraction pipeline remains identical regardless of whether the caller is a Python application, an HTTP client, or an AI agent.

What I Learned

Building this project changed the way I think about AI engineering.

The model is only one part of the system.

The surrounding engineering matters just as much:

Validation
Error handling
Evaluation
Grounding
Deterministic processing
Observability
Testing

Those pieces are what make AI systems reliable enough for production.

What's Next?

I'm continuing to expand docapi with:

OCR support for scanned documents
Additional model providers
Larger evaluation datasets
A managed hosted version

The goal remains the same:

Build AI systems that are not only intelligent, but predictable, measurable, and reliable.

If you've built similar AI infrastructure or have ideas for improving document extraction reliability, I'd be interested to hear your thoughts.

Building a Production-Grade OAuth 2.1 + OpenID Connect Authorization Server from Scratch

P VIKRAM KISHORE — Sat, 27 Jun 2026 15:32:18 +0000

One of the biggest projects I worked on during my vacation wasn't a bug bounty report or a cloud project.

It was building my own OAuth 2.1 + OpenID Connect Authorization Server.

GITHUB : https://github.com/Waterbottles792/OAuth-App

Like many developers, I'd integrated "Login with Google" or worked with JWTs before, but I realized I never truly understood what happened behind the scenes.

Questions like these kept coming up:

How does an authorization code become an access token?
Why is PKCE mandatory?
Why are refresh tokens rotated?
Why do identity providers expose a JWKS endpoint?
How are ID tokens different from access tokens?
Why are some authentication systems much more secure than others?

Instead of reading another article, I decided to build the entire system myself.

The Goal

Rather than creating a simple authentication service, I wanted to implement something that closely follows the OAuth 2.1 and OpenID Connect specifications while making security the primary design goal.

Every feature was built only after understanding the threat it was designed to prevent.

What I Built

The project includes:

OAuth 2.1 Authorization Server
OpenID Connect Identity Provider
Authorization Code Flow with mandatory PKCE (S256)
JWT Access Tokens and ID Tokens
UserInfo Endpoint
JWKS Endpoint
OpenID Discovery (/.well-known/openid-configuration)
Client Registry
User Consent Management
Token Introspection
Token Revocation
MFA Support
Redis-backed Server Sessions
Audit Logging
Security Alerting
Zero-downtime Signing Key Rotation

The backend is built with Node.js, Express, and TypeScript, while the frontend uses Next.js. PostgreSQL stores persistent data, and Redis handles sessions and caching.

Security Decisions

The most valuable part of the project wasn't adding features—it was understanding why modern identity systems make certain security decisions.

Some examples include:

Passwords and client secrets are hashed using Argon2id rather than weaker hashing algorithms.
JWTs are signed using RS256 with asymmetric keys, eliminating algorithm confusion issues associated with insecure configurations.
Authorization Code Flow is the only supported grant type, with PKCE (S256) required for every authorization request.
Refresh tokens are single-use and automatically rotated. Any attempt to reuse an old refresh token revokes the entire token family.
Redirect URIs require an exact match, preventing wildcard-based attacks.
Sessions are stored server-side using Redis with secure, HttpOnly cookies.
Authorization codes and refresh tokens are never stored in plaintext—they're stored as SHA-256 hashes.

Implementing these decisions forced me to understand the attacks they are designed to prevent, rather than simply copying configurations from tutorials.

What I Learned

Before this project, authentication felt like a collection of APIs and libraries.

Now I understand it as a sequence of carefully designed security protocols.

I learned how:

Identity and authorization are separate concerns.
PKCE protects public clients from authorization code interception.
JWT signing and key rotation work in production.
Refresh token rotation limits the impact of token theft.
OpenID Connect builds an identity layer on top of OAuth.
Proper session management is just as important as token security.

Most importantly, I learned that building secure authentication is about understanding standards—not inventing your own.

Looking Ahead

This project was one of the most challenging things I built during my vacation, but it completely changed the way I think about authentication and identity.

There are still many areas I want to explore, including federation, SAML, passkeys (WebAuthn), and advanced identity architectures.

For now, I'm happy to have built a strong foundation by implementing OAuth 2.1 and OpenID Connect from the ground up.

If you're learning application security or backend development, I highly recommend building an authentication system yourself. You'll gain a much deeper appreciation for the standards and the security decisions behind them than you ever will by simply consuming an authentication library.

Thanks for reading.

Building My First Web Server with Terraform: Learning Infrastructure as Code on AWS

P VIKRAM KISHORE — Fri, 26 Jun 2026 15:04:31 +0000

During my vacation, one of my goals was to move beyond application security and start understanding the infrastructure that modern applications run on.

As someone interested in cybersecurity, I realized that understanding cloud infrastructure is just as important as understanding how to find vulnerabilities. Before you can secure infrastructure, you need to know how it's built.

That's when I decided to learn Terraform.

Why Terraform?

I could have created resources manually through the AWS Console.

But that's not how production environments work.

Infrastructure as Code (IaC) allows you to define your entire infrastructure in code, making deployments repeatable, version-controlled, and easier to maintain.

Terraform seemed like the perfect place to start.

My First Project

For my first Terraform project, I built a complete web server from scratch on AWS.

The infrastructure included:

AWS VPC with IPv4 and IPv6 support
Internet Gateway
Egress-Only Internet Gateway for IPv6
Custom Route Table
Public Subnet
Security Group allowing SSH, HTTP, and HTTPS
Elastic Network Interface with a static private IP
Elastic IP
EC2 Instance
Automatic Apache2 installation using user_data

Everything was provisioned with a simple:

terraform init
terraform plan
terraform apply

What I Learned

At first, Terraform felt like just another configuration language.

After building this project, I realized it's much more than that.

I finally understood how all the networking components connect together.

Before this project, terms like VPCs, subnets, route tables, internet gateways, and security groups felt like separate AWS services.

Now I understand how a request from the internet actually reaches a web server:

Internet → Internet Gateway → Route Table → Subnet → Security Group → Network Interface → EC2 Instance

That single flow made many AWS networking concepts finally click.

More Than Just Writing Code

This project also changed the way I think about infrastructure.

Instead of manually creating resources, everything becomes reproducible.

Need another environment?

Run Terraform.

Need to recreate the infrastructure?

Run Terraform.

Need to review infrastructure changes before deploying?

Use terraform plan.

Infrastructure becomes something you can review, version, and collaborate on—just like application code.

What's Next?

This is only the beginning of my Infrastructure as Code journey.

Over the next few weeks, I plan to explore:

Multiple AWS services
Terraform modules
Remote state management
IAM and security best practices
Kubernetes
Docker integration
CI/CD with Terraform

I'm documenting everything I build as I learn.

If you're also learning cloud infrastructure, I'd love to hear what projects helped you understand AWS and Terraform better.

Thanks for reading.

What I Did During My Summer Vacation: Day 1 - My First 10 Bug Bounty Reports

P VIKRAM KISHORE — Thu, 25 Jun 2026 15:49:14 +0000

Before college starts again, I wanted to document what I worked on during my vacation.

This is the first post in a series where I'll share everything I learned over the past few months—from bug bounty hunting to AI security, GenAI engineering, and the projects I built.

Getting Started

Until recently, most of my security experience came from CTFs and intentionally vulnerable labs.

While they taught me a lot about exploitation techniques, I wanted to understand how security works in real production applications.

So I decided to spend my vacation participating in private bug bounty programs.

The Results

By the end of my vacation, I had submitted 10 bug reports across multiple private programs.

The findings ranged from Low to High and Expert severity.

One of the most impactful reports involved an unauthenticated API exposure that, if abused, could have exposed information related to approximately 39,070 investors and employees.

Some of the vulnerability classes I encountered included:

CORS Misconfigurations
GraphQL User Enumeration
Subdomain Takeovers
GitHub Actions Supply Chain Risks
Excessive CI/CD Permissions
CSP Misconfigurations
OAuth & Authentication Issues
Information Disclosure

What Bug Bounty Actually Taught Me

Before starting, I thought bug bounty was mainly about finding vulnerabilities.

I quickly realized I was wrong.

Finding a bug is usually the final step.

Most of the work happens long before that.

I spent hours:

Reading thousands of lines of JavaScript
Tracing API requests
Mapping authentication flows
Understanding business logic
Following how different services communicate
Learning why applications were built the way they were

Some days I wouldn't find a single vulnerability.

Other days I'd spend hours chasing something that turned out to be intended behavior.

But every investigation improved the way I think about application security.

Rejections Are Part of the Process

One thing I learned early is that not every report will be accepted.

Not every report deserves a bounty.

Sometimes the issue is already known.
Sometimes it's out of scope.
Sometimes the impact isn't high enough.

That's part of bug bounty.

Every report—accepted or not—teaches you something new.

What's Next?

This vacation wasn't just about bug bounty.

I also spent time learning AI security, RAG systems, LLM evaluations, observability, and building GenAI projects.

Over the next few posts, I'll share those experiences as well.

If you're a student thinking about getting into bug bounty, my biggest advice is this:

Don't chase bounties. Chase understanding.

The vulnerabilities come naturally once you truly understand how applications work.

Thanks for reading, and I'd love to hear what you've been working on this summer.

Happy hacking! 🚀