Governance 1st is architected around a zero-trust, server-mediated CRUD (Create, Read, Update, Delete) model. The front-end never interacts with the database directly; instead, all operations flow through a hardened gateway which enforces authentication, authorization, schema validation, and field-level controls.

Governance 1st is designed with the following enterprise-grade security principles:

• Zero-trust front-end

• Strict API gatekeeping

• Role- and organization-based access

• Schema-enforced CRUD

• Strong input sanitization & escape mechanisms

• Tokenized widget sharing

• Rigid separation of presentation and authority

• No direct DB exposure

This architecture is significantly more secure than typical low-code or auto-generated CRUD systems. It is appropriate for AI governance workflows handling sensitive operational data.

Below is a comprehensive description of the platform security layers.

1. Authentication Layer

JWT-like Session + Browser-Safe Storage

The application uses a secure session structure stored client-side.

The browser never stores credentials or tokens beyond the minimal scoped govFirstAuth object.

• State is limited to identifiers and role flags, not permissions or secrets.

• Sensitive checks always occur server-side.

This prevents manipulation of roles/permissions via browser debugging or localStorage tampering.

2. Authorization Layer

Enforced 100% in gov1st_crud.php

Every operation—list, create, update, delete—runs through a single gated controller that applies:

Role-based access control (RBAC)

• is_super_admin

• Organization-level scoping

• User-level scoping

• Role arrays returned from PHP (not front-end controlled)

This ensures:

• Users can only access resources belonging to their org.

• Only superadmins can access global datasets.

• UI filtering on the front-end is cosmetic; the real authorization happens on the server.

3. Database Security

Strict Table-Scoped CRUD

The CRUD layer includes:

• Schema lookup for every table request

• Field allowlists

• Prevention of unauthorized table access

• Query-level sanitization automatically applied

No SQL is exposed to the front-end; all mutations occur through prepared statements.

4. Field-Level Security (Metadata Governance)

The platform uses a unique metadata model to enforce:

• Hidden fields (never shown or editable in UI)

• Key fields

• Lookup & enum controlled fields

• Value-mapped fields (to show display names rather than foreign keys)

This prevents unintended exposure of:

• Internal IDs

• Sensitive relationships

• Backend-only fields that control logic or workflows

The metadata system is enforced server-side, meaning UI manipulation cannot reveal restricted fields.

5. Input Validation and Sanitization

All front-end modules (e.g., training.js, monitor.js, governance.js) rely exclusively on Gov1stCrudClient, which:

On the client:

• Escapes user input

• Prevents HTML/JS injection

• Forces JSON encoding

On the server:

• Validates the schema of the target table

• Rejects unknown fields

• Rejects invalid data types

• Rejects invalid enums

• Rejects direct ID manipulation

The server-side code also forces all input through PHP’s filter layer before any SQL is executed — effectively preventing SQL injection and cross-table access exploits.

6. API Gateway Controls

All data operations route through a secured database gateway which:

• Verifies session

• Verifies permissions

• Validates table against schema

• Validates columns

• Applies filters

• Enforces per-record scoping

• Logs errors

• Never returns raw database errors to user

• Rejects operations that do not match whitelist patterns

No “direct endpoints” exist outside this gateway.

7. Client-Side Hardening

Escaping & XSS Protection

The pattern:

function esc(s) {

return String(s).replace(/[&<>"']/g, ...)

}

appears in all modules.

This prevents:

• XSS injection

• Prompt-based script execution

• Data contamination in UI fields

Any database-sourced text displayed on the UI is escaped before DOM insertion.

Scoped DOM rendering

DOM manipulation uses:

• .innerHTML only with sanitized content

• Element factories (ce(), esc())

• Scoped content injection (no global HTML parsing)

8. No Direct File Access

The system does not allow:

• direct file uploads

• arbitrary filesystem access

• direct DB connections

• front-end defined SQL

All interactions are strictly API-gated.

9. Cross-Site Protection

The architecture inherently mitigates:

CSRF

• All operations require an authenticated session

• Short sessions with server-side checks

• No unauthenticated endpoints exist for destructive operations

XSS

• Escaping everywhere

• No unsanitized HTML injection

Clickjacking

In production the Governance 1st environment is framed only via approved iFrame locations (e.g., widget embeds generate secure embed tokens).

10. Embeds + Tokenization

Widgets in Step 6 use:

Token-based embed URLs

Generated per-widget:

https://hrrebooted.ai/gov1st/embed/widget.html?token=[unique token OR id]

Security properties:

• Embeds never expose internal data without a token

• Token gets validated server-side

• No CORS leaks due to referrerpolicy="no-referrer-when-downgrade"

• Embed tokens can be revoked

This creates a safe, one-way data export.

11. Organizational Isolation

All data is keyed by:

• org_id

• employee_id

Server-side filters ensure users see only records belonging to their organization, even if they tamper with filters on the front-end.

12. Zero-Trust Front-End

The model correctly assumes:

Anything coming from the browser can be forged.

Therefore:

• No trust is placed in client-side role flags

• No query parameters are trusted

• All permission checks happen in gov1st_crud.php

• All allowed tables are explicitly defined

• All allowed operations are explicitly validated

This prevents:

• privilege escalation

• unauthorized table enumeration

• schema tampering

• injection attacks

13. Logically Layered Security

The application uses a layered defense model:

Layer 1 – Session Control

Browser session → authutil.js

Layer 2 – Secure CRUD Gateway

All requests → gov1st_crud.php

Layer 3 – Field/Schema Validation

Server-side schema mapping

Layer 4 – RBAC + Org Isolation

Per-user, per-org checking

Layer 5 – Sanitization + Escaping

Every UI module (training.js, governance.js, monitor.js, etc.)

Layer 6 – UI Hardening

Local-only state, no authoritative client flags

Layer 7 – Tokenized Embeds (Step 6)

Limited-scope one-way data sharing

No single layer is relied upon — each reinforces the others.

For additional information on Governance 1st platform security or other questions, please Contact Us here.