KAEL combines generated output, persistent state, identity, external integrations, and permissioned tools. Safety therefore depends on access control and system design—not only model prompting.

| Field | Value |

|---|---|

| Documentation status | Active |

| Applies to | KAEL clients, API integrations, operators, and tenants |

| Last source review | 2026-06-26 |

1. The server calculates clearance; clients do not grant it.

2. Operator tokens, tenant keys, provider keys, cookies, and webhook secrets never belong in public code.

3. Tool access must be narrower than conversational access.

4. A generated statement is not proof that an action occurred.

5. Destructive or external actions require explicit authorization and auditable results.

6. Users need controls for history and memory.

KAEL can use anonymous identity, authenticated identity, Passport data, ARM memberships, invites, tenants, and operator records to determine access.

Clearance can affect:

- Daily message limits.

- Available models.

- Available tools.

- Access to persistent context.

- Operator-only endpoints.

Do not reproduce clearance logic in a client as an authorization boundary.

Untrusted text—including webpages, user messages, uploaded files, Discord messages, and retrieved documents—must be treated as data. It must not silently override tool policies or operator authorization.

Tool implementations should validate:

- The resolved identity.

- The required clearance.

- Arguments and target resources.

- Whether the action is read-only or mutating.

- Whether confirmation is required.

- Store only data needed for a user-facing feature.

- Avoid secrets and high-risk personal data.

- Keep signed-in and visitor-scoped memory separate.

- Expose deletion controls.

- Do not show one user’s memory or history to another.

- Verify Discord interaction signatures.

- Verify deployment webhook HMAC signatures.

- Restrict CORS to intended browser origins for credentialed requests.

- Rate-limit authentication, chat, agent, and webhook surfaces.

- Log authorization failures without logging credentials.

If a credential appears in source, logs, screenshots, or documentation:

1. Revoke or rotate it at the provider.

2. Remove it from active configuration and repository history.

3. Review access logs and affected actions.

4. Replace it with an environment or secret-manager reference.

5. Document the incident without reproducing the secret.

Report suspected security issues through [aethex.support](https://aethex.support). Do not post active credentials in Discord or a public issue.