Cybersecurity for Legal Aid: A Working Threat Model

Legal aid clinics handle sensitive client data subject to privilege, attorney-client confidentiality, and certain regulatory regimes. This article walks through a working threat model for legal aid clinics deploying AI.

Threat model components

A working threat model identifies:

1. Threat actors (who has incentive to attack)
2. Attack surfaces (where attacks originate)
3. Vulnerabilities (weak points in defenses)
4. Threats (specific attack scenarios)
5. Impact (severity per scenario)
6. Likelihood (probability)
7. Mitigations (controls that reduce likelihood or impact)

Threat actors

For a legal aid clinic:

• Nation-state actors: rare target; sophisticated client matters may draw attention.
• Organized crime: financial and identity data in eviction / consumer / family cases.
• Insider risk: former employees; lax permissions.
• Hacktivists: politically charged cases (immigration, criminal defense) can attract attention.
• Opposing parties: civil cases; subpoenas and discovery.
• Subpoena / court order: data could be compelled.

Attack surfaces

• Public-facing AI portal
• Internal lawyer-portal access
• LLM API endpoints
• Database backups
• Audit logs
• Vendor access (third-party LLM providers)
• Insider user devices

Common vulnerabilities

From observed legal aid clinic security audits (2024):

• Default credentials on internal tools
• Lack of MFA on portal admin accounts
• Unencrypted backups
• Vendor-tool API keys stored in source code
• PII in logs without redaction
• Audit logs missing (or removed to save storage costs)
• Unpatched dependencies in AI agents

Threats and mitigations

T1: Credential stuffing on portal

Likelihood: high.

Mitigations:

• MFA mandatory.
• Account lockout after 5 failed attempts.
• Rate limiting on auth endpoints.
• Bot detection (turnstile, reCAPTCHA).

T2: LLM prompt injection from user input

Likelihood: high.

Mitigations:

• Sanitize user input.
• Use system prompt to constrain LLM behavior.
• Apply adversarial input detection.
• Log suspicious inputs for review.

T3: LLM data exfiltration from model

Likelihood: medium.

Mitigations:

• Self-hosted open-source models on private infrastructure for sensitive workloads.
• Use BAA cloud endpoints where self-hosting isn't viable.
• Avoid consumer-tier AI endpoints for sensitive data.
• Strict access controls on internal model artifacts.

T4: PII in audit logs

Likelihood: high.

Mitigations:

• Strip PII before logging.
• Use hashed identifiers.
• Encryption at rest for log storage.
• Audit log retention policy.

T5: Vendor compromise

Likelihood: medium-low (depends on vendor).

Mitigations:

• Multiple vendors (avoid single-vendor lock-in).
• Continuous monitoring of vendor security advisories.
• SOC 2 Type II vendor compliance review annually.
• Self-hosted alternatives for critical workloads.

T6: Backup exposure

Likelihood: medium.

Mitigations:

• Encryption at rest.
• Restricted access to backup credentials.
• Test backups for restoration.
• Backup lifecycle: encrypted, transit-restricted.

Recommended security stack

For a mid-size legal aid clinic:

• Frontend: Next.js, TypeScript, OWASP-compliant security headers
• Backend: Node.js or Python with OWASP Top 10 mitigations
• AI: Self-hosted Llama 3.3 70B with pgvector
• Database: PostgreSQL with encrypted backups
• Auth: Okta or Authentik with MFA
• Audit: append-only log with daily offsite backup
• Monitoring: Snyk + Datadog

Compliance mapping

• NIST 800-53 Rev 5 (federal baseline)
• HIPAA Privacy Rule (where health data is involved)
• State bar opinions on confidentiality
• Cyber insurance requirements (annual audit often required)

Acknowledgments

This article summarizes public sources as of early 2026. Specific deployments vary by clinic scope.

Dillon Deutsch has worked with legal aid clinics on security audits. https://courtgpt.ai