Cortega AI Governance Platform v1.0.4

Cortega AI Governance Platform v1.0.4

Cortega 1.0.4 is a feature release on 1.0.3. Install paths, first login, and the three deployment topologies (local Docker, AWS, Terraform) are unchanged. Use this package instead of 1.0.3 for new installs and upgrades.

Download

Download cortega-1.0.4.tar.gz from this release and extract it on the machine where you will run the installer or manage the deployment.

The package contains deployment scripts, Docker Compose files, Terraform roots, customer guides, third-party notices, and a MANIFEST.json with the exact Cortega image tags tested for this release. Source code is not included in the customer package.

Upgrade an existing 1.0.3 install with the same path you used originally (deploy/aws/deploy.sh, deploy/terraform/manage.sh <cloud> upgrade, or the compose recreate in deploy/existing-environment-install.md). The control plane applies database migrations on startup.

Upgrade notes

Before upgrading, check for duplicate enabled LLM model routing keys (migration 000094 will fail if any exist):

SELECT lower(coalesce(nullif(model_id, ''), name)) AS routing_key,
       count(*) AS enabled_count
FROM llm_models
WHERE enabled
GROUP BY 1
HAVING count(*) > 1;

Disable or rename duplicates before upgrading. See docs/product/db-migrations.md.

Operational changes after upgrade:

• Pass-through routing mode is removed (migrations 000095/000096). Clients that forwarded their own upstream credential without a Cortega identity must switch to a strict identity plus the configured upstream credential header (upstream_credential_header, default X-Cortega-Upstream-Authorization).
• Edge dynamic SSO enrollment no longer uses an install-wide toggle. Configure allowed email domains per tenant under System → Tenants (tenant_edge_registration_domains, migration 000099).
• Direct model selection is now per-tenant (migration 000097). Existing tenants inherit the prior global setting on upgrade.

What's new

Edge provisioning & AI Verifier

• No silent tenant creation on first SSO sign-in. Unknown emails follow a defined resolution path: existing user → domain list match → pending approval.
• Per-tenant SSO enrollment domains replace the install-wide "Allow Dynamic" toggle. Tenant 0 admins set allowed email domains at tenant create/edit.
• AI Verifier Pro vs Enterprise (tenant_entitlements.verifier_package, migration 000098): Pro is a single seat with exact-email provisioning; Enterprise remains a pooled seat model.
• POST /api/v1/edge/access-request — unauthenticated "Request access" from the Verifier sign-in screen (business email, full name, optional note).
• Pending Approval improvements — cross-tenant visibility for platform admins; provision Verifier Pro from a pending row; optional request note on the approval screen (migration 000100).
• SSO device flow errors are surfaced to the native app via edge_sso_device_sessions.failure_reason (migration 000101) instead of timing out silently.
• Native Verifier app (macOS + Windows) — refreshed sign-in UX (Cortega.AI / Enterprise tabs), on-light branding, sign-out / reset saved sign-in, and stability fixes for frozen restart and disappearing errors.

Model routing, providers & gateway auth

• Global routing-key uniqueness among enabled models (migration 000094). Two enabled models may not resolve to the same gateway routing key across providers; API returns 409 on collision.
• Pass-through routing removed in favour of client-supplied upstream credentials with a strict Cortega identity (migrations 000095/000096). LLM providers and MCP servers with passthrough credential/auth type forward the client's header value upstream.
• Per-tenant direct model selection (migration 000097). Tenant admins toggle whether identities may address a concrete model directly vs. team router only.
• Disabling a provider now disables all of its models in the database (not just at gateway render time).
• Team identity fixes for Playground and MCP api-key callers — tenant-qualified team metadata matches MCP authorization policy, restoring MCP Playground tool listing for the Default team.

Console, guided setup & in-product help

• Guided LLM setup wizard — provider → model → identity → model authorization in one flow; skips disabled providers.
• Guided MCP setup wizard — server → tools → identity authorization.
• Model Playground — model picker hidden when direct model selection is off; Playground Key determines team routing; cleaner error messages (team names without tenant UUID prefixes).
• MCP Playground — Playground Key on Default team exercises normal MCP authorization (tool list no longer empty due to team mismatch).
• In-product Help (/help) — searchable customer-facing guides shipped with the SPA.

Insights & Model Intel

• Insights → Recommendations — tenant selector includes All tenants for Tenant 0 aggregate view; deep-link opens the Recommendations tab directly.
• Insights → Workload — models × workload-category matrix from Cortega Agents Workload Analyzer traffic (GET /api/v1/insights/workload-report).
• Model Intel — canonical model collapse, seller allowlist sync, richer recommendation UI, and Cortega config integration for catalog alignment.

Cortega Agents

• Workload Analyzer classifications feed the new Insights Workload tab.
• Console and Research views updated for workload-domain threads and usage reporting.

Deploy & operations

• Multicloud Terraform install paths (AWS, Azure, GCP) and related runbook updates.
• ClickHouse low-memory overlay fixes for 8 GiB core hosts; Superset URL pin fix on no-LB topologies.
• Load balancer combined-pool URL advertising; Presidio image registry migration; gateway compose reliability fixes.
• Prometheus file_sd directory permission race fix (deploy no longer fails mid-upgrade).

First login

Unchanged from prior 1.0.x releases:

Email:    admin@cortega.local
Password: cortega-admin

Change the bootstrap password immediately after signing in.

Guides

See docs/guides/ in the package, especially edge-agent-deployment-guide.md, mcp-servers-guide.md, user-guide.md, identity-design.md (via Help), clickhouse-lowmem.md, aws-runbook.md, and terraform-runbook.md.

For Edge provisioning detail, see docs/product/edge-provisioning-flows.md in the source repository.

Cortega AI Governance Platform v1.0.3

Cortega AI Governance Platform v1.0.3

Cortega 1.0.3 is a patch release on 1.0.2. Install, first login, and the three deployment paths are unchanged. Use this package instead of 1.0.2 for new installs and upgrades.

Download

Download cortega-1.0.3.tar.gz from this release and extract it on the machine where you will run the installer or manage the deployment.

The package contains deployment scripts, Docker Compose files, Terraform roots, customer guides, third-party notices, and a MANIFEST.json with the exact Cortega image tags tested for this release. Source code is not included in the customer package.

Upgrade an existing 1.0.2 install with the same path you used originally (deploy/aws/deploy.sh, deploy/terraform/manage.sh <cloud> upgrade, or the compose recreate in deploy/existing-environment-install.md). The control plane applies database migrations on startup.

What's new

Insights (ClickHouse)

• Fixed a memory-configuration bug where the low-memory ClickHouse overlay was applied on every host regardless of actual available memory. On standard 8 GiB instances this could cap ClickHouse's usable memory to roughly 200 MiB, causing Insights aggregation queries to fail with a memory-limit error. The overlay now only applies on genuinely low-memory hosts (below 6 GiB), and 4 GiB hosts get a corrected memory ceiling so the intended cap is the one that actually takes effect.
• Fixed Insights/Superset returning a 404 on load-balanced installs, caused by the deploy template pinning Superset's URL to the non-load-balanced address.

Deploy reliability

• Fixed a deploy that could fail at its very last step, with an on-disk permission error, even though every application service had already started up successfully. This affected single-node AWS and Terraform installs.
• The AWS installer now warns when a topology setting you've edited directly in deploy/aws/.env (for example, load-balancer enablement) disagrees with the install's already-provisioned state, instead of silently discarding your edit. It points you at deploy/aws/setup.sh / refresh-state.sh as the supported way to change topology after initial setup.

First login

Unchanged from prior 1.0.x releases:

Email:    admin@cortega.local
Password: cortega-admin

Change the bootstrap password immediately after signing in.

Guides

See docs/guides/ in the package, especially aws-runbook.md, terraform-runbook.md, and clickhouse-lowmem.md.

Cortega AI Governance Platform v1.0.2

Cortega AI Governance Platform v1.0.2

Cortega 1.0.2 is a patch release on 1.0.1. Install, first login, and the three deployment paths are unchanged. Use this package instead of 1.0.1 for new installs and upgrades.

Download

Download cortega-1.0.2.tar.gz from this release and extract it on the machine where you will run the installer or manage the deployment.

The package contains deployment scripts, Docker Compose files, Terraform roots, customer guides, third-party notices, and a MANIFEST.json with the exact Cortega image tags tested for this release. Source code is not included in the customer package.

Upgrade an existing 1.0.0 or 1.0.1 install with the same path you used originally (deploy/aws/deploy.sh, deploy/terraform/manage.sh <cloud> upgrade, or the compose recreate in deploy/existing-environment-install.md). The control plane applies database migrations on startup.

What's new

Multi-tenancy

Existing single-tenant installs keep the same behavior. Platform operators can now run more than one tenant on one Cortega install.

• Tenants (under System) lists every tenant and lets a System admin add one. Each tenant can be configured with AI Gateway (monthly credits), AI Firewall (seats), and AI Verifier (seats). Tenant 0 is labeled System in the UI.
• Teams, identities, users, guardrails, MCP servers, audit logs, observability, Insights, Cortega Agents, and Edge are scoped to the signed-in tenant. A request that cannot be attributed to a tenant is rejected.
• System admins can see and manage users across tenants, assign a tenant when adding a user or approving SSO, and see the current tenant in the top bar. Gateways, License, and Platform Health stay System-only.
• The Administrator role can only be assigned in the System tenant. Other tenants use a tenant admin role.
• On a multi-tenant install, Pass-Through Routing cannot be enabled. MCP OAuth/JWT, Basic Auth, and OIDC identities cannot be created there either — use Generic JWT (and API keys).

Identities and Client Setup

• Generic JWT and API key identities can now be enabled together on the same LLM or MCP surface. The gateway accepts a validated JWT or a known key on Authorization: Bearer. MCP OAuth/JWT still cannot share that header with API keys.
• Two tenants can each configure Generic JWT. If they share an IdP issuer, each must set a distinct Audience so the gateway can tell their tokens apart.
• Client Setup has a Where the client runs toggle (same network vs outside) and lists internal and external LLM, MCP, and HTTP gateway URLs.

Model Intel and Insights

• Insights includes a Recommendations tab. When Model Intel is configured, it uses the last 30 days of that tenant's traffic to suggest upgrades and alternates for the models you already run, with a short explanation of why.
• Provider diagnostics link through to the same recommendations for a focused model.
• Model Intel is an independently deployed catalog/recommend service. It is not inside cortega-1.0.2.tar.gz. Point Cortega at it with the Model Intel settings in the install env; those settings now survive AWS and Terraform upgrades.

Cortega Agents

• Cortega Agents ingest, cost, and API access are tenant-scoped. One tenant cannot see another tenant's findings or usage.
• Workload Analyzer (off by default, under Cortega Agents → Settings) classifies in-scope exchanges into productized workload categories. The category catalog comes from Model Intel when it is configured.

EdgeSafe (control plane)

• Edge enrollment, devices, apps, and observability are scoped to the tenant. Each tenant has its own JWT signing key. Enrollment CAs are associated with a target tenant so a device certificate resolves which tenant it belongs to.
• Shared-secret enrollment (EDGE_AGENT_ENROLLMENT_KEY) is removed. Enroll with SSO or a per-device client certificate (MDM-issued or Cortega-issued). Devices already using the old shared key must re-enroll.
• Observation ingest no longer trusts a client-submitted device_id. Device identity comes from the verified Edge token.
• On hosted Cortega, a first-time Edge Verifier "Continue with Google" signup can auto-provision a Verifier tenant (and reuse it on return) instead of landing in System.
• The Windows Edge agent now installs as a machine-wide service, matching the macOS LaunchDaemon model, with the same QUIC/connection-coalescing protections.

Native EdgeSafe installers remain separate from this Core Gateway package. Use the latest EdgeSafe macOS release alongside this control-plane version. A Windows installer is packaged separately when published.

Install and Insights (ClickHouse)

• Optional Cortega Agents, legal-data, and Model Intel env values are in the AWS and Terraform templates and are copied into the core runtime env on deploy, so upgrades no longer drop them.
• A ClickHouse low-memory overlay is available for ~4 GiB core/single-node hosts so Insights and Presidio stay on without ClickHouse crowding out the rest of the stack. See docs/guides/clickhouse-lowmem.md.

First login

Unchanged from 1.0.0:

Email:    admin@cortega.local
Password: cortega-admin

Change the bootstrap password immediately after signing in.

Guides

See docs/guides/ in the package, especially identity-guide.md, user-management-guide.md, edge-agent-deployment-guide.md, clickhouse-lowmem.md, aws-runbook.md, and terraform-runbook.md.

1.0.1

Cortega AI Governance Platform v1.0.1

Cortega 1.0.1 is a patch release on 1.0.0. Install, first login, and the three deployment paths are unchanged. Use this package instead of 1.0.0 for new installs and upgrades.

Download

Download cortega-1.0.1.tar.gz from this release and extract it on the machine where you will run the installer or manage the deployment.

The package contains deployment scripts, Docker Compose files, Terraform roots, customer guides, third-party notices, and a MANIFEST.json with the exact Cortega image tags tested for this release. Source code is not included in the customer package.

Upgrade an existing 1.0.0 install with the same path you used originally (deploy/aws/deploy.sh, deploy/terraform/manage.sh <cloud> upgrade, or the compose recreate in deploy/existing-environment-install.md). The control plane applies database migrations on startup.

What's new

Identities, JWT, and playgrounds

• Generic JWT identities can apply to LLM, MCP, or both. Team comes from claim-to-team rules on the identity (sub → Cortega team), then LLM team routers and MCP authorization use that team.
• JWT and API keys cannot share a surface (they both use Authorization: Bearer). Basic Auth can still combine with JWT. At most one Basic Auth identity is allowed on LLM and one on MCP; extra users go in username-to-team rows on that provider.
• Mock / IdP tokens must match Audiences. LLM tokens typically use cortega-llm; MCP tokens use the protected-resource URL. A dual-surface JWT identity must list both audiences. The Model Playground now explains InvalidAudience with the token aud versus the identity's audience list.
• The Identities table is sorted alphabetically by name.

MCP and observability

• MCP Queries shows the server and tool from the actual call, not the session's authorized-server list or the JSON-RPC method name.
• MCP team attribution is restored in Observability (identity team from the MCP authorization hop).
• Creating a second MCP Authorization row for a team that already has one is rejected (409). The New Authorization form hides occupied teams.

Accounts and audit

• Creating a user, signing in, signing out, and changing your own password now write audit-log rows.
• Suspended accounts cannot obtain a session even with a valid password.

EdgeSafe (control plane)

• Device enrollment, enrollment CAs, and per-agent identity/serial are first-class in the management UI (Enrollment, Devices).
• Optional mTLS at the edge ingress for enrolled agents.
• macOS agent packaging and identity import are documented in the Edge agent deployment guide.
• Memory-leak fixes in the Edge agent HTTP client.

Native EdgeSafe installers remain separate from this Core Gateway package. Use the latest EdgeSafe macOS release alongside this control-plane version.

Cortega Agents and AI Bench

• Cortega Agents adds Research and Settings, legal verification (including CourtListener-backed citation checks), and richer finding rationale / sources-checked metadata.
• AI Bench includes a legal hallucination suite and keeps benchmark traffic out of production Observability.
• In the left nav, AI Bench now sits between Cortega Agents and System.

Install and Insights (Superset)

• Terraform installs served over HTTPS no longer hit mixed-content blocks on Insights. Superset is embedded under the app origin (/superset-embed) on load-balanced topologies, matching the AWS scripted path.
• Superset's session cookie is marked Secure when Superset's own public URL is https.
• On AWS/Azure/GCP, port 8088 is open to the public CIDR only when there is no load balancer. With an LB, 8088 is limited to the VPC so Insights stays on the app URL.

First login

Unchanged from 1.0.0:

Email:    admin@cortega.local
Password: cortega-admin

Change the bootstrap password immediately after signing in.

Guides

See docs/guides/ in the package, especially identity-guide.md, edge-agent-deployment-guide.md, aws-runbook.md, and terraform-runbook.md.

Cortega AI Governance Platform v1.0.0

Cortega 1.0.0 is the first public release of the Cortega AI Governance Platform.

Cortega AI Governance Platform includes infrastructure and tools to help you shape, manage and govern your AI traffic without the risk of having data leave your network.

The Cortega Control Plane is a central management point for all platform components.

The Cortega Gateway Cluster is a set of one or more gateways that performs the task for processing AI traffic while shaping and governing it according to policies managed via the Control Plane. The Gateways route MCP and LLM traffic between AI applications, agents, MCP clients, and upstream model providers. It routes governed LLM and MCP traffic so teams can centralize provider access, model routing, identity, guardrails, budgets, observability, and operational controls.

The Cortega EdgeSafe is a complete privacy enabled solution for AI Agents (e.g ChatGPT, Claude, CoPilot etc) and Shadow AI.

Other components include the Cortega AI Bench (specialized Model and Agent benchmarks for regulated domains like healthcare, fintech, legal etc) and Cortega Agents (agents that perform security and compliance analysis).

Download

Download cortega-1.0.0.tar.gz from this release and extract it on the machine where you will run the installer or manage the deployment.

The package contains deployment scripts, Docker Compose files, Terraform roots, customer guides, third-party notices, and a MANIFEST.json with the exact Cortega image tags tested for this release. Source code is not included in the customer package.

Install

Cortega ships with three install paths. They all deploy the same platform images and gateway runtime; choose the path that matches how you want infrastructure created.

AWS scripted install

Use this for a fast AWS deployment managed by Cortega scripts. It supports single-node installs, multi-node installs with dedicated gateway nodes, and an optional load-balancer node.

cp deploy/aws/env.example deploy/aws/.env
$EDITOR deploy/aws/.env

deploy/aws/setup.sh
deploy/aws/deploy.sh

After deployment, open the printed app URL and sign in with the bootstrap admin account. See docs/guides/aws-runbook.md in the package for topology, DNS, Cloudflare, gateway scaling, logs, upgrades, and teardown.

Terraform install for AWS, Azure, or GCP

Use this when you want infrastructure managed by Terraform. The Terraform layer creates the cloud network, firewall rules, VMs, disks, and SSH key; the shared deployer then installs Cortega over SSH.

cd deploy/terraform/aws        # or azure / gcp
cp terraform.tfvars.example terraform.tfvars
$EDITOR terraform.tfvars

./apply.sh

Use deploy/terraform/manage.sh <cloud> endpoints to print app and gateway URLs after deployment. See docs/guides/terraform-runbook.md for day-2 operations, upgrades, state backup guidance, and provider-specific notes.

Bring your own Docker host

Use this for an existing VM, on-prem host, or cloud instance you manage yourself.

cp deploy/.env.example .env
cp .env.provider-keys.example .env.provider-keys   # optional provider keys
$EDITOR .env

docker compose --env-file .env -f deploy/docker-compose.aws-core.yml up -d

docker compose --env-file .env \
  -f deploy/docker-compose.aws-core.yml \
  -f deploy/docker-compose.aws-gateway.yml up -d

See deploy/existing-environment-install.md for the full compose path, optional load balancer, and verification commands.

Main Platform Modules

Core Gateway

The Core Gateway is the foundation of Cortega. It manages the gateway fleet and governs production LLM and MCP traffic before it reaches upstream providers or tools.

Core capabilities include:

• Provider and model management for OpenAI, Anthropic, Gemini, Vertex AI, Amazon Bedrock, Azure, OpenRouter, Groq, Mistral, Ollama, custom endpoints, and other provider-style backends.
• Encrypted provider credential storage, environment-variable credentials loaded only into gateway containers, cloud runtime credentials, stored Bedrock credentials, pass-through client credentials, and no-credential custom providers.
• Model routing through concrete models, named virtual models, and team-specific model authorization policies.
• LLM identities through Cortega-issued virtual keys, with one-time key reveal, rotation, expiration, team assignment, and request attribution.
• Team and provider budgets for spend governance, with gateway-side enforcement rather than reporting-only tracking.
• LLM and MCP guardrails for request and response inspection, including regex detectors, Presidio-backed PII/PHI detection, webhook guardrails, Bedrock Guardrails, ordering controls, and scoped bindings by model, key, MCP server, or MCP tool.
• MCP server registration, tool discovery, upstream authentication, and team-level authorization so MCP callers only see and execute approved servers and tools.
• Observability for LLM, MCP, guardrail, and gateway traffic, including latency, token usage, model/provider selection, cost, outcome, team, identity, and security findings.
• Insights dashboards for team spend, model performance, gateway performance, and security findings.
• Gateway health, config inspection, restart/reconnect controls, platform health checks, audit log, user management, and role-based access control.
• Gateway migration tooling for importing LiteLLM providers, models, teams, budgets, guardrails, MCP servers, users, and virtual keys through a reviewable CLI workflow with plan, approve, apply, and rollback steps.

The included guides in docs/guides/ cover the day-2 workflows: providers and models, identities, MCP servers, MCP authorization, guardrails, pass-through routing, client identification, user management, and gateway migration.

EdgeSafe

Cortega EdgeSafe extends governance to AI traffic that does not naturally point at the Core Gateway, such as browser-based AI tools, desktop AI applications, and local MCP usage on employee laptops.

The EdgeSafe modules in Cortega manage:

• Observability for captured AI and MCP activity.
• Apps policy for deciding which AI domains or native surfaces are ignored, monitored, governed, or denied.
• Registered devices and their last-seen runtime configuration.
• Guardrails that run on the laptop with observe, mask, and reject actions.

Native EdgeSafe installers are separate from this Core Gateway package. The macOS EdgeSafe package is available now at Cortega EdgeSafe for macOS v1.0.0. Windows will be published separately.

Cortega AI Bench

The Cortega AI Bench helps teams test how their governed AI stack behaves before and after policy changes. In this release, the LLM Benchmark module can run industry-specific safety suites through a selected Cortega gateway and model, score whether active guardrails allowed or blocked the expected samples, and preserve benchmark history.

Cortega AI Bench also separates benchmark telemetry from production observability by tagging benchmark traffic and surfacing it in its own observability view. Benchmark families include LLM safety and Agent behavior.

Cortega Agents

Cortega Agents are verification workflows for AI. They are designed to review governed LLM responses and compare factual claims against configured sources or structured reference data.

The current Cortega Agents area is a family of domain verifiers, starting with legal and medical use cases, that can flag fabricated or unsupported claims above and beyond request/response guardrail checks. Cortega Agents covers gaps in traditional AI governance and security solutions that rely solely on guardrails and deep packet inspection (e.g gateways and firewalls or endpoint security solutions).

First Login

After install, open the app URL printed by the installer or configured in .env.

Email:    admin@cortega.local
Password: cortega-admin

Change the bootstrap password immediately after signing in.

Cortega AI Governance Platform v0.0.21

Initial commit

Cortega AI Governance Platform v0.020

0.0.20

Initial commit

Cortega AI Governance Platform v0.0.19

Initial commit