Source status: no status is stated in the source document, so none is assigned here. Do not treat this page as a finalized specification. The normative rules are in the Technical Specification.

Security and Trust Boundaries¶

The language will treat external data and code as untrusted until explicitly validated.

1. Input Safety¶

External input must be validated before use.
Untrusted data must retain its untrusted status until validated.
Unsafe conversions must be explicitly authorized.
Database queries and system commands must use safe interfaces.

2. Authorization¶

Access to protected resources requires explicit permissions.
Permissions must follow least-privilege principles.
Authorization checks must occur before protected operations.
Privileged operations must be clearly identifiable.

3. Trust Boundaries¶

External APIs, files, user input, and third-party modules are untrusted by default.
Trust must not transfer automatically between modules.
Data validation must be explicit and verifiable.
Security-sensitive operations must declare their requirements.

4. Information Protection¶

Sensitive values should have identifiable types.
Secret values must not be accidentally exposed through logs or error messages.
Data access should be restricted by declared permissions.
Unsafe handling of sensitive data should trigger compiler warnings or errors.

5. Security Verification¶

The compiler must enforce declared security constraints.
Static analysis should identify common vulnerabilities.
Runtime checks must protect boundaries that cannot be verified statically.

Design Goal¶

AI agents should not be able to accidentally bypass security boundaries through unsafe assumptions, undeclared permissions, or improper handling of untrusted data.

Source and authority¶

This page migrates SECURITY.md in full. It is an explanatory / implementation document, not the normative specification. Where it simplifies a rule, the Technical Specification governs. The original file is preserved in source-original/LANG/.