From context compilation to multi-agent coordination — a technical walkthrough of the broker architecture, the MCP tool set, and how the security properties hold.
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.
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.
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.
Untrusted by default. Receives only compiled derivatives — signed, scoped, TTL-bounded. Content is injected into the AI tool's in-memory context only. Never written to disk.
The developer opens their IDE, uses their AI tool, and gets better output. Everything else is invisible infrastructure.
.mcp.jsonThe MCP adapter discovers the Corla broker endpoint from the project config file written by corla init. No user action required after initial setup.
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.
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?
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.
The raw content passes through the full compilation pipeline: intent extraction → redaction → scope projection → signing → package emission. See the compiler diagram below.
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.
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.
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.
Raw asset content goes in. A signed, scoped, redacted derivative comes out — useful for AI-assisted work, not reconstructable into the original.
Goal, constraints, domain keywords — the metadata safe to expose.
PII and secrets stripped. Emails, API keys, JWTs, connection strings.
RBAC role ceiling applied. Internal sections removed. Sensitivity filtered.
HMAC-SHA256 with enterprise key. TTL embedded. Canonical JSON.
Signed CompiledPackage JSON. Cached in Redis. Audited.
// 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"
}
// 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
}
}
Context delivery adds negligible latency to the AI tool's response time. The developer never notices the security infrastructure working.
| Data type | Zone 1 → Zone 2 | Zone 2 → Zone 3 | Notes |
|---|---|---|---|
| Raw asset content | ✓ In memory only | ✗ Never | Loaded, compiled, then discarded in Zone 2 |
| Compiled package | ✗ N/A | ✓ Signed + TTL | Signature verified by adapter before use |
| Enterprise signing key | ✓ Encrypted | ✗ Never | Used in Zone 2 for signing only |
| Bearer token (JWT) | ✗ N/A | ↔ Auth only | JTI validated against Redis; token not logged |
| Audit events | ✓ Written to sink | ✗ Never | Hashes only — input/output content never stored |
| Policy rules | ✓ Read-only | ✗ Never | Used for scope projection; not transmitted |
| Content references (S3 keys) | ✓ Internal only | ✗ Never | Never exposed to developer zone |
npm install -g @corla/adapter
corla init — writes .mcp.json and appends a Corla behaviour block to CLAUDE.md (auto-loaded by Claude Code as genuine system context). Works with Claude Code, Cursor, and Windsurf automatically.
corla login — OAuth 2.1 PKCE browser flow. Set CORLA_TOKEN in your .env file. Done.
Every subsequent AI tool invocation in the project directory automatically pulls enterprise context. The developer types claude or opens Cursor and their AI tool already knows the enterprise's patterns, conventions, and constraints.
No flags. No prompts. No selecting context. No copy-pasting playbooks. The context is just there — compiled, scoped, and injected before the first token is generated.
$ claude "implement the payment webhook handler"
[corla] ✓ Context: payments-playbook-v3 (Platform Eng)
[corla] ✓ Standards: typescript-strict, auth-service-v2
[corla] ✓ Scope: senior / payments / internal
Claude is thinking...
Corla extends beyond context delivery into a coordination layer for multi-agent workflows. Agents across separate machines and teams can collaborate through the broker — no human relay, no shared codebases, every exchange audited.
All agent-to-agent communication passes through Corla. The broker enforces access control, applies token scoping, and logs every exchange — no message bypasses the audit trail.
A frontend developer's agent and a backend developer's agent can coordinate on API contracts without sharing codebases. A vendor's agent and an internal security agent can collaborate without exposing raw architecture.
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.
Frontend and backend agents surface contract mismatches through the broker before either side ships — without sharing codebases.
A broker-side review agent checks every PR against architecture standards, approved dependencies, and current failure modes — before a human reviewer sees it.
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.
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.