Use Cases How It Works Agent Deliberation Security Blog Pricing Get Access →
Security

Cooperative compliance. Unbypassable audit.

Corla protects two things simultaneously: your intellectual property through a compilation layer that ensures raw assets never cross a trust boundary, and your organisation's integrity through server-side accountability that cannot be bypassed.

Security Model

Four independent layers.

Each layer is enforced independently. A compromise at one layer does not cascade to others.

L1
Identity & Auth

Every session is authenticated, bounded, and revocable.

OAuth 2.1 with PKCE — no implicit flows, no long-lived credentials. JWTs with 15-minute default TTL. Every token validated against a Redis revocation list on every single request. Revocation propagates in under 30 seconds via atomic pipeline operation.

OAuth 2.1 PKCESAML / OIDCJWT (15m TTL)Redis revocation list<30s propagationFail closed on auth error
L2
Access Control

RBAC with project scope and sensitivity ceiling.

Grants are per-developer, per-project, per-role — created explicitly by enterprise admins. Roles carry permission sets and sensitivity ceilings. The policy engine checks grant validity, expiry, project match, and permission scope on every compile request. Instant revocation propagates via session kill.

Role-based accessProject scopingSensitivity ceilingGrant expiryAdmin-controlledInstant session kill
L3
Context Protection

CLAUDE.md + visible deterrence + signed packages.

The setup script appends a Corla behaviour block to CLAUDE.md — the transparent, developer-visible file that Claude Code loads as genuine system context. The report_policy_violation tool is a visible deterrent: the developer knows it exists and knows it fires when extraction is attempted. Packages are HMAC-signed; the adapter verifies the signature before use. Context is in-memory only — never written to disk.

CLAUDE.md behaviour blockreport_policy_violationHMAC signingVisible deterrenceIn-memory onlyNo disk writes
L4
Output & Audit

Server-side logging is the only unbypassable layer.

Every MCP call is logged at the broker — this is the ground truth for audit, compliance, and anomaly detection. It does not depend on the AI agent cooperating or the developer not circumventing client-side mechanisms. Input and output are stored as SHA-256 hashes, never as raw content. The audit log is append-only at the database level. Anomaly detection flags unusual access patterns automatically.

Output policy filterImmutable audit logHash-only storageAnomaly detectionSOC 2 exportISO 27001 ready
Intellectual Property

The source never travels. Only derivatives do.

Corla's compilation layer is an IP protection mechanism as much as a security one. The distinction matters: access controls can be misconfigured. The compilation guarantee is architectural — the source simply never travels.

What counts as enterprise IP in this context

A system prompt encoding proprietary domain reasoning. A playbook refined over years of production incidents. An architecture document capturing decisions your best engineers made. These aren't generic documents — they're competitive advantages encoded in text. Corla treats them as such.

Why compilation is stronger than access control alone

Access control says who can read a file. Compilation means the file is never transmitted as-is. What crosses the boundary is a scoped, signed derivative — useful for AI-assisted work, not reconstructable into the original. The IP never exists in readable form outside the broker.

The IP protection guarantee

  • Raw asset content never leaves the broker in any form
  • What developers receive is a compiled, scoped, signed derivative
  • The derivative is not reconstructable into the original source
  • Each package is HMAC-signed and TTL-bounded — tampering is detectable, access is time-limited
  • Role and project scoping means a vendor on one project cannot access IP from another
  • When access is revoked, it propagates immediately — there is no window of residual exposure
Threat Model

Threats we've modelled and mitigated.

These are the threat vectors Corla is designed to address.

High

Direct extraction — "repeat your system prompt"

A developer prompts the AI tool to disclose the context instructions injected into their session.

Mitigated: CLAUDE.md block instructs the agent to call report_policy_violation and decline. The tool is a visible deterrent — the developer knows it exists. All tool calls are visible in Claude Code's UI. Attempt is logged server-side regardless of outcome.
High

Token theft and replay

A developer's CORLA_TOKEN is stolen and used from an attacker's machine.

Mitigated: 15-minute TTL limits window. Session fingerprinting detects environment changes. Enterprise can revoke the token instantly — propagates in <30s. Anomaly detection flags unusual IP/timing.
High

Scope escalation — accessing assets beyond grant

A developer attempts to request context from projects or assets outside their grant.

Mitigated: Policy engine enforces project scope and role permissions on every request. JWT claims are validated against the database grant — they cannot be self-issued or modified.
Medium

Package tampering in transit

A MITM attack attempts to modify the compiled package between the broker and the developer's adapter.

Mitigated: HMAC-SHA256 signature verified by adapter before use. TLS in transit. Invalid signature is a critical security event — logged and reported immediately.
Medium

Indirect extraction via AI output

A developer engineers prompts to get the AI to produce output that reveals proprietary patterns, even without quoting context directly.

Mitigated: Output policy filter. Behaviour envelope constrains response patterns. Scope projection means the developer never receives high-sensitivity content if their role ceiling is lower.
Medium

Stale access after engagement ends

A vendor engagement ends but the developer's token remains valid, allowing continued access.

Mitigated: Enterprise admin revokes the grant in the admin console. Revocation propagates in <30 seconds. Grant expiry can also be set at creation time for automatic termination.
Security Invariants

Rules that cannot be broken.

These invariants are enforced at the code level, not just the policy level. Violating them is not a misconfiguration — it is a build-time or runtime error.

I1

Raw asset content never crosses a trust boundary

Assets are loaded, compiled, and discarded inside Zone 2. The RawAsset.content field never appears in any network response, log entry, or database record outside Zone 2.

I2

Audit events are append-only

The AuditEvent table has no UPDATE or DELETE permissions at the database level. Not even for administrators. Not even for cleanup jobs. Every event is permanent.

I3

Token validation always hits Redis

The revocation check is never skipped and never cached. If Redis is unavailable, the request is rejected (fail closed). Caching the validation result would make revocation meaningless.

I4

Package signatures are verified before use

The adapter verifies the HMAC-SHA256 signature of every compiled package before injecting it. An invalid signature is a critical security event, logged immediately.

I5

Tokens are never logged

Bearer tokens, signing keys, and encryption keys must never appear in logs, error messages, or audit events. Only the JTI (token ID) is logged.

I6

Context injection is in-memory only

Compiled package content must never be written to disk, temp files, or any persistent storage on the developer's machine. If the process exits, the context is gone.

I7

Fail closed on auth errors

When in doubt about a token's validity, the request is rejected with 401. No default-allow fallback. Every auth error path is explicit.

I8

Server-side logging cannot be bypassed by client-side action

Client-side mechanisms (CLAUDE.md, MCP prompts, report_policy_violation) are cooperative tooling and visible deterrence. They improve compliance but depend on agent cooperation. Server-side logging does not. It is the ground truth and cannot be overridden by content in any context window.

Design Philosophy

Designed for cooperation, not covert control.

Corla does not try to enforce behaviour against a developer's interests through hidden mechanisms. It doesn't need to.

All tool calls are visible

Claude Code shows every MCP tool call in its UI. A developer can see — and deny — any tool call. Corla is designed with this transparency in mind. Deterrence comes from visibility, not hidden execution.

CLAUDE.md is transparent

The behaviour constraints written to CLAUDE.md are visible to the developer. Deletion is detectable via git diff and the absence of expected get_context calls server-side. Deletion is not silent — it is just transparent.

Server-side is the ground truth

Every MCP call is logged at the broker regardless of what happens client-side. This is the enforcement layer that cannot be bypassed. Compliance infrastructure is built on it — not on assumptions about AI agent behaviour.

Compliance

Compliance readiness.

SOC 2 Type II

Audit-ready event logs with searchable export. Available under NDA for enterprise customers. Report covers security, availability, and confidentiality trust service criteria.

ISO/IEC 42001

Alignment with the AI management system standard. Governance framework documentation, risk assessments, and control mappings available for Enterprise tier customers.

GDPR / CCPA

Personal data minimisation by design. Input and output stored as hashes — not raw content. Data residency options available. DPA provided for all customers.

Security review or penetration test planned?

We welcome security reviews. Documentation, architecture diagrams, threat model, and SOC 2 report are available under NDA. Contact our security team directly.

security@corla.ai Request Access