# Haley
A standalone RBAC solution that integrates with a company’s private LLM, data warehouse, and IAM, ensuring fine-grained access control, data masking, and full auditability—crucial for industries handling sensitive data (finance, healthcare, government, eCommerce).

### TLDR;

**Problem**: LLMs handle unstructured, high-risk production data. Current solutions lack robust role-based access, risking data leaks and compliance penalties.

**Solution**: Haley enforces fine-grained RBAC + data masking on LLM queries. Seamlessly integrated with IAM solutions, ensuring only authorized data is returned.

**Benefits**:
1. Accelerated Adoption: Safely deploy LLMs org-wide
2. Reduced Costs: Reuse existing IAM and data infra
3. Compliance-Ready: Automatic audits, masking, and redaction

## Problem Statement

:::info
Enterprise LLM adoption is hindered when LLMs can’t determine who should have access to which information, risking data leakage or unauthorized disclosures.
:::

#### Exponential Growth of AI in Regulated Sectors

- Finance, healthcare, and government are rapidly adopting LLM-based solutions for analytics and decision-making.
- These sectors handle highly confidential or regulated data (PII, PHI, M&A, classified documents).

#### Existing LLM Solutions Lack Robust Access Controls

- Typical out-of-the-box LLM deployments don’t differentiate data access based on user roles.
- Risks include data leaks, inadvertent disclosures, and non-compliance with HIPAA, FINRA, GDPR, etc.

#### Complex Regulatory & Compliance Landscape

- Enterprises face major penalties and reputational harm for information leakage.
- Traditional data governance tools fail to integrate properly with the unstructured queries LLMs handle.

## Solution

:::info
Haley is a Role-Based Access Control (RBAC) layer for LLMs, enabling fine-grained access control and data masking so users see only data they’re authorized for—accelerating company-wide LLM adoption while maintaining compliance.
:::

- Integrates with existing solutions like Active Directory to map users’ roles, groups, or clearance levels.
- Enforces fine-grained access policies, ensuring only authorized users can view sensitive fields or documents.

### Key Features
- Data Masking & Redaction: Automatically sanitizes sensitive data (PII, deal terms) based on each user’s role.
- Auditing & Compliance: Logs every request, including user identity, query details, and redacted vs. unredacted data.
- Governance: Prevents non-work-related queries and controls unnecessary usage costs.
- Flexible Deployment: Connects seamlessly to on-prem LLMs and vector databases, with no sensitive data leaving the environment.

### Use Cases

#### Finance: Investment Banking

- Senior Bankers see full M&A details; junior analysts see only summaries or anonymized parties.
- Automatic logs facilitate SEC/FINRA compliance

#### Healthcare: Hospitals

- Doctors see patient PHI; others only see what’s necessary:
-- Data scientists: masked records for analysis
-- Administration: basic, non-clinical info
-- Patient scheduling: limited profile data
- HIPAA compliance ensured via full audit trails and data redaction.

#### Government

- Different departments see only relevant information for their particular department or case.
- Citizen Service Portals: Some data (e.g., personal earnings, SSNs) must remain hidden for unauthorized staff
-- Case workers: Access sensitive details for approvals
-- Support staff: Sanitized case summaries only

### Benefits

- Lower LLM Adoption Risk: Role-based controls let every department—from finance to HR—use LLMs safely, boosting productivity.
- Reduced CAPEX/OPEX: Integrates with existing identity providers (e.g., Active Directory) and vector databases, avoiding costly new infrastructure.
- Low Operational Overhead: Just assign or update roles in AD to manage access—no system rebuilds needed.
- Scalable Enterprise-Wide Governance: Centralized policies unify governance rules, simplifying audits and compliance.

## Go-To-Market

:::info
Leverage the enterprise AI adoption wave by positioning Haley as a critical compliance tool. Target highly regulated industries where data leaks pose major risks.
:::

### Market Opportunity

#### Rapid Growth of Enterprise AI

- Enterprise AI is growing at a double-digit CAGR, projected to exceed $50B within a few years.
- Finance, healthcare, and government are some of the fastest adopters due to large data volumes and complex regulatory needs.
- These organizations are willing to invest significantly to prevent data breaches and reputational damage.

#### Untapped Potential for “Safe AI” Solutions
- Many AI vendors focus on model performance, not compliance.
- Without robust RBAC, organizations risk leaks, non-compliance, and fines.
- Haley fills the gap by combining productivity gains with data protection.

#### Adoption Tipping Point
- Regulations are tightening, data leaks are rising, and organizations can’t afford to lag in secure AI deployment.
- Haley addresses this by offering compliance-ready, on-prem controls.

#### Unfocused Competition:
- High-level AI governance tools lack granular, real-time controls for on-prem LLMs.
- Model providers prioritize cost and performance over compliance.

### GTM Strategy

#### Ideal Customer Profile
- Highly Regulated Organizations: Financial institutions, governments, healthcare providers
- Strict Compliance Environments: Firms needing data sovereignty and infrastructure control
- Enterprises Pursuing Company-Wide AI Adoption: Seeking cost savings via chatbots, knowledge retrieval, etc., with multiple teams needing varied access levels.

#### Channel + Ecosystem + Direct Sales
- Develop relationships with System Integrators, ISVs and IT consultants as part of their standard LLM implementation package
- Technical collaboration with vector database, RAG tooling, and LLM orcherstration software packages to ensure compatability
- Direct sales team targeting key accounts

## Strawman Technical Design

>A component-based architecture offers both high-security and scalable performance. By including a policy engine, a sandbox vs. direct path decision process, and a final post-processing check, you mitigate data leaks while still providing a responsive user experience. Over time, caching and learned policies will reduce overhead and streamline repeated queries, making the system more adaptive and efficient

### Core Data Flow

#### 1. Haley Gateway Layer
Purpose:
- Serves as the entry point for all user queries.
- Receives the natural language (NL) query from the UI (or CLI, or external API) and handles basic input validation.

Key Responsibilities:

- Initial Logging: Logs the incoming request (timestamp, user ID, raw query).
- Forwarding: Passes the query to the Identity & Policy component.
Implementation Considerations:

#### 2. Identity & Policy
Purpose:

- Identity Retrieval: Validate the user’s authentication token/credentials, retrieve roles and permissions (e.g., from Active Directory, Okta, or any IAM).
- Policy Engine: Combine user role data with organizational policies to define which data fields or operations are allowed.

Key Responsibilities:

- User Role & Permissions: Query the enterprise’s IAM/AD.
- Policy Lookup: Identify relevant policies for the user’s role, environment, or data classification.
- Risk Assessment: LLM-based or heuristic engine here to classify query sensitivity.

#### 3. Orchestration Engine
Purpose:

- Takes the policy outcome (risk score, user role) and decides which path to follow: sandbox or policy-based query rewriting.

Key Responsibilities:

- Route Decision:
-- High-Risk: Send the query to the Sandbox Module.
-- Low-Risk: Send the query to the Rewrite Module.
- Tracking State: Keeps track of how the query flows through the system.
- Caching & Learned Policies: If the query is “seen before” and was safe, it might skip some steps.

#### 4a. Sandbox Module (High-Risk Path)
Purpose:

- Execute the query in a controlled environment to see if it would return sensitive data.

Key Responsibilities:

- Dry Run or Simulated Execution:
-- Possibly an “EXPLAIN” query or a partial fetch to see what columns/tables are accessed.
- Sensitive Field Detection:
-- If it detects references to disallowed columns, it flags or automatically masks them.
- Rewrite or Drop:
--- If forbidden columns appear, either remove them from the query or mask them for the real fetch.

#### 4b. Rewrite Module (Low-Risk Path)
Purpose:

- For known safe or low-risk queries, automatically rewrite them by removing or masking forbidden fields.

Key Responsibilities:

- Policy Enforcement:
-- Looks at the user’s role-based restrictions.
-- Dynamically modifies the query (e.g., remove columns ssn, credit_card) or apply row-level filters.
- Minimal Overhead:
-- Bypass the heavier sandbox step, enabling faster response time.

#### 5. Data Execution Layer
Purpose:

- Execute the final, sanitized query against real databases or vector stores, and retrieve results for post-processing.

Key Responsibilities:

- Connection Pooling & Queries:
-- Supports Postgres (SQL), Pinecone (vector search), MongoDB (NoSQL), etc.
- Reusability:
-- Unified interface to handle different query forms (SQL, vector search, document search).
- Masking Hooks:
-- Optionally apply final masking if some fields can be easily hidden at the DB level (e.g., database column masking).

#### 6. Post-Processing & Check
Purpose:

- Final pass to ensure no forbidden data slipped through or wasn’t caught by earlier steps.

Key Responsibilities:

- Pattern Scanning:
-- For text fields, run regex or ML-based checks for SSNs, credit cards, etc.
- Compliance Enforcement:
-- If something is found, mask or remove it before returning the result.

#### 7. Return & Audit Logs
Purpose:

- Deliver sanitized or approved results back to the user.
- Record all relevant steps in the audit trail.

Key Responsibilities:

- User Notification:
-- If data was masked or trimmed, inform the user (“Some fields were removed per your access level.”).
- Detailed Logging:
-- Log which columns/tables were accessed, what was masked, and whether the query was high or low risk.
-- Useful for compliance (HIPAA, GDPR, etc.) and debugging.

#### 8. (Cross-Cutting) Caching & Learned Policies
Purpose:

- Improve performance and reduce repeated sandbox overhead by storing knowledge of previously safe queries and user behavior patterns.

Key Responsibilities:

- Query + Result Cache:
-- Store (query signature, user role, final masked result) for quick reuse.
- ML/LLM-Driven:
-- Over time, the system learns that certain queries from a specific user role are always safe, so it can bypass the sandbox.
- TTL & Versioning:
-- Invalidate or refresh caches when data changes or policies get updated.

### Strawman Tech Stack
**Gateway Layer:**
Language: Node.js, Python Flask, or a Golang microservice.
Proxy: NGINX, Envoy, or Kong.

**Identity & Policy:**
IAM: Active Directory, Okta, or custom SSO.
Policy Engine: Open Policy Agent (OPA) or custom RBAC logic.

**Orchestration Engine:**
Language: Python, Java, Go—whatever the team prefers.
Might be combined with the Gateway or be standalone microservice.

**Sandbox & Rewrite Modules**:
Parsing & Rewriting: SQL parsers, LLM-based interpreters for natural language.
Sandboxing: Could use a dev/test DB instance or an “EXPLAIN” approach.

**Data Execution Layer:**
Connectors/Adapters for Postgres, MongoDB, Pinecone, etc.

**Post-Processing:**
Regex/ML-based PII detection.
Potential data classification rules (e.g., labeling columns as “HIPAA,” “PCI,” etc.).

**Audit Log:**
Storage: Secure database (e.g., PostgreSQL with restricted access) or an append-only store for compliance.

## Strawman Business Plan

### Team Composition
Tech Team:
- 1 Team Lead (Tech Co-Founder)
- 1 AI Engineer
- 2 BE Engineer
- 1 FE Engineer

Business Team:
- 1 CEO (Biz Co-Founder)
- 1 Marketing & Pre-Sales
- 1 Sales

### Revenue Model
- Annual subscription based on features and token volume
- Licensing + Maintenance for OnPrem customers

### Timeline

**Months 0-3:** Team Building
- Hiring
- Lead-Gen Campaign for PoCs and Pilots
- MVP development

**Months 3-6:** MVP & POcs
- Hiring
- MVP supporting a set of SQL, NoSQL, AD, and LLM
- First PoC / Pilot

**Months 6-9:** PMF Validation
- Hiring & Firing
- First PoC / Pilot accepted by customer
- 3 to 5 Pilots underway
- Support for more databases, access rules, roles, data types, etc...

**Months 9-12:** Commercialization
- First commercial contract signed
- Hiring & Firing
- Scaling planning (Tech, Marketing, Sales, etc...)

## FAQ

**Q: Why Haley?**
**A:** Unlike HAL 9000, which was not a helpful AI and did not respect RBAC, Haley is helpful by ensuring RBAC is enforced in all human generative AI interactions.