Privacy Agent

Every day, developers ship privacy violations without knowing it.

A social security number hardcoded at line 16. A password logged in plaintext at line 43. Medical data exposed in an error message at line 57. None of it malicious. All of it invisible.

There are 28.7 million developers writing code. There are 50,000 privacy engineers in the world. That's a 574:1 ratio — meaning for every privacy professional, 574 developers are shipping code that will never get a privacy review.

Privacy Agent fixes that. One @mention in any GitLab issue or merge request. No setup. No new tools. No privacy expertise required.

The agent scans the entire repository, identifies violations across GDPR, CCPA, HIPAA, and 5 other jurisdictions, creates tracked vulnerability issues with copy-paste fixes, generates a full compliance report with real dollar fine estimates, and posts inline comments on merge requests — all before the code ships.

This is what changes for developers: violations are caught at line 16, not in a breach notification letter.

Inspiration

There are 28.7 million developers writing code today. There are roughly 50,000 privacy engineers in the world. That's a 574:1 ratio, meaning for every privacy professional, 574 developers are shipping code that will never get a privacy review.

Privacy violations aren't usually malicious. They're invisible. A social security number hardcoded in a config file. Medical data showing up in application logs. An API returning credit card numbers when only a username was needed. Developers aren't privacy lawyers. They're moving fast, shipping features, and privacy compliance is a different language most of them were never taught.

The result: the average data breach costs $4.88M. GDPR fines have exceeded €4.9B since 2018. And 83% of breaches involve human error, code that a privacy review would have caught.

I built Privacy Agent because I've spent 12+ years as a privacy engineer at Microsoft, Uber, and Remitly watching this problem compound in every codebase I've ever touched. There has never been a tool that meets developers where they already work, inside GitLab, and speaks their language instead of the lawyer's.

What it does

Privacy Agent is a two-step GitLab Duo AI flow powered by Anthropic Claude. Triggered by a single @mention in any GitLab issue or merge request, it:

Scans the entire repository autonomously, surveying repo structure, grepping for PII patterns, and doing deep reads only on files with actual hits across Java, Python, JavaScript, SQL, configuration files, and any text-based file
Detects 10 categories of privacy violations: hardcoded PII and secrets, GDPR violations, CCPA/CPRA violations, multi-jurisdiction issues (HIPAA, COPPA, LGPD, PIPL, PIPEDA), Privacy by Design failures, API data flow issues, database storage problems, AI/ML-specific risks, consent issues, and third-party supply chain risks
Reports with surgical precision. Every finding includes the exact vulnerable code, a copy-paste-ready fix, the specific regulatory article violated, a real dollar fine estimate across 8 jurisdictions, and the human impact on data subjects
Takes action automatically, creating individual vulnerability issues for every CRITICAL finding with severity labels, generating a full audit report issue with complete JSON findings and total fine exposure, and posting an inline comment on merge requests with a severity table and top findings
Stops itself using loop prevention logic that detects when the flow was triggered by its own output and stops immediately, preventing runaway compute cycles

Privacy Agent reacts to GitLab events, takes autonomous action, and produces real artifacts — vulnerability issues, audit reports, and MR comments — without any human intervention after the trigger.

⚡ How to Trigger It

Privacy Agent is triggered by GitLab's native event system. No setup required.

From any GitLab Issue:

@ai-privacy-agent-flow-gitlab-ai-hackathon

Please scan the tests/ folder in this project for privacy violations:
gitlab.com/gitlab-ai-hackathon/participants/28441126

From any Merge Request comment:

@ai-privacy-agent-flow-gitlab-ai-hackathon

Please scan this merge request for privacy violations and post findings
as inline comments.

That's it. One @mention is the entire user interface. No CLI. No configuration files. No new dashboards. Privacy Agent lives where developers already work.

What fires automatically after the trigger:

repo_scanner surveys the repo, greps for PII patterns, reads suspicious files
violation_reporter creates vulnerability issues, audit report, and MR comment
Loop prevention stops the flow from re-triggering on its own output

🤖 Why This Qualifies for the GitLab & Anthropic Prize

Privacy Agent is built entirely on the GitLab Duo Agent Platform with Anthropic Claude as the core reasoning engine. This is not incidental — Claude is what makes the product possible.

The technical stack

Layer	Technology
Agent Platform	GitLab Duo Agent Platform (flow.yml + agent.yml)
AI Model	Anthropic Claude (via GitLab Duo)
Orchestration	GitLab Flows — two-step AgentComponent pipeline
Trigger	GitLab native event system (@mention in issues and MRs)
Output	Native GitLab artifacts (issues, vulnerability issues, MR comments)

Why Claude specifically — not just any LLM

A rule-based scanner can pattern-match for password= with a regex. Only Claude can:

Connect invisible code patterns to specific laws:

cache.set("session:" + userId, sessionToken)
// No PII visible — but Claude identifies this as a GDPR Article 5
// storage limitation violation because there is no TTL argument

Understand structural violations, not just surface patterns:

database.execute("UPDATE users SET deleted=1 WHERE id=" + userId)
// No sensitive data in this line — but Claude recognizes this
// soft-delete pattern fails the GDPR Article 17 right-to-erasure requirement

Reason across 8 jurisdictions simultaneously: A single finding triggers Claude to evaluate GDPR Tier 1 vs Tier 2, CCPA intentional vs unintentional, HIPAA culpability tier, and COPPA applicability — producing jurisdiction-specific fine estimates with the exact regulatory article and calculation basis for each.

Produce idiomatic fixes in any language: The fix for a Java violation uses Java idioms. The fix for a Python violation uses Python idioms. The fix for a SQL migration uses SQL. Claude understands the language context, not just the pattern.

This is not a wrapper around a regex engine

This is Claude executing privacy law and secure coding simultaneously, embedded directly in the GitLab SDLC — triggered automatically, taking real action, producing real GitLab artifacts.

The GitLab Duo Agent Platform + Anthropic Claude combination is not a convenience choice. It is the only technical stack that makes this level of legal and technical reasoning possible inside a developer workflow.

📄 Sample Agent Output

Privacy Agent returns a structured JSON report for every violation found. Here is a real example from scanning tests/UserService.java:

[
  {
    "file": "tests/UserService.java",
    "line": 17,
    "type": "Hardcoded PII - Social Security Number",
    "severity": "CRITICAL",
    "description": "Social Security Number (SSN) hardcoded directly in source code as a constant. SSNs are highly sensitive PII under GDPR Article 9 (special category data) and constitute a direct breach risk if source code is exposed through repository access, logs, or version control history.",
    "vulnerableCode": "private static final String DEFAULT_SSN = \"123-45-6789\";",
    "exactFix": {
      "summary": "Remove hardcoded SSN and retrieve from secure environment variable or secrets manager",
      "codeChange": "private static final String DEFAULT_SSN = System.getenv(\"DEFAULT_SSN\");",
      "infrastructureNote": "Store SSN in AWS Secrets Manager, HashiCorp Vault, or GitLab CI/CD masked variables. Never commit actual SSN values to version control.",
      "dependencies": null
    },
    "explanation": "Retrieving the SSN from environment variables ensures it is never committed to source code. The actual value should be stored in a secrets management system with access controls, audit logging, and encryption at rest.",
    "relevantLaw": "GDPR Article 9 (Processing of special categories of personal data), GDPR Article 32 (Security of processing)",
    "dataSubjectImpact": "If this SSN represents a real individual, exposure could enable identity theft, fraudulent credit applications, tax fraud, and medical identity theft. The individual would face years of credit repair and potential financial losses.",
    "estimatedFine": {
      "range": "€20M or 4% of global annual revenue (GDPR Tier 2)",
      "basis": "GDPR Article 83(5)(a) - violation of Article 9 (special category data without adequate safeguards)",
      "calculationNote": "Tier 2 fine applies because SSNs are special category data under Article 9. Actual fine depends on number of affected individuals, whether SSN is real or test data, and whether breach occurred."
    }
  },
  {
    "file": "tests/UserService.java",
    "line": 20,
    "type": "Hardcoded PII - Credit Card Number",
    "severity": "CRITICAL",
    "description": "Credit card number hardcoded in source code. Even though this appears to be a test card number (Visa test card format), hardcoding payment card data violates PCI-DSS requirements and creates a pattern that could be replicated with real card data.",
    "vulnerableCode": "private static final String TEST_CARD = \"4111-1111-1111-1111\";",
    "exactFix": {
      "summary": "Remove hardcoded card number and use tokenized reference or environment variable",
      "codeChange": "private static final String TEST_CARD = System.getenv(\"TEST_CARD_TOKEN\");",
      "infrastructureNote": "Use payment processor's test mode with tokenized card references. For production, implement PCI-DSS compliant tokenization via Stripe, Braintree, or similar.",
      "dependencies": null
    },
    "explanation": "Payment card data must never appear in source code. Use tokenization services that return non-sensitive tokens. Even test card numbers establish dangerous coding patterns.",
    "relevantLaw": "PCI-DSS Requirement 3.2 (Do not store sensitive authentication data after authorization), GDPR Article 32 (Security of processing)",
    "dataSubjectImpact": "If real card data were substituted using this pattern, cardholders would face unauthorized charges, account takeover, and fraudulent purchases. Financial institutions would need to reissue cards.",
    "estimatedFine": {
      "range": "$5,000-$100,000 per month of non-compliance (PCI-DSS) + €20M or 4% revenue (GDPR)",
      "basis": "PCI-DSS violation penalties + GDPR Article 83(5)(a)",
      "calculationNote": "PCI-DSS fines are assessed by payment brands. GDPR applies if EU cardholder data is involved. Combined exposure can exceed $500K for small breaches."
    }
  }
]

Every finding in the report includes:

Field	What It Contains
`file`	Exact file path where the violation was found
`line`	Line number of the vulnerable code
`type`	Violation category and specific subtype
`severity`	CRITICAL / HIGH / MEDIUM / LOW
`description`	Detailed explanation of why this is a violation
`vulnerableCode`	The exact offending line copied from the file
`exactFix.codeChange`	Copy-paste replacement code
`exactFix.infrastructureNote`	Environment setup required
`relevantLaw`	Specific regulatory article violated
`dataSubjectImpact`	How this affects real people
`estimatedFine.range`	Dollar fine range across jurisdictions
`estimatedFine.calculationNote`	How the fine was calculated

When Privacy Agent completes a scan, it automatically creates three things:

A full audit report: a new GitLab issue with complete JSON findings, severity table, and total fine exposure
Individual vulnerability issues — one per CRITICAL finding, with severity labels and copy-paste fixes
A summary comment posted on the triggering issue linking back to the audit report

📊 Sample Audit Report — What Gets Created in GitLab

When Privacy Agent completes a scan it automatically creates a new GitLab issue containing the full audit report. Here is a real example generated from scanning tests/UserService.java:

Issue Title: Privacy Audit Report — violations found

Labels: privacy compliance audit

Severity Summary

Severity	Count
🔴 CRITICAL	6
🟠 HIGH	2
🟡 MEDIUM	0
🟢 LOW	0

Total estimated fine exposure:

GDPR: €20M or 4% global revenue (maximum tier)
PCI-DSS: $5,000 - $500,000 per month of non-compliance
GLBA / HIPAA: $100 - $50,000 per violation
CCPA: $2,500 - $7,500 per consumer

🔴 CRITICAL Findings (6)

1. Hardcoded PII - Social Security Number tests/UserService.java · Line 18

private static final String DEFAULT_SSN = "123-45-6789";

Fix:

// SSN removed - use test data factories with synthetic values in test environments only

Infrastructure Note: Use faker libraries (e.g., JavaFaker) to generate synthetic SSNs. Dependencies: com.github.javafaker:javafaker:1.0.2 (test scope only) Law: GDPR Article 9 (Special Categories), 15 U.S.C. § 6801-6809 (GLBA), CCPA § 1798.140(o)(1)(A) Impact: Exposed SSN enables identity theft, fraudulent credit applications, tax fraud, and medical identity theft. Fine: €20M or 4% global revenue (GDPR); $100-$50,000 per violation (GLBA)

2. Hardcoded PII - Credit Card Number tests/UserService.java · Line 21

private static final String TEST_CARD = "4111-1111-1111-1111";

Fix:

// Credit card removed - use payment gateway test tokens in sandbox environments

Infrastructure Note: Use Stripe test mode tokens (tok_visa) or payment gateway sandbox credentials. Law: PCI-DSS Requirement 3.2, 3.4; GDPR Article 32; CCPA § 1798.150 Impact: Exposed credit card enables unauthorized purchases, account takeover, and financial fraud. Fine: $5,000-$500,000 per month (PCI-DSS); €20M or 4% revenue (GDPR); $100-$750 per consumer (CCPA)

3. Hardcoded Secret - Live API Key tests/UserService.java · Line 24

private static final String STRIPE_API_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc";

Fix:

private static final String STRIPE_API_KEY = System.getenv("STRIPE_API_KEY");

Infrastructure Note: Immediately revoke sk_live_4eC39HqLyjWDarjtT1zdp7dc in Stripe dashboard. Store new key in AWS Secrets Manager or HashiCorp Vault. Rotate quarterly. Law: GDPR Article 32(1)(b); SOC 2 CC6.1; PCI-DSS Requirement 8.2.1 Impact: Compromised payment API enables unauthorized charges, data exfiltration, and financial fraud at scale. Fine: €10M or 2% global revenue (GDPR); $100-$50,000 per affected consumer

4. Hardcoded Secret - Database Password tests/UserService.java · Line 27

private static final String DB_PASSWORD = "Sup3rS3cr3tPassw0rd!";

Fix:

private static final String DB_PASSWORD = System.getenv("DB_PASSWORD");

Infrastructure Note: Rotate database password immediately. Store in secrets manager. Use IAM database authentication where possible. Enable audit logging. Law: GDPR Article 32(1); HIPAA § 164.312(a)(2)(i); SOC 2 CC6.1 Impact: Database compromise exposes all user PII, enabling identity theft, account takeover, and dark web data sales. Fine: €20M or 4% global revenue (GDPR); $100-$50,000 per record (HIPAA); $2,500-$7,500 per consumer (CCPA)

5. Privacy by Design - Password Logging tests/UserService.java · Line 43

logger.info("Login attempt: username=" + username + " password=" + password);

Fix:

logger.info("Login attempt: username=" + username);

Infrastructure Note: Audit existing logs for password exposure and purge. Implement log scrubbing rules. Use structured logging with field-level controls. Law: GDPR Article 32(1); NIST SP 800-63B § 5.1.1.2; OWASP Top 10 A09:2021 Impact: Logged passwords enable account takeover, credential stuffing, and identity theft across services. Fine: €20M or 4% global revenue (GDPR); $100-$50,000 per violation (HIPAA); $2,500-$7,500 per consumer (CCPA)

6. Privacy by Design - SSN and Name Logging tests/UserService.java · Line 48

logger.info("Processing user SSN: " + ssn + " name: " + name);

Fix:

logger.info("Processing user ID: " + userId);

Infrastructure Note: Replace all PII in logs with pseudonymous identifiers (UUID, hashed ID). Implement log redaction policies. Limit log retention to 30-90 days. Law: GDPR Article 9 (special categories), Article 25 (privacy by design); 15 U.S.C. § 6801 (GLBA); CCPA § 1798.100(c) Impact: Combined SSN and name exposure enables credit fraud, tax fraud, medical identity theft, and full identity takeover. Fine: €20M or 4% global revenue (GDPR); $100-$50,000 per violation (GLBA); $2,500-$7,500 per consumer (CCPA)

🟠 HIGH Findings (2)

7. Hardcoded PII - Real Email Address tests/UserService.java · Line 30

private static final String ADMIN_EMAIL = "john.smith@company.com";

Fix:

private static final String ADMIN_EMAIL = System.getenv("ADMIN_EMAIL");

Infrastructure Note: Store admin email in environment variable. For tests, use example.com domain (RFC 2606 reserved for testing). Law: GDPR Article 4(1), Article 5(1)(c) (data minimization); CCPA § 1798.140(o)(1)(A) Impact: Exposed admin email enables targeted phishing, social engineering, and spam against the named individual. Fine: €10M or 2% global revenue (GDPR); $2,500-$7,500 per violation (CCPA)

8. Privacy by Design - PII in Error Messages tests/UserService.java · Line 56

throw new RuntimeException("Failed to find user with email: " + email + " SSN: " + DEFAULT_SSN);

Fix:

String correlationId = UUID.randomUUID().toString();
logger.error("User lookup failed. Correlation ID: " + correlationId);
throw new RuntimeException("User lookup failed. Reference: " + correlationId);

Infrastructure Note: Map correlation ID to PII only in secure audit log. Never expose PII in user-facing error messages or stack traces. Dependencies: java.util.UUID Law: GDPR Article 5(1)(c) (data minimization), Article 32; CCPA § 1798.100(c) Impact: Exception messages appear in stack traces, error monitoring systems, and user interfaces creating uncontrolled PII exposure. Fine: €10M or 2% global revenue (GDPR); $2,500-$7,500 per violation (CCPA)

This report was generated automatically by Privacy Agent. Triggered by: @ai-privacy-agent-flow-gitlab-ai-hackathon Full JSON findings available in the linked audit report issue.

🐛 Vulnerability Issues — What Gets Created in GitLab

For every CRITICAL finding, Privacy Agent automatically creates a tracked GitLab issue with this structure:

Issue Title: 🔴 CRITICAL: Privacy by Design - SSN and Name Logging (tests/UserService.java Line 48)

Labels: CRITICAL privacy compliance security

Issue Body:

Vulnerability Details

Field	Value
File	`tests/UserService.java`
Line	48
Severity	CRITICAL

Vulnerable Code

logger.info("Processing user SSN: " + ssn + " name: " + name);

Description

Social Security Number and full name logged together, creating high identity theft risk. SSN is special category data under GDPR Article 9. Logging PII violates data minimization and creates unnecessary breach surface.

Fix Required

Remove PII from logs — use pseudonymous user ID only:

logger.info("Processing user ID: " + userId);

Infrastructure Note: Replace all PII in logs with pseudonymous identifiers (UUID, hashed ID). Implement log redaction policies. Limit log retention to 30-90 days.

Legal Compliance

Relevant Law: GDPR Article 9 (special categories), Article 25 (data protection by design); 15 U.S.C. § 6801 (GLBA); CCPA § 1798.100(c)

Data Subject Impact: Combined SSN and name exposure enables opening credit accounts, filing fraudulent tax returns, obtaining medical services, and full identity takeover.

Estimated Fine

Regulation	Exposure
GDPR	€20M or 4% global revenue
GLBA	$100 - $50,000 per violation
CCPA	$2,500 - $7,500 per consumer

Basis: GDPR Article 83(5)(a) - special category data without legal basis; GLBA § 501(b); CCPA § 1798.155(b)

Every vulnerability issue is:

Automatically created — no human intervention required
Individually tracked — each CRITICAL finding gets its own issue
Labeled and assignable — fits directly into existing GitLab sprint workflows
Linked to the full audit report — complete JSON findings one click away
Closeable — developers mark resolved when fix is merged

How we built it

Privacy Agent is built entirely on the GitLab Duo Agent Platform using two chained AgentComponent instances in a flow.yml:

Step 1 : repo_scanner uses 7 tools (list_repository_tree, find_files, grep, read_file, read_files, list_dir, gitlab_blob_search) with a carefully engineered system prompt that encodes 10 violation categories, false positive rules, a fine reference table for 8 jurisdictions, and a structured JSON output schema with fields for file, line, severity, vulnerable code, exact fix, regulatory citation, fine estimate, and data subject impact.

Step 2 : violation_reporter receives the scanner's output via context:repo_scanner.final_answer using the GitLab Flows from/as context handoff syntax, then uses 4 tools (create_issue, create_vulnerability_issue, create_merge_request_note, create_issue_note) to create all GitLab artifacts.

The flow is triggered by GitLab's event system via @mention in issue comments, MR comments, or reviewer assignment. The underlying AI reasoning is Anthropic Claude running through GitLab Duo, which provides the legal reasoning depth needed to connect code patterns to regulatory violations, something no rule-based scanner can do.

Challenges we ran into

1. The context handoff problem Getting output from Step 1 to Step 2 required discovering the correct from/as syntax:

from: "context:repo_scanner.final_answer"
as: "scan_results"

The GitLab Flows documentation didn't make this obvious. It took a bit of trial error to get it right.

2. The infinite loop problem When the reporter created GitLab issues, those issues triggered the flow again, creating an infinite loop of audit reports. The fix was adding loop prevention logic to both prompts, checking the goal for keywords like "Privacy Audit Report" and stopping immediately if detected.

3. The timeout problem The reporter was trying to create 10+ vulnerability issues sequentially, hitting the 180-second timeout mid-execution. The fix was increasing timeouts to 360 seconds and capping vulnerability issues at 10 per run.

4. False positives Early versions flagged function parameters named userEmail and placeholder strings like test-at-example.com as violations. Engineering explicit false positive rules into the prompt resolved this without sacrificing detection accuracy on real violations.

5. JSON readability The exactFix.codeChange field was rendering as a single escaped string in raw JSON. Restructuring exactFix as a nested object with separate codeChange, infrastructureNote, and dependencies fields made it human-readable without post-processing.

Accomplishments that we're proud of

1. It actually works The flow correctly identifies 15 privacy violations across 5 test files, produces severity-ranked JSON with exact code fixes, creates individual vulnerability issues with proper labels, generates a full audit report, and posts inline MR comments, all from a single @mention.

2. Claude does real legal reasoning The agent correctly identifies that cache.set("session:" + userId, sessionToken) without a TTL argument violates GDPR Article 5 storage limitation, even though there's no PII visible in that line. That's not pattern matching. That's understanding what the code does and applying privacy law to it.

3. Zero false positives on the test suite The agent correctly ignores function parameters named userEmail, placeholder strings like test-at-example.com, and regex validators, flagging only actual hardcoded PII values.

4. The fine estimates are real Every finding includes jurisdiction-specific dollar estimates with the specific regulatory article, tier, and calculation basis. A CCPA violation affecting 100,000 users shows $750M in potential exposure. That's what gets a CFO to pay attention.

5. Built in under 24 hours From first prompt to working flow with loop prevention, file path tracking, and multi-step context handoff.

What we learned

1. Prompt engineering for legal reasoning is a different discipline Getting Claude to reliably connect code patterns to specific regulatory articles required encoding the full fine reference table, explicit false positive rules, and structured output schemas directly in the system prompt. Vague instructions produced inconsistent results. Precise legal schemas produced consistent ones.

2. GitLab Flows context handoff is non-obvious The from/as syntax for passing output between AgentComponents is not prominently documented. This was the single most impactful discovery in the entire build. Without it, Step 2 never received Step 1's findings.

3. Loop prevention is not optional for event-driven agents Any agent that creates GitLab artifacts will trigger itself again unless it explicitly checks whether it was triggered by its own output. This should be a default consideration for every flow that writes to GitLab.

4. Grep-first is dramatically more efficient than read-first Scanning for high-signal patterns before doing full file reads reduced unnecessary LLM calls by approximately 70% on clean codebases. The order of operations matters enormously for both cost and latency.

5. Claude's depth is the product The most impressive findings weren't hardcoded SSNs, those any regex could catch. They were structural violations: soft-delete patterns that violate right-to-erasure, session caches without TTL that violate storage limitation, training data arrays that create model memorization risk. Only a model that understands both code and law simultaneously can find those.

What's next for Privacy Agent

1. CI/CD pipeline integration A GitLab CI job that runs Privacy Agent on every push and blocks merge if CRITICAL violations are found, bringing privacy gates into the standard pipeline workflow.

2. Auto-remediation For well-understood violation patterns (hardcoded secrets, PII in logs), automatically commit the fix to a new branch and open a merge request, removing the human step entirely.

3. Privacy debt dashboard A GitLab wiki page that tracks violation trends over time, showing whether a codebase is getting more or less private with each sprint.

4. Enterprise repo sweep Extend gitlab_blob_search to scan across entire GitLab groups and organizations, enabling a single trigger to audit all repositories in a company.

5. Privacy License integration Connect findings directly to Privacy License's AI Privacy License protocol, automatically generating machine-readable data governance attestations for repositories that pass the audit, turning a compliance scan into a verifiable privacy credential.

6. Regulation updates As new regulations pass (EU AI Act Article 53 enforcement, US federal privacy law), update the detection engine to cover new violation categories without changing the underlying flow architecture.

Built With

claude
gitlabcicd
gitlabcustomagents
gitlabduoagentplatform
gitlabflows
gitlabgraphapi
gitlabrestapi
java
javascript
python
sql
yaml

Inspiration

What it does

⚡ How to Trigger It

🤖 Why This Qualifies for the GitLab & Anthropic Prize

The technical stack

Why Claude specifically — not just any LLM

This is not a wrapper around a regex engine

📄 Sample Agent Output

📊 Sample Audit Report — What Gets Created in GitLab

Severity Summary

🔴 CRITICAL Findings (6)

🟠 HIGH Findings (2)

🐛 Vulnerability Issues — What Gets Created in GitLab

Vulnerability Details

Vulnerable Code

Description

Fix Required

Legal Compliance

Estimated Fine

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Privacy Agent

Built With

Updates