QuilrAi

Overview

QuilrAI is an AI security platform that governs agent actions across four enforcement planes, browser, endpoint, LLM gateway and MCP, with a central decision engine that evaluates identity, context, intent, content and behaviour in a single pass. Each governed agent is paired with a Guardian Agent that reads the agent's purpose statement, determines required permissions, and enforces least privilege on tool calls at runtime. The endpoint agent covers locally running developer tools such as Claude Code, Cursor and Copilot, which never reach an API gateway. The organisation presented the platform for full AARM conformance covering both the community requirements and the nine runtime requirements.

Classification

Coverage surface

MCPEndpointCloudData/DBAPINetworkSaaS

Stage

Launched

Type

CommercialOpen Source

Target audience

SMBMid-marketEnterprise

Deployment

SaaSSelf-hostedHybrid

Technical profile

Spec-grounded axes, verified by the TWG.

Interception architecture (R1)

Kernel eBPFVendor IntegrationSDK InstrumentationProtocol Gateway

Policy model (R3)

Hybrid

Authorization decisions (R4)

ALLOWDENYMODIFYDEFERSTEP_UP

Conformance review

Platform capabilities

• Pre-execution interception through an inline policy gateway, with DENY blocking before any target-side effect and no fail-open code path
• Deferral without side effects, with every denial and deferral written to an auditable decision log carrying the matched rule and reason
• Per-session context accumulation covering prior actions, data classification and the original user request, defaulting to highest sensitivity when classification is unavailable
• Append-only hash-chained context logs, making tampering with an earlier entry detectable
• Four action classifications: forbidden, context-dependent deny, context-dependent allow, context-dependent defer
• Parameter validation across type, range, pattern and allowlist/blocklist
• Five authorization decisions: ALLOW, DENY, MODIFY, STEP_UP, DEFER
• STEP_UP approval routing with full action context and a bounded timeout defaulting to DENY
• Dependent-action cascade handling with a configurable cascade limit that DENYs when exceeded, plus follow-up receipts on resolution or timeout
• Ed25519-signed receipts for all five decision types, over a documented canonical serialization, verifiable offline against a published public key
• Identity binding across human principal, service identity, agent instance, session identifier and role/privilege scope, preserved through deferral and delegated execution
• Identity claim validation against trusted sources including freshness and revocation checks
• Semantic drift tracking using cosine similarity over embeddings, aggregated cumulatively across action sequences
• Structured telemetry export to SIEM and SOAR within seconds, in OCSF, covering DEFER events, with filtering by action type, decision and identity
• Just-in-time credential issuance with minimal validity and operation-specific scoping, with issuance and use logged

Architecture

The evidence describes a single enforcement point with a set of services hanging off it. Actions reach an inline policy gateway before execution, the gateway calls a policy engine that returns one of five decisions, and the decision is written to a signed receipt before the action either proceeds or stops. Nothing in the evidence describes a second path to the target, and the organisation states there is no fail-open code path, so the gateway is the only place enforcement happens. That matters for everything downstream, because a receipt only carries weight if the action could not have reached the target without passing the evaluator that signed it. Session state is held in one place and reused by two separate controls. The gateway accumulates prior actions, data classifications and the original user request into an append-only hash-chained log (each entry covers the hash of the one before it, so editing an earlier entry breaks the chain and is detectable), and that log is the input both for policy evaluation on later actions and for the drift calculation in R7. Semantic distance is computed as cosine similarity between embeddings of the original request and each subsequent action, aggregated across the sequence, which means drift is measured against the request preserved in the chain and not against a rolling window of recent behaviour. The policy engine defers when a rule references context the chain has not populated yet, when two policies of equal priority conflict, or when confidence falls under the configured threshold, so an incomplete chain produces a DEFER instead of a guess. Identity binding is the strongest part of the design as described. Each action carries the human principal, service identity, agent instance, session identifier and role or privilege scope, validated against trusted sources with freshness and revocation checks, and that binding survives both deferral resolution and delegated execution. Deferral is where most implementations lose the principal, since an action approved twenty minutes later is easy to re-attribute to the approver or to the runtime, and QuilrAI states the original principal and scope are carried through to the follow-up receipt. Credential issuance sits outside the decision path, scoped per operation and time-boxed, with a verified case where a read operation received a credential that could not write.