Tenant Administration Guide

Tenant administrators manage members, credentials, billing visibility, and audit history. Use these controls to grant the least access needed and to preserve a reviewable operational record.

Access

Open the relevant account page:

• Team Members at /account/members requires member-management visibility;
• Credentials at /account/credentials requires secret-management access;
• Billing at /account/billing requires billing visibility; and
• Audit Log at /account/audit-log requires audit visibility.

Unavailable pages or controls indicate the active account lacks the required tenant capability. Access is enforced by the API as well as the interface.

Manage a member

1. Open Team Members and confirm the active tenant.
2. Invite or select the member.
3. Grant only the role, product profile, capabilities, and resource scope required for their work.
4. Verify the member can reach the intended resource and cannot reach an out-of-scope resource.
5. During offboarding, remove resource memberships and revoke credentials or grants owned by that person.

Manage credentials safely

Create a named secret reference with a clear owner and purpose. Topline displays metadata and health, not the stored secret value after creation. Rotate by adding the replacement, testing every consumer, promoting the new version, and then revoking the old value. Never paste a credential into chat, documentation, artifact source, or audit notes.

Review billing

Use Billing to review the tenant's available plan and usage information. Treat unavailable or stale provider data as unknown rather than zero. Export or share billing details only with authorized recipients.

Investigate activity

Search the Audit Log by actor, action, resource, outcome, and time range. Start narrow, preserve relevant resource IDs and timestamps, and expand only as needed. Audit metadata is evidence of platform activity; it is not a place to copy secret payloads.

Security and tenant boundary

All administration is tenant-bound. A role does not automatically grant access to every resource, and a resource link does not bypass authorization. Use least privilege, short-lived integration grants, named credential ownership, and prompt offboarding.

Automation and MCP

External clients receive only their granted OAuth scopes and current tenant capabilities. Developer tokens and MCP grants are managed separately from member roles and should be revoked when no longer required. Automated changes must preserve the same review and audit boundaries as UI changes.

Errors and recovery

• Invite or grant fails: confirm the identity, tenant, capability, and resource scope.
• Credential consumer fails after rotation: restore the previous active version if safe, inspect the consumer reference, and repeat the smoke test.
• Billing unavailable: retry after the provider window and escalate without inferring usage.
• Audit result missing: verify the time range, tenant, action spelling, and retention window.
• Unexpected access: remove the narrowest implicated grant first, preserve IDs and timestamps, and begin an authorized audit review.

Enablement, smoke check, and rollback

For access changes, test one intended and one prohibited action. For credential changes, test every named consumer before revocation. Roll back by restoring the previous role, capability, scope, or credential version; do not weaken unrelated controls.

Limitations

Available billing fields, retention, roles, and product capabilities depend on the tenant configuration. Removing access does not delete historical audit records or outputs the member previously created.