Trust & security

A security tool has to be built like one

AEGIS holds a position of trust in the communities it protects, so it is designed against a written threat model, keeps privacy-conscious data defaults, and documents its residual risks instead of hiding them. Here is how that works — including what AEGIS deliberately does not claim.

Threat-model highlights

A selection from the full threat model, covering the assets that matter most: guild safety state, evidence, audit integrity, tokens, and sessions.

Threats and their implemented mitigations
ThreatMitigation (implemented)
Stolen dashboard sessionSessions are opaque 256-bit tokens stored hashed; HttpOnly/Secure/SameSite cookies; revocation and logout-everywhere; logins and logouts audited with session metadata.
Compromised staff accountAnti-nuke budgets apply to staff too; responses can strip dangerous roles or quarantine the actor; owner approval is the default budget for admin grants.
Malicious moderatorLeast-privilege RBAC; hierarchy checks block acting on equal or higher ranks and protected staff; every action is cased and audited; separation of duties on reversals and appeals.
Cross-site request forgery (CSRF)Origin/Referer checks on all cookie-authenticated mutations; single-use, short-TTL OAuth state; SameSite=Lax cookies.
Injection (SQL / XSS)Parameterized queries exclusively with schema validation on inputs; React auto-escaping with a restrictive Content-Security-Policy and no raw HTML injection.
Replay & double-executionConfirmation components are consumed atomically and single-use; scheduled reversals claimed with optimistic locking; idempotent job effects.
Privilege escalation in AEGIS itselfCentral permission checks on every command and endpoint; the guild owner is the only implicit grant; role mappings are audited.
Cross-guild data leakageEvery query is guild-scoped at the repository and route layer, object lookups always include the authorized guild ID, and integration tests assert isolation.
Secret leakageStartup env validation without echoing values; log redaction for tokens, cookies, and content; provider tokens encrypted at rest (AES-256-GCM); audit rows never store secrets.
Denial of service / abuse of AEGISRedis-backed per-IP API rate limits, request body caps, per-user command cooldowns, bounded extraction, and capped query limits.

Data & privacy defaults

No message content stored by default

Ordinary messages are never stored. Sentinel keeps content hashes for duplicate detection in a short in-memory window, and signals store normalized metadata — counts, hostnames, rule names — not full text.

Deliberate capture only

The only content capture is intentional: a staff member using Report Message stores a 200-character preview as evidence context, governed by the guild's retention policy.

Behavior, not identity

Risk factors reference behavior ("posted a suspicious link"), never inferred identity. AEGIS performs no identity correlation, no member IP collection, and no off-platform tracking.

Redaction everywhere

Application logs redact tokens, cookies, message content, and evidence bodies. Provider tokens are encrypted at rest, and audit rows never contain secrets.

Retention classes

Retention windows by data class
ClassSignalsMessage evidence
minimal30 daysReferences only, 30 days
standard (default)180 days90 days
extended365 daysConfigurable, up to 730 days
customPer guildPer guild

An hourly purge deletes expired signals and hard-purges evidence 30 days after soft-deletion. Aggregated analytics persist beyond raw-signal deletion, and the dashboards state that caveat. Reading evidence requires a dedicated permission and is itself logged — who, via what, and when.

Audit integrity chain

Every administrative and automated action lands in an append-only, per-guild SHA-256 hash chain with correlation IDs. Investigations can be reconstructed end to end, and the chain can be verified on demand.

event #1042case.create
prev
b7e0…334c
hash
9f2c…a1d4
event #1043evidence.reveal
prev
9f2c…a1d4
hash
5d81…e772
event #1044case.reverse
prev
5d81…e772
hash
c04a…19bf
Each audit event stores the SHA-256 hash of the previous event. Altering or removing any row breaks every hash after it — /audit verify walks the chain and reports the first mismatch. Illustrative hashes shown.

Access control & separation of duties

Server-side RBAC on every path

Discord permission flags only affect command visibility. Every consequential action — bot command or dashboard request — re-checks AEGIS permissions server-side against the same RBAC tables, so the two surfaces can never disagree.

Dashboard requires both

Dashboard access requires an authorized AEGIS principal and revalidated Discord guild membership. The browser never decides what you can see — the API does.

Separation of duties by default

Appeal decisions and case reversals cannot be performed solely by the moderator who took the original action while the policy is on (the default).

Automated actors are labeled

Actions taken by Sentinel or the system carry an explicit actor type. An automated enforcement never masquerades as a human decision in cases or the audit log.

The full role and permission catalog is on the capabilities page.

Honest limitations

Security products that claim perfection should worry you. What AEGIS does not claim:

  • No tool prevents every attack. AEGIS narrows the window between compromise and containment; it does not eliminate it.
  • Detection is tunable, not perfect. False positives happen — which is why protections start in log_only, approval rejections are recorded for tuning, and every score is traceable to its factors.
  • The audit chain makes tampering detectable, not impossible. A database superuser could still delete rows; deployments should pair the chain with WAL archiving, offsite backups, and least-privilege database roles.
  • AEGIS operates within Discord's permission model. It never claims to override Discord hierarchy — role removals are attempted only where the bot can actually edit the role.
  • Evidence file uploads stay disabled until the storage adapter is wired to a malware scanner; the pipeline is specified with strict type and size limits plus content hashing.
  • Sensitive-action reauthentication on the dashboard is on the roadmap; today the mitigations are a short session TTL and logout-everywhere.