📘 Demo Application Guide

The Control Core Demo Application is a comprehensive, production-ready application designed for testing policies, conducting training demonstrations, developing new authorization patterns, and learning Control Core capabilities.

For what may change in the Demo App vs what must stay in policy, see Demo resource and PBAC boundaries. CI enforces selected resource-side enforcement drift via quality/demo-app/scripts/check_demo_resource_enforcement_drift.py.

📌 What is the Demo Application?

The Demo Application simulates a real-world business application with AI-powered features, sensitive data, and complex authorization requirements. It's specifically designed to showcase Control Core's policy enforcement capabilities without any hardcoded access control logic.

Key Characteristics

Intentionally Unprotected:

No built-in access control policies
All users can access all features by default
Perfect for demonstrating "before and after" policy enforcement
Shows immediate impact of Control Core policies

Production-Ready Architecture:

Enterprise-grade security middleware
JWT-based authentication
Role-based access control framework (enforced by Control Core)
Comprehensive audit logging
Real-time data from PostgreSQL database

How the demo app fits with Control Core:

Click to enlarge

Rich Feature Set:

AI Chat Assistant with multiple provider support
AI Agents for automated business processes
Customer Management (CRM)
Employee Management (HRMS)
Financial Analytics and Reporting
Payment Transaction Processing
Medical Center (Healthcare scenarios)
Analytics Dashboard

📌 Why Use the Demo Application?

1. Testing Policies

Test your policies in a realistic environment before deploying to production:

Scenario: Test FINTRAC Policy

# 1. Deploy demo app
# 2. Create FINTRAC policy in Control Core
# 3. Configure Bouncer to protect demo app
# 4. Test with different users and transaction amounts
# 5. Verify policy behaves correctly
# 6. Review audit logs
# 7. Deploy to production with confidence

2. Internal Demonstrations

Demonstrate Control Core capabilities to stakeholders:

For Executives:

Show immediate value of policy-based access control
Demonstrate compliance automation (FINTRAC, OSFI, HIPAA)
Real-time policy changes without code deployment
Comprehensive audit trail for regulatory requirements

For Technical Teams:

Policy development workflow
Integration with existing systems
Performance (sub-100ms decisions)
Scalability and reliability

For Compliance Teams:

Automated compliance enforcement
Audit logging and reporting
Policy version control
Segregation of duties

3. Policy Development

Develop and refine policies in a safe environment:

Development Workflow:

1. Create policy in sandbox
2. Test against demo app
3. Refine based on results
4. Add comprehensive test cases
5. Deploy to production

Advantages:

Realistic test data
Multiple user profiles
Various scenarios (financial, healthcare, HR)
No risk to production systems

4. Learning and Training

Learn Control Core concepts hands-on:

For New Users:

Understand policy structure
Learn Rego language
Practice policy testing
Explore integrations (PIP)

For Developers:

Master advanced Rego patterns
Build custom integrations
Optimize policy performance
Implement compliance requirements

🚀 Deployment

Prerequisites

System Requirements:

Memory: 4GB RAM minimum, 8GB recommended
CPU: 2 cores minimum, 4 cores recommended
Storage: 10GB free space
Software: Docker 20.10+, Docker Compose 2.0+

Ports Required:

3001: Demo Application Frontend
8080: Bouncer API entrypoint (recommended for all app-facing traffic)
8000: Demo Application API upstream (keep internal/private when bouncer is enabled)
5433: Demo PostgreSQL Database (to avoid conflict with Control Core DB)

No-Bypass Configuration Chart

Use this chart as your deployment source of truth whenever a bouncer is enabled.

Setting	Sidecar mode	Reverse-proxy mode
`NEXT_PUBLIC_API_BASE_URL`	Bouncer-facing URL (`http://localhost:8080` in local dev)	Public bouncer/gateway URL (for example `https://api.company.com`)
`DEMOAPP_API_URL` (server-side)	Bouncer service URL (`http://demo-app-api:8080`)	Bouncer private/gateway URL used by server runtime
Upstream API port (`:8000`)	Internal-only inside network/pod	Private-only behind gateway
Allowed direct frontend → `:8000`	No	No

Quick Start Deployment

Option 1: Automated Setup Script (Recommended for First-Time Setup):

The automated setup script (setup_demo_app.py) provides a complete, one-command setup experience:

# Navigate to project root
cd control-core-012025

# Run the automated setup script
python demo-app/infra/setup_demo_app.py

# The script will automatically:
# 1. Check system requirements (Python, Docker, etc.)
# 2. Set up environment variables (.env file)
# 3. Configure database connection
# 4. Install all dependencies (backend and frontend)
# 5. Initialize database with comprehensive sample data
# 6. Prompt for LLM API key (or you can configure later)
# 7. Prompt for GitHub token (or you can configure later)
# 8. Wait for bouncer registration (if Control Core is running)
# 9. Load test policies
# 10. Start all services with hot reload enabled

What the Setup Script Configures:

Environment Variables: Creates .env file with template configuration
LLM Integration: You'll need to provide your own LLM API key (see configuration section below for supported providers)
GitHub Integration: You'll need to provide your own GitHub token (see configuration section below)
Database: PostgreSQL with comprehensive sample data
Services: Starts backend API and frontend with hot reload

Note: The setup script will create a .env file with placeholder values. You'll need to obtain your own API keys and tokens before the demo app can use AI features or GitHub integration.

Access Points After Setup:

Frontend: http://localhost:3000
Backend API: http://localhost:8000
API Documentation: http://localhost:8000/devdocs
Database: localhost:5433 (if using separate PostgreSQL)

Option 2: One-Click Start (For Subsequent Runs):

# Navigate to demo app directory
cd demo-app

# Start complete demo environment
./infra/start-dev.sh

# The script will:
# 1. Start PostgreSQL with sample data
# 2. Initialize database schema
# 3. Load demo users and business data
# 4. Start API server
# 5. Start frontend application

# Access demo app
# Frontend: http://localhost:3001
# API Docs: http://localhost:8000/devdocs
# Database: localhost:5433

Stop Demo Application:

./infra/stop-dev.sh

Reset to Factory Defaults:

# Resets database and restarts all services
./infra/start-dev.sh

Option 2: Manual Deployment

Step 1: Start Database

cd demo-app-api

# Start PostgreSQL with Docker
docker run -d \
  --name demo-postgres \
  -e POSTGRES_USER=demo_user \
  -e POSTGRES_PASSWORD=demo_password \
  -e POSTGRES_DB=demo_app \
  -p 5433:5432 \
  postgres:15-alpine

# Initialize database
python init_db.py

# Verify
docker exec demo-postgres psql -U demo_user -d demo_app -c "\dt"

Step 2: Start API Server

# Install dependencies
pip install -r requirements.txt

# Configure environment
export DATABASE_URL="postgresql://demo_user:demo_password@localhost:5433/demo_app"
export SECRET_KEY="<set-from-secret-manager>"
export JWT_SECRET="<set-from-secret-manager>"

# Start API
uvicorn app.main:app --reload --host 0.0.0.0 --port 8000

# Verify API is running
curl http://localhost:8000/health
# Expected: {"status": "healthy"}

# View API documentation
# Navigate to: http://localhost:8000/devdocs

Step 3: Start Frontend

cd demo-app

# Install dependencies
npm install

# Configure environment (NO-BYPASS: point to bouncer, not direct API)
export NEXT_PUBLIC_API_BASE_URL=http://localhost:8080

# Start development server
npm run dev

# Or use alternative port if 3000 is taken
npm run dev:3001

# Access application
# Navigate to: http://localhost:3001

Step 4: Verify Deployment

# Check frontend
curl http://localhost:3001

# Check API health
curl http://localhost:8000/health

# Check database
docker exec demo-postgres psql -U demo_user -d demo_app -c "SELECT COUNT(*) FROM users;"

# Should show 5 demo users

Option 3: Docker Compose Deployment

cd demo-app/infra

# Review docker-compose configuration
cat docker-compose.yml

# Start all services
docker-compose up -d

# Check services
docker-compose ps

# View logs
docker-compose logs -f

# Stop services
docker-compose down

docker-compose.yml Example:

version: '3.8'

services:
  demo-db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: demo_user
      POSTGRES_PASSWORD: demo_password
      POSTGRES_DB: demo_app
    ports:
      - "5433:5432"
    volumes:
      - demo-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U demo_user -d demo_app"]
      interval: 10s
      timeout: 5s
      retries: 5

  demo-api:
    build: ../../demo-app-api
    environment:
      DATABASE_URL: postgresql://demo_user:demo_password@demo-db:5432/demo_app
      SECRET_KEY: demo_secret_key
      JWT_SECRET: demo_jwt_secret
    ports:
      - "8000:8000"
    depends_on:
      demo-db:
        condition: service_healthy

  demo-app:
    build: ..
    environment:
      NEXT_PUBLIC_API_BASE_URL: http://localhost:8000
    ports:
      - "3001:3001"
    depends_on:
      - demo-api

volumes:
  demo-db-data:

📌 Demo Users and Access Levels

The demo application includes 5 pre-configured users with different roles and attributes. Every user shares the same password: demo (override with env DEMO_USERS_PASSWORD on the Demo App API).

Admin User

Credentials: admin / demo

Profile:

Role: System Administrator
Department: IT
Security Clearance: Secret
Groups: IT_Administrators, System_Admins, Security_Team
MFA: Enabled
Compliance: 100% training complete

Access:

All features and pages
All data classifications (public, internal, confidential, secret)
User management
System configuration

Use For:

Demonstrating full administrative access
Testing unrestricted policies
Showing user management features

Manager User

Credentials: manager / demo

Profile:

Role: Operations Manager
Department: Operations
Security Clearance: Confidential
Groups: Operations_Managers, Team_Leads, Project_Managers
Work Schedule: Hybrid
Compliance: 95% training complete

Access:

Management dashboards
Team data
Public, internal, and confidential data

Use For:

Demonstrating management-level access
Testing department-based policies
Showing hybrid work policies

Analyst User

Credentials: analyst / demo

Profile:

Role: Data Analyst
Department: Analytics
Security Clearance: Confidential
Groups: Data_Analysts, Business_Analysts, Research_Team
Work Schedule: Remote
MFA: Disabled (intentionally for testing)
Compliance: 80% training (pending)

Access:

Analytics dashboards
Reports and visualizations
Public and internal data

Use For:

Demonstrating remote work policies
Testing MFA requirements
Showing compliance training enforcement
Testing risk-based access

HR User

Credentials: hr / demo

Profile:

Role: HR Administrator
Department: Human Resources
Security Clearance: Confidential
Groups: HR_Team, Employee_Management, Compliance_Team
MFA: Enabled

Access:

Employee data
HR records
PII (with restrictions)

Use For:

Demonstrating PII protection
Testing role-based data access
Showing healthcare compliance (HIPAA)

Finance User

Credentials: finance / demo

Profile:

Role: Finance Manager
Department: Finance
Security Clearance: Secret
Groups: Finance_Team, Accounting_Team, Audit_Team
MFA: Enabled
Compliance: 100% training complete

Access:

Financial records
Transaction data
Audit reports
All data classifications

Use For:

Demonstrating financial compliance (FINTRAC, AML)
Testing transaction monitoring policies
Showing segregation of duties

🛡️ Using for Policy Testing

Testing Workflow

1. Deploy Demo App:

cd demo-app
./infra/start-dev.sh

2. Configure Bouncer to Protect Demo App:

# In Bouncer .env file
TARGET_HOST=localhost:8000  # Demo API
BOUNCER_PORT=8080

# Restart Bouncer
docker-compose restart bouncer

3. Access Demo App Through Bouncer:

# Direct access (no policy enforcement)
http://localhost:3001

# Through Bouncer (with policy enforcement)
# Update demo app API URL to point to bouncer (never direct :8000)
export NEXT_PUBLIC_API_BASE_URL=http://localhost:8080

4. Create Test Policy:

package controlcore.policy

import rego.v1

default allow := false

# Test: Only analysts can access analytics
allow if {
    input.user.roles[_] == "analyst"
    input.resource.path == "/analytics"
}

5. Test with Different Users:

# Login as analyst
# Navigate to /analytics
# Expected: Access granted

# Login as hr
# Navigate to /analytics
# Expected: Access denied

6. Review Results:

Check decision logs in Control Core
Verify expected behavior
Refine policy as needed

Test Scenarios

Scenario 1: Department-Based Access

# Policy: HR can only access employee data
package demo.hr_access

import rego.v1

default allow := false

allow if {
    input.user.department == "Human Resources"
    input.resource.type == "employee_data"
}

Test:

Scenario 2: Financial Compliance (FINTRAC)

# Policy: Large transactions require compliance officer
package demo.fintrac

import rego.v1

default allow := false

allow if {
    input.resource.type == "payment_transaction"
    input.transaction.amount < 10000  # Under FINTRAC threshold
}

allow if {
    input.resource.type == "payment_transaction"
    input.transaction.amount >= 10000  # Over threshold
    input.user.attributes.fintrac_certified == true
    input.user.roles[_] == "compliance-officer"
}

Test:

Go to Payment Transactions page
Try to approve transaction > $10,000 CAD as finance user → ❌
Try same as admin (with fintrac_certified) → ✅

Scenario 3: Healthcare Compliance (HIPAA)

# Policy: Medical records require care team membership
package demo.hipaa

import rego.v1

default allow := false

allow if {
    input.resource.type == "medical_record"
    patient_id := input.resource.patient_id
    
    # Check if user is on care team (from demo database)
    care_team := data.patient_care_teams[patient_id]
    input.user.id in care_team.members
}

Test:

Configure PIP to connect to demo database
Create policy using care team data
Test access to medical records

📌 Using for Internal Demos

15-Minute Standard Demo

Preparation (5 minutes):

Start demo app and Control Core
Verify all services running
Open two browser windows:
- Window 1: Demo app
- Window 2: Control Core console

Demo Flow (10 minutes):

Part 1: Show Unprotected State (2 minutes):

1. Login to demo app as "analyst" user
2. Navigate through all pages
3. Show: "Analyst can see everything - including financial data, employee PII"
4. Emphasize: "This is how most applications work - trust the application code"

Part 2: Create and Apply Policy (3 minutes):

1. Switch to Control Core window
2. Navigate to Policies → Create Policy
3. Create simple policy:
   
   package demo.department_access
   
   default allow := false
   
   allow if {
       input.user.department == input.resource.department
   }

4. Save and deploy to production
5. Explain: "No code changes, no deployment, just policy"

Part 3: Show Protected State (3 minutes):

1. Switch back to demo app
2. Refresh page
3. Navigate to financial data (as analyst)
4. Show: "Access denied - analyst not in finance department"
5. Login as "finance" user
6. Show: "Finance user CAN access financial data"

Part 4: Show Audit Trail (2 minutes):

1. Switch to Control Core
2. Navigate to Monitoring → Decisions
3. Show real-time decision logs
4. Highlight: "Every access attempt logged for compliance"
5. Export audit report

30-Minute Comprehensive Demo

Part 1: Context-Aware Policies (10 minutes):

Connect Data Source (PIP):
- Show Okta integration
- Real-time user data sync
- Attribute mapping
Create Context-Aware Policy:

package demo.context_aware

import rego.v1

default allow := false

allow if {
    # Real-time data from Okta
    user := data.policy_data.okta.identity.users[input.user.id]
    user.status == "ACTIVE"
    "Finance_Team" in user.groups
    
    # Time-based access
    is_business_hours
    
    # MFA required for sensitive data
    input.user.attributes.mfa_verified == true
}

Demonstrate Policy Enforcement:
- Test during business hours ✅
- Test outside business hours ❌
- Test with/without MFA ✅/❌

Part 2: Compliance Scenarios (10 minutes):

FINTRAC Large Cash Transaction:
- Show payment transaction page
- Attempt transaction > $10,000 CAD
- Show policy requiring FINTRAC certification
- Demonstrate automatic logging
OSFI Segregation of Duties:
- Show user with both initiator and approver roles
- Demonstrate automatic blocking
- Show compliant scenario

Part 3: AI Security (10 minutes):

AI Prompt Filtering:
- Navigate to AI Chat
- Try prompt with PII → Blocked
- Try normal prompt → Allowed
- Show filtered response
AI Content Injection:
- Show how Control Core adds context to prompts
- Demonstrate response sanitization
- Explain compliance benefits

Demo Best Practices

Preparation Checklist:

During Demo:

Start with simple scenarios
Build complexity gradually
Show real-time changes
Highlight compliance benefits
Answer questions but stay on track
Keep audit logs visible

Common Demo Mistakes to Avoid:

Don't assume everyone knows Rego
Don't rush through policy creation
Don't skip the "before" state
Don't forget to show audit logs
Don't oversell - let product speak

🛡️ Using for Policy Development

Development Workflow

1. Identify Requirement:

Business Need: "Only compliance officers can approve FINTRAC reportable transactions"

2. Create Test Cases First (TDD):

package demo.fintrac_tests

import rego.v1

# Test: Compliance officer can approve
test_compliance_officer_can_approve if {
    allow with input as {
        "user": {
            "id": "user-1",
            "roles": ["compliance-officer"],
            "attributes": {"fintrac_certified": true}
        },
        "transaction": {
            "amount": 15000,
            "currency": "CAD"
        }
    }
}

# Test: Regular user cannot approve
test_regular_user_denied if {
    not allow with input as {
        "user": {
            "id": "user-2",
            "roles": ["teller"]
        },
        "transaction": {
            "amount": 15000,
            "currency": "CAD"
        }
    }
}

3. Implement Policy:

package demo.fintrac

import rego.v1

default allow := false

allow if {
    input.transaction.amount >= 10000
    input.transaction.currency == "CAD"
    input.user.roles[_] == "compliance-officer"
    input.user.attributes.fintrac_certified == true
}

4. Test Against Demo App:

# Login as different users
# Navigate to payment transactions
# Try to approve large transactions
# Verify policy works as expected

5. Refine and Iterate:

Add edge cases
Handle missing data
Optimize performance
Add documentation

6. Deploy to Production:

Deploy to sandbox first
Test with real users (if safe)
Promote to production
Monitor decision logs

Testing Patterns

Pattern 1: User Role Testing

# Test matrix
Users: [admin, manager, analyst, hr, finance]
Resources: [clients, employees, financial, analytics, payments]
Actions: [read, write, delete, approve]

# Systematically test all combinations
for user in users:
    for resource in resources:
        for action in actions:
            test(user, resource, action)
            verify_expected_result()

Pattern 2: Boundary Testing

# Test transaction thresholds
test_amounts = [9999, 10000, 10001]  # Around FINTRAC threshold

for amount in test_amounts:
    test_transaction(amount)
    verify_reporting_requirement()

Pattern 3: Context Testing

# Test time-based policies
test_times = [
    "2025-01-25T08:00:00Z",  # Before business hours
    "2025-01-25T12:00:00Z",  # During business hours
    "2025-01-25T18:00:00Z",  # After business hours
]

for time in test_times:
    test_with_time(time)
    verify_access_decision()

📌 Using for Learning

Learning Path

Week 1: Basics

Deploy demo app
Explore features as different users
Create first simple policy
Test policy with demo app
Review decision logs

Week 2: Rego Fundamentals

Learn Rego syntax
Create RBAC policies
Test with demo users
Add test cases
Practice debugging

Week 3: Advanced Patterns

Attribute-based access control
Time and location-based policies
Data filtering
Context-aware policies

Week 4: Integrations

Connect demo database as PIP
Use database data in policies
Test multi-source policies
Practice incremental sync

Week 5: Compliance

Implement FINTRAC policies
Implement OSFI segregation of duties
Implement HIPAA minimum necessary
Test compliance scenarios

Week 6: AI Security

AI agent access control
Prompt filtering
Content injection
Response sanitization

Hands-On Exercises

Exercise 1: Basic RBAC

Task: Create policy where only HR users can access employee data

package exercise.hr_access

import rego.v1

# Your solution here

Expected behavior:

hr user → Can access /employees ✅
finance user → Cannot access /employees ❌

Exercise 2: Department-Based Access

Task: Users can only see data from their department

package exercise.department

import rego.v1

# Your solution here

Test with:

Finance user accessing financial data ✅
Finance user accessing HR data ❌

Exercise 3: FINTRAC Reporting

Task: Transactions ≥ $10,000 CAD require FINTRAC-certified officer

package exercise.fintrac

import rego.v1

# Your solution here

Test with payment transactions page.

Exercise 4: Time-Based Access

Task: Analytics only accessible during business hours (9 AM - 5 PM)

package exercise.time_based

import rego.v1

# Your solution here

Test at different times.

📌 Configuration

Environment Variables

The demo app uses environment variables for all configuration. The automated setup script creates a .env file with default values, but you can customize these:

Backend Configuration (`demo-app-api/.env`)

# Database Configuration
DATABASE_URL=postgresql://demo_user:demo_password@localhost:5433/demo_app

# API Configuration
API_BASE_URL=http://localhost:8000
FRONTEND_BASE_URL=http://localhost:3000

# LLM Configuration (choose one or more providers)
# For Groq/Grok (Free tier available)
GROK_API_KEY=your_grok_api_key_here
# For OpenAI
OPENAI_API_KEY=your_openai_api_key_here
# For Anthropic Claude
ANTHROPIC_API_KEY=your_anthropic_api_key_here
# For Hugging Face
HUGGINGFACE_API_KEY=your_huggingface_api_key_here
# For Google AI/Gemini
GOOGLE_AI_API_KEY=your_google_ai_api_key_here

# GitHub Repository Configuration (for Policy Sync)
POLICY_REPO_URL=https://github.com/your-org/control-core-policies
GITHUB_TOKEN=your_github_token_here
POLICY_REPO_BRANCH=main

# Security
SECRET_KEY=demo_secret_key_change_in_production
JWT_SECRET=demo_jwt_secret_change_in_production

# Demo Mode
DEMO_MODE=true
AUTO_SETUP=true

Frontend Configuration (`demo-app/.env.local`)

# API Base URL for browser requests.
# When bouncer is deployed, this MUST point to bouncer entrypoint.
NEXT_PUBLIC_API_BASE_URL=http://localhost:8080

# Optional server-side API URL (Next.js routes)
# Keep bouncer as default and use internal direct URL only for controlled bootstrap paths.
DEMOAPP_API_URL=http://demo-app-api:8080
DEMOAPP_INTERNAL_API_URL=http://demo-app-api:8000

# Optional: App Name and Version
NEXT_PUBLIC_APP_NAME=Control Core Demo App
NEXT_PUBLIC_APP_VERSION=1.0.0

Getting LLM API Keys

The Demo App supports multiple LLM providers. You can use any of the following providers based on your preferences and requirements:

Supported LLM Providers

The Demo App supports the following LLM providers:

Groq (Free tier available) - Fast inference, great for demos
OpenAI (GPT-4, GPT-3.5) - High-quality responses, paid
Anthropic Claude - Advanced reasoning, paid
Google AI/Gemini - Multimodal capabilities, paid
Hugging Face - Open-source models, free tier available
Ollama - Local/self-hosted models, free
Azure OpenAI - Enterprise OpenAI via Azure
AWS Bedrock - Amazon's managed LLM service
Cohere - Enterprise language models
Custom LLM - Connect your own LLM service

Groq (Free, Recommended for Demos)

Groq provides fast inference with a generous free tier, making it ideal for demonstrations:

Visit Groq Console: Open the Groq console in your browser
Sign Up: Create a free account with your email (no credit card required)
Navigate to API Keys:
- Click on your profile icon in the top right
- Select "API Keys" from the dropdown menu
- Go directly to the API Keys page in Groq console
Create API Key:
- Click "Create API Key"
- Give it a name (e.g., "Control Core Demo App")
- Copy the generated key immediately (you won't be able to see it again)
Configure the Key:
- Add to .env file: GROK_API_KEY=your_key_here
- Or configure in Demo App UI: Navigate to AI Chat → Settings → Configure AI Provider

Benefits: Free tier with generous rate limits, no credit card required, fast inference

OpenAI (GPT-4, GPT-3.5)

For high-quality AI responses, OpenAI offers GPT-4 and GPT-3.5 models:

Visit OpenAI Platform: Open the OpenAI platform in your browser
Sign Up or Log In: Create an account (credit card required for paid usage)
Navigate to API Keys:
- Go to API Keys section in OpenAI platform
- Or: Settings → API Keys
Create API Key:
- Click "Create new secret key"
- Give it a name
- Copy the key immediately
Configure the Key:
- Add to .env file: OPENAI_API_KEY=your_key_here
- Or configure in Demo App UI

Benefits: High-quality responses, advanced reasoning, widely supported

Anthropic Claude

Anthropic's Claude models offer advanced reasoning and safety features:

Visit Anthropic Console: Open the Anthropic console in your browser
Sign Up: Create an account (credit card required)
Navigate to API Keys:
- Go to API Keys section
- Or: Settings → API Keys
Create API Key:
- Click "Create Key"
- Copy the key immediately
Configure the Key:
- Add to .env file: ANTHROPIC_API_KEY=your_key_here
- Or configure in Demo App UI

Benefits: Advanced reasoning, safety-focused, long context windows

Google AI/Gemini

Google's Gemini models offer multimodal capabilities:

Visit Google AI Studio: Open Google AI Studio in your browser
Sign In: Use your Google account
Create API Key:
- Click "Create API Key"
- Select or create a Google Cloud project
- Copy the key
Configure the Key:
- Add to .env file: GOOGLE_AI_API_KEY=your_key_here
- Or configure in Demo App UI

Benefits: Multimodal (text, images), free tier available, Google Cloud integration

Hugging Face (Free Tier Available)

Hugging Face provides access to open-source models:

Visit Hugging Face: Open Hugging Face in your browser
Sign Up: Create a free account
Get Access Token:
- Go to Settings -> Access Tokens in Hugging Face
- Click "New token"
- Select permissions (read access minimum)
- Copy the token
Configure the Token:
- Add to .env file: HUGGINGFACE_API_KEY=your_token_here
- Or configure in Demo App UI

Benefits: Free tier available, access to many open-source models, community-driven

Ollama (Local/Self-Hosted)

Ollama allows you to run models locally without API keys:

Install Ollama: Visit the Ollama website and download
Run Locally:
- Install Ollama on your machine
- Pull models: ollama pull llama2 or ollama pull mistral
- Ollama runs on http://localhost:11434 by default
Configure:
- Set base URL in Demo App UI: http://localhost:11434
- No API key required for local usage

Benefits: Free, private, no internet required, full control

Azure OpenAI

For enterprise deployments using Microsoft Azure:

Azure Portal: Open Azure Portal in your browser
Create OpenAI Resource:
- Create an Azure OpenAI resource
- Deploy a model (GPT-4, GPT-3.5)
Get API Key:
- Go to your OpenAI resource → Keys and Endpoint
- Copy the API key and endpoint
Configure:
- Add to .env: AZURE_OPENAI_API_KEY=your_key_here and AZURE_OPENAI_ENDPOINT=your_endpoint
- Or configure in Demo App UI with custom base URL

Benefits: Enterprise-grade, Azure integration, compliance features

AWS Bedrock

For Amazon Web Services deployments:

AWS Console: Open AWS Bedrock console in your browser
Enable Bedrock: Enable Bedrock service in your AWS account
Get Credentials: Use AWS IAM credentials (Access Key ID and Secret Access Key)
Configure:
- Set AWS credentials in environment or Demo App UI
- Configure region and model selection

Benefits: AWS integration, enterprise features, multiple model options

Custom LLM Provider

You can connect your own LLM service:

Prepare Your LLM Service:
- Ensure it supports OpenAI-compatible API format
- Or configure custom API endpoints
Configure in Demo App UI:
- Select "Custom LLM" provider
- Enter your API endpoint URL
- Provide API key if required
- Configure model name

Benefits: Full control, use your own infrastructure, custom models

Configuration via UI

The easiest way to configure LLM providers is through the Demo App UI:

Navigate to AI Chat: Go to the AI Chat Assistant page
Open Settings: Click "Configure AI Provider" or look for AI Configuration in sidebar
Add Provider:
- Select your preferred provider from the dropdown
- Enter your API key
- Select a model
- Optionally configure base URL (for custom providers)
- Test the connection
- Save configuration
Set Default: Mark one provider as default for automatic use

Note: You can configure multiple providers and switch between them as needed. The Demo App will use your default provider unless you specify otherwise.

GitHub Token (For Policy Sync)

If you want to sync policies with a GitHub repository, you'll need a GitHub Personal Access Token:

Go to GitHub Settings:
- Log in to GitHub
- Click your profile icon → Settings
- Navigate to: Developer settings → Personal access tokens → Tokens (classic)
- Or go directly to Personal Access Tokens in your GitHub account settings
Generate New Token:
- Click "Generate new token" → "Generate new token (classic)"
- Give it a descriptive name (e.g., "Control Core Policy Sync")
- Set expiration (recommended: 90 days or custom)
- Select scopes:
  - ✅ repo (Full control of private repositories) - Required for private repos
  - ✅ public_repo (Access public repositories) - Required if using public repos
- Click "Generate token"
Copy Token:
- Copy the token immediately (you won't be able to see it again)
- Store it securely
Configure the Token:
- Add to .env file: GITHUB_TOKEN=your_token_here
- Or configure in Control Core: Settings → Controls Repository → GitHub Configuration

Important:

Tokens provide access to your repositories - keep them secure
Never commit tokens to version control
Rotate tokens regularly (every 90 days recommended)
Revoke tokens immediately if compromised

Configuration via UI

Many settings can be configured directly in the Demo App UI:

AI Configuration: Navigate to AI Chat → Settings → Configure AI Provider
User Preferences: User profile settings
API Endpoints: Configured via environment variables

📌 Sample Data Overview

The demo app includes realistic sample data for testing:

Clients (50+)

Mix of small, medium, and large businesses
Various industries (tech, finance, healthcare)
Different risk levels
Geographic diversity
Contract statuses

Employees (25+)

Multiple departments (IT, Finance, HR, Operations)
Various clearance levels
Different work schedules (office, hybrid, remote)
Training and compliance statuses
Manager hierarchy

Financial Records (100+)

Revenue data across quarters
Expense categories
Profit margins
Budget vs actual

Transactions (200+)

Payment transactions
Various amounts (including FINTRAC-reportable)
Multiple currencies
Different transaction types
Timestamps for pattern analysis

Medical Records (Healthcare Demo)

Patient demographics
Care team assignments
Medical conditions
Treatment records
Insurance information

📌 Connecting Demo App to Control Core

Step 1: Deploy Both Systems

# Terminal 1: Control Core
cd deployment-assets/docker-compose
docker-compose up -d

# Terminal 2: Demo App
cd demo-app
./infra/start-dev.sh

Step 2: Configure Bouncer

# Edit Bouncer .env
nano control-core-bouncer/.env

# Set target to demo app
TARGET_HOST=localhost:8000
BOUNCER_PORT=8080

# Restart Bouncer
cd control-core-bouncer
docker-compose restart bouncer

Step 3: Update Demo App Configuration

# Point demo app to Bouncer instead of direct API
export NEXT_PUBLIC_API_BASE_URL=http://localhost:8080

# Server-side routes should also use bouncer by default
export DEMOAPP_API_URL=http://demo-app-api:8080
export DEMOAPP_INTERNAL_API_URL=http://demo-app-api:8000

# Restart demo app
cd demo-app
npm run dev:3001

Step 3.1: Run a bypass sanity check

# Good: bouncer health reachable
curl -sS http://localhost:8080/health

# Expected in hardened deployments:
# direct upstream app port is not exposed to end users
curl -i http://localhost:8000/health

Step 4: Create Resource in Control Core

# Via API
curl -X POST http://localhost:8082/api/v1/resources \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Demo App API",
    "type": "api",
    "path": "/api/*",
    "methods": ["GET", "POST", "PUT", "DELETE"],
    "attributes": {
      "application": "demo-app",
      "environment": "development"
    }
  }'

Step 5: Test End-to-End

# 1. Create policy in Control Core
# 2. Access demo app (goes through Bouncer)
# 3. Verify policy enforced
# 4. Check decision logs

📌 Advanced Usage

Custom Sample Data

Add Your Own Test Data:

# Connect to demo database
docker exec -it demo-postgres psql -U demo_user -d demo_app

# Add custom client
INSERT INTO clients (name, industry, tier, country, risk_level)
VALUES ('Test Corp', 'Technology', 'enterprise', 'Canada', 'low');

# Add custom employee
INSERT INTO employees (name, department, role, clearance_level)
VALUES ('Test User', 'Finance', 'analyst', 3);

# Add custom transaction
INSERT INTO payment_transactions (customer_id, amount, currency, type, status)
VALUES (1, 15000, 'CAD', 'wire_transfer', 'pending');

Testing with PIP Integration

Connect Demo Database as PIP:

In Control Core → Integrations → Data Sources
Add PostgreSQL connection:
- Host: localhost
- Port: 5433
- Database: demo_app
- User: demo_user
- Password: demo_password
Map attributes:
- resource.owner → owner_id
- resource.department → department
- customer.risk_score → risk_level
Use in policies:

allow if {
    # Real data from demo database
    customer := data.policy_data.postgresql.database.customers[input.resource.customer_id]
    customer.risk_level == "low"
}

Performance Testing

Load Testing:

# Install Apache Bench
sudo apt-get install apache2-utils

# Test API performance
ab -n 10000 -c 100 http://localhost:8080/api/clients

# Results show:
# - Requests per second
# - Latency distribution
# - Policy evaluation overhead

Stress Testing:

# Use wrk for advanced load testing
wrk -t12 -c400 -d30s http://localhost:8080/api/clients

# Monitor Bouncer metrics
curl http://localhost:8080/api/v1/metrics

🛠️ Troubleshooting Demo App

Common Issues

Issue: Demo app won't start

# Check port conflicts
lsof -i :3001
lsof -i :8000
lsof -i :5433

# Use alternative ports
npm run dev:3002  # Frontend on 3002

# Check logs
docker-compose logs demo-api
docker-compose logs demo-db

Issue: Cannot login

# Verify database has demo users
docker exec demo-postgres psql -U demo_user -d demo_app -c "SELECT username, role FROM users;"

# Expected output:
#  username | role
# ----------+--------
#  admin    | admin
#  manager  | manager
#  analyst  | analyst
#  hr       | hr
#  finance  | finance

# Reset database if needed
python init_db.py

Issue: No data showing

# Check database has sample data
docker exec demo-postgres psql -U demo_user -d demo_app -c "SELECT COUNT(*) FROM clients;"

# Should show 50+

# Reload sample data
python init_db.py --reload-data

Issue: API not responding

# Check API health
curl http://localhost:8000/health

# Check API logs
docker-compose logs demo-api | tail -50

# Check database connection
docker-compose logs demo-api | grep -i database

# Restart API
docker-compose restart demo-api

📌 Demo Scenarios Library

Financial Services Scenarios

Scenario 1: FINTRAC Transaction Monitoring

User: finance
Feature: Payment Transactions
Policy: FINTRAC LCTR (>$10,000 CAD)
Demo: Show automatic flagging and approval workflow

Scenario 2: OSFI Segregation of Duties

Users: Create user with conflicting roles
Feature: Transaction approval
Policy: OSFI segregation policy
Demo: Show automatic blocking of conflict

Scenario 3: AML Customer Due Diligence

User: manager
Feature: Client Management
Policy: KYC verification required
Demo: Block access to un-verified customers

Healthcare Scenarios

Scenario 1: HIPAA Minimum Necessary

User: hr (acting as nurse)
Feature: Medical Center
Policy: Minimum necessary PHI
Demo: Show field-level filtering

Scenario 2: Break-the-Glass Emergency Access

User: admin (acting as emergency physician)
Feature: Medical records
Policy: Emergency access with audit
Demo: Show emergency override with logging

AI Security Scenarios

Scenario 1: AI Prompt Filtering

User: analyst
Feature: AI Chat
Policy: Block prompts with PII
Demo: Show rejected prompts

Scenario 2: AI Response Sanitization

User: finance
Feature: Financial AI
Policy: Mask sensitive data in responses
Demo: Show redacted content

📌 Resources

Demo App Documentation: In-app help at /help
API Documentation: http://localhost:8000/devdocs
Sample Policies: Available in Control Core template library
Training Videos: Coming soon

📌 Next Steps

Deploy Demo App: Get started with one command
Run Demo: 15-minute demo flow
Test Policies: Validate before production
Learn Control Core: Hands-on exercises

📞 Support

Demo Setup Help: support@controlcore.io
Demo Best Practices: Request demo training
Custom Scenarios: We can help build custom demo scenarios
Troubleshooting: General Troubleshooting Guide

The Demo Application is your sandbox for mastering Control Core. Experiment freely, break things, learn, and build confidence before deploying to production!

📘 Demo Application Guide

📌 What is the Demo Application?

Key Characteristics

📌 Why Use the Demo Application?

1. Testing Policies

2. Internal Demonstrations

3. Policy Development

4. Learning and Training

🚀 Deployment

Prerequisites

No-Bypass Configuration Chart

Quick Start Deployment

Option 2: Manual Deployment

Option 3: Docker Compose Deployment

📌 Demo Users and Access Levels

Admin User

Manager User

Analyst User

HR User

Finance User

🛡️ Using for Policy Testing

Testing Workflow

Test Scenarios

📌 Using for Internal Demos

15-Minute Standard Demo

30-Minute Comprehensive Demo

Demo Best Practices

🛡️ Using for Policy Development

Development Workflow

Testing Patterns

📌 Using for Learning

Learning Path

Hands-On Exercises

📌 Configuration

Environment Variables

Backend Configuration (demo-app-api/.env)

Frontend Configuration (demo-app/.env.local)

Getting LLM API Keys

Supported LLM Providers

Groq (Free, Recommended for Demos)

OpenAI (GPT-4, GPT-3.5)

Anthropic Claude

Google AI/Gemini

Hugging Face (Free Tier Available)

Ollama (Local/Self-Hosted)

Azure OpenAI

AWS Bedrock

Custom LLM Provider

Configuration via UI

GitHub Token (For Policy Sync)

Configuration via UI

📌 Sample Data Overview

Clients (50+)

Employees (25+)

Financial Records (100+)

Transactions (200+)

Medical Records (Healthcare Demo)

📌 Connecting Demo App to Control Core

Step 1: Deploy Both Systems

Step 2: Configure Bouncer

Step 3: Update Demo App Configuration

Step 3.1: Run a bypass sanity check

Step 4: Create Resource in Control Core

Step 5: Test End-to-End

📌 Advanced Usage

Custom Sample Data

Testing with PIP Integration

Performance Testing

🛠️ Troubleshooting Demo App

Common Issues

📌 Demo Scenarios Library

Financial Services Scenarios

Healthcare Scenarios

AI Security Scenarios

📌 Resources

📌 Next Steps

📞 Support

Backend Configuration (`demo-app-api/.env`)

Frontend Configuration (`demo-app/.env.local`)