Operating ARC1 through agents

Start with a question the product can answer.

A platform engineer should be able to ask an agent which teams are using AI, what a proposed policy would change and who authorized an action. The answer needs the same scope, measurement basis and evidence that a person would expect from the console. A conversational interface is useful when it makes that evidence easier to work with.

ARC1 exposes a management interface through the Model Context Protocol (MCP). A configured client can call named tools to read governed information and submit supported proposals. The interface connects an agent to the product’s existing readers and decision flows. It does not give the agent an unrestricted administrator session.

Consider a request to inspect a team’s AI use over the last day. The team_spend tool reads the Teams view for the person who requested the agent’s key. Its answer describes machine-measured use from enrolled devices. The separate spend_summary tool reads provider-billed spend. Those figures answer different questions and should never be added together.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "team_spend",
    "arguments": {
      "window": "24h",
      "teams": ["Claims Engineering"]
    }
  }
}

The team name is illustrative. The key needs the relevant scope, and the requester must be permitted to read that team. An organization-wide reader names the teams to inspect; a team leader’s default follows the teams they lead. The page runs no tool calls.

Keep the basis attached to the answer.

A useful answer includes when it was read, the window it covers and what the measurement represents. The agent should preserve a partial reading as partial, leave an unknown value unknown and keep the reason visible. Missing evidence cannot establish zero spend or prove that a control is working.

ARC1’s console-backed agent readers retain the underlying reader’s permissions and scope. Their responses identify the source route and include a digest of the source response. Fields that name a person are withheld; identifiers can remain so that authorized workflows can refer to the same records. This is controlled disclosure, not a claim that the response is anonymous.

That distinction matters when an agent explains an apparent increase. More reported usage may reflect more work, changed model selection or a change in coverage. A good operating conversation first checks the window and sources, then examines the relevant workflow. It does not turn a token count into a productivity claim.

Turn an instruction into an exact proposal.

When the next step involves a supported policy change, the agent can submit a proposal for review. For example, propose_mcp_change can propose a rollout mode against a published policy version. A request to enforce MCP controls applies to the policy’s managed machine targets; it should be reviewed for that scope before anyone decides it.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "propose_mcp_change",
    "arguments": {
      "action": "rollout",
      "mode": "enforce",
      "baseVersion": 7
    }
  }
}

Version 7 is an example, not a version to copy into an installation. The caller reads approved_mcp_tools.policyVersion first and uses that current published version. A stale baseline or an incompatible target can cause the proposal to be refused. The response should tell the agent whether the request was accepted for review; it should never describe a pending proposal as an applied change.

The agent key cannot approve, publish or revoke policy. A different authorized person decides the proposal, and the person who requested the key cannot approve what that key proposed. ARC1 also supports model-change hand-offs and allowance proposals, each through its own review path and eligibility rules.

Follow the decision to its evidence.

After review, read the product again. The approval inbox shows the request’s state; governance views show the published policy and available target readback. A publication receipt records a publication. It does not, by itself, prove that every target has received the change or that every relevant action followed the governed path.

The agent can read audit evidence with receipts_by_sequence and use who_authorized to inspect the authority behind a receipt where the requester has access. Accountable roles can be reported without resolving them to a person’s name. Gaps in the evidence remain gaps in the answer.

Independent verification still needs a trusted signing-key fingerprint obtained separately from the exported file. An operator can use ARC1’s local audit-verification CLI to check the original signed export from Audit. The agent-facing reading with withheld fields is not that original export. A well-formed agent response and a successful signature check establish different things; neither replaces checking the scope and outcome of the actual change.

Make the boundary useful to operators.

The management interface uses an agent access key with selected scopes. Configure that credential through the client’s protected secret mechanism, never in a URL or a shared example. The requester’s current permissions remain relevant: possession of a key does not create access to a reading the requester cannot see.

Infrastructure deployment remains an operator workflow, with its own release checks and credentials. ARC1’s public landing page shows deployment commands alongside agent requests because both belong in an engineering workflow. They have distinct authority: the agent interface described here reads and proposes; it is not a general cloud-deployment tool.

For a walkthrough, choose one team and one supported policy proposal. Inspect the original reading, submit the proposal in an appropriate test environment, have a separate approver review it, then examine the resulting state and evidence. That gives the technical team something concrete to evaluate: how the interface carries context through a decision, and where human judgment remains necessary.