← Back to Blog

One Command to Policy-Enforced Agents: Introducing the CLI Init Tool and MCP Server

Getting spending controls onto an AI agent’s wallet should not require wiring up SDKs, generating API keys through a dashboard, configuring wallet adapters, and manually registering MCP tools. But until now, it did.

Today we’re shipping two things that collapse that entire process into a single command: a CLI init tool and an MCP server.

One Command

npx @policylayer/mcp init

That’s it. The CLI handles everything:

  1. Browser authentication — opens your default browser, authenticates via your PolicyLayer account (or creates one)
  2. Organisation setup — selects your organisation (or creates one for new accounts)
  3. Agent creation — name your agent, get an API key
  4. Policy configuration — set daily limits, per-transaction caps, and optional hourly budgets
  5. MCP registration — writes the config your AI client needs to discover PolicyLayer’s tools

When the init finishes, your agent has spending controls. No dashboard clicks, no manual config files, no copy-pasting API keys between browser tabs.

What Gets Installed

The init tool configures @policylayer/mcp as an MCP server. MCP (Model Context Protocol) is the standard for exposing tools to AI clients. Once registered, your agent automatically discovers five tools:

ToolPurposeMode
check_budgetRemaining spending capacity across all policy dimensionsRead-only
validate_transactionAdvisory check: would this transaction pass policy?Read-only
list_policiesActive spending policies for this agentRead-only
transaction_historyRecent policy decisions for audit and contextRead-only
send_transactionValidate, sign, and broadcast a transactionExecution

The first four are available immediately. send_transaction requires a wallet — more on that below.

Two Modes: Read-Only and Execution

Not every agent needs to send transactions. Some just need to check budgets before proposing actions. Others need to execute.

Read-only mode is what you get out of the box. Your agent can query its budget, validate hypothetical transactions, and review history. This is useful for agents that recommend actions for human approval, or that need to reason about financial constraints without acting on them.

Agent: "I need to pay 500 USDC to 0xAbc for the data feed."

→ calls validate_transaction(chain: "base", asset: "usdc",
    to: "0xAbc...", amount: "500")

→ PolicyLayer: "DENIED — exceeds daily limit of 100 USDC.
    Remaining: 73.50 USDC"

Agent: "The payment exceeds our daily budget. I can process
    up to 73.50 USDC today. Shall I proceed with a reduced
    amount or queue this for tomorrow?"

The agent never sees the policy rules directly. It calls a tool, gets a result, and reasons about next steps. This is exactly the tool-layer enforcement pattern we’ve written about before.

Execution mode adds send_transaction. To enable it, add wallet environment variables (WALLET_PRIVATE_KEY, CHAIN, RPC_URL) to your MCP server config. The private key stays on your machine — PolicyLayer never sees it. PolicyLayer validates the intent against your policies, the MCP server signs locally, and the transaction broadcasts.

Agent: "Sending 25 USDC to 0xDef for the API subscription."

→ calls send_transaction(chain: "base", asset: "usdc",
    to: "0xDef...", amount: "25",
    memo: "Monthly API subscription")

→ PolicyLayer: validates intent → SDK signs locally → broadcasts

→ { success: true, hash: "0x7a3f..." }

The Non-Custodial Guarantee

This matters enough to state plainly: your private key never leaves your machine.

The MCP server runs locally. When send_transaction fires, the flow is:

  1. Agent constructs a transaction intent (chain, asset, recipient, amount)
  2. MCP server sends the intent to PolicyLayer’s API for policy validation
  3. API returns a cryptographic approval token (or a denial)
  4. MCP server signs the transaction locally using your key
  5. MCP server broadcasts the signed transaction

PolicyLayer sees intents. PolicyLayer returns approvals or denials. PolicyLayer never holds, transmits, or has access to your signing key. If our API goes down, your agent can’t transact — fail-closed, not fail-open.

This is the same two-gate architecture that underpins all of PolicyLayer. The CLI and MCP server are a new interface to the same cryptographic enforcement.

What the Init Flow Looks Like

$ npx @policylayer/mcp init

  PolicyLayer
  Set up spending controls for your AI agent.

  ──────────────────────────────────────────────────
  1. Authenticate
  Sign in to your PolicyLayer account via the browser.

  ✓ Signed in as dev@acme.com

  ──────────────────────────────────────────────────
  2. Organisation
  Choose which organisation this agent belongs to.

  ✓ Organisation: Acme Research Labs

  ──────────────────────────────────────────────────
  3. Create Agent
  Give your agent a name.

  ? Agent name: market-scanner
  ✓ Agent created: market-scanner

  ──────────────────────────────────────────────────
  4. Spending Policy
  Set spending limits to control how much your agent can spend.

  ? Asset to control: USDC — enter limits in dollars
  ? Daily limit in dollars (USDC): 500
  ? Per-transaction limit in dollars (USDC): 100

  ✓ Policy created for USDC
    Daily limit:    $500
    Per-tx limit:   $100

  ──────────────────────────────────────────────────
  5. MCP Configuration

  Detected environment: Claude Code

  ? Run this command now? Yes
  ✓ PolicyLayer MCP server added to Claude Code.

  ──────────────────────────────────────────────────
  Setup complete

The CLI detects your AI client (Claude Code, Cursor, Claude Desktop) and registers the MCP server automatically. If it can’t detect one, it outputs the JSON config for you to place manually.

After Setup

Once init completes, open your AI client and the tools are there. No imports, no registration code, no boilerplate. The agent discovers them through MCP’s standard tool discovery.

Everything the CLI creates — agents, policies, API keys — is visible and editable in the dashboard. Adjust limits, add new policies, revoke keys, review audit logs. The CLI gets you started; the dashboard gives you ongoing control.

An agent checking its budget:

→ check_budget()

{
  "budgets": [{
    "asset": "USDC",
    "remaining": {
      "daily": "425.00",
      "hourly": "175.00",
      "perTransaction": "100.00"
    }
  }]
}

An agent reviewing recent decisions:

→ transaction_history(timeframe: "24h", limit: 5)

{
  "events": [
    {
      "timestamp": "2026-02-21T14:32:00Z",
      "decision": "APPROVED",
      "intent": { "asset": "USDC", "to": "0xDef...", "amount": "25.00" }
    },
    {
      "timestamp": "2026-02-21T13:01:00Z",
      "decision": "DENIED",
      "reason": "Exceeds per-transaction limit",
      "intent": { "asset": "USDC", "to": "0xAbc...", "amount": "500.00" }
    }
  ]
}

The agent doesn’t need to parse policy rules or understand enforcement logic. It gets structured results and decides what to do next. The policy layer is invisible infrastructure.

Why MCP

We could have shipped a REST wrapper and told developers to write tool definitions. We chose MCP because it eliminates the last integration step: registration.

With MCP, you don’t write tools.push({ name: 'check_budget', ... }). The protocol handles discovery. Your AI client sees the tools, their schemas, and their descriptions automatically. The agent knows what’s available without you telling it.

This also means policy tools sit alongside whatever other MCP servers your agent uses — file access, web browsing, database queries. Spending controls become part of the agent’s standard toolkit, not a special case requiring custom wiring.

What’s Next

The init tool and MCP server ship today on npm. The init command works with Claude Code, Cursor, and Claude Desktop. Wallet signing supports viem and ethers adapters out of the box.

If you’re running AI agents that touch money, this is the fastest path to production-grade spending controls.


Related reading:

Get started:

Ready to secure your AI agents?

Get spending controls for autonomous agents in 5 minutes.

Get Started