Security overview
Jutsu protects your security data with layered controls — encryption, authenticated transport, scoped credentials, and least-privilege access — so that the system you use to defend your environment is itself defensible.
This page summarizes Jutsu's posture and links to the deeper references. Each layer below is independent: a weakness in one does not collapse the others.
Defense layers
| Layer | Control |
|---|---|
| Identity | Email/password (hashed) or Google SSO; JWT bearer sessions scoped to an organization. See Authentication & SSO. |
| Authorization | Organization member roles and platform roles, enforced by middleware guards. See Role-based access control. |
| Secrets at rest | Integration credentials are encrypted before they are stored. |
| Transport | Services talk to OpenSearch and to each other over HTTPS/TLS with authentication. |
| Tenancy | Every record is scoped to an organization and access is evaluated within that boundary. |
| Accountability | User, resource, and alert actions are recorded in audit trails. See Audit logging. |
Encryption at rest for sensitive secrets
Integration credentials are not stored in plaintext. AgentSOAR cloud and identity credentials (for example AWS, Azure, and GCP) are encrypted with AES-256-GCM before they are written to the database. The platform derives a 256-bit key from a deployment secret (AGENTSOAR_CREDENTIAL_ENCRYPTION_KEY, required to be at least 16 characters) and seals each credential as an authenticated iv + ciphertext + authTag envelope, so a stored credential cannot be read or tampered with without the key.
Credentials are decrypted only at the moment a response action needs them; they are never returned by read APIs.
The encryption key is supplied per deployment. If it is unset, cloud-credential operations fail closed rather than storing secrets in the clear. Confirm key management against your deployment.
TLS in transit
Service-to-service and service-to-datastore traffic uses TLS. Connections to OpenSearch use an https:// endpoint and carry credentials on every request — either an API key or HTTP basic authentication — so the search tier never accepts anonymous or cleartext access.
Secrets management
Sensitive configuration — the JWT signing secret, OAuth client secrets, datastore passwords, and the credential-encryption key — is provided through environment configuration and Kubernetes secrets rather than committed to source. Managed datastores (Postgres, OpenSearch, RabbitMQ, Redis) are referenced only by URL through those secrets.
Least-privilege integration credentials
Integration credentials are scoped to the organization that owns them and to the specific provider and domains they apply to. Only roles authorized to manage credentials can create or rotate them, and the response worker uses a credential only for the actions a given organization has configured. Grant each integration the narrowest provider permissions that let it do its job.