DEV Community: Sreegeethesh

I Built an AI Red Team Platform to Attack LLMs, RAG Systems, and Agents

Sreegeethesh — Thu, 24 Sep 2026 12:18:09 +0000

I Built an AI Red Team Platform to Attack LLMs, RAG Systems, and Agents

AI applications are getting better at generating code, answering questions, retrieving information, and interacting with tools.

But testing whether an AI application works is very different from testing whether it behaves safely when someone intentionally tries to break it.

That was the problem I wanted to explore.

So I built AI Red Team, a local-first AI security testing platform designed to attack AI systems I own, collect reproducible evidence, and verify whether security fixes actually worked.

GitHub: https://github.com/SREEGEETHES/ai-redteam

The core idea is simple:

Don't just find a vulnerability. Capture the evidence and prove the fix.

What is AI Red Team?

AI Red Team is a security testing platform for:

LLM applications
RAG systems
AI agents
AI model APIs
Local AI environments

The current implementation includes:

18 deterministic OWASP-based attacks
6 vulnerable/secure lab environments
183 automated tests
16 deterministic detectors
SHA-256 integrity hashes for evidence
Automated retesting
FAIL → PASS → VERIFIED workflow
JSON, Markdown and HTML reports
FastAPI API
CLI
Streamlit dashboard
Docker support
Local-first execution

The goal isn't to claim that an AI system is "secure" after running a few tests.

Instead, the platform answers a much narrower question:

Did this specific security scenario pass or fail, and can I reproduce the result?

Why I Built It

Traditional application security tools are extremely useful, but AI systems introduce additional attack surfaces.

For example, an application might expose an LLM that can:

Receive user-controlled prompts.
Retrieve documents from a vector database.
Call internal tools.
Generate structured output.
Access application data.
Potentially influence external systems.

That means security testing cannot stop at:

Request → Response

You also need to understand the complete path:

User Input
    ↓
   LLM
    ↓
Retrieval
    ↓
Tool Selection
    ↓
Application Logic
    ↓
Side Effect

This changes how security testing needs to be approached.

The OWASP GenAI LLM Top 10

The platform uses the OWASP GenAI LLM Top 10 2026 as its primary taxonomy.

The implemented coverage includes:

Prompt Injection
Sensitive Information Disclosure
Supply Chain Vulnerabilities
Data and Model Poisoning
Improper Output Handling
Excessive Agency
System Prompt Leakage
Vector and Embedding Weaknesses
Misinformation
Unbounded Consumption

Instead of treating these as documentation categories, I implemented executable security tests around them.

The Attack Lifecycle

Every scan follows a structured workflow:

DISCOVER
   ↓
THREAT MODEL
   ↓
BASELINE
   ↓
ATTACK
   ↓
OBSERVE
   ↓
COLLECT EVIDENCE
   ↓
DETECT
   ↓
CLASSIFY
   ↓
REPORT
   ↓
REMEDIATE
   ↓
RETEST
   ↓
REGRESSION

A security scanner shouldn't simply throw payloads at an endpoint and print a result.

It needs to explain what happened.

Deterministic Testing Instead of LLM-as-a-Judge

One of the biggest design choices was avoiding an LLM as the primary security judge.

For example, imagine a test designed to determine whether a known canary secret is exposed.

Instead of asking another LLM:

"Does this response look like a secret leak?"

the scanner can deterministically check:

Expected canary:
CANARY_SECRET_12345

Response:
"I found the value CANARY_SECRET_12345..."

Detector:
canary_secret_leak

Result:
FAIL

That makes the result reproducible.

The platform uses deterministic payloads and detectors for its implemented attack cases.

The result model is:

PASS
FAIL
INCONCLUSIVE
NOT_APPLICABLE
ERROR

An important rule is:

No evidence = no PASS.

An inconclusive test should not become a passing test simply because the target didn't return an obvious failure.

Evidence Is the Important Part

Finding a vulnerability is only half the job.

The scanner needs to preserve what actually happened.

An evidence record can contain:

Scan ID
Test ID
Timestamp
Target
Request
Response
HTTP status
Headers
Tool calls
Retrieved documents
Detectors triggered
Expected behavior
Observed behavior
Reproduction count
Result
SHA-256 integrity hash

For example:

Test: LLM02-SD-001
Result: FAIL
Detector: canary_secret_leak
Reproduction count: 2
Evidence hash: SHA-256

The SHA-256 hash provides an integrity check for the stored evidence.

I deliberately describe this as integrity-verifiable evidence, rather than "tamper-proof evidence."

A hash can detect changes to the data. It does not magically prevent someone from modifying both the evidence and its stored hash.

Testing Vulnerable vs Secure Applications

Another important part of the project is the lab environment.

Instead of testing only one application, I created vulnerable and secure variants.

The project contains six lab pairs:

Vulnerable LLM
Secure LLM

Vulnerable RAG
Secure RAG

Vulnerable Agent
Secure Agent

This makes it possible to test the scanner itself.

The workflow looks like this:

Vulnerable Target
       ↓
     Scan
       ↓
     FAIL
       ↓
     Fix
       ↓
Secure Target
       ↓
    Retest
       ↓
     PASS
       ↓
   VERIFIED

This became the central workflow of the project.

FAIL → PASS → VERIFIED

A vulnerability finding shouldn't simply disappear because the application was changed.

The platform therefore includes a retest workflow.

Example:

Initial Scan

LLM02 Sensitive Information Disclosure
             ↓
           FAIL

After applying a fix:

Retest

Previous Result: FAIL
Current Result:  PASS
             ↓
          VERIFIED

This gives the project a security engineering workflow rather than a one-time vulnerability scanner.

Testing AI Agents Is Different

Agent security introduced another important problem.

Suppose an agent receives:

Delete all customer records.

The model may attempt to call:

delete_customer_records()

But that does not necessarily mean the application is vulnerable.

There are several different things to measure:

Model behavior
      ↓
Did the model attempt the action?

Security control
      ↓
Did authorization prevent it?

Application behavior
      ↓
Did the application execute it?

Actual side effect
      ↓
Was any data actually changed?

For example:

Model attempted destructive tool call
          ↓
Authorization middleware blocked it
          ↓
Database unchanged

That is very different from:

Model attempted destructive tool call
          ↓
Tool executed
          ↓
Database modified

This distinction became important when designing the agent testing architecture.

RAG Security Testing

RAG systems introduce another security boundary.

The model isn't only receiving a prompt.

It is also receiving information retrieved from a knowledge base.

That creates potential issues around:

poisoned documents
cross-tenant retrieval
unauthorized information disclosure
malicious instructions inside retrieved content
weak embedding boundaries
ungrounded responses

The testing architecture therefore treats retrieval as part of the evidence chain:

User Query
    ↓
Retriever
    ↓
Retrieved Documents
    ↓
LLM
    ↓
Response

The scanner can then inspect what was retrieved and compare that with the expected security boundary.

Architecture

The project is structured around several major components:

                    AI RED TEAM
                         │
                Scan Orchestrator
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   Attack Engine    Evidence Engine   Policy Engine
        │                │                │
        └────────────────┼────────────────┘
                         │
              Target Adapter Layer
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
      LLM               RAG              Agent
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
                  Findings / Reports
                         │
                 Retest / Regression

The target adapter layer allows different AI interfaces to be tested without coupling the attack engine to one specific implementation.

The project includes adapters for:

REST
Ollama
OpenAI-compatible APIs
RAG
Agents

CLI + API + Dashboard

The platform can be used through multiple interfaces.

CLI

The CLI is useful for automation and CI/CD workflows.

redteam scan --target ...

Retesting can be triggered with:

redteam retest <scan-id>

FastAPI

The API provides programmatic access to scanning functionality.

Streamlit

The dashboard provides a visual workflow for:

Targets
   ↓
Scans
   ↓
Findings
   ↓
Evidence
   ↓
OWASP Coverage
   ↓
Remediation
   ↓
Retest
   ↓
Regression
   ↓
Reports

The current dashboard contains 13 pages.

Reports

The scanner can generate:

JSON reports
Markdown reports
HTML reports

This makes the results useful both for automation and human review.

A typical workflow could be:

CI/CD
  ↓
Run security tests
  ↓
Generate JSON
  ↓
Store artifact
  ↓
Review findings

Testing the Scanner

A security testing tool should itself be tested heavily.

The current project has:

183 automated tests.

These cover areas including:

attack definitions
payload generation
detectors
adapters
evidence
classification
orchestration
API behavior
lab environments
retesting
regression behavior

The goal was to make the framework deterministic enough that changes to the scanner itself don't silently break existing security checks.

Local-First Design

I intentionally designed the project around local testing.

The project can be started using:

.\run_local.bat

The Streamlit dashboard then becomes available locally.

The project also includes Docker support.

A local-first workflow makes experimentation easier without requiring every test to be sent to an external service.

What This Project Is Not

AI Red Team is not a replacement for:

Burp Suite
OWASP ZAP
traditional SAST
DAST
cloud security scanners
infrastructure security testing

It focuses specifically on AI model interfaces and AI application behavior.

It is also not a guarantee that an application is secure.

Passing the implemented test suite means:

The application passed the security scenarios that were actually tested.

It does not mean:

The application contains no vulnerabilities.

That distinction is fundamental to security testing.

Security Boundaries

The project is intended for:

local development
developer-owned applications
authorized staging environments
intentionally vulnerable labs

It should not be used against systems without authorization.

The lab environments also make it possible to learn the attack and defense cycle without targeting real systems.

Technology Stack

Python
FastAPI
Streamlit
SQLAlchemy
Pydantic
pytest
Docker
SQLite
Altair

Along with integrations for AI targets such as Ollama and OpenAI-compatible interfaces.

What I Learned

The most interesting part of this project wasn't writing attack payloads.

It was designing the difference between:

"The model said something suspicious."

and:

"This specific security control failed,
here is the reproducible evidence,
and here is the retest proving whether the fix worked."

That difference is what turned this from a collection of prompt attacks into a security testing workflow.

I also learned that AI security needs to consider multiple layers simultaneously:

Model
 ↓
Prompt
 ↓
Retrieval
 ↓
Tools
 ↓
Application
 ↓
Authorization
 ↓
Side Effects

Testing only the model isn't enough when the model is connected to real application functionality.

Current Project Status

The current implementation includes:

18 deterministic attacks
16 deterministic detectors
6 vulnerable/secure lab pairs
183 automated tests
SHA-256 evidence integrity
FAIL → PASS → VERIFIED retesting
JSON / Markdown / HTML reports
13-page Streamlit dashboard
CLI
FastAPI
Docker support

Repository:

https://github.com/SREEGEETHES/ai-redteam

What's Next?

There are several directions I want to explore further:

More advanced attack chaining
Adaptive AI red-team agents
MCP security testing
More RAG isolation tests
More agent authorization scenarios
CI/CD security gates
Expanded regression testing
Additional AI security benchmarks

But I wanted the first version to solve one problem properly:

Attack → Capture Evidence → Fix → Retest → Verify

Rather than trying to build an AI security platform that claims to test everything.

Final Thought

AI security isn't only about making models refuse bad prompts.

Once an AI system can retrieve documents, access APIs, execute tools, or influence application state, security becomes a system-level problem.

That's what I wanted to explore with AI Red Team.

Don't just ask whether the AI works.

Try to break it.

Capture what happened.

Fix it.

Then attack it again.

I Built JARVIS to Put Security Guardrails Around My Vibe Coding Workflow

Sreegeethesh — Wed, 16 Sep 2026 13:59:45 +0000

I’ve been using AI coding agents heavily.

They make it ridiculously easy to go from:

“I have an idea”

to:

“I have a working application”

But while preparing for a cybersecurity interview, I realized I had a problem.

I was getting faster at building software.

I wasn’t getting equally systematic at checking the software I was building.

So I built something.

Meet J.A.R.V.I.S. Framework.

GitHub: https://github.com/SREEGEETHES/J.A.R.V.I.S-framework

What is JARVIS?

JARVIS is a universal audit and diagnostic framework for AI coding agents.

The idea is to make an AI agent follow a structured engineering protocol instead of casually reviewing a project and saying:

“Looks good.”

The current framework has 158 checks.

70 security checks

The House Party Protocol covers things like:

Secrets

Authentication

Authorization

SQL injection

XSS

SSRF

IDOR

CSRF

CORS

Secure cookies

AI security

CI/CD security

46 web launch checks

Drop My Needle looks at:

Performance

Accessibility

Legal requirements

Asset optimization

Forms

Error pages

Launch configuration

42 deployment checks

Prepare for Landing checks:

Git hygiene

Environment files

Dependencies

Build readiness

Health checks

Logging

Rollback preparation

Operational readiness

The important part: No Fake Pass

This is probably my favorite part of the framework.

AI can be very confident.

That doesn’t mean it is correct.

So I created a simple rule:

No evidence = No PASS

If JARVIS can’t prove that a security control exists in the code, it shouldn’t mark the check as passed.

The audit uses:

PASS
FAIL
WAITING_AUTH

This makes the agent focus on evidence instead of assumptions.

Four phases

Every major protocol follows:

Discovery
↓
Audit
↓
Remediation
↓
Reporting

Discovery

Inspect the repository and identify relevant code and configuration.

Audit

Run the defined controls and collect evidence.

Remediation

Safe code issues can be fixed automatically.

High-impact changes require human approval.

Reporting

Results are persisted in:

.jarvis/STATE.md

So the audit doesn’t disappear when the AI session ends.

Why human authorization?

I don’t want an AI agent to interpret:

“Fix everything”

as permission to modify production infrastructure.

Some changes are fundamentally different from editing a source file.

Changing:

Cloud infrastructure

Production credentials

Databases

Billing configuration

External services

should have a human checkpoint.

That’s why JARVIS has a separate human authorization mode.

And yes, the name is from Iron Man

I’m a huge Iron Man fan.

When I started this project, I wanted the experience to feel like having a technical co-pilot beside me.

So JARVIS became the perfect name.

But underneath the theme, the idea is pretty simple:

Build fast with AI, but don’t skip the engineering checks.

Supported environments

The framework is designed to work across multiple AI coding environments, including:

Antigravity

OpenCode

Claude Code

Cursor

Windsurf

Cline / Roo Code

The repository includes both global and project-level installation options.

What I’m hoping to learn

This is still an evolving project.

I’m particularly interested in where this idea goes as AI coding agents become more capable.

Can structured protocols make agents more reliable?

Can persistent audit state make AI-assisted development easier to review?

Can we automate more security checks without giving agents too much authority?

That’s what I’m experimenting with.

If you’re building with AI coding agents, I’d love to know how you’re handling security in your workflow.

GitHub: https://github.com/SREEGEETHES/J.A.R.V.I.S-framework

ai #security #devsecops #appsec #vibecoding #opensource #python #coding

Your SaaS Isn't Production-Ready Just Because `npm run build` Works

Sreegeethesh — Wed, 02 Sep 2026 11:48:48 +0000

A few days ago, I was going through one of my SaaS applications before shipping it.

The product worked.

The UI looked good.

The API worked.

Authentication worked.

And technically, I could have deployed it and called it done.

But opening DevTools, viewing the page source, checking how Google would understand the site, and looking at the production bundle told a different story.

A working application is not necessarily a production-ready application.

So I ended up doing a complete frontend production-hardening pass.

Here is the checklist I now use before calling a SaaS frontend ready for production.

1. Build a Proper Page Source

Modern React applications can easily produce pages where the initial HTML tells crawlers almost nothing about the application.

The browser eventually renders everything correctly, but crawlers, link previews, search engines, and other machines still benefit from meaningful HTML.

I started checking the actual page source instead of judging the application only from what React rendered on screen.

The page should expose enough meaningful information for machines to understand what it represents.

2. Build a Custom 404 Page

A default server error or blank React page is a terrible dead end.

A proper 404 page should:

clearly explain that the requested page doesn't exist,
maintain the product's branding,
provide navigation back into the product,
link to important pages,
and return the correct HTTP status where possible.

Even error pages are part of the product experience.

3. Give Every Page a Unique Title

One of the easiest mistakes in a SPA is having every route use the same title.

For example:

My SaaS

is much less useful than:

AI Video Editor | ProductName

or:

Pricing | ProductName

Every important route now gets its own descriptive title.

This improves search visibility, browser-tab usability, bookmarks, and link previews.

4. Write Useful Meta Descriptions

I also stopped using generic descriptions such as:

The best platform for everything.

Every important public page gets a description explaining what that specific page actually offers.

Good metadata should help someone decide whether the page is relevant before they even open it.

5. Add Canonical URLs

Applications often accidentally expose the same content through multiple URLs.

Query parameters, alternate paths, trailing slashes, campaign URLs, and routing behavior can all create duplicate versions of a page.

Canonical tags tell search engines which URL should be considered the authoritative one.

A small detail, but an important one.

6. Use One Clear Primary Heading Per Page

Design systems make it surprisingly easy to build pages that look visually correct while having terrible document structure underneath.

Each page should have a clear purpose.

The primary heading should communicate that purpose.

Then the remaining headings should form a logical hierarchy.

Not because an SEO plugin says so.

Because semantic HTML makes the page easier for search engines, accessibility tools, browsers, and humans to understand.

7. Generate a Sitemap

If the application contains publicly indexable pages, I add a sitemap.xml.

It contains the canonical public URLs I actually want crawled.

The important part is not merely generating a sitemap.

It is making sure the sitemap doesn't advertise pages that should never be indexed in the first place.

8. Configure `robots.txt`

Then comes robots.txt.

It communicates which sections crawlers should or shouldn't access and points them toward the sitemap.

For SaaS products, this becomes especially useful when separating public marketing pages from dashboards, authenticated routes, internal tools, or temporary environments.

9. Add `llms.txt`

This one is newer.

Alongside traditional search-engine optimization, I also started thinking about how AI systems understand products.

I added an llms.txt file containing a concise, machine-readable explanation of the product and its important resources.

Whether llms.txt becomes a universal standard or not, the underlying idea is worth paying attention to:

websites are increasingly being consumed by machines other than traditional search crawlers.

SEO is slowly becoming broader than Google.

10. Stop Treating the Favicon as an Afterthought

That tiny icon appears everywhere:

browser tabs, history, bookmarks, shortcuts, search interfaces, and sometimes mobile surfaces.

I replaced the placeholder favicon with something simple, recognizable, high-contrast, and consistent with the product identity.

Small visual elements can have an outsized effect on how finished a product feels.

11. Add Internal Links and Breadcrumbs

A lot of SaaS landing pages behave like isolated islands.

I started deliberately connecting related pages.

Features → relevant use cases.

Blog posts → related documentation.

Documentation → product pages.

Child pages → parent sections.

Where the information hierarchy justified it, I added breadcrumbs as well.

Good internal linking helps users navigate while also helping crawlers understand the structure and relationships between pages.

12. Add Structured Data

Humans understand a page through visual context.

Machines don't always get that luxury.

Structured data gives additional context about what the page represents.

Depending on the page, this can describe things such as:

the organization,
software/application information,
articles,
breadcrumbs,
FAQs,
or other supported entities.

For breadcrumb-enabled pages, I also added breadcrumb structured data rather than relying only on the visual component.

13. Fix Every Production Console Error

One rule I started following:

a production browser console should be boring.

No mysterious errors.

No failed requests.

No hydration problems.

No missing assets.

No repeated warnings that everyone has learned to ignore.

Warnings have a tendency to become background noise.

And when the important error finally appears, nobody notices it.

14. Disable Production Source Maps When They Aren't Needed

Development source maps are incredibly useful.

Production source maps require more thought.

Depending on the deployment model, publicly accessible source maps can expose significantly more information about the application's source than intended.

For applications that don't need publicly shipped source maps, I disable them in the production build or upload private maps only to the monitoring platform that requires them.

15. Reduce Massive JavaScript Bundles

Then I opened the bundle output.

This is where things usually get interesting.

A beautiful landing page shouldn't require downloading a ridiculous amount of JavaScript before becoming useful.

I started looking for:

oversized dependencies,
libraries imported globally,
components that could be lazy-loaded,
routes that could be code-split,
duplicate dependencies,
unused packages,
and features that shouldn't be in the initial bundle.

Bundle size is not just a Lighthouse metric.

It affects actual humans using slower hardware and slower networks.

16. Remove Every Default Vite/React Placeholder

This sounds obvious.

Yet production applications constantly ship with traces of their scaffolding.

Vite logos.

React favicons.

Default metadata.

Placeholder page titles.

Starter README text.

Example assets.

Development console messages.

Boilerplate copy.

I now search the repository before release and remove anything that makes the application look like a starter template instead of an actual product.

The Bigger Lesson

None of these changes individually feels revolutionary.

That is exactly why they get ignored.

Developers naturally focus on the difficult parts:

authentication,
databases,
payments,
AI pipelines,
background jobs,
infrastructure,
and application logic.

Then we finish the feature and mentally declare the product complete.

But production quality lives in hundreds of smaller decisions surrounding the feature.

Can Google understand the page?

Can an AI system understand the product?

Does the browser console stay clean?

Does a broken URL still feel like part of the application?

Are users downloading JavaScript they don't need?

Does the website still advertise the framework used to scaffold it?

Does every page actually explain what it is?

These aren't glamorous engineering tasks.

But together they make the difference between:

“I built a React app.”

and

“I shipped a product.”

My current pre-production frontend checklist:

Meaningful page source
Custom 404
Unique page titles
Page-specific meta descriptions
Canonical URLs
Semantic page headings
sitemap.xml
robots.txt
llms.txt
Product-specific favicon
Internal links + breadcrumbs
Structured data
Zero unexplained console errors
Production source-map strategy
JavaScript bundle optimization
Zero framework placeholders

I'm probably going to keep extending this checklist as I ship more products.

Because shipping the feature is only half the job.

The other half is making the web understand what you shipped.

# I Built My Developer Portfolio as Peter Parker's Lab 🕷️

Sreegeethesh — Thu, 13 Aug 2026 06:21:19 +0000

I could have built another developer portfolio.

You know the one.

Dark background.

Glowing buttons.

"Full Stack Developer | AI | Cloud | DevOps"

Six project cards.

GitHub link.

Done.

But honestly, that doesn't feel like me.

Before I was interested in AI, software engineering, cloud, automation and all the other things I keep breaking and rebuilding, I was just a kid who loved Spider-Man.

And the older I got, the more I realized that I didn't actually relate to Spider-Man because he was a superhero.

I related to Peter Parker.

The curious kid.

The awkward kid.

The kid who builds things.

The kid who experiments.

The kid who fails and somehow keeps going.

That felt familiar.

So when I started building my portfolio, I wanted it to represent that.

I called it:

🧪 Peter Parker's Lab

The idea is that my portfolio is basically my digital lab.

A place where I can show what I'm building, what I'm learning and what I'm experimenting with.

🕷️ Peter Parker → curiosity

🕸️ Spider-Man → persistence

💻 Developer → everything I'm building today

And honestly, "lab" describes my development journey pretty well.

I build something.

It breaks.

I investigate why.

I fix it.

Then I get another idea and break something else.

😂

That's the fun part.

I'm currently interested in building things around:

AI
AI agents
automation
full-stack applications
developer tools
cloud infrastructure
DevOps
local-first software

I'm not trying to pretend I've mastered all of it.

I'm trying to keep learning by building real things.

That's what I want this portfolio to show.

Not just a list of technologies.

Not just a list of GitHub repositories.

But the problems I'm curious about and the things I'm actually trying to create.

🌐 Peter Parker's Lab

https://peterparker-lab.vercel.app/

This is version one.

I'll keep changing it as I change.

New projects.

New experiments.

New ideas.

Probably new bugs too.

Because maybe the best portfolio isn't one that says:

"Look how much I know."

Maybe it's one that says:

"Look what I'm curious enough to build next."

🕷️❤️

And yes...

I still think Spider-Man is one of the coolest characters ever.

Some things don't change.

I Built an Open-Source AI Video Clipping Pipeline

Sreegeethesh — Sat, 08 Aug 2026 06:46:05 +0000

I Built an Open-Source AI Video Clipping Pipeline

I wanted a tool that could take a long video and turn it into social-ready clips without uploading the entire video to some SaaS platform.

So I built AutoClip.

The idea is simple:

YouTube URL / Video File
          ↓
      Transcription
          ↓
   LLM Clip Selection
          ↓
   Vertical Reframing
          ↓
    Speaker Tracking
          ↓
   Animated Captions
          ↓
     MP4 Export
          ↓
    Buffer Scheduling

The interesting part is that the video processing happens locally.

AutoClip uses an LLM to identify moments worth clipping, but only the transcript text is sent to the LLM. The actual video stays on the user's machine.

It supports multiple caption styles:

Word Pop
Karaoke Fill
Clean Lower Third
Boxed

The final clips are rendered as 9:16 MP4s ready for social platforms.

Publishing Architecture

I also wanted publishing to follow the same privacy model.

Instead of building a cloud scheduler, AutoClip uses a BYOK approach.

The stack is:

Your PC
  ↓
AutoClip processes video
  ↓
Cloudflare R2
  ↓
Buffer
  ↓
Social Platform

The R2 bucket acts as temporary media storage so Buffer can access the video.

Once the job is handed off, the user's computer doesn't need to stay online.

No central media storage.

No SaaS layer.

No subscription.

No watermark.

No telemetry.

Just your infrastructure and your API keys.

Why I Built It

There are plenty of AI video tools already.

I wanted one where I could actually understand and control what happens to my content.

The goal was:

Your machine edits.
Your Buffer publishes.
Your content stays yours.

AutoClip is open source.

GitHub:

SREEGEETHES / Autoclip

AutoClip

The local-first AI clipper that finishes the job. Drop in a long video → get ranked, caption-burned, speaker-tracked 9:16 clips out — and schedule them to post while your PC is off.

Paste a YouTube link or drop a file. AutoClip transcribes it, uses an LLM to find the moments actually worth clipping, reframes them to vertical while tracking whoever is speaking, burns in animated captions, exports platform-ready MP4s — then hands the finished clips to Buffer to publish on schedule. No accounts with us. No uploads to our servers. No watermarks. No subscription.

Your machine edits. Your Buffer publishes. Your R2 bridges the media. Nobody owns your content but you.

What it does

Ingest anything — a YouTube URL or a local file, hours long or minutes.
Find the real hooks — an LLM reads the transcript and ranks the moments worth clipping, down to the word. Timing…

View on GitHub

I'd love feedback from anyone building content automation, video tooling, or local-first AI applications.

How I built an offline semantic photo search app (Python + Vector DB)

Sreegeethesh — Mon, 03 Aug 2026 10:51:14 +0000

Show DEV 🚀

I built OmniCard, a local-first AI media manager.

Features:

• Semantic image search

• AI captions

• Smart tags

• Duplicate detection

• SQLite + LanceDB

• Desktop application with pywebview

The goal was simple:

Search photos by what's inside them instead of by filename.

Example:

"Drone over mountains"

instead of

IMG_4829.jpg

The app stores everything locally, so your media never leaves your computer.

Live demo:
https://sreegeethes.github.io/Omnicard/

GitHub:
https://github.com/SREEGEETHES/Omnicard

Release:
https://github.com/SREEGEETHES/Omnicard/releases/tag/v1.0.0

Would love feedback from other Python and AI developers.

DEV Community: Sreegeethesh

I Built an AI Red Team Platform to Attack LLMs, RAG Systems, and Agents

I Built an AI Red Team Platform to Attack LLMs, RAG Systems, and Agents

What is AI Red Team?

Why I Built It

The OWASP GenAI LLM Top 10

The Attack Lifecycle

Deterministic Testing Instead of LLM-as-a-Judge

Evidence Is the Important Part

Testing Vulnerable vs Secure Applications

FAIL → PASS → VERIFIED

Testing AI Agents Is Different

RAG Security Testing

Architecture

CLI + API + Dashboard

CLI

FastAPI

Streamlit

Reports

Testing the Scanner

Local-First Design

What This Project Is Not

Security Boundaries

Technology Stack

What I Learned

Current Project Status

What's Next?

Final Thought

I Built JARVIS to Put Security Guardrails Around My Vibe Coding Workflow

ai #security #devsecops #appsec #vibecoding #opensource #python #coding

Your SaaS Isn't Production-Ready Just Because `npm run build` Works

1. Build a Proper Page Source

2. Build a Custom 404 Page

3. Give Every Page a Unique Title

4. Write Useful Meta Descriptions

5. Add Canonical URLs

6. Use One Clear Primary Heading Per Page

7. Generate a Sitemap

8. Configure robots.txt

9. Add llms.txt

10. Stop Treating the Favicon as an Afterthought

11. Add Internal Links and Breadcrumbs

12. Add Structured Data

13. Fix Every Production Console Error

14. Disable Production Source Maps When They Aren't Needed

15. Reduce Massive JavaScript Bundles

16. Remove Every Default Vite/React Placeholder

The Bigger Lesson

# I Built My Developer Portfolio as Peter Parker's Lab 🕷️

🧪 Peter Parker's Lab

I Built an Open-Source AI Video Clipping Pipeline

I Built an Open-Source AI Video Clipping Pipeline

Publishing Architecture

Why I Built It

SREEGEETHES / Autoclip

AutoClip

What it does

How I built an offline semantic photo search app (Python + Vector DB)

Show DEV 🚀

8. Configure `robots.txt`

9. Add `llms.txt`