Meet the Brutor CLI: the governed path, in one command

When security and IT teams investigate how developers ended up calling AI providers directly with personal API keys, the underlying cause is rarely malicious intent. More often, it is friction.

The governed path may already exist, but using it can require developers to find the correct gateway URL, determine which models their team is authorized to use, configure individual MCP servers, and translate all of that into the formats required by Claude Code, Cursor, VS Code, and other tools.

The alternative can be as simple as a single environment variable.

This creates a familiar enterprise challenge: when the approved path is more difficult than the unapproved one, developers will naturally optimize for speed.

Brutor CLI is designed to remove that friction. It gives developers a straightforward way to configure their local AI tools against the governed platform, while keeping enterprise policies and controls in the request path.

From laptop to governed AI in one command

Getting started is intentionally simple:

brutor setup detects the AI tools installed in the developer environment, including Claude Code, Claude Desktop, Cursor, VS Code, Codex, Goose, and the ~/.agents convention, and provides the configuration required for each.

For example:

Once configured, AI requests from those tools are routed through the governed platform. This brings enterprise controls such as guardrails, budgets, model policies, and audit logging into the developer workflow without requiring developers to manage those controls themselves.

The objective is straightforward: make the compliant path the path that is easiest to adopt.

Access-aware discovery

Configuration is only part of the challenge. Developers also need to know which models, MCP servers, and other AI capabilities they are authorized to use.

Brutor CLI provides that information directly from the platform, scoped to the developer’s access:

For MCP servers, brutor mcp connect provides a ready-to-run command together with a generic JSON configuration block, pointing to the governed MCP endpoint.

This means MCP traffic remains subject to the same platform controls as other AI traffic, including guardrails, per-tool limits, approvals, and audit logging.

Importantly, this is not simply a static service catalog. The CLI communicates with the end-user Portal API using the authenticated session, so the results reflect the developer’s actual resource-group membership and associated permissions.

Developers see what they are authorized to use, and do not receive configuration for services outside their access.

Governed skills on the developer’s machine

Agent Skills continue to run server-side in Brutor’s sandbox by default, using progressive disclosure over MCP. The skill bundle therefore remains within the platform.

However, some development workflows benefit from running a curated skill directly within the developer’s coding agent. Brutor supports this through an explicit, administrator-controlled export mechanism.

Individual skills can be marked as exportable:

Local export is intentionally controlled.

Export is disabled by default for each skill, developers can export only skills available to their resource groups, and every export generates an audit record identifying the user, skill, and version.

This makes local skill execution an explicit organizational decision rather than an unmanaged distribution mechanism.

Designed for enterprise environments

The CLI is intended to be more than a convenience wrapper. Several design decisions address the operational and security requirements of enterprise deployments:

• Credentials are stored in the OS keychain. Brutor uses macOS Keychain, Windows Credential Manager, or Linux Secret Service rather than storing credentials in plaintext files. Only non-secret configuration such as the gateway URL, tenant, and username is stored in ~/.config/brutor/config.json.
• Two-factor authentication is supported. Existing account security policies can therefore be applied to CLI access.
• Provider credentials remain server-side. Developers configure their Brutor credentials; underlying OpenAI and Anthropic provider credentials remain encrypted and managed by the platform.
• CI and automation are supported. --password-stdin allows authentication without exposing passwords through the terminal or shell history.
• The CLI is distributed as a single static binary. Written in Rust, it does not require a runtime or additional dependency tree on the developer machine.

These choices are important because enterprise adoption depends not only on functionality, but also on how the tool fits into existing security and operational controls.

A developer interface for the AI control plane

Brutor CLI is one part of the broader Brutor AI Control Plane.

Its role is to provide a consistent interface for managing enterprise AI across the environments where developers actually work: govern the AI you build, observe the AI you buy, and discover the AI already being used across the organization.

For IT and security teams, the value of the CLI is therefore not simply faster configuration. Every developer environment configured through Brutor can bring AI traffic into the organization’s governed path from the outset.

That changes the economics of shadow AI. Instead of relying solely on detection and remediation after unmanaged usage has appeared, organizations can reduce the incentive to bypass approved services in the first place by making the governed option straightforward to adopt.

The principle is simple: governance works best when it is built into the path developers already want to take.

Command reference

Full command reference and installation instructions: docs.brutor.ai/developers/cli

The Brutor AI Gateway is the enforcement engine of the Brutor AI Control Plane, routing, securing, and governing AI traffic across LLMs, MCP servers, and autonomous agents.