Authorization & data
Workspace consent, roles, saved interests and disconnecting an agent.
OAuth and workspace consent
Nabit MCP uses OAuth through the browser. Sign in to Nabit and approve the workspace shown on the consent screen. The current OAuth scope is nabit:recommendations; its name covers the current recommendation integration, including its authorized product, collection, preference and trend tools. It is not a generation scope.
The grant is bound to the authenticated account, client and workspace. Each request still checks workspace membership, product access, role and eligible plan status. A workspace grant does not let an agent choose an arbitrary account or another workspace in tool arguments.
Older product-only grants remain limited to their selected product. Current workspace capabilities require reconnecting and approving workspace consent. Check requiresWorkspaceAuthorization in get_connection_status.
Roles and spending
Owners, admins and members can perform permitted product actions. Viewers cannot write product data, generate or spend Credits. Workspace and member spending limits or pauses are enforced for paid actions. An owner or admin manages billing and can see the available billing history.
Approving a connection lets the agent use the granted tools. Review actions that save or change products, preferences, tracking, schedules or feedback. Check the price before asking for a new recommendation batch. Read-like batch tools can settle previously held Credits.
What Nabit receives
Nabit receives the tool inputs your agent sends, such as product facts, product IDs, requested actions, explicit feedback and topics you have consented to save. A product URL preview can fetch a public page. Do not put secrets in product fields or interest topics.
The recommendation integration does not automatically gain access to your complete Codex, ChatGPT or other host conversation history. Its profile sets retainRawConversation to false. This is not a guarantee about how your host agent stores conversations; review that client's own data controls.
Saved interests are opt-in. update_recommendation_profile replaces the explicitly authorized topics; disabling useSavedInterestSignals clears those topics. Product facts, saved references and feedback remain in Nabit until managed through the relevant product controls.
Operational records
Nabit records operational MCP metadata, including account/workspace/grant and product identifiers, tool name, status, error code, duration and selected metadata such as snapshot ID, action and item count. This operational log uses a field allowlist; it is not a copy of the full host conversation.
Tools can create persistent product records, collections, preferences, schedules and Credit ledger entries. Consult the Privacy policy for published data practices and Contact for privacy or deletion requests. This guide does not promise a retention period beyond that policy.
Disconnect an agent
Open Connected agents, find the connection and select Disconnect, then confirm. This revokes that grant. Its access and refresh tokens stop authorizing new requests; other grants remain independent.
Your products and saved references stay in Nabit. Disconnecting does not delete product data, cancel previously submitted work or automatically refund a reservation. Inspect the existing request and Credit settlement rules for work already started.
Keep OAuth tokens in your MCP client's credential storage. Never paste them into prompts, URLs, tickets or public logs. API-key authentication is not available in this release.
HTTP API authorization
The implemented public /v1 routes reuse the existing adapter authorization. Send Authorization: Bearer <access token> in the HTTP header with the existing OAuth workspace grant and nabit:recommendations scope. Browser session cookies alone do not authorize these routes. Missing, expired or revoked tokens are rejected. Older product-only OAuth and legacy connection tokens do not satisfy the workspace consent required by these operations; reconnect through OAuth.
No API-key issuing, storage, scopes or per-key limits are implemented in milestone 3; those remain for milestone 4. All requests still pass the same account/workspace membership, role, product isolation, plan and rate-limit checks. Recommendation spending goes through the shared Credit service. Callers cannot select identity or upstream endpoints in request parameters. A public route name does not mean anonymous access.
/v1 uses the existing operational MCP log with the corresponding capability name, status, error code and selected metadata. It does not create a separate billing ledger. Disconnecting the OAuth grant also prevents subsequent /v1 requests with its tokens. Implementing these routes locally does not publish them to production.