[FEATURE]: Secure Gemini API Architecture & Prompt Injection Hardening

[vraj826]

Is your feature request related to a problem? Please describe.
Currently, the frontend exposes the Gemini API key using NEXT_PUBLIC_GEMINI_API_KEY, which bundles the credential into the client-side JavaScript and makes it visible through browser devtools/network inspection. This creates a critical security vulnerability where malicious users can abuse the API key, exhaust quotas, or perform unauthorized requests.

Additionally, custom prompts from .gitbunrc and CLI arguments are directly appended into the LLM prompt pipeline without sanitization, length validation, or injection boundaries, making the AI enhancement flow vulnerable to prompt injection and malformed instruction chaining.

---

Describe the solution you'd like
I would like to introduce a secure server-side AI architecture for the Next.js frontend and harden the LLM prompt pipeline.

Proposed improvements:

• Move Gemini inference to a secure Next.js API route (/api/generate)
• Replace NEXT_PUBLIC_GEMINI_API_KEY with a server-only GEMINI_API_KEY
• Refactor frontend AI calls to communicate only with the API route
• Add prompt sanitization and validation middleware
• Implement request throttling/rate limiting
• Add typed request-response validation using zod
• Ensure AI fallback handling remains intact

This change would improve security, maintainability, and production readiness while preventing credential leakage and prompt injection abuse.

---

Describe alternatives you've considered
Some smaller alternatives were considered:

• Simply obfuscating the frontend API key
• Adding frontend-only validation before Gemini requests
• Limiting prompt size without architectural changes

However, these approaches do not properly secure the API key because any NEXT_PUBLIC_* variable is still exposed to the browser bundle. A server-side proxy architecture is the most robust and scalable solution.

---

Additional context
Potential files affected:

frontend/src/lib/gemini.ts
frontend/src/lib/generateCommit.ts
frontend/src/app/api/generate/route.ts
src/llm/ollamaEnhancer.ts
src/config/loadConfig.ts

Additional enhancements that can be included:

• Prompt boundary enforcement
• Injection phrase filtering
• Request schema validation
• Cooldown handling for playground spam
• Better error handling and fallback states

This issue addresses both:

1. Critical frontend credential exposure
2. Unsafe prompt concatenation in the AI enhancement pipeline

[vraj826]

@nirvik34 I'll like to work on this issue under GSSoC'26, kindly assign this to me!

[vgudur-dev]

The "Injection phrase filtering" item in the additional enhancements is the right call — but a static phrase list will miss paraphrased and encoded variants. The OWASP Agent Memory Guard library adds a semantic scan layer that complements the zod schema validation already proposed:

// frontend/src/app/api/generate/route.ts
import { AgentMemoryGuard, TrustLevel, PolicyAction } from 'agent-memory-guard';

const guard = new AgentMemoryGuard();

export async function POST(req: Request) {
  const { prompt, config } = GenerateRequestSchema.parse(await req.json());

  // Scan user-supplied prompt (TrustLevel.USER)
  const promptScan = await guard.scan(prompt, { trustLevel: TrustLevel.USER });
  if (promptScan.action === PolicyAction.BLOCK) {
    return Response.json({ error: 'Input rejected', threat: promptScan.threatClass }, { status: 400 });
  }

  // Scan .gitbunrc config values (TrustLevel.EXTERNAL — file could be attacker-controlled)
  const configScan = await guard.scan(config.customPrompt, { trustLevel: TrustLevel.EXTERNAL });
  if (configScan.action === PolicyAction.BLOCK) {
    return Response.json({ error: 'Config rejected', threat: configScan.threatClass }, { status: 400 });
  }

  return callGemini(prompt, config);
}

The key distinction is that .gitbunrc values should be treated as TrustLevel.EXTERNAL (not USER) because the config file could be committed by a third party or modified by a supply-chain attack — this maps to OWASP Agentic Security Initiative ASI-06 (Persistent Context Poisoning via Config). The AgentThreatBench ATB-M01 through ATB-M03 corpus covers the paraphrase/encoding bypass cases that static phrase lists miss.