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.

Our mission

We're on a mission to change the way the housing market works. Rather than offering one service or another, we want to combine as many and make our clients' lives easy and carefree. Our goal is to match our clients with the perfect properties that fit their tastes, needs, and budgets.

Our vision

We want to live in a world where people can buy homes that match their needs rather than having to find a compromise and settle on the second-best option. That's why we take a lot of time and care in getting to know our clients from the moment they reach out to us and ask for our help.

Our team

Our strength lies in our individuality. Set up by Esther Bryce, the team strives to bring in the best talent in various fields, from architecture to interior design and sales.

Esther Bryce

Founder / Interior designer

Lianne Wilson

Broker

Jaden Smith

Architect

Jessica Kim

Photographer