Security Hardening Checklist

Use this checklist when preparing an Open Astra deployment for production. Each item includes the configuration needed and the threat it addresses.

1. JWT configuration

Threat: Weak or default JWT secrets allow token forgery; long-lived tokens extend the blast radius of a credential leak.

• Generate a cryptographically random JWT_SECRET of at least 64 bytes.
• Set JWT_EXPIRY to 15 minutes or less for access tokens.
• Use refresh tokens (JWT_REFRESH_EXPIRY=7d) to allow re-issuance without re-authentication.
• For multi-service deployments, prefer RS256 (asymmetric) so services can verify without holding the signing key.

# .env
JWT_SECRET=<64-byte random hex>          # openssl rand -hex 64
JWT_EXPIRY=15m                           # short-lived access tokens
JWT_REFRESH_EXPIRY=7d                    # longer-lived refresh tokens
JWT_ALGORITHM=HS256                      # or RS256 for asymmetric

See Auth Hardening for the full JWT configuration reference.

2. Secret rotation

Threat: Long-lived API keys and passwords are high-value targets. If leaked, they remain valid indefinitely.

• Store all secrets in environment variables or a secrets manager — never in astra.yml or committed files.
• Set rotation reminders with rotateAfterDays in the secrets config.
• Use the Vault integration for API keys that must be rotated without restarting the gateway.

workspace:
  secrets:
    - name: OPENAI_API_KEY
      source: env                        # read from environment
    - name: STRIPE_SECRET_KEY
      source: vault                      # read from HashiCorp Vault
      vaultPath: secret/data/stripe
    - name: DB_PASSWORD
      source: env
      rotateAfterDays: 30               # warn if not rotated

See Secrets Management for the full configuration.

3. Workspace isolation

Threat: Agents in one workspace accessing data from another, or low-privilege users accessing admin agents.

• Each workspace gets its own isolated memory and knowledge graph — never shared across workspaces by default.
• Configure Agent Grants to restrict which roles can invoke which agents.
• Use Model Restrictions to prevent users from switching to expensive or unapproved models.
• Enable Cross-Workspace memory only when explicitly required — set read-only by default.

4. Rate limiting

Threat: Abuse of the API, runaway agents, or accidental loops causing excessive cost or DoS.

• Enable rate limiting at the gateway level with per-user and per-workspace limits.
• Set per-agent request limits separately from global limits for high-volume agents.
• Combine with Agent Quotas to cap cost per user per billing period.

gateway:
  rateLimit:
    enabled: true
    windowMs: 60000                      # 1 minute window
    perUser:
      maxRequests: 60                    # 60 req/min per user
    perWorkspace:
      maxRequests: 500                   # 500 req/min per workspace
    perAgent:
      maxRequests: 30                    # 30 req/min per agent

5. Approval workflows

Threat: Agents with access to destructive tools (file write, shell exec, API calls) taking unauthorized actions.

• Require human approval for sensitive tool calls using the Approvals system.
• Set a short timeoutSeconds to auto-deny unreviewed requests rather than leaving them open.
• Scope approvals to specific path patterns or argument shapes, not entire tools, to reduce friction for safe usage.

agents:
  - id: deploy-agent
    tools:
      - shell_exec
      - file_write
    approvals:
      required:
        - tool: shell_exec               # any shell call needs approval
        - tool: file_write
          pathPattern: /etc/**           # only system paths need approval
      approvers:
        - role: workspace-admin
      timeoutSeconds: 300               # auto-deny after 5 min

6. Ethical check for public agents

Threat: Users prompting agents to produce harmful content or exfiltrate data.

Always enable Ethical Check on agents accessible via channels (Telegram, Discord, etc.). This adds a policy evaluation layer before each tool call and after each response.

7. SSRF protection

Threat: Agents making HTTP requests to internal services, cloud metadata endpoints, or localhost.

• Open Astra includes a built-in SSRF guard that blocks requests to private IP ranges, link-local addresses, and cloud metadata endpoints (169.254.169.254).
• The guard also follows and validates redirect targets — a redirect from a public URL to an internal address is blocked.
• All outbound calls from http_request, pdf_read, channel adapters (Jira, Zapier, Linear), and webhook delivery are routed through the SSRF guard.

8. Row-level security

Threat: Queries returning data from other workspaces or users due to missing WHERE clauses.

• RLS middleware automatically scopes database queries to the current workspace and user context.
• Memory, knowledge base, graph, and session queries are all workspace-isolated by default.
• SQL bypass patterns (comma-join injection, UNION-based attacks) are detected and blocked.

9. Intrusion detection and brute-force protection

Threat: Credential stuffing, token enumeration, or sustained unauthorized access attempts.

• Failed authentication attempts are tracked per IP and per account with sliding-window counters.
• Accounts are temporarily locked after repeated failures (configurable threshold).
• JWT revocation uses a fail-closed model — if the revocation check cannot complete, the token is rejected.

10. GDPR data erasure

Threat: Incomplete data deletion leaving PII in memory tiers, graph nodes, or search indexes.

• GDPR erasure spans all 5 memory tiers, the knowledge graph, Typesense search indexes, and session history.
• Erasure operations are logged in the audit trail for compliance evidence.
• See PII Detection for automated PII scanning before data reaches memory.

Checklist summary