Quince Software

AI Agent Authorization as a Service

AI Agent Authorization as a Service

For the agents a business runs and the applications beside them · Enterprise security

Quince Software implements enterprise authorization for applications and AI agents, on open standards: one decision point that every application and every agent asks, with the rules held as data in Git and every decision naming the rule that produced it, or reporting that none matched.

Caroline is the firm's Authoring-first Authorization Platform: this design, working. A client receives it as a deliverable asset of the implementation, running in their own estate.

Ask for a walk-through

AI agents

Between the agents and the tools that run them

An AI agent acting in a business needs the same answer an application does: whether this action, on this data, on behalf of this person, is allowed, and under which rule.

Caroline sits as an intermediary layer under the agents a business runs and the AI management tools that create and run them, so every action an agent takes passes through one decision point. The rules are the same rules, held as data in Git and applied by a person, and each decision names the rule it came from, or reports that none matched: what an agent did, and why, is on the record.

Wider than the screen. Scroll the diagram sideways to follow it.

Where Caroline sits with AI agents

Every tool call passes through one decision point

AI agent management layer The tools that create and run agents, and the agents themselves

AI management tools Create and run

Where a business's agents are built, given their tools and run.

agent created, agent run

AI agents Acting

Act in the business on a person's behalf, by calling tools and systems.

action requested

Caroline Authorization

One decision point every tool call passes through, with the rule behind each answer.

decision, naming the rule that produced it

MCP servers Tools

The tools an agent calls, each one running only once the call is allowed.

allowed tool runs

Target systems Systems of record

The business systems and data the tools act on, which keep owning their data.

read or written by the tool

creates and runs every tool call asks allowed call acts on the system

How it fits together

Where the data goes

AuthZEN is the contract at the edge: an application asks its question in a standard shape and gets an answer in the same standard shape, so whatever sits behind it can change without the application changing with it.

Wider than the screen. Scroll the diagram sideways to follow it.

Reference architecture, as Caroline runs it

AuthZEN 1.0 is the contract at the edge

Decision point

Caroline Authoring

Decision tester, rule editor, live audit trail and history.

intent in natural language, one schema-valid rule

Git Record

The record of what changed, and when.

policy change committed

Policy information point Attributes

One front to whichever systems own the attributes.

attribute changed

OPAL Live sync

Distributes policy and attributes as they change.

policy 0.27 s, attributes 0.06 s

Scope gate Admission

Rejects unauthorised callers before the engine runs.

caller accepted

Open Policy Agent PDP

A generic evaluator over rules held as data.

decision under 5 ms, with its reason

Application or AI agent Enforcement

Asks the question in a standard shape, enforces the answer.

AuthZEN 1.0 response

human applies commit attributes policy 0.27 s · attributes 0.06 s accepted AuthZEN 1.0 request AuthZEN 1.0 response
An application asks its question at the edge and the scope gate admits the caller. Open Policy Agent decides and returns the rule it used, or the fact that none matched. Behind them, OPAL carries policy from Git and attributes from the systems that own them, and a rule drafted in natural language reaches the engine only once a human has applied it.

Policy authoring

Write the rule in plain English.

a nurse may read a patient record only while assigned to that patient's care team

The platform

Meet Caroline

Caroline puts authoring first: the console where rules are written, tested and reviewed comes before the decision point that evaluates them.

The policy editor in plain-English view. Four rules are read back as sentences, three that permit and one that forbids, each beside its rule identifier, above a note on how they combine.
The live rules read back as sentences. A request is allowed only when a permit applies and no prohibition does. Enlarge
Drafting a rule with AI. A sentence asks to let analysts read confidential reports regardless of clearance. A model running locally drafts one JSON rule marked schema-valid, and a table of canonical scenarios shows the one decision that would change, from DENY to ALLOW, before anything is applied.
Asked for in one sentence, drafted by a model running locally, and marked schema-valid. Before anything is applied, the table shows the one scenario of six whose answer would change. Enlarge
Reviewing a change before it is written. The new rule is shown as a sentence with its owner and review date. A table of six canonical scenarios shows the one whose answer changes, from DENY to ALLOW, and a second table shows that 7 of the last 35 real requests would now be answered differently.
A change under review, with nothing written yet. Besides the test scenarios, it checks the requests the engine has actually answered: 7 of the last 35 would now get a different answer. Enlarge
A denial with its evidence open. A table checks each rule against the request and shows that both admin-all and deny-suspended applied. Below it are the AuthZEN request and the engine's raw response, ending in decision false.
A refusal with its evidence open: each rule checked against the request, clause by clause, then the AuthZEN request and the engine's raw reply. Enlarge
An ALLOW decision whose reason names the rule dept-read-own, with links to the evidence, the audit entry and the Rego behind the decision.
An allowed request names the rule that allowed it, and the evidence behind it is a click away. Enlarge
A DENY decision marked deny-override, whose reason names the explicit rule deny-suspended.
An explicit prohibition outranks every permission, and the refusal names the rule that stopped it. Enlarge
An ALLOW decision whose reason is the rule break-glass-emergency, with links to the evidence, the audit entry and the Rego behind the decision.
Access granted under break-glass. The reason is the emergency rule itself, so every such exception can be picked out of the audit. Enlarge
The recent decisions log: 35 decisions, of which 13 were allowed, 15 denied and 7 were deny-overrides, above a table giving the time, subject, action, resource, decision and deciding rule of each.
The decision log keeps the subject, the resource and the deciding rule of each request. Of these 35, 13 were allowed, 15 denied and 7 stopped by an explicit prohibition. Enlarge
The policy change history. Each rule change is a Git commit with its time, source and author. One was drafted by AI and approved; the open entry shows the new rule as a sentence, with its owner and review date.
Every change is a Git commit, including one drafted by AI and approved by a person. Each opens as the rule in plain English, with an owner and a review date. Enlarge
The policy editor in plain-English view. Four rules are read back as sentences, three that permit and one that forbids, each beside its rule identifier, above a note on how they combine.

The live rules read back as sentences. A request is allowed only when a permit applies and no prohibition does. Close

Drafting a rule with AI. A sentence asks to let analysts read confidential reports regardless of clearance. A model running locally drafts one JSON rule marked schema-valid, and a table of canonical scenarios shows the one decision that would change, from DENY to ALLOW, before anything is applied.

Asked for in one sentence, drafted by a model running locally, and marked schema-valid. Before anything is applied, the table shows the one scenario of six whose answer would change. Close

Reviewing a change before it is written. The new rule is shown as a sentence with its owner and review date. A table of six canonical scenarios shows the one whose answer changes, from DENY to ALLOW, and a second table shows that 7 of the last 35 real requests would now be answered differently.

A change under review, with nothing written yet. Besides the test scenarios, it checks the requests the engine has actually answered: 7 of the last 35 would now get a different answer. Close

A denial with its evidence open. A table checks each rule against the request and shows that both admin-all and deny-suspended applied. Below it are the AuthZEN request and the engine's raw response, ending in decision false.

A refusal with its evidence open: each rule checked against the request, clause by clause, then the AuthZEN request and the engine's raw reply. Close

An ALLOW decision whose reason names the rule dept-read-own, with links to the evidence, the audit entry and the Rego behind the decision.

An allowed request names the rule that allowed it, and the evidence behind it is a click away. Close

A DENY decision marked deny-override, whose reason names the explicit rule deny-suspended.

An explicit prohibition outranks every permission, and the refusal names the rule that stopped it. Close

An ALLOW decision whose reason is the rule break-glass-emergency, with links to the evidence, the audit entry and the Rego behind the decision.

Access granted under break-glass. The reason is the emergency rule itself, so every such exception can be picked out of the audit. Close

The recent decisions log: 35 decisions, of which 13 were allowed, 15 denied and 7 were deny-overrides, above a table giving the time, subject, action, resource, decision and deciding rule of each.

The decision log keeps the subject, the resource and the deciding rule of each request. Of these 35, 13 were allowed, 15 denied and 7 stopped by an explicit prohibition. Close

The policy change history. Each rule change is a Git commit with its time, source and author. One was drafted by AI and approved; the open entry shows the new rule as a sentence, with its owner and review date.

Every change is a Git commit, including one drafted by AI and approved by a person. Each opens as the rule in plain English, with an owner and a review date. Close

Measured

What comes back, and how fast

Measure Result
Policy save to enforced decision 0.27 s, with the change recorded in Git
Attribute change to effect 0.06 s, straight from the source system
Decision latency Under 5 ms
Decision explanation Every decision names its rule, or reports that none matched

These figures are measured on the firm's own installation of Caroline.

The engagement

Three steps, each ending in something running

  1. Step one

    Pilot

    A decision point runs against one of your own use cases, with your real policies, on a bounded scope. You judge the design on working software before committing to a rollout.

    You end up with. A running decision point answering your use case, with the policies that produced each answer.

  2. Step two

    Production deployment

    Rollout across the application estate, with the governance around policy change, the playbooks for onboarding each application, and the handover to whoever will operate it.

    You end up with. Enterprise authorization in production across the estate, onboarding playbooks, and an operations handover to your team.

  3. Step three

    Retainer

    Ongoing policy governance, onboarding of further applications as they arrive, and operation of the decision points themselves.

    You end up with. Continuing governance of the policy estate and operation of the decision points, against an agreed scope.

See Caroline decide

In a walk-through you will see a policy change enforced while you watch, with the change already committed.

Ask for a walk-through