Trust & Security

We don’t claim certifications we don’t have. This page describes what Aegis actually does today, not aspirational marketing language. If something below matters to your evaluation and you want more detail, reach out.

Tenant isolation

Every organization’s data — agents, activity, policies, approvals, audit events, security alerts — is scoped by an organizationId that is always derived server-side from your authenticated session or API key, never trusted from client input. Every database query that reads or writes tenant data includes that scope directly, so one organization can never see or modify another’s data through the application or the public API.

Role-based access control

Access within an organization is governed by six fixed roles — Owner, Admin, Engineer, Security, Finance, and Viewer — through a single, central capability map rather than scattered role checks across the codebase. An organization can never end up with zero Owners, and only an existing Owner can grant or remove the Owner role, closing the usual privilege-escalation path.

Audit trail

Every policy and permission change, every agent mutation, and every approval decision is recorded to an append-only audit log — there is no update or delete path exposed for audit data. Mutations and their audit record are written in the same database transaction, so an audited action can never succeed without leaving a trace.

Policy engine: fails closed

When an agent asks Aegis whether it’s allowed to take an action, and nothing — no permission, no policy — matches that action, the decision is BLOCK, not ALLOW. The engine is designed to fail closed by default, and an unexpected error during evaluation raises rather than silently defaulting to allow.

API keys

API keys are organization-scoped credentials shown to you exactly once at creation. Aegis never stores or logs the raw key — only a SHA-256 hash of it, looked up on each request. Keys can be revoked immediately from the dashboard, and support optional expiration.

Secret redaction

Metadata and context your agents send us — event payloads, evaluation context, approval context — is scanned for credential-shaped fields (keys, tokens, passwords, secrets, cookies, authorization headers) and redacted before it is ever written to the database, across every ingestion path.

Outbound webhooks

Webhook deliveries are HMAC-signed with a per-endpoint secret so receivers can verify authenticity, and every destination URL is checked against private/internal IP ranges — both when you create the endpoint and again immediately before each delivery, since DNS answers can change between the two.

Application security

• Passwords are hashed with bcrypt; hashes are never sent to the client.
• All mutations are validated server-side with a schema library, never relying on client-side validation alone.
• Standard security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and HSTS in production) are set on every response.
• The public API is rate-limited per key and supports an idempotency key so a retried request can’t duplicate a mutation.

What we don’t claim

We are not SOC 2, ISO 27001, HIPAA, or GDPR certified. If your organization requires a formal certification or compliance attestation as a condition of adoption, talk to us — we’d rather tell you where we stand today than imply something we can’t back up.

Responsible disclosure

If you believe you’ve found a security issue in Aegis, we want to hear about it before anyone else does. A security contact isn’t configured for this deployment yet — see NEXT_PUBLIC_CONTACT_EMAIL in docs/deployment.md. We don’t currently run a paid bug bounty program — say so plainly rather than imply one exists.