Skip to main content

Documentation Index

Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

The hardest engineering problem in agent design isn’t getting the agent to do useful work. It’s making sure a useful agent doesn’t do harmful work. Studio’s answer is a single, opinionated architecture: every tool call passes through a classifier, every classifier-flagged call passes through an approval gate, the gate is rendered in a way the operator can actually read, and the operator can stop or redirect a run at any moment. This page is the engineering description of that architecture. It is the page to read if you are deciding whether to grant your team Autopilot.

​
The trust levels

Studio has three trust levels. They are the primary lever you have over agent behavior.
Trust levelApproval behaviorWhen to use
ManualEvery tool call requires explicit approval, regardless of class.Unfamiliar device, learning the agent’s habits, regulated change windows.
Supervised (default)Read-only operations run freely. Tools classified as moderate, dangerous, or unknown require approval.Day-to-day operations where the operator wants speed for safe calls and a gate for everything else.
AutonomousAuto-approves tools the policy permits, removes turn budgets, runs sequences without per-call prompts.Controlled environments — labs, scoped procedures, automation against a target you have already characterized.
The trust level applies to the conversation, not to the tool. A read-only call in Manual still asks for approval; a destructive call in Autonomous still pauses if the policy classifies it as Dangerous. The trust level moves the threshold; the classifier moves the floor.

​
Tool classification

Every tool that Copilot can call is classified before it runs. The class determines whether the trust level alone is enough to authorize the call.
ClassExamplesBehavior
Read-onlyshow, display, ping, traceroute, inventory list, log fetch, SNMP get, banner scan.Permitted in any trust level.
ModerateEntering config mode, single-line interface change, ACL edit, saving configuration, connector write to a non-destructive endpoint.Approval required in Supervised; auto-approved in Autonomous if the policy allows.
Dangerousreload, erase, format, clear ip route *, force-delete, factory-reset, BGP clear, anything that takes the device offline or destroys state.Approval required in Supervised and Autonomous. Cannot be auto-approved by trust level alone.
UnknownA tool the classifier cannot place with confidence (rare, usually a custom connector tool with a generic verb).Treated as Moderate-or-worse. Never auto-approved without explicit policy.
The classifier is part of the tool registry. Each tool’s domain (terminal, connector, MCP, diagram, search, network discovery, packet capture, etc.) declares which subset of its operations require approval. New connector and MCP tools default to Unknown until the org admin explicitly classifies them.

​
The approval gate

When a tool call requires approval, Copilot pauses and renders a card the operator can read. The card includes:
  • The tool name and the domain it belongs to — so you know whether it’s a terminal command, a connector call, a write to your inventory, or a destructive operation on a device.
  • The exact arguments — including the destination (host, connector endpoint, file path), the payload (command text, request body), and any parameters the model is filling in.
  • The risk class — Read-only / Moderate / Dangerous / Unknown.
  • The credential reference that would be used, if any — by name only, never the secret.
  • A diff or preview for staged commands, so you can see the change in human-readable form before approving.
  • Approve, reject, or modify as actions. Modify lets you edit the arguments before approving.
The approval gate is non-bypassable. A tool that wants to run cannot get past it; the agent simply waits. The wait is observable — Copilot’s status shows “awaiting approval” with the tool and the time elapsed.

​
Streaming and steering

While Copilot is running, you watch progress in real time. The right-side panel shows:
  • The current model thinking state (when extended thinking is enabled).
  • Each tool call as it streams (name, arguments, partial output as the call returns).
  • Token and turn usage against the run’s budget.
  • The classification and approval state of any pending tool.
  • Sub-agent activity when a delegated agent is running.
You can act on what you see in three ways:
ActionWhat it does
Send a steering messageNew text from you joins the conversation at the next natural break. The agent picks it up before continuing.
Queue a steering messageA steering message that fires at the next tool boundary. Useful when you want to redirect the agent’s plan without interrupting an in-flight call.
Stop the runHard stop. The current tool finishes; nothing further runs. The transcript is preserved.
Steering is a first-class feature. It exists because no one writes a perfect first prompt, and because plans drift. You should use it freely. The transcript will show what the agent did and what you said in response — that’s the record, and it’s complete.

​
Sub-agents inherit the gate

Copilot can delegate to specialist sub-agents — researcher, executor, terminal-ops, browser-ops, network discovery, procedure authoring. A sub-agent runs in the same conversation, with the same trust level, and the same approval policy. A delegation cannot escalate beyond what the parent’s posture allows. This matters because it would be easy to design an architecture where a sub-agent gets its own scope, and a Read-only researcher could quietly call a Dangerous executor without the parent’s gate. Studio’s design is the opposite: the gate sits at the agentic loop, every tool call from any agent goes through it, no exceptions.

​
Just-in-time credentials

When a tool call requires a credential — to authenticate to an SSH host, to call a connector — the credential is requested through the vault, not through the LLM. The flow is:
1

Tool indicates a credential reference

The tool’s argument schema includes a credentialRef (a Keychain entry ID), not the secret itself.
2

Approval card shows the reference

The operator sees “will authenticate to core-router-1 using Keychain entry core-fleet-admin” — by name, never by secret.
3

On approval, the vault unwraps

The Go sidecar requests the credential from the vault, unwraps the per-record envelope, and uses the secret in the protocol library.
4

Plaintext stays in sidecar memory

The plaintext credential never crosses back into the Electron renderer process or the LLM context. It is used by the Go sidecar at the moment of authentication and discarded.
This is what we mean when we say “secrets never enter the model context” — the LLM sees the credential reference, the protocol library sees the secret, and the two are wired together by the vault without the LLM ever holding the plaintext. The exception is procedure substitution: if a procedure body explicitly substitutes {{password}} into a prompt that goes to the model, that plaintext does enter the model context. This is documented under known limits and the AI-context scrubbing roadmap.

​
Pre- and post-tool hooks

Studio supports hooks that run before and after every tool call. Hooks are an extensibility point, not a default behavior, and they exist for organizations that want to:
  • Log every tool call to a SIEM.
  • Block specific tool argument patterns regardless of class.
  • Reject calls that target hosts outside an allowlist.
  • Re-classify a tool dynamically based on the argument (for example, treating interface gigabitethernet0/0/0 as Dangerous on the management interface).
Hooks run server-side or in the agent depending on the kind. Failed hooks block the tool call and surface the failure in the approval gate.

​
Choosing the right posture

A practical mapping for the kinds of work Studio gets used for:
SituationTrust levelNotes
Investigating a production incident on a device you don’t fully know.Manual or Supervised.Read-only checks first; switch to Supervised once you’ve characterised the device.
Routine diagnostic on a known host.Supervised.The approval prompts catch the rare moderate operation; everything else is fluid.
Drafting a runbook from a successful conversation.Supervised + Planning mode.Planning produces clean sequences; supervision catches the few moderate steps.
Running a vetted procedure against a labelled host.Supervised or Autonomous, depending on the procedure’s allowed_tools.Procedures restrict tools at run time; Autonomous on top is appropriate when the runbook itself is trusted.
Bulk operations against a fleet inside a maintenance window.Autonomous, scoped procedure, narrow allowed_tools.Approval per device would be operationally unworkable. The scope is the safety mechanism.
The shape that emerges: the threshold for Autopilot is “I know what’s allowed and what target it’s allowed against.” Not “I trust the agent.”

​
What this is not

The HITL surface is not a substitute for any of the following:
  • A change-management process. Approval at the agent gate is not approval at the CAB.
  • A separation-of-duties review. One person approving their own approvals is one person doing both.
  • An audit log. The gate produces evidence; the audit page describes what’s recorded.
  • A guarantee that the agent does not surprise you. The gate makes surprises observable, not impossible.
The gate is the enforcement point. Process around it is the reason the enforcement matters.

AI provider and data flow

What happens to the data the gate is approving — where it goes for inference and what comes back.

Audit and telemetry

What’s recorded about every approval, every tool call, and every steering interruption.