How Agent Control Room fits your application or platform

You can connect a single application directly to Agent Control Room for AI agent authorization. Your application asks before an agent acts; Agent Control Room applies your rules and answers one step at a time. Your application checks the signed, unexpired permit bound to the exact work before carrying it out. No gateway, external registry, orchestrator or scanner is required: your backend simply calls the API before taking action.

If your organisation already runs those systems, Agent Control Room fits alongside them. Gateways keep routing traffic, registries keep listing agents, and scanners and policy engines keep supplying their findings. Agent Control Room provides the decision on whether this business step, by this agent, on this resource, may go ahead now — so agents can work with useful autonomy inside the boundaries your business has set. The system that does the work stays yours.

Agent Control Room can only govern the actions that pass through it. Start with how your platform must be built so that every governed step asks first.

Build the enforcement point →

The pattern

AgentYour application or gatewayAgent Control Room decidesSigned permitYour system checks it and actsOutcome reported

The answer is always one of three: allow, refuse, or ask a person first. Most steps are allowed or refused by rules; a person is asked only where a rule says so.

Four places it fits

These are optional connection points, not a required stack. Use the ones that match the systems you already run; a direct application connection follows the same decision pattern.

See the four connection points working together in a concrete bank-transfer example, from an agent’s request to the bank system’s reported outcome.

Follow the example step by step →

Ready-made recipes cover all four connection points: an MCP server interceptor, agent-orchestration hand-offs, an API gateway plug-in, and security-scanner integrations — each in a few lines of code.

Browse the plug-ins →

API and AI gateways

Already does: Authenticate callers, route traffic, apply quotas and filter content.

Agent Control Room adds: Every governed call gets its own business decision, not just a connection check. Before the call passes, the gateway asks for a decision, checks the signed permit locally with the published key, and reports whether the step was executed.

GatewaydecideActionCheck permit locallyForwardreportExecutionOutcome

decideActiongetGrantVerificationKeyreportExecutionOutcome

MCP gateways

Already does: Expose tools to agents and control which agent may list or call which tool.

Agent Control Room adds: Each tool call becomes one business decision, so an agent's reach through a tool stays inside the boundaries you set. The gateway sends the tool name and arguments as they are; Agent Control Room computes the fingerprint and never stores the arguments. When a person must decide, the gateway receives a hold token instead of a permit.

Tool calldecideToolCallPermit, refusal or holdRun toolreportExecutionOutcome

decideToolCallgetApprovalStatusreportExecutionOutcome

Agent orchestration and hand-offs

Already does: Start agents, pass work between them and keep the chain running.

Agent Control Room adds: Work passed between agents stays governed end to end. The orchestrator reports the hand-off chain as standard facts, so a rule can refuse long chains or ask a person when no person started the work. Each hand-off can also name the grant it came from: Agent Control Room checks that grant against its own record, and permissions can only shrink down the chain — a delegated step never outlives, outreaches or outspends the grant above it. Workspace circuit breakers cap how fast one chain, and the whole fleet, may be granted work, so a runaway cascade is held rather than amplified. Afterwards, the full chain can be retrieved as a verifiable execution graph of decisions and reported outcomes — evidence of what was authorised, not a judgement of intent.

Agent Ahands off to Agent BOrchestrator adds chain factsdecideAction

decideAction

delegation.initiator_agentdelegation.via_agentdelegation.hop_countdelegation.human_origin

Policy engines and security scanners

Already does: Answer generic access questions and inspect content for personal data, secrets or injected instructions.

Agent Control Room adds: Their findings inform your business rules without taking over the decision. Verdicts arrive as standard context facts; rules can use them, but a verdict never grants on its own: Agent Control Room never scans content itself.

Scanner or policy engineVerdict as a factdecideActionPermit or refusal

decideActiondescribePolicyEngine

sec.dlp_verdictsec.pii_detectedsec.prompt_injection_scoreauthz.external_verdict

Register directly, or keep your registry as the master

Agent Control Room keeps only a thin enforcement record: who the agent is, whether it is active, and which actions it may ask for. You can register agents directly in your workspace management console or through API operation registerAgent. If you already have an agent registry, it stays the master: your deployment pipeline can keep the enforcement record in sync through the same call. An agent that was never registered is refused and recorded for an administrator to review.

registerAgentlistAgents

Who owns what

Your systemsAgent Control Room
Routing, identity and quotasRules for each action
Agent inventory and lifecycleApprovals when a rule asks a person
Content scanning and dataSigned, short-lived permits
Doing the workThe decision record and its evidence

What it is not

  • Not a proxy or gateway
  • Not a model router
  • Not a content scanner
  • Not a model inventory

Optionally, the Complyee Policy Library reads your written corporate policies into the same decision, with cited evidence. Advisory readings never change the answer; a gate can only hold or refuse work the written policy does not support, never grant.

Running several agents that hand work to each other? See how delegation, cascades and evidence are controlled at the execution boundary.

Multi-agent governance →