Policy decides what AI can do. Enforced at every layer.
Limit Platform separates policy from code. Who can do what, on what data, under what conditions: declared in policy, versioned in storage, enforced at every cross-layer boundary, audited per decision.
// authorization · enforced at every layer · inside the perimeter
Authorization is a layer, not a switch.
In a regulated AI deployment, authorization is not a checkbox at login. It is a continuous question: can this user, on this matter, with this clearance, through this channel, at this time, ask this model about this data? The answer depends on facts that change between requests.
Limit Control treats authorization as a layer the entire system passes through. Policies are declared, versioned, and reviewable. Decisions are enforced at every cross-layer boundary, not just at the application edge. Every decision is logged with the policy version, the inputs, and the outcome.
Declarative policy. Cross-layer enforcement.
- 01
Policy as versioned source-of-truth
Policies are declared in a structured language, versioned in storage, and reviewable as part of normal change-management. Changes are themselves audited.
- 02
Enforcement at every cross-layer boundary
Authorization decisions happen at the layer that has the context to make them: at the data boundary for read/write, at the runtime boundary for model invocation, at the integration boundary for outbound action.
- 03
Per-decision audit and reasoning
Every authorization decision lands in the evidence store with the policy version, the inputs that determined the outcome, and any matter-specific context.
- 04
Integration with existing identity and matter context
Decisions consume the customer's existing identity provider, matter or case context, and ethical-wall configuration. Authorization respects the structures already in place.
Inside the same perimeter as the workload it governs.
The policy engine deploys inside the customer perimeter alongside the workloads it governs. No authorization decision depends on an external service. Policies stay with the customer; decisions stay with the customer; evidence stays with the customer.
The engine is independent of the workloads it serves: a single policy can cover decisions across multiple applications on the platform, ensuring consistency without coupling.
- Where decisions happen
- In-process at the enforcing layer (data, runtime, integration). Low-latency decision evaluation on every request.
- Where policies live
- Versioned in storage inside the perimeter. Changes go through normal review and audit.
- How it relates to identity
- Consumes identity claims from the customer IdP. Does not maintain its own user directory.
- How it relates to audit
- Every decision is recorded in the evidence trail with policy version and reasoning context.
This capability is one layer of the operating system. Every application uses it. Every customer perimeter that runs Limit Platform gets it. See the full architecture →
See it in your environment.
Walk us through the systems already in place. We'll show you how this layer fits.