Security & Responsible Automation

ASL treats security as continuous risk reduction, not a marketing guarantee. This overview explains the current public website controls and the engineering principles used across projects. It is not a claim of certification, perfect security, or identical controls in every prototype.

Public website protections

• Encrypted transport: the public site is served over HTTPS, with HTTP redirected to HTTPS.
• Restrictive browser policy: content security, anti-framing, content-type, referrer, and browser-permission headers reduce common web attack paths.
• Limited contact endpoint: the form API listens only on the server’s loopback interface and is exposed through a narrow reverse-proxy route.
• Abuse controls: request-size limits, server-side field validation, a honeypot field, and per-address rate limiting help reduce automated form abuse.
• Service isolation: the contact service runs as a dedicated non-login account with system service restrictions and access only to the storage it needs.
• Secret separation: email-delivery credentials are stored outside the public web root in a restricted environment file and are never sent to the browser.
• Delivery resilience: a valid inquiry is recorded locally before optional email delivery is attempted, so a temporary email-provider failure does not silently discard the submission.
• Email scraping resistance: the public contact address is assembled only after a visitor interaction instead of appearing directly in the initial page source.

Authorization and consent

Permission is a design requirement. Automated actions should be tied to a known user, account, approved integration, verified recipient, or documented business purpose. The website’s optional phone field requires a separate, un-pre-checked SMS consent box. Consent is not required to submit an inquiry and mobile opt-in data is not sold, rented, or shared with third parties or affiliates for marketing or promotional purposes.

Least privilege and secret handling

Services and integrations should receive only the permissions required for their task. Production secrets belong in protected runtime configuration or a secret manager—not in browser code, public repositories, screenshots, or documentation. Test credentials are rotated before production use, and access should be removed when no longer needed.

Data minimization and retention

ASL aims to collect the smallest practical data set for the requested workflow. Projects should identify why each field is needed, who can access it, how long it remains useful, and how it can be corrected, exported, deleted, or suppressed where applicable. Sensitive data should not be reused for unrelated marketing.

Fail-closed behavior and human review

Automation can create harm when it guesses. Sensitive systems should stop when selectors change, authorization is uncertain, a destination cannot be verified, an external action has an ambiguous result, or an AI-generated conclusion lacks sufficient evidence. High-impact decisions and filings remain subject to appropriate human review.

AI transparency

AI output can be incomplete, biased, stale, or wrong. ASL products are designed to show uncertainty, evidence, provenance, and the distinction between generated assistance and authoritative information. AI-supported legal intake and complaint tools organize information; they do not provide legal advice, establish an attorney-client relationship, or make agency decisions.

Auditability and reliable operations

Where the workflow warrants it, systems use timestamps, status records, idempotency keys, delivery references, provenance, and structured logs. Deployments emphasize health checks, service supervision, configuration validation, backups, release verification, and rollback planning. Logs should help explain what happened without printing passwords, API keys, or unnecessarily sensitive content.

Third-party services

Some projects rely on cloud, messaging, email, payment, AI, telecom, research, or platform providers. Each dependency adds availability, privacy, security, and policy risk. Integrations are scoped to the project, configured with the least practical access, and reviewed when a provider’s terms, interface, or behavior changes.

Security limitations

No website or application can guarantee that every attack, outage, vendor failure, or human mistake will be prevented. Security controls evolve with the product. Features described on this site may be prototypes, pilots, or active development and may not all use the same architecture.

Report a security concern

Please use the secure inquiry form and place Security report in the subject line. Include the affected page or project, a clear description, reproducible steps, and the potential impact. Do not access data that is not yours, disrupt services, use social engineering, or publicly disclose an unresolved issue before ASL has a reasonable opportunity to investigate.