Use Cases How It Works Agent Deliberation Security Blog Docs Pricing Login Get Started →
Architecture

How Corla works

From context compilation to scoped delivery — a technical walkthrough of the broker architecture, the MCP tool set, and how the security properties hold.

Zone Model

One broker between enterprise knowledge and every agent.

The three-zone model defines where assets live, where compilation happens, and what can cross each boundary. It is a security model, not just a deployment topology.

Zone 1 · Enterprise

Your infrastructure

On-premise or dedicated VPC. You own and operate this zone. Corla never requires direct access to it — assets are fetched by secure content reference only.

  • Raw asset content (prompts, playbooks, skills)
  • Policy definitions (RBAC roles, scopes)
  • Enterprise signing key (encrypted at rest)
  • Immutable audit sink (append-only)
  • Admin console (grant management)
this product
Zone 2 · Broker

Corla managed SaaS

Corla lives here. It fetches asset references (not content) from Zone 1, loads content from secure storage, compiles, signs, and serves. It never persists raw content.

  • OAuth 2.1 token service
  • Policy engine (RBAC evaluation)
  • Compilation pipeline (5 stages)
  • Audit engine + disclosure detection
  • Package cache (Redis, encrypted)
Zone 3 · Member

Member's AI tool

Untrusted by default. Receives only compiled derivatives — signed, scoped, TTL-bounded. Whether the AI tool is Claude Code, Cursor, VS Code, Windsurf, Claude.ai, or ChatGPT, the contract is identical: in-memory context only, never written to disk.

  • ·MCP adapter (CLI) or custom connector (browser)
  • ·AI tool (Claude Code, Cursor, VS Code, Windsurf, Claude.ai, ChatGPT)
  • ·Compiled package (opaque derivative)
  • ·Local repository or workspace
  • No raw asset content. Ever.
Request Flow

14 steps. Developer sees 3.

The developer opens their IDE, uses their AI tool, and gets better output. Everything else is invisible infrastructure.

01
Developer Zone

IDE opens, adapter reads .mcp.json

The MCP adapter discovers the Corla broker endpoint from the project config file written by corla init. No user action required after initial setup.

02
Zone 2→3 Boundary

OAuth 2.1 PKCE authentication

The adapter presents the developer's bearer token. The broker validates it against the Redis revocation list. If revoked or expired, the request is rejected immediately — fail closed.

Token validation always hits Redis. Caching the validation result is explicitly prohibited — it would break the <30s revocation guarantee.
03–04
Zone 2 · Broker

Policy evaluation

The policy engine loads the developer's grant from the database and checks: Is the grant still active? Is it expired? Does the project match the token's project claim? Does the role have the required permissions?

05
Zone 1→2 Boundary

Asset content fetched by reference

The broker resolves content references (S3 keys or vault paths) and loads raw content. This is the only point where raw content exists in Zone 2 — in memory, never persisted, never transmitted further in raw form.

06–07
Zone 2 · Compiler

Compilation pipeline (5 stages)

The raw content passes through the full compilation pipeline: intent extraction → redaction → scope projection → signing → package emission. See the compiler diagram below.

08–09
Zone 2→3 Boundary

Signed package delivered to adapter

The compiled package crosses the trust boundary. The adapter verifies the HMAC signature before accepting it. An invalid signature is a critical security event, logged and reported.

10–11
Developer Zone

Context injected in-memory into AI tool

The adapter injects the compiled package into the AI tool's context window. In-memory only — never written to disk, never in a temp file, never in a log.

12–14
Audit · All Zones

Output filtered, events logged

The AI response passes through an output policy filter. Input and output are hashed (not stored raw) and logged immutably. The audit event is written to the enterprise's audit sink within 5 seconds.

The Compiler

Five stages. Clean structured output.

Raw asset content goes in. A signed, scoped, redacted derivative comes out — useful for AI-assisted work, not reconstructable into the original.

1

Intent extract

Goal, constraints, domain keywords — the metadata safe to expose.

2

Redact

Two-pass redaction: regex (always on) for emails, API keys, JWTs, connection strings. Optional Presidio NER for names, addresses, contextual identifiers. Configurable per enterprise.

3

Scope project

RBAC role ceiling applied. Internal sections removed. Sensitivity filtered.

4

Sign & seal

HMAC-SHA256 with enterprise key. TTL embedded. Canonical JSON.

5

Emit package

Signed CompiledPackage JSON. Cached in Redis. Audited.

What goes in

// RawAsset — stays in Zone 1/2 only
{
  id: "asset_abc123",
  type: "SYSTEM_PROMPT",
  content: `You are a payment processing
    assistant for Acme Corp. Always use
    our internal idempotency key format:
    ACM-{timestamp}-{uuid}. Never log
    card numbers. Contact john@acme.com
    for escalations. API key: sk-prod-...`,
  sensitivity: "HIGH"
}

What comes out

// CompiledPackage — crosses boundary
{
  packageId: "pkg_xyz789",
  expiresAt: 1735000000,
  artifacts: [{
    assetType: "system_prompt",
    content: `You are a payment processing
      assistant. Always use idempotency
      keys. Never log card numbers.
      [EMAIL] [SECRET_REDACTED]`,
    role: "system"
  }],
  signature: "a3f9b2c1...",
  behaviourEnvelope: {
    disclosureRestriction: true
  }
}
Performance

Fast enough to be invisible.

Context delivery adds negligible latency to the AI tool's response time. The developer never notices the security infrastructure working.

<50ms
Warm cache delivery
Package already compiled, Redis hit
<400ms
Cold compile
First request or cache miss
<30s
Revocation propagation
Atomic Redis pipeline, no polling
Boundary Rules

What can and cannot cross each boundary.

Data typeZone 1 → Zone 2Zone 2 → Zone 3Notes
Raw asset content✓ In memory only✗ NeverLoaded, compiled, then discarded in Zone 2
Compiled package✗ N/A✓ Signed + TTLSignature verified by adapter before use
Enterprise signing key✓ Encrypted✗ NeverUsed in Zone 2 for signing only
Bearer token (JWT)✗ N/A↔ Auth onlyJTI validated against Redis; token not logged
Audit events✓ Written to sink✗ NeverHashes only — input/output content never stored
Policy rules✓ Read-only✗ NeverUsed for scope projection; not transmitted
Content references (S3 keys)✓ Internal only✗ NeverNever exposed to developer zone
Setup

One MCP endpoint. Two paths to it.

Developers wire Corla into their IDE via the CLI. Everyone else adds it as a custom connector in Claude.ai or ChatGPT — no install, no terminal. Same broker, same audit trail, same context.

Developers · CLI

Claude Code, Cursor, VS Code, Windsurf

Three commands and the IDE knows your org. The corla init command writes .mcp.json, .vscode/mcp.json, and the Cursor / Windsurf configs in one shot. Optional --antigravity flag enables Antigravity support.

$ npm install -g @corla/adapter
$ corla init
$ corla login

First login uses your one-time invite secret and prompts you to set a password. Every subsequent corla login uses the password — no admin involvement needed to reconnect.

Everyone Else · Connector

Claude.ai & ChatGPT (web + mobile)

No CLI. Open the AI tool, add Corla as a custom connector, paste the URL, sign in. Designers, support, sales, marketing, product, and any role using Claude or ChatGPT gets the same scoped context as the engineering team.

  1. 1.Settings → Connectors → Add custom
  2. 2.Paste https://broker.corla.ai/mcp
  3. 3.Sign in with your invite secret (set a password)

Members can also visit the member portal any time to view active projects, change their password, or copy connector instructions.

Multi-project switching, no reconnect

Members with access to multiple projects switch between them inside a single connection. Claude and ChatGPT see available projects automatically via the list_projects MCP tool. No disconnect, no re-auth, no admin ticket — just ask the agent to switch projects.

Multi-Agent CoordinationOn the Roadmap

Agents that work together. Grounded in the same context.

A coordination layer for multi-agent workflows is on Corla's roadmap. The broker today delivers context to single agents; the coordination layer extends that with broker-mediated agent-to-agent exchanges across separate machines and teams — no human relay, no shared codebases, every exchange audited.

🔗

Broker-mediated

All agent-to-agent communication will pass through Corla. The broker enforces access control, applies token scoping, and logs every exchange — no message bypasses the audit trail.

🌐

Cross-machine, cross-team

A frontend developer's agent and a backend developer's agent will coordinate on API contracts without sharing codebases. A vendor's agent and an internal security agent will collaborate without exposing raw architecture.

📐

Same ground truth

Every agent in a workflow loads enterprise context from the same broker at session start. Their coordination is grounded in the same standards — not each team's local interpretation of them.

What becomes possible

API contract alignment

Frontend and backend agents surface contract mismatches through the broker before either side ships — without sharing codebases.

Automated PR review

A broker-side review agent checks every PR against architecture standards, approved dependencies, and current failure modes — before a human reviewer sees it.

Incident investigation

An on-call agent and an SRE agent work a shared thread, correlating symptoms and recent deploys. Root cause surfaces faster because both agents share the same enterprise context.

Async onboarding handoff

A senior developer's agent posts architectural decisions and rationale. A new joiner's agent reads the thread, builds context, and asks questions — no synchronous scheduling required.

Questions about the architecture?

We publish detailed technical documentation for enterprise security reviews. SOC 2 report available under NDA.

Get Started Security deep dive →