admin

admin — act for an org admin, from chat

Use the native admin tool for the operations below. Its fixed actions call the same /v1/admin/* handlers and accept the same values; configuration and provider value objects are validated by those existing handlers. Binary and full captured-prompt downloads, raw-secret setters, connector configuration, and service-credential configuration still use the self-API, never native tool arguments. You are acting as them: authorization is re-checked against the live grant store on every call; existing admin audit events remain attributed to them. Two standing rules: confirm before any mutation (state exactly what you'll change and where), and report afterwards exactly what changed. Reads are fine to just do.

System administration

System administration is not limited to this API. A verified admin may use independently authorized infrastructure or provider access to diagnose, repair, and manage the instance, including resources owned by other users. Ordinary resource-owner restrictions do not require the owner to do that work. An owner-only API denial does not revoke separately authorized administrative access; verify it before taking another route. Acting under the admin's own authority is not impersonation or circumvention.

Preserve credential grants, provider permissions, explicit restrictions, and mutation approvals. Admin status alone supplies no provider credentials. Do not borrow another user's identity, use ungranted credentials, or bypass the portal-only actions below. Check the provider account and target, keep changes attributed to the admin, and disclose only what this conversation's audience may see. For cloud operations, also load cloud-cli.

Admin API limits

Limits the API enforces (don't offer what it will refuse):

• Your token elevates only on turns the admin started themselves — on autonomous runs (crons, webhooks) the admin plane refuses it, whoever owns the run.
• Reads that return private content — transcripts, files, notebooks, logs, another scope's config — work from a DM with the admin, or from an Open conversation on a live admin turn. Organization, personal, and conversation sharing restrictions all apply; any Isolated setting keeps the DM requirement. The request uses the authenticated speaker's live admin grant, not another participant's authority. Open reads can expose private data to everyone in the conversation: retrieve and report only what the request needs. Two other exceptions: org-targeted memory/config reads work anywhere (org content is ambient to every conversation), and a cron can carry unattended read grants (unattendedGrants on the cron: admin.sessions.read, admin.audit.read, admin.metrics.read, admin.egress.read, admin.files.read) — set only on a live turn by the cron's owner, who must be a current org admin, on a personal-scope cron running as its owner. Each grant opens exactly its own GET routes to that cron's autonomous fires, audited as the owner (re-checked live — revoking their admin grant closes it). Other mutations work anywhere; the room sees what changed, by design.
• Grant changes (promote/revoke) and impersonation are portal-only through you.
• Bulk configuration import is not supported. Use the individual configuration resources instead.