Skip to main content

Identity and Access Boundaries

Use this page when you need the public-safe access model for Helpifyr routes, docs, and operator workflows.

When to use this page​

  • You need to decide whether a surface should be public, internal-read, or guarded-write.
  • You need to design an integration without weakening the auth model.
  • You need to explain identity posture without disclosing secrets or internal-only steps.

Prerequisites​

  • You have read Secure and Govern.
  • You can inspect the Fabric security page and readiness surfaces.

Architecture / Flow​

flowchart TD
    A["Choose route or workflow"] --> B["Classify access type"]
    B --> C["Apply auth requirement"]
    C --> D["Check audit and signoff implications"]
    D --> E["Publish public-safe guidance or owner-only runbook"]

Step-by-step procedure​

1. Separate surface classes first​

The core categories are:

  • public-safe summaries and landing pages
  • internal or guarded read surfaces
  • authenticated control-plane API routes
  • intake or write paths with higher risk

2. Use the documented Fabric security matrix​

Illustrative readback:

GET /api/v1/security/readiness
GET /api/v1/platform/services
GET /api/v1/docs/platform

From the current public-safe posture:

  • /health and selected summaries may be low-risk reads
  • /api/v1/* control-plane surfaces typically require api_key
  • sensitive write or intake actions require stronger controls and must not be described as anonymous access

3. Keep docs examples inside the public-safe boundary​

Public docs may include:

  • route families
  • auth expectations
  • verification examples
  • owner handoffs

Public docs must not include:

  • secret values
  • bypass instructions
  • hidden operator shortcuts that defeat policy

Verification​

This page is being applied correctly when:

  1. the surface class is explicit
  2. the auth posture is explicit
  3. the example stays public-safe

Common failure modes​

Explaining a guarded route as if it were public​

Problem:

  • consumers build the wrong risk posture.

Better path:

  • state the auth requirement and owner boundary clearly

Blurring docs-read access and runtime-mutation access​

Problem:

  • readers assume docs visibility implies write permission.

Better path:

  • separate public readback from control-plane mutation

Source Truth​

Next paths​