For a developer
You want your agent useful on what you are working on and nowhere near what you are not. The day comes down to a few things: environments named once, secrets that never reach a command line, an agent that reads freely and asks before it changes anything, and a record you can check afterwards. Each section is one task and the chapter behind it.
Set the machine up, once
rta kv init --generate # a dedicated key for your secret store
rta mcp install claude # register rta with your agent, under the name claude
rta doctorWith --generate nothing asks for a passphrase again, and losing that key costs this store and nothing else. mcp install registers rta mcp serve --as claude, and the name is what grants follow, so another client registered under another name gets none of them. Read doctor's info rows: the store unlocks from this environment is a fact about what your agent's server inherits. Secrets · Connecting your AI tool.
Name each environment once
rta kv set staging-db-password # asks for it, echoing nothing, so no shell history holds it
rta profile set staging --note "shared staging" --ttl 8h \
--plugin pg --set host=db.staging.internal --set database=app \
--secret password=kv:staging-db-password
rta profile listA value typed after the key would land in your shell history, so kv set asks for it here, at the terminal and without echoing it; one already in a file comes from --file, and the TUI's kv set form masks it. A profile points every plugin that has something in it at one environment, and its secrets: hold a reference, never a value. In the TUI it is one form: f, then n. Profiles.
Work in one environment at a time
rta use staging --for 2h
rta pg query "select count(*) from orders" # no --profile: staging is on
rta use --offWhile a profile is on, rta mcp serve refuses every other one, whatever grants exist. It only takes away, so it is the safe thing to reach for first. Switching authorizes nothing.
Give your agent one thing, for a while
rta grant allow pg.query --profile staging --agent claude --ttl 1h --rate 30/1h
rta grant allow kv.get staging-db-password --agent claude --ttl 5m --max-uses 1
rta grant listA read costs nothing until it names a profile. Anything that changes something, or returns what somebody stored, costs a grant: one capability, optionally one record, gone on its own. --rate is the bound people skip and the one that makes a runaway visible while it is happening. When your team keeps roles, rta grant roles lists them and rta grant issue dev --agent claude issues a day's worth at once. Grants · Pair with an agent on a staging database.
Answer it while you work
rta agent pending
rta agent allow # one call waiting: shows it, with what it would do, and asks
rta agent allow 5473aa62 # several waiting: name the oneA call waiting for you shows on every screen of the TUI, in one line above it: w opens the queue, enter shows what a call would do, a names the call and what it would do and enter allows exactly that one, d denies it. Allowing runs that one call and leaves no standing grant behind; A is the form for one that should. A call parks instead of being refused only on a server started with --consent — be asked instead of refused says when that is worth it and when it is not.
See what it did
rta agent log --limit 20
rta agent log --refusedEvery call that came over MCP is a line — refusals included, secret arguments masked — and g in the TUI opens the same record. What you run at your own terminal is not in it: the record is what the agent did. The record.
Secrets, day to day
eval "$(rta kv env staging-db-password)" # STAGING_DB_PASSWORD, in this shell only
rta kv get tls-cert --out /tmp/server.pem # written at 0600
rta kv history staging-db-password # when each earlier value was set, never the valueA value pasted over the wrong key is undone by name, and rta kv status answers without unlocking anything. Undoing a mistake.
Keep the TUI open
rta
rta dashboard add pg.overview --profile staging/ searches every capability, f is your environments, and + puts a capability on the dashboard. The tiles rta picks on its own never reach off the machine; one that does is yours to add, pinned to the connection you name. The TUI.
End of the task
rta grant revoke --all
rta use --offGrants lapse on their own. Revoking is for a task that ended early, or for walking away from a machine with a server still running.
Related
- For a security team — the same boundary, from the side that owns it
- Profiles · Grants · The TUI
Next
An agent in a cluster — when the agent should run somewhere else and hold nothing.