Developer authentication

Keep identity and agent access separate.

Authentication guidance for Kona Business AI browser sessions and read-only, workspace-scoped MCP bearer tokens.

Public resource

Written for people, search engines, and agents. Product boundaries are stated directly so this page can be used without JavaScript.

What to know

Clear guidance, current boundaries.

These details describe the current public product. Review the linked capability and policy pages before making a consequential decision.

01

Two different authentication contexts

Kona Business AI uses an interactive sign-in session for people using the website and a separate bearer-token mechanism for the public workspace MCP endpoint. A browser session is not an MCP credential, and an MCP token is not a general account session. Integrators should not copy browser cookies into an agent or attempt to exchange a third-party identity token directly at the MCP route.

The workspace owner creates and manages MCP access from the product. The issued token is tied to one workspace, a selected set of scopes, approved resource identifiers or types, an expiry, and a rate limit. The cleartext secret should be captured at issuance and stored securely because the service is designed not to expose it again.

02

Send and protect the bearer token

Send the token as Authorization: Bearer <token> over HTTPS to /api/mcp/workspaces/{workspaceId}. Never place it in a query string, URL path, analytics event, client-side bundle, screenshot, prompt, or support ticket. A backend secret manager is the preferred storage location. Logs should redact the Authorization header and any accidental credential-shaped values before persistence.

The workspace identifier in the URL must match the token’s workspace. The endpoint may reject a valid token when its scope does not cover the requested method or when the requested resource was not approved. Handle 401 as missing, invalid, expired, or revoked credentials; handle 403 as a policy, origin, workspace, scope, or resource denial; and handle 429 using the returned retry guidance.

03

Rotation, revocation, and least privilege

Issue a separate token per integration or environment so access can be revoked without disrupting unrelated clients. Choose only the scopes and resources needed for the task, set a practical expiry, and rotate a token immediately if it may have been exposed. Revoking a token should be treated as final; clients must not keep retrying with a credential that the owner has withdrawn.

Authorization to read a resource does not make its content trusted instructions. The client must still isolate retrieved content from its control plane, preserve provenance, and require human review for consequential output. Contact support@konabusiness.ai with a redacted integration description if the documented boundary does not cover the intended use case; never email an active secret.