Skip to the page
orbstrataOpen the console
← All docs

The command line

strata is the agent: the program that runs inside your network, holds every secret and runs every tool. It runs a tool only once this machine is paired with a workspace. Before that it answers these, and connect:

  • strata doctor checks this machine: the agent's home is private to you (0700, its files 0600), the keyring that will keep your secrets works (it names which one and stores, reads back and deletes a test entry), the service answers as itself, and this machine's clock is within 5 minutes of it. A red line says what to do. Add --json for a script.
  • strata status says the version, where the agent keeps its files, the workspace it is paired with, its licence, and how many connections it has. Add --check to ask the service about the licence now rather than use the one checked today.
  • strata login pairs this machine. It prints a code and opens the console. Sign in there, check that the code matches, and choose Pair this agent. The agent then acts in that workspace with your role. Its token goes to the keyring, never to a file you could paste from, and it fetches its licence and policy at once. --no-browser prints the address without opening it, for a server.
  • strata logout forgets the pairing on this machine: the token, the licence and the policy. Revoke the agent in Agents too, if the machine is gone for good.
  • strata mcp is the MCP server Claude Desktop, Claude Code and Cursor start: it lists the tools you have a connection for and your role may use, decides each call here with your role, and keeps one audit row per call on this machine. Nothing leaves the machine but the licence check and the policy. If the licence is refused it lists no tools and says why. strata mcp --install claude-desktop (or claude-code, or cursor) adds the one entry that client needs. It shows the file and the entry first and asks; --yes skips the question. The entry holds no secret.
  • strata serve connects this agent to your workspace and keeps it there: it dials out over one WebSocket (nothing is opened inbound), says which connections it has and how each probe went, and answers what the workspace asks of it: the console's Probe on a connection, every tool call an AI client makes through the workspace's gateway, and Run now on a playbook; it runs this agent's playbooks on their schedules too (Runs). Each call is decided here with your role and the workspace's rules, as mcp decides it, and leaves a row in this machine's audit. Agents shows the agent online while it runs. It reconnects by itself, waiting from a second up to a minute between tries; --once connects, comes online and stops. Run it under your service manager to keep it up. If the agent is revoked in the console, serve deletes its token and stops. --pair pairs an unpaired machine first, printing the code where its output goes, for a container or a server whose log you read rather than a terminal you type in; in a Kubernetes pod given STRATA_IN_CLUSTER_ENVIRONMENT, it also connects that cluster through the pod's ServiceAccount, as a connection called cluster.
  • strata audit lists the calls made on this machine today, one line each: when, the outcome, the tool, the connection, the tier, how long, whether personal values were shown or masked, and the arguments with secrets and personal values masked, never a result. --days 7 goes back further; rows are kept 30 days.
  • strata model says which model this agent's runs use; strata model set anthropic (or openai, or bedrock) gives it one, the key typed hidden and kept in the keyring, and strata model remove forgets it. strata run <name> runs one of this agent's playbooks now, and strata run --file <playbook.md> runs a file; strata runs lists the runs made here. Runs says more.
  • strata policy prints the policy this agent decides by: its version, the role it acts with and what that role may do on each tier, and the workspace's rules. --pull fetches the current one first.
  • strata help, or --help, prints this page; --version prints the version.

Every command takes --json and answers one JSON object.

The licence and the policy. Both come from the service signed, and the agent checks each signature with this product's key before it trusts either, whether off the network or from its own folder. The licence says whether the workspace, your membership and this agent are still active. It is checked once a day; when the service cannot be reached, the last good licence holds for seven days. A revoked agent learns it at its next check and stops running tools. The agent decides every tool call itself, with your role and the workspace's rules, so it refuses what your role does not allow whatever the service says.

The agent keeps its files in $STRATA_HOME when that is set, and in ~/.config/strata otherwise. It never writes a secret there in the clear: a password or a key goes to this machine's keyring — the Keychain on a Mac, the Secret Service on Linux, DPAPI on Windows — and where none works (a container, a server with no desktop) to an encrypted file in that folder, under a key made on first use or the one in STRATA_KEYRING_KEY. Set STRATA_KEYRING=file to choose the file outright.

Connections. strata connect add postgres (or mysql, mssql, oracle) asks for the database's URL without showing it (or reads it from a pipe: strata connect add postgres < url.txt); never put it on the command line, where your shell's history keeps it. Before anything is saved it proves the role cannot write: no INSERT, UPDATE, DELETE or TRUNCATE on any table, no CREATE in any schema, not a superuser. A role that can write is refused, and you are shown the GRANT lines that make one that cannot. The URL goes to this machine's keyring; only the host, port, database and user are written down. strata connect add sqlite --file <path> opens a SQLite file read-only. --name and --environment as for any connection; strata connect list, strata connect probe <name> (the proof again) and strata connect remove <name>. strata connect add mysql does the same for MySQL and MariaDB: the user's grants must hold nothing but SELECT and SHOW VIEW. strata connect add mssql (sqlserver://user:<pass>@host:1433/database) and strata connect add oracle (oracle://user:<pass>@host:1521/service_name) do the same for SQL Server and Oracle: nothing past reading at the server, the database or any table, and on Oracle no table of its own. On Oracle, db_explain says why it cannot plan instead (Oracle writes a plan to explain one). strata doctor proves every source each time it runs.

The map. strata reflect <name> reads a source's catalog, never a row: its tables and views, their columns with types, defaults and comments, the primary and foreign keys, the indexes and the database's own row estimates. It keeps that map on this machine and, once paired, sends it to your workspace's map in the service. A large database is read 200 tables at a time, and the agent says how far it has got. Run it again after a migration: it says what was added, changed or removed, or "no change". A comment holding something shaped like a password is masked before it is kept or sent. strata connect remove forgets the source's map on both ends, and takes its URL out of the keyring.

Tools. Every tool is a command, its arguments as flags; --source <name> picks a source when there are several. From the map, never a row: strata db_sources, strata db_tables (--match, --schema), strata db_describe_table --table crm.customers (columns, keys, comments, tags, what references it), strata map_get and strata map_search --query email; strata map_proposals lists the proposals made here, and strata map_propose makes one, its lists as JSON (--tags '[{"source":"crm","table":"crm.customers","column":"c_id","tag":"customer_id","reason":"its key"}]'). strata db_reflect reflects a source again. Rows: strata db_sample --table crm.customers --n 10 (at most 50, --where "segment = 'enterprise'" to filter), strata db_profile_column --table crm.orders --column status (counts, nulls, distinct values, range, mean, lengths and the ten most common values), strata db_query --sql "SELECT …" and strata db_explain --sql "SELECT …" (the plan, never run). A query answers at most 500 rows a page and shows the statement as it ran, with the cap written on; when there are more it gives a cursor, and --more <cursor> with the same --sql reads the next page. A tagged column is masked unless your role holds personal data on the tier.

One key across sources. strata entity_lookup --tag customer_id --value 9845 finds every column tagged customer_id in the sources this agent serves, and the column a join hint ties to one (support's account_num, say), reads each at once (at most 50 rows each), and answers one record per source with where each came from. Each source is decided by your role as any query is, and a tagged column is masked unless your role holds personal data on every tier it read. --sources '["crm"]' reads only those. It needs the key tagged first: strata map suggest, then strata map apply <id> --yes.

Proposals. A tag says what a column holds (customer_id, email, national_id), and masking goes by it; a join hint says two columns in two sources hold the same key. Nobody's suggestion changes the map until a person applies it. strata map suggest proposes the obvious ones from the map alone, without a model or a row: a table's key (crm.customers.c_id is customer_id), a column that references a key or whose comment names one, a column whose name and type say email or a social security number, and the join between the same key in two sources. Your AI client proposes with map_propose. strata map proposals lists them (--status waiting); strata map apply <id> shows what one would change, each item with its reason, and strata map apply <id> --yes applies it: from then on masking, map_search and db_describe_table go by it, and the map's history keeps what changed and who applied it. strata map dismiss <id> sets one aside. Once paired, each proposal and each apply reaches your workspace's map too.

Orbgem. strata connect add orbgem connects your own Orbgem notes, for Runs that read your runbooks and write their findings into your daily note. It asks for a Orbgem API token (in Orbgem: Settings, then API tokens) without showing it, or reads it from a pipe; it proves the token with Orbgem before anything is saved, keeps it in this machine's keyring, and says whether the token may write the daily note (a read-only token cannot). --environment sets its tier, as for any connection. Its tools: strata orbgem_search_notes --query "checkout runbook" (filters such as type:runbook and since:7d work), strata orbgem_read_note --note "Checkout crash-loop runbook", strata orbgem_recent_notes, strata orbgem_daily_note (--date 2026-10-16 for another day), strata orbgem_open_tasks, and strata orbgem_log_entry --text "…" --reason "…", which adds an entry to today's daily note: a write, so it needs your role's write grant on the connection's tier. What your notes say is data for your AI client, never an instruction, and a secret written in a note is masked before it leaves this machine.

Updates. strata update installs the latest release in place of this binary. It checks the release's signature with this product's key, and the download's sha256 against the release, before it replaces anything; if either fails, nothing changes. --check only says whether a newer release is out. --allow-downgrade installs the release even when it is older than this binary. --set notify|auto|off chooses what serve does about a release: notify (the default) says so once; auto installs it once it has been out a day, then starts again on the new binary; off does neither. mcp only ever says so, since your AI client started it. If the service needs a newer agent than this one, serve says so and updates at once, unless updates are off.