DEV Community: Harshal Mehta

[Boost]

Harshal Mehta — Fri, 10 Apr 2026 03:16:22 +0000

Harshal Mehta

Apr 10

The New Rules of the Game: How AI Is Rewriting Cybersecurity Consulting and Compliance

#cybersecurity #compliance #ai #consulting

Comments

8 min read

The New Rules of the Game: How AI Is Rewriting Cybersecurity Consulting and Compliance

Harshal Mehta — Fri, 10 Apr 2026 03:16:09 +0000

I Didn't Plan to Care About Compliance

Let me be honest with you. A few years ago, if you told me I'd be writing about compliance frameworks and consulting strategies, I would have laughed. I was a developer. I wrote code. I fixed bugs. I shipped features. Compliance was that thing the "other team" handled -- the people who sent us spreadsheets and asked if we encrypted things.

Then I started working in cybersecurity.

And suddenly, compliance wasn't some abstract checklist living in a Google Drive folder. It was the reason we redesigned authentication flows. It was the reason a product launch got delayed by three months. It was the thing that kept our CISO up at night -- not because of hackers, but because of auditors.

That shift in perspective changed everything for me. And if you're a developer, a security practitioner, or someone even remotely curious about where this industry is heading, I think it's worth talking about what's happening right now. Because AI isn't just changing how we write code. It's fundamentally changing how organizations think about risk, compliance, and who they trust to guide them through it.

Compliance Used to Be a Checkbox. Now It's a Moving Target.

Here's the thing about compliance that nobody tells you early in your career: it was never really about security. At least, not entirely. Compliance frameworks -- SOC 2, ISO 27001, HIPAA, PCI-DSS, GDPR -- they exist because trust needs to be standardized. Your customers, your partners, your regulators need a shared language to say, "Yes, this organization takes data protection seriously."

For a long time, that language was static enough. You'd implement controls, document them, get audited once a year, and move on. The frameworks evolved, sure, but slowly. You could plan for them.

That world is disappearing.

The introduction of AI into enterprise workflows has created compliance scenarios that existing frameworks weren't designed to handle. Consider just a few questions that didn't exist five years ago:

If your AI model is trained on customer data, does that count as "processing" under GDPR?
If an LLM generates a security policy, who is accountable when that policy has a gap?
How do you audit a decision made by a system that can't fully explain its own reasoning?
If your third-party vendor uses AI to handle support tickets containing PHI, is your BAA still valid?

These aren't hypothetical edge cases anymore. These are conversations happening in boardrooms, in Slack channels, and on compliance calls every single week. And the honest answer to most of them is: we're still figuring it out.

The EU AI Act is now in effect. The NIST AI Risk Management Framework is being adopted. New guidance on AI governance seems to drop monthly. The ground is shifting under our feet, and the organizations that treat compliance as a once-a-year fire drill are going to get burned.

Why Cybersecurity Consulting Is Having Its Moment

This is where consulting comes in -- and I don't mean the old-school consulting of sending a 200-page PDF and calling it a day.

The cybersecurity consulting landscape is transforming because organizations are dealing with a kind of complexity they've never faced before. It's not just "are we secure?" anymore. It's "are we secure, compliant, ethical, and operationally resilient in a world where our own tools are making autonomous decisions?"

That's a fundamentally different problem. And it requires a fundamentally different kind of advisor.

The consultants who thrive in this environment aren't just policy experts or pentesters. They're people who can sit in a room with a CTO and a legal counsel and a compliance officer and translate between all three. They understand the technical debt behind a compliance gap. They understand the regulatory intent behind a technical control. They understand that a startup burning through runway can't implement controls the same way a Fortune 500 company does.

The best consulting isn't about knowing all the answers. It's about asking better questions than your client thought to ask themselves.

I've been on both sides of this. As a developer, I used to resent consultants who came in, disrupted our workflow, and left us with recommendations that ignored our architecture. Now, working closer to the advisory side, I understand why that disconnect happens -- and more importantly, how to bridge it.

If you're a developer reading this: the ability to understand why a compliance control exists and translate it into something your engineering team can actually implement? That's a superpower. Seriously. The industry is desperate for people who speak both languages.

AI: The Double-Edged Sword in Compliance

Let's talk about the elephant in the room. AI is simultaneously making compliance easier and harder. And depending on who you ask, it's either the savior of the industry or the thing that will create more problems than it solves.

Here's my honest take: it's both.

Where AI is genuinely helping

Continuous monitoring. Traditional compliance was periodic. You'd audit quarterly or annually. AI-powered tools are enabling continuous compliance monitoring -- flagging configuration drift in real-time, detecting anomalous access patterns, automatically mapping controls to regulatory requirements. This is genuinely transformative. Instead of discovering you've been non-compliant for six months during an audit, you find out in six minutes.

Evidence collection. If you've ever prepared for a SOC 2 audit, you know the pain of gathering evidence. Screenshots, logs, policy documents, access reviews -- it's brutal. AI tools are automating significant chunks of this. They pull evidence from your cloud infrastructure, your identity providers, your ticketing systems. What used to take weeks can now take days.

Risk assessment at scale. Evaluating third-party vendor risk used to mean sending questionnaires and hoping for honest answers. AI-driven platforms can now analyze a vendor's public-facing security posture, cross-reference with threat intelligence feeds, and flag risks that a questionnaire would never surface.

Policy generation and gap analysis. LLMs can draft policies, compare them against frameworks, and identify gaps. They're not perfect, and they absolutely need human review, but they can turn a two-week policy development cycle into a two-day one.

Where AI is creating new headaches

Shadow AI. Your employees are using ChatGPT, Claude, Copilot, and a dozen other AI tools -- many of them without your security team's knowledge or approval. They're pasting customer data into prompts. They're using AI-generated code without reviewing it. Shadow AI is the new shadow IT, and it's moving faster than most governance frameworks can keep up with.

Explainability and auditability. Regulators want to understand why a decision was made. Traditional rule-based systems are auditable by design. Machine learning models? Not so much. When your AI-powered fraud detection system flags (or misses) a transaction, can you explain exactly why? If the answer is "sort of," that's a compliance problem.

Data governance complexity. AI models need data. Lots of it. Where that data comes from, how it's processed, where it's stored, who has access, and what happens to it after training -- these questions intersect with virtually every data protection regulation on the books. And most organizations' data governance practices weren't built for this level of complexity.

Supply chain risk. You're not just evaluating your own AI usage anymore. You're evaluating your vendors' AI usage. And their vendors' AI usage. The supply chain risk surface has expanded in ways that make traditional vendor assessments feel quaint.

What This Means If You're a Developer

I know some of you are reading this thinking, "I just write code. This isn't my problem."

I get it. I really do. I used to think the same way.

But here's the reality: compliance is increasingly a development problem. The controls aren't just policies sitting in a wiki somewhere. They're implemented in code. Access controls, encryption at rest, audit logging, data retention, consent management -- all of it lives in your codebase.

And with AI becoming embedded in development workflows (Copilot, AI-powered testing, automated code review), the line between "development decision" and "compliance decision" is getting blurrier by the day.

A few things I'd encourage every developer to internalize:

Understand the "why" behind security requirements. When your security team says "we need audit logs for all admin actions," don't just implement it mechanically. Understand which framework requires it, what the auditor is looking for, and what "good" looks like. That context makes you a better engineer.
Treat AI tools like any other third-party dependency. You wouldn't use a random npm package without checking its license and maintenance status. Apply the same rigor to AI tools. Where is your data going? What are the terms of service? Is the tool SOC 2 compliant?
Build observability into AI-powered features. If you're integrating AI into your product, think about auditability from day one. Log inputs and outputs. Track model versions. Make decisions traceable. Your future compliance team will thank you.
Get comfortable with ambiguity. The regulatory landscape around AI is evolving fast. There won't always be a clear-cut answer. The developers who can navigate that ambiguity -- who can make reasonable judgment calls and document their reasoning -- are going to be incredibly valuable.

The Consultant of Tomorrow

I've been thinking a lot about what the next generation of cybersecurity consultants looks like. And I don't think it's the stereotypical suit-and-tie figure dropping buzzwords in a boardroom.

I think it's someone who has written production code and understands why a "simple" compliance requirement might take a sprint to implement. Someone who has sat through an audit and knows where the gaps usually hide. Someone who can read a regulation, translate it into a threat model, and then help an engineering team build the right controls -- not the cheapest ones, not the most impressive-sounding ones, but the right ones for that organization's risk profile.

I think it's someone who understands AI deeply enough to advise on its governance without either fear-mongering or hand-waving. Someone who can help a 50-person startup navigate SOC 2 without drowning in enterprise-grade bureaucracy, and also help a multinational corporation figure out what responsible AI deployment actually looks like in practice.

The consulting world is changing because the problems are changing. And the people best positioned to solve those problems are the ones who live at the intersection of technology, risk, and pragmatism.

Final Thoughts

We're at a genuinely interesting inflection point. AI is forcing the cybersecurity and compliance world to evolve faster than it has in decades. The frameworks are catching up. The tooling is getting better. But the biggest gap isn't technological -- it's human.

We need more people who can bridge the gap between code and policy. Between engineering and governance. Between innovation and responsibility.

If you're a developer curious about the compliance side of security, lean into that curiosity. If you're a compliance professional trying to understand the technical implications of AI, keep asking those questions. And if you're someone thinking about cybersecurity consulting, know this: the world needs advisors who have actually lived in the trenches, not just studied them from the outside.

The rules of the game are being rewritten in real-time. Might as well help write them.

If this resonated with you, I'd love to connect. I'm always up for conversations about cybersecurity, compliance, AI governance, or the messy space where they all overlap. Drop a comment or find me on [LinkedIn - https://www.linkedin.com/in/harshalmehtaprofile/].

How AI Is Transforming Cybersecurity and Compliance — A Deep Dive into PCI DSS

Harshal Mehta — Tue, 07 Apr 2026 01:40:55 +0000

The intersection of artificial intelligence and cybersecurity is no longer a future concept — it is the present reality shaping how organizations defend their data, detect threats, and demonstrate regulatory compliance. As cyber threats grow in sophistication and volume, traditional rule-based security tools are struggling to keep pace. AI is filling that gap with speed, precision, and adaptability that human analysts alone cannot match.

Nowhere is this transformation more consequential than in the world of payment security and compliance. The Payment Card Industry Data Security Standard (PCI DSS) — the global framework governing how organizations handle cardholder data — has long been a compliance burden for businesses of all sizes. AI is now fundamentally changing how companies achieve, maintain, and prove PCI DSS compliance, making the process faster, smarter, and far more resilient.

The Cybersecurity Landscape: Why AI Has Become Essential

Modern cyber threats have outgrown the era of signature-based defenses. Attackers are leveraging automation, polymorphic malware, and AI-driven phishing campaigns to evade detection. The numbers tell a stark story: the average time to identify a data breach globally remains alarmingly high, and the cost of a single incident can run into millions of dollars — not counting the reputational damage and regulatory fines that follow.

Three core challenges are driving the adoption of AI in cybersecurity:

Volume and velocity. Security operations centres (SOCs) are drowning in alerts. AI can triage, correlate, and prioritize thousands of events per second — far beyond any human capacity.

Evolving attack surfaces. With cloud migration, remote work, and IoT proliferation, the attack surface has expanded enormously. AI can monitor these environments continuously and adaptively.

Talent shortage. The global cybersecurity skills gap remains significant. AI augments lean security teams, automating routine tasks so analysts can focus on high-value investigations.

What Is PCI DSS and Why Does It Matter?

PCI DSS is a set of security standards developed by the Payment Card Industry Security Standards Council (PCI SSC) to protect cardholder data. Any organization that stores, processes, or transmits credit and debit card information — from global retailers to small e-commerce platforms — must comply.

The standard is organized around six core goals and twelve requirements, covering areas such as:

Building and maintaining a secure network
Protecting stored cardholder data
Maintaining a vulnerability management program
Implementing strong access control measures
Regularly monitoring and testing networks
Maintaining an information security policy

Non-compliance can result in significant financial penalties, suspension of card processing privileges, and in the event of a breach, liability for fraudulent transactions. With PCI DSS v4.0 now in full effect as of 2025, requirements have become more rigorous — placing a renewed emphasis on continuous monitoring, customized implementation, and demonstrable security outcomes rather than checkbox compliance.

How AI Is Transforming PCI DSS Compliance

1. Continuous Monitoring and Real-Time Threat Detection

One of the most demanding PCI DSS requirements is Requirement 10: logging and monitoring all access to network resources and cardholder data. Traditionally, this meant generating enormous log files that were reviewed periodically — a reactive, time-consuming process.

AI-powered Security Information and Event Management (SIEM) platforms change this entirely. Machine learning models establish a behavioral baseline for users, systems, and network traffic. Any deviation — an unusual login time, a sudden spike in data exports, or an unexpected access to the card data environment (CDE) — triggers an immediate alert.

This continuous, real-time posture aligns directly with the spirit of PCI DSS v4.0, which emphasizes ongoing security rather than point-in-time compliance snapshots. AI doesn't sleep, doesn't miss anomalies due to alert fatigue, and improves its detection accuracy over time.

2. Automated Vulnerability Management

PCI DSS Requirement 6 mandates the identification and patching of system vulnerabilities in a timely manner. Historically, vulnerability management involved periodic scans followed by lengthy remediation cycles — a process that left organizations exposed between assessments.

AI-driven vulnerability management platforms now perform continuous scanning, automatically prioritize vulnerabilities based on exploitability and business risk, and in some cases trigger automated remediation workflows. This means organizations can demonstrate to auditors not just that they scan for vulnerabilities, but that they act on them intelligently and systematically.

Predictive AI models can also assess which vulnerabilities are most likely to be exploited in the near term — based on threat intelligence feeds, dark web activity, and attack trend analysis — allowing security teams to stay ahead of attackers rather than simply reacting.

3. AI-Powered Access Control and Identity Verification

PCI DSS Requirements 7 and 8 are concerned with restricting access to cardholder data and implementing robust authentication mechanisms. AI is redefining what "strong authentication" looks like through behavioral biometrics and continuous authentication.

Rather than relying solely on passwords or static multi-factor authentication (MFA), AI systems continuously analyze how a user interacts with systems — typing patterns, mouse movements, navigation habits — and can silently flag or block sessions that deviate from a user's established profile. This provides an adaptive layer of access control that is both more secure and less disruptive to legitimate users.

For privileged access management (PAM), AI can automatically detect and flag abnormal privileged account behavior in the CDE — such as an administrator accessing card data at unusual hours or bulk-downloading transaction records — and escalate or block the action in real time.

4. Data Discovery and Cardholder Data Environment (CDE) Scoping

One of the most underestimated challenges in PCI DSS compliance is knowing where cardholder data actually lives. Organizations often underestimate the scope of their CDE because card data has a way of spreading — through backups, test environments, log files, emails, and shared drives.

AI-powered data discovery tools use natural language processing (NLP) and pattern recognition to scan structured and unstructured data repositories, automatically identifying Primary Account Numbers (PANs), card verification values, and other sensitive data elements. This gives compliance teams an accurate and current map of where cardholder data resides, dramatically simplifying scoping for PCI DSS assessments and reducing the attack surface by enabling targeted data minimization.

5. Intelligent Log Analysis and Audit Trail Management

Generating logs is mandatory under PCI DSS; making sense of them is the hard part. A mid-sized organization can produce millions of log entries daily across firewalls, endpoints, applications, and network devices. Manual review of these logs for anomalies is practically impossible.

AI transforms log analysis from a reactive compliance task into a proactive security function. Machine learning models identify patterns across massive log datasets, detect subtle indicators of compromise (such as low-and-slow data exfiltration), and surface the most security-relevant events for human review. This directly supports PCI DSS Requirement 10.7, which mandates the review of logs for suspicious activity at least daily.

Some platforms now generate audit-ready reports automatically, mapping AI-detected events to specific PCI DSS requirements — significantly reducing the time and cost associated with Qualified Security Assessor (QSA) audits.

6. Fraud Detection and Transaction Monitoring

Beyond infrastructure compliance, AI is having a profound impact on the payment fraud side of PCI DSS. Requirement 12 calls for organizations to support information security with organizational policies and programs — and AI-driven fraud detection is increasingly central to this.

Machine learning models trained on billions of historical transactions can detect fraudulent activity in milliseconds — analyzing variables such as transaction amount, location, device fingerprint, purchase history, and velocity patterns. These models adapt continuously to new fraud typologies, catching novel attack patterns that rule-based systems would miss entirely.

For payment processors and card issuers, AI-driven fraud detection is not just a compliance asset — it is a competitive differentiator and a direct driver of reduced fraud losses.

Challenges and Considerations

The adoption of AI in PCI DSS compliance is not without its complexities.

Explainability and auditability. QSAs and regulators need to understand how security decisions are made. Black-box AI models can create challenges when organizations must explain why a particular alert was generated or a decision taken. The move toward explainable AI (XAI) is helping address this — but organizations must ensure their AI tools can produce audit-friendly documentation.

Model integrity and adversarial attacks. AI systems themselves can be targets. Adversarial inputs — carefully crafted data designed to fool machine learning models — are an emerging threat. Organizations deploying AI in their security stack must also protect the models themselves.

Data quality and bias. AI is only as good as the data it is trained on. Poor quality training data — or data that doesn't reflect the current threat landscape — can lead to missed detections or excessive false positives. Ongoing model maintenance and retraining are essential.

Third-party risk. Many AI security tools are delivered as cloud-based SaaS platforms. Under PCI DSS, organizations remain responsible for the security of cardholder data even when it is processed by third-party vendors — meaning vendor due diligence and contractual obligations must extend to AI providers.

The Road Ahead: AI and the Future of Compliance

PCI DSS v4.0's emphasis on customized implementation and demonstrable security outcomes — as opposed to prescriptive checkbox compliance — creates fertile ground for AI. Organizations can now build AI-driven controls that demonstrably achieve the security objectives of PCI DSS, even if they don't follow the letter of specific prescriptive requirements, provided they can document and justify the approach through the Customized Approach.

Looking further ahead, the convergence of AI with zero-trust architecture, quantum-resistant cryptography, and autonomous security operations centres (Autonomous SOC) will reshape the compliance landscape further. The organizations that invest in AI-augmented security today will be better positioned to adapt to whatever the next iteration of PCI DSS — and the next wave of cyber threats — demands.

Conclusion

AI is not a silver bullet for cybersecurity compliance, but it is the most powerful tool available to organizations grappling with the dual challenge of sophisticated threats and rigorous regulatory requirements. In the context of PCI DSS, AI enables organizations to move from reactive, audit-driven compliance to a continuous, intelligence-led security posture.

From real-time anomaly detection and intelligent vulnerability management to automated data discovery and AI-enhanced fraud prevention, the use cases are concrete, proven, and growing. As PCI DSS continues to evolve and cyber threats become ever more advanced, AI will move from a competitive advantage to an operational necessity for any organization that handles payment card data.

The question is no longer whether AI belongs in your compliance program — it is how quickly and effectively you can deploy it.

This article is intended for informational purposes and reflects publicly available information on AI, cybersecurity, and PCI DSS compliance as of April 2026.

I Built EvalGuard: A LLM Security & Evaluation Platform

Harshal Mehta — Mon, 30 Mar 2026 13:17:35 +0000

I Built EvalGuard: A Full-Stack LLM Security & Evaluation Platform

After spending some days watching teams ship AI features with basically zero confidence in how their models would behave under adversarial conditions, I decided to build the tool I kept wishing existed.

EvalGuard is a full-stack LLM security and evaluation platform. Think Promptfoo meets Datadog — but purpose-built for AI teams who need more than vibe checks before deploying to production.

This post covers the architecture, the interesting technical decisions, and what I learned building this end-to-end as a solo project.

What EvalGuard Does

At a high level, EvalGuard gives teams three things:

1. Eval Suites — run structured evaluations across multiple LLM providers (OpenAI, Anthropic, Google AI, Groq) side by side. Compare GPT-4o vs Claude vs Llama on the same test cases with 7 different scoring metrics.

2. Red-Teaming — attack your own models before someone else does. 50+ attack templates across 5 categories: prompt injection, jailbreaking, PII leakage, bias, and toxicity. Beyond static templates, EvalGuard uses an LLM to dynamically generate adversarial prompts tailored to your model's specific system prompt.

3. Agent Monitoring — real-time tracing at the span level with automatic policy violation detection. If your agent does something it shouldn't, you know immediately.

Everything sits behind org-level plans with usage tracking, rate limiting, and CI/CD integration via GitHub Actions or CLI.

Architecture Overview

The system is split into 5 layers:

Clients → Frontend & Auth → API Layer → Processing → Data & Providers

Clients

Three ways to interact with the platform:

Dashboard — Next.js web UI
CLI — built with Typer, talks to the API directly
Python SDK — async, built on httpx, with LangChain integration

Frontend & Auth

Next.js 15 + React + Tailwind + shadcn/ui
Clerk handles auth — JWT + JWKS, multi-tenant out of the box

Clerk was genuinely the right call here. Multi-tenancy with org-level access control would have taken weeks to build from scratch. Offloading that entirely let me focus on the actual product.

API Layer (FastAPI)

The backend is a FastAPI app with a middleware chain: CORS → Auth → Org Guard → Rate Limit, before any request hits a route.

Routes are grouped into: Suites, Runs, Red-Team, Agents, Reports, Billing, CI/CD, Keys.

SQLAlchemy 2.0 async with Pydantic validation throughout. The async SQLAlchemy shift was worth it — under load, the difference is noticeable.

Processing (Celery Workers)

This is where the interesting stuff happens. Three main workers, but before getting into what each does — why Celery at all?

LLM calls are slow. A single eval run might involve dozens of API calls to external providers, each taking 2–10 seconds. Doing that synchronously in a FastAPI request would mean holding HTTP connections open for minutes, timeouts everywhere, and zero visibility into progress. The answer is obvious: push the work onto a queue and process it asynchronously.

The architecture looks like this:

FastAPI → Redis (broker) → Celery Workers → PostgreSQL (results)
    ↑                                              ↓
    └─────────────── Status polling ───────────────┘

When a user triggers an eval run or a red-team campaign, FastAPI creates a DB record, pushes a task onto the Redis queue, and immediately returns a run_id to the client. The frontend polls for status updates. Workers pick up tasks, do the heavy lifting, and write results back to Postgres as they complete.

Redis here is doing double duty — it's both the Celery broker (task queue) and the result backend (where task state gets written). That's a deliberate choice to keep the infra footprint small rather than introducing a separate message broker.

Each worker type runs in its own Celery queue, so you can scale them independently:

Eval Runner — evalguard.eval queue

Test Case → LLM Call → Score

Test cases within a suite are fanned out as individual Celery tasks using group() so they run in parallel across workers. Results get aggregated back with a chord callback that writes the final suite summary once all cases complete. This means a 50-case eval suite doesn't run sequentially — it saturates however many workers you have.

from celery import group, chord
from app.tasks import run_test_case, finalize_eval_suite

# Fan out all test cases in parallel, aggregate when all complete
job = chord(
    group(
        run_test_case.s(case_id=case.id, run_id=run.id)
        for case in suite.test_cases
    ),
    finalize_eval_suite.s(run_id=run.id)
)

job.apply_async()

group() fires all test cases in parallel across available workers. chord() holds the finalize callback until every task in the group has a result — that's where pass/fail rates, aggregate scores, and the final run status get computed and written to Postgres.

Red-Team Runner — evalguard.redteam queue

Attack → Target → Judge → Risk

Red-team runs are more sequential by nature — generate attack, hit target, judge response, score risk — so these use Celery chains. Each attack prompt is its own chain, but multiple chains run concurrently across the queue. The judge step is where LLM-as-a-Judge fires, adding latency but also adding the signal that makes red-team results actually meaningful.

Report Generator — evalguard.reports queue

Query → Jinja2 → PDF

Separated into its own queue specifically so report generation never competes with eval or red-team capacity. Reports can be slow (big DB queries, PDF rendering) and you don't want one large report export starving active eval runs of workers.

Workers have graceful shutdown configured — on deploy or restart, Celery's SIGTERM handling lets in-flight tasks finish before the process exits. Without this, a worker restart mid-eval would silently drop results and leave runs stuck in a RUNNING state forever.

Core Services (inside Processing)

LiteLLM Router — unified interface across all providers. Swapping models is one config change.
Scorer Engine — 7 scoring metrics, composable per eval suite
LLM-as-a-Judge — secondary model evaluates target model responses for safety and accuracy
Attack Generator — uses an LLM to craft adversarial inputs from the target model's system prompt
Policy Engine — defines and enforces rules for agent monitoring

Data & Providers

PostgreSQL 16 — 12 tables, managed on Render
Redis 7 — task queue + rate limiting, managed on Render
Cloudflare R2 — report storage

The AI-Powered Parts

This is where EvalGuard gets self-referential in a fun way.

LLM-as-a-Judge

Static scoring (exact match, regex) only gets you so far. For safety evaluation especially, you need semantic understanding. EvalGuard uses a secondary LLM to evaluate whether the target model's response was actually safe and appropriate — not just syntactically correct.

The judge prompt is structured around the eval category. A PII leakage judge looks for different signals than a toxicity judge.

Dynamic Attack Generation

The 50+ static templates are a starting point, not a ceiling. Given a target model's system prompt, EvalGuard calls an LLM to generate novel adversarial inputs specific to that model's context. A customer support bot and a code assistant have completely different attack surfaces — the generator accounts for that.

Semantic Similarity Scoring

For cases where you want to measure how close an output is to an expected answer without requiring exact matches, EvalGuard uses sentence-transformers embeddings to compute cosine similarity. Useful for evaluating open-ended responses where wording varies but meaning should be consistent.

Deployment: Render Blueprint + Docker

The entire infra is defined in a render.yaml Blueprint file:

Frontend — Node web service
Backend — Docker web service
Workers — Docker background workers
PostgreSQL 16 — managed DB
Redis 7 — managed cache

Render spins all of this up from a single Blueprint deploy. The workers have graceful shutdown handling so in-flight Celery tasks don't get killed mid-run on deploys.

Huge thanks to Render here — the free hobby Postgres gave me a real month of building without worrying about infra costs, and the Blueprint + Docker combo meant I could focus on the actual product instead of YAML wrestling.

CLI & SDK

The Python SDK is async (httpx under the hood) with a LangChain integration for teams already in that ecosystem.

from evalguard import EvalGuardClient

client = EvalGuardClient(api_key="...")
run = await client.runs.create(suite_id="...", model="gpt-4o")
results = await run.wait()
print(results.summary())

The CLI is built with Typer and covers the full surface: trigger runs, pull results, manage keys, stream logs. Designed to drop into GitHub Actions without friction.

What I'd Do Differently

Async SQLAlchemy from day one. I started sync and migrated mid-build. It's not painful, but it's friction you don't need.

More investment in the Judge prompts earlier. The quality of LLM-as-a-Judge evaluations is almost entirely determined by how well the judge prompt is structured. I underestimated this.

Blueprint-first deployment. I set up the Render Blueprint after the fact. Defining infra as code from the start would have saved a few annoying debugging sessions.

What's Next

Open the red-team templates to community contributions
Deeper LangSmith / Langfuse integration
More agent tracing protocols

Not open-source at this point, but genuinely happy to talk architecture, design decisions, or anything LLM eval-related in the comments.

The hosted instance is paused right now to keep costs sane, but if you want a live walkthrough, drop a comment or DM me and I'll spin it back up.

Built this solo — backend, frontend, CLI, SDK, deployment, the whole stack. If you're building in the LLM evaluation or AI security space, I'd love to hear what you're working on.