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):