Skip to main content

Security and data protection

This page summarizes, in plain language, the security controls RuleForge applies by default. The goal is to give you and your security team clarity on what's already taken care of by the product.

Access and identity​

  • Strong passwords: sign-up requires strong passwords and password resets use temporary links.
  • Corporate SSO: you can sign in with your company's identity provider (Google, Okta, Entra ID, etc.) via SSO with OIDC. In this mode, your company's policies (MFA, conditional access) apply to RuleForge too.
  • Automatic provisioning: users can be created and deactivated automatically from your provider via SCIM. When someone leaves, RuleForge access is cut along with it.
  • Clear session context: RuleForge always shows which organization you're operating in, avoiding confusion between environments.

Roles and permissions​

  • Access is controlled by roles (administrator, reviewer, engineer, read only, etc.).
  • The role applies to the organization and can be adjusted per project.
  • See Roles and permissions for details.

Credential protection​

  • Passwords and integration credentials (Git, pipelines, identity providers) are stored encrypted.
  • Sensitive values (API key secrets, integration tokens) appear only once on screen, at creation time. After that, RuleForge never displays the full value.
  • When updating a configuration, leaving a secret field blank preserves the current value — this prevents accidental secret exposure.

Webhooks​

  • Only accept public URLs (http or https).
  • Local or private-network URLs are blocked by default.
  • You can configure a secret so the receiving system can verify the notification came from RuleForge.
  • Every delivery is recorded, with results and automatic retries on failure.

Logs and audit​

  • Sensitive actions (publishing, key revocation, integration changes) are recorded in audit.
  • You can query history by person, entity, or period.

Limits and abuse protection​

  • Sensitive flows (login, sign-up, password reset) have attempt limits to prevent automated attacks.
  • The organization receives warnings when its API usage approaches the plan limit.

Recommendations for your team​

  • Use corporate SSO whenever possible.
  • Enable SCIM to automate offboarding.
  • Grant the minimum role necessary to each member.
  • Rotate API keys periodically.
  • Review audit as part of your security routine.
  • Use secrets on webhooks that fire against sensitive systems.

What this page doesn't cover​

This is a summary of controls applied inside the product. It doesn't replace your company's internal policies (device hardening, corporate secrets management, legal compliance review). If you need a deeper technical summary, talk to the customer success team.