Skip to main content
Devctrl sits between your AI agents and the tools they use. Every request passes through the managed gateway, where it’s authenticated, authorized against your policies, and logged — before reaching the upstream tool server.

​
Architecture

┌─────────────┐                                                ┌──────────────┐
│   Claude    │──┐                                        ┌──▶│   Jira API   │
└─────────────┘  │                                        │   └──────────────┘
                 │   ┌──────────────────────────────┐     │
┌─────────────┐  │   │     gateway.devctrl.ai/mcp   │     │   ┌──────────────┐
│  OpenClaw   │──┼──▶│                              │─────┼──▶│   Linear     │
└─────────────┘  │   │  Auth → Policy → Proxy → Log │     │   └──────────────┘
                 │   │                              │     │
┌─────────────┐  │   └──────────────────────────────┘     │   ┌──────────────┐
│ Your Agent  │──┘              │                         └──▶│   Stripe     │
└─────────────┘                 ▼                              └──────────────┘
                      ┌─────────────────┐
                      │   Audit Logs    │
                      └─────────────────┘
All agents connect to https://gateway.devctrl.ai/mcp. You manage your projects, tools, identities, tasks, and policies in the Devctrl Console.

​
Request flow

When an agent makes a tool call, here’s what happens:
1

Authenticate

The gateway verifies the bearer token against the identity’s credential. If a task token is present in the X-Task-Token header, it loads the task session and its context.
2

Rate limit check

The request is checked against rate limits at the session, project, and global levels. If any limit is exceeded, the request is rejected with a 429 status.
3

Resolve tool

The gateway looks up the requested tool to find which upstream MCP server hosts it.
4

Evaluate policies

The policy engine runs your CEL expressions against the request context:
{
  "identity": { "name": "...", "labels": { ... } },
  "task":     { "name": "...", "labels": { ... }, "context": { ... } },
  "request":  { "tool": { "name": "...", "args": { ... } } }
}
Deny rules are checked first. If any deny rule matches, the request is blocked. Then allow rules are checked — all must pass. If no active policy release exists, the project’s default action (allow or deny) applies.
5

Proxy to upstream

For allowed requests, the gateway forwards the tool call to the upstream MCP server and returns the response to the agent.
6

Log the result

Every decision — allow or deny — is recorded in the audit log with the full context: identity, task, tool, arguments, policy evaluation results, and upstream response.

​
Key components

MCP Gateway

The managed service that routes MCP requests between agents and tool servers.

Policy Engine

Evaluates CEL expressions against every tool call to enforce allow/deny decisions.

Console

The web interface where you manage projects, identities, tasks, tools, and policies.

Audit Log

Complete record of every agent action — what was requested, what was decided, and why.