AI-Control-Tower

AI Control Tower is a platform that gives an organization a single control plane for its AI estate. It keeps a registry of every provider, model, agent, application and MCP server; watches every run; and — when you put it in the request path — enforces policy, budgets, routing and tool access on live model and tool calls, while holding the upstream credentials so applications never do.

• What's inside
• Architecture
• Quick start (local)
• Running with Docker Compose
• Configuration
• Demo data, accounts and roles
• Product tour
• Onboarding your AI estate
• Using the gateways from your applications
• API at a glance
• Background jobs
• Management commands
• Running the tests
• Project structure
• Security model
• Troubleshooting
• License

flowchart LR
    subgraph callers["Callers"]
        app["Applications and agents"]
        ide["IDEs and MCP clients"]
        engine["External AI engines"]
    end

    subgraph tower["AI Control Tower"]
        aigw["AI Gateway<br/>/api/v1/gateway/chat/"]
        mcpgw["MCP Gateway<br/>/api/v1/mcp/"]
        a2agw["A2A Gateway<br/>/api/v1/a2a/"]
        telemetry["Telemetry API<br/>/api/v1/executions/"]
        governance["Policies, budgets,<br/>approvals, audit"]
        registry["Registries"]
        ui["Web UI"]
    end

    app --> aigw
    app --> mcpgw
    app --> a2agw
    ide --> mcpgw
    engine --> telemetry
    aigw --> providers["Model providers"]
    mcpgw --> servers["MCP servers"]
    a2agw --> peers["Other agents:<br/>mailboxes and A2A endpoints"]
    aigw -. checks .-> governance
    mcpgw -. checks .-> governance
    a2agw -. checks .-> governance
    registry --- db[("PostgreSQL")]
    governance --- db
    ui --- db
    tower --- redis[("Redis: Celery, Channels, cache")]

The platform runs in two modes, side by side:

• Reporting mode — your engines keep calling their providers directly and report what they did to the telemetry API. The Tower observes and advises; it is never in the request path.
• Gateway mode — applications send model calls to the AI Gateway, tool calls to the MCP Gateway and work for other agents to the A2A Gateway. Policy verdicts become real refusals, budgets become real stops, and every call is recorded.

Everything vendor-specific sits behind an adapter registry in integrations/: providers (openai, generic_rest, mock), agent engines, webhook normalizers, MCP transports (streamable_http, mock) and A2A transports (jsonrpc, mock). Adding a vendor means registering one class, not editing call sites.

Stack: Python 3.12 · Django 6.1 · Django REST Framework 3.18 · Channels 4.3 + Daphne (ASGI and WebSockets) · Celery 5.6 + Redis · PostgreSQL 16 (SQLite for local use) · Bootstrap 5, jQuery and Chart.js · WhiteNoise.

This runs the whole platform on your machine with SQLite, no Docker and no Redis. For every other setup — PostgreSQL and Redis without Docker, a clean install without demo data, connecting real providers and MCP servers, and production deployment — see SETUP.md. For the full technical reference — every setting, the integration contracts of the API and both gateways, operations, troubleshooting and FAQs — see the Technical Guide. How the platform applies the IRGF governance framework — risk tiers, the deployment and change gates, the Control Plane and applications as systems of agents — is in IRGF alignment.

Prerequisites: Python 3.12 and Git.

git clone <your-repository-url> aig-tower
cd aig-tower
python -m venv .venv

Activate the virtual environment:

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

# macOS / Linux
source .venv/bin/activate

pip install -r requirements.txt

Create a file named .env in the project root:

DJANGO_DEBUG=1
USE_SQLITE=1
# No Redis locally: run background tasks in-process instead of queueing them.
CELERY_TASK_ALWAYS_EAGER=1

.env.example is written for Docker Compose (PostgreSQL and Redis on their service hostnames). For a plain local run, the three lines above are all you need; every other setting has a safe development default. See Configuration for the full list.

python manage.py migrate
python manage.py seed_demo

seed_demo builds a realistic organization — Northwind Financial Group — with users, teams, providers, models, agents, applications, 500 executions, budgets, risks, policies, approvals, a governed MCP estate with real gateway traffic, and an A2A estate: published agents, an external reinsurer's agent, contracts between them and real hand-offs, refusals included. It also puts the IRGF lifecycle to work: risk classifications, deployment authorizations for agents and one application, changes waiting at Gate G4, an exception, and the drift the Control Plane finds. It is idempotent; run it again whenever you like.

On its first run it also prints a service-account API key — the only time that key is shown. Copy it: it is how external code talks to the API and the gateways. (Lost it? Open the profile menu → Integrations, open the langgraph-runtime service account and issue a new key there.)

python manage.py runserver 8000

Open http://localhost:8000 and sign in:

runserver already serves ASGI through Daphne, so the live monitor's WebSockets work in development without a separate process.

The Compose file runs the production-shaped stack: PostgreSQL, Redis, the ASGI web server, a Celery worker and Celery beat.

cp .env.example .env
# Edit .env: set DJANGO_SECRET_KEY, and any provider keys you want to use.
docker compose up --build

In a second terminal, load the demo estate and create your own superuser if you want one:

docker compose exec web python manage.py seed_demo
docker compose exec web python manage.py createsuperuser

Then open http://localhost:8000.

The web container sets USE_MANIFEST_STATIC=1, so static files are served compressed and fingerprinted by WhiteNoise.

All configuration is read from environment variables (a .env file in the project root is loaded automatically).

The database never stores a credential. Each provider and MCP server record holds a credential_ref — the name of an environment variable — and the platform resolves the secret at call time. Set those variables in the platform's environment, for example:

OPENAI_API_KEY=sk-...
AZURE_OPENAI_API_KEY=...
GITHUB_MCP_TOKEN=...
GITHUB_COPILOT_TOKEN=...   # reads Copilot seats and billing usage for Developer Tools

The registries show each credential as Resolved or Missing, so you can see at a glance which ones the running platform can actually find.

seed_demo creates these users in Northwind Financial Group, all with the password ControlTower!2026 (change it with --password):

Signing in as different people is the quickest way to see role-based access at work.

Permissions are organization-scoped: the same person can be an Approver in one organization and a Viewer in another.