ComplyeeAgent Control Room

A fictional example

How one governed bank transfer moves through the system

A customer asks a bank’s agent, FinBot, to transfer 25,000 SEK to Alice. FinBot can propose the transfer, but it cannot give itself permission or move the money directly. Independent policy decides whether the exact action may proceed; the bank’s own system remains responsible for execution.

The names, amount and rule below are illustrative. A real bank defines its own actions, thresholds, trusted facts and approval responsibilities.

One separation makes the pattern work

The thing proposing the work is not the thing granting permission, and Agent Control Room is not the thing executing it.

FinBot proposes

The agent describes one specific transfer it wants the bank to perform.

Agent Control Room decides

Deterministic rules return allow, refuse, or ask a person first.

The bank executes

The bank verifies the permit and remains in control of its ledger and payment systems.

The surrounding systems are optional

A bank can connect its application directly to Agent Control Room. In a larger platform, a gateway, MCP layer, orchestrator and scanner can each contribute at a natural control point. They do not form a required stack, and they need not all be present.

CustomerFinBotOptional connection pointAgent Control Room decidesBank system executes

The transfer, step by step

This example uses a fictional bank rule: transfers over 10,000 SEK must be approved by a person. Routine transfers that the rules allow would continue without waiting.

  1. 01

    FinBot proposes one exact action

    The proposal identifies the agent, the action transfer_funds, the amount, the source account and the destination. The bank keeps the underlying customer data and transaction payload in its own systems.

  2. 02

    The application asks before anything executes

    A normal application or API gateway can call decideAction. If the transfer is exposed as an MCP tool, an MCP interceptor can call decideToolCall with the tool name and arguments. These are alternative entry points into the same decision process, not two calls required in sequence.

  3. 03

    Agent Control Room evaluates the request

    It checks the registered agent, the declared action, required context and ordered deterministic rules. The answer can only be allow, refuse, ask a person first, or Not decided when required evidence is incomplete.

  4. 04

    This illustrative rule asks a person

    Because 25,000 SEK exceeds the bank’s fictional 10,000 SEK threshold, the transfer is held. The application can poll getApprovalStatus. If the person refuses, execution stops; if the person approves, the same exact proposal can receive a permit.

  5. 05

    A signed permit binds the exact work

    The permit is short-lived and bound to the proposal’s fingerprint. Changing the amount, destination or other fingerprinted work means the permit no longer matches.

  6. 06

    The bank verifies, then executes

    The bank system uses the public key published by getGrantVerificationKey to check the signature locally, together with the permit’s expiry and payload fingerprint. Only then does the bank execute the transfer in its own payment system.

  7. 07

    The outcome closes the record

    After the attempt, the application calls reportExecutionOutcome to record whether the transfer was executed, aborted or failed downstream. Reporting describes what happened; it does not change the earlier decision.

Where the four connection points fit

The same transfer can meet Agent Control Room at different points in a bank’s architecture. The named products are examples to make each category tangible, not prerequisites or endorsements.

CONNECTION 01

API and AI gateways

Examples: Kong Gateway, Envoy, Azure API Management and Apigee

What it already does
The gateway authenticates callers, terminates secure connections, applies quotas and routes the transfer request to the right bank service.
What it contributes here
A gateway plug-in can intercept the request before it reaches the payment service, call decideAction and stop a refused request at the front door.
What Agent Control Room adds
Agent Control Room adds the action-by-action business decision. The gateway or bank service can verify an issued permit locally with getGrantVerificationKey before allowing the exact request through.
Gateway receives requestdecideActionVerify signed permitPayment service
See the API gateway plug-in recipe →

CONNECTION 02

MCP gateways and tool interceptors

Examples: Anthropic MCP SDK, Kong MCP Gateway and mcp-proxy

What it already does
MCP exposes tools such as transfer_funds to an agent through a standard interface and carries the tool name and arguments to the server that implements it.
What it contributes here
An interceptor catches the tool call before its handler runs and sends the tool name and arguments to decideToolCall. Agent Control Room computes the fingerprint without storing the raw arguments.
What Agent Control Room adds
If the outcome asks a person, the call remains on hold. Only an allowed call with a matching permit reaches the tool handler; the integration reports the result afterwards.
FinBot calls transfer_fundsdecideToolCallPermit, refusal or holdTool handler
See the TypeScript MCP interceptor recipe →

CONNECTION 03

Agent orchestration and hand-offs

Examples: LangGraph, CrewAI and Microsoft Semantic Kernel

What it already does
The orchestrator manages FinBot’s multi-step workflow, including data lookup, delegation, tool calls and the final customer response.
What it contributes here
It can pause the workflow when the decision asks a person, check getApprovalStatus and resume only after an allowed result. It can also supply trusted delegation facts such as who initiated the chain, hop count and human origin.
What Agent Control Room adds
Agent Control Room applies the bank’s rules to the current step and its declared lineage. A long or unexpected delegation chain can be refused or held without turning the orchestrator itself into the policy authority.
Workflow reaches transferDelegation factsdecideActionPause or continue
See the Python / LangGraph recipe →

CONNECTION 04

Security scanners and policy sources

Examples: Presidio, Lakera Guard (Check Point) and Complyee Policy Library

What it already does
Presidio (open source, community-governed) or Lakera Guard (Check Point) can inspect text for prompt injection, personal data or other security concerns. Complyee Policy Library can read relevant written corporate policy and return cited evidence through Agent Control Room’s pairing.
What it contributes here
The caller can submit trusted scanner findings as standard sec.* context facts. The optional Policy Library reading is recorded separately as policy evidence, not mixed into those facts.
What Agent Control Room adds
Agent Control Room remains the decision authority. A scanner finding can inform a rule but never grants permission. A Policy Library advisory reading cannot change the outcome; a configured gate can only hold or refuse, never grant.
Scanner or policy sourceFinding or cited evidencedecideActionAllow, refuse or hold
See the security-scanner recipes →

BESIDE THE EXECUTION PATH

How identity providers fit: Microsoft Entra ID and Okta

Examples: Microsoft Entra ID, Okta, Ping Identity and Auth0

Identity is not a fifth connection point. The identity provider works before and beside the transfer, establishing who is asking; it does not sit between FinBot and the payment system.

What it already does
Entra ID or Okta authenticates the customer or relationship manager working with FinBot, enforces multi-factor authentication and issues a signed sign-in token carrying verified claims such as the user, their roles and their tenant.
What it contributes here
Before asking about the 25,000 SEK transfer, the bank’s application checks the token’s signature against the identity provider’s published keys, then maps the verified claims into trusted context facts (for example requester.role) sent with decideAction. Because those facts come from the validated token, not from FinBot’s prompt or reasoning text, the agent cannot invent who it is acting for.
What Agent Control Room adds
Entra ID and Okta answer “who is this, and are their credentials valid?”, usually with access that covers many requests. Agent Control Room answers “may FinBot perform this exact 25,000 SEK transfer to Alice now, under the bank’s rules?” Even with a valid token, the fictional 10,000 SEK rule still asks a person first, and only a signed permit bound to this transfer lets the bank proceed.
User signs in (Entra ID or Okta)Verified claims become factsFinBot proposes transferdecideActionPermit or hold

requester.role is an illustrative fact name, not a standard catalogue fact.

See the identity token verification recipe →

What the completed record can show

The decision record connects the proposal to its policy result and the real execution outcome without making Agent Control Room the owner of the bank’s transaction data.

  • Which registered agent asked and which declared action it proposed
  • The one-way fingerprint binding the decision to the exact work
  • The rule outcome and the trusted context used to reach it
  • Any person’s approval or refusal when policy required review
  • The signed, expiring permit issued for allowed work
  • Whether execution succeeded, was aborted or failed downstream

From example to implementation

Return to the architecture overview to compare the four optional connection points, or continue to the API reference for request shapes and verification guidance.

Return to How it fits →Open the API reference →