LAWDE Shield

Security Policy

Last updated: July 2026

Security is the foundation of LAWDE Shield.

Our architecture is intentionally designed around minimizing trust requirements rather than asking customers to trust marketing claims.

Our engineering philosophy is based on four principles:

  • Collect less.
  • Store less.
  • Request fewer permissions.
  • Verify everything.

LAWDE Shield connects to GitHub using a least-privilege GitHub App.

Repository contents remain read-only (contents:read). Athena PR analysis may post a single review comment (pull_requests:write) and read CI (checks:read, actions:read). LAWDE Shield does not request contents-write, push, or merge permissions.

LAWDE Shield is designed around a Zero Code Retention architecture.

When repository context is required for analysis, code is intended to be processed in volatile memory and not permanently retained as part of normal platform operation.

Developers remain in control.

Repositories may define a `.lawdeignore` file to exclude specific files or directories from AI-assisted analysis.

If a restricted file appears in an execution path, LAWDE Shield is designed to halt automated analysis rather than bypass those restrictions.

Workspace data is isolated using PostgreSQL Row Level Security (RLS).

Each workspace can only access its own resources.

Connections to LAWDE Shield are encrypted using HTTPS/TLS.

Sensitive credentials are stored using industry-standard security practices.

AI-generated analyses are validated before presentation.

Low-confidence analyses may be withheld in favor of deterministic debugging information.

AI never controls repository access or routing logic.

Depending on enabled features, LAWDE Shield may use providers including:

  • Supabase
  • Vercel
  • GitHub
  • OpenAI
  • Anthropic
  • Paystack

If you discover a security vulnerability, please report it through our Responsible Disclosure Policy.

We appreciate responsible security research and will investigate all legitimate reports.

support@lawde.net