Security and Compliance
Use this page when you need the main public-safe explanation of Helpifyr security posture, permissions model, secrecy boundaries, and compliance-facing readback.
When to use this page
- You are evaluating whether the platform security model is acceptable.
- You need the primary public-safe security overview before product-specific deep pages.
- You need security language that remains technically precise without exposing secrets or internal-only controls.
Prerequisites
- You have read Secure and Govern.
- You know whether your concern is access control, secrets, auditability, or compliance posture.
Security model
The current public-safe model is built around:
- no secrets in Git
- explicit auth boundaries
- fail-closed automation and signoff
- read-first verification before destructive action
- review-gated handling of risky workflows
Architecture / Flow
Step-by-step procedure
1. Start with the relevant access boundary
Use Identity and Access Boundaries when the question is about who may read or write a surface.
2. Keep the secret model narrow
Public docs posture:
- secrets must not live in Git
- repository metadata is not a secret source
- host-local or environment-injected secret handling remains the expected pattern
3. Verify security posture before action
Illustrative reads:
GET /api/v1/security/readiness
GET /api/v1/signoff/readiness
GET /api/v1/platform/services
4. Separate compliance-facing explanation from internal controls
Public docs may explain:
- control objectives
- verification posture
- trust boundaries
- review and signoff expectations
Public docs should not disclose:
- secret values
- internal-only bypass paths
- sensitive operational procedures that widen attack surface
Verification
This page is being applied correctly when:
- the security concern is classified
- public-safe and operator-only detail remain separated
- readiness and signoff posture are part of the answer
Common failure modes
Explaining compliance as policy text only
Problem:
- the docs do not show how posture is actually verified.
Better path:
- pair policy claims with readiness and review evidence
Mixing public-safe guidance with internal-only controls
Problem:
- the page becomes either too vague or too risky to publish.
Better path:
- keep the public page precise about boundaries and hand off internal detail explicitly