Kanawai AIKanawai AI: The Central AI Intelligence Brain for the Enterprise
Request Demo
Request Demo

Vendor Integrations & Client Connectivity

Kanawai AI connects securely to enterprise tools and cloud platforms using industry-standard authentication protocols. This document details the connectivity approach, security controls, and best practices for each supported integration.

Last updated: June 9, 2026

Integration Architecture Overview

Kanawai AI follows a zero-trust integration architecture where every connection is authenticated, encrypted, and scoped to the minimum permissions required. All vendor connections flow through a centralized integration layer that provides unified logging, rate limiting, and credential management.

Least Privilege

Every integration requests only the minimum API scopes and permissions required for its specific function. Permissions are audited quarterly and pruned when no longer needed.

Credential Lifecycle

All credentials — API keys, OAuth tokens, certificates — are stored in enterprise secrets managers with automated rotation, expiration enforcement, and audit logging.

Centralized Gateway

All vendor API traffic routes through a centralized integration gateway that enforces authentication, rate limiting, request validation, and comprehensive audit logging.

Vendor Integration Directory

Each vendor integration below details the specific connection method, authentication protocol, data scope, and security controls implemented by Kanawai AI. All integrations use the most secure authentication method available from each vendor.

Anthropic Claude

Cloud API / API Key with AI Gateway

API Key

Data scope: AI inference requests, prompt/response data (ephemeral)

API keys stored in enterprise secrets manager (e.g., GCP Secret Manager, HashiCorp Vault)
Routed through centralized AI Gateway for unified access control and audit logging
Separate API keys per environment (dev/staging/prod) with automated rotation every 30–90 days
Rate limits and spend caps configured per-key to prevent credential abuse

AWS

IAM Cross-Account Roles / STS AssumeRole

IAM Roles

Data scope: Cloud resources, infrastructure metadata, security configurations

Cross-account access via STS AssumeRole with temporary credentials (no long-lived access keys)
ExternalId required in trust policies to prevent confused deputy attacks
Trust policies scoped to specific IAM role ARNs — never wildcard root account access
All AssumeRole calls audited via AWS CloudTrail with centralized log aggregation

Microsoft Azure

Entra ID App Registration / Service Principal

OAuth 2.0

Data scope: Azure resources, Entra ID directory data, security configurations

Certificate-based authentication preferred over client secrets for service principals
Credentials stored in Azure Key Vault with Managed Identity access
Application permissions scoped to specific resources — no tenant-wide admin roles
Unique app registrations per environment with automated credential rotation

Cloudflare

Scoped API Tokens / Access Service Tokens

API Key

Data scope: DNS records, WAF configurations, Workers, analytics

Scoped API tokens restricted to specific zones, accounts, and permission sets — never global API keys
Access Service Tokens for machine-to-machine communication with zero-trust enforcement
JWT validation at the edge for API gateway authentication
New scannable token format (cfut_/cfat_) enables automated secret scanning and leak detection

Microsoft Copilot

Microsoft Graph API / OAuth 2.0

OAuth 2.0

Data scope: Copilot interactions, productivity data, AI usage analytics

OAuth 2.0 Client Credentials flow with certificate-based authentication
Application permissions scoped to least-privilege Graph API endpoints
Delegated permissions used only when user context is required
Token caching with automatic refresh — no persistent credential storage

Discord

Bot Token / OAuth 2.0 with PKCE

Bot Token

Data scope: Channel messages, user presence, server metadata

Bot tokens stored in secrets manager — never hardcoded in source
OAuth 2.0 with PKCE for user-delegated authorization flows
Webhook signature verification using Ed25519 public key validation
Short-lived access tokens (15–30 min) with refresh token rotation

DocuSign

OAuth 2.0 JWT Grant / Authorization Code Grant

OAuth 2.0

Data scope: Envelope metadata, signing events, document status

JWT Grant for automated server-to-server integrations (no user presence required)
RSA key pair authentication with private key stored in secure vault
Authorization Code Grant with PKCE for user-interactive flows
DocuSign Connect webhooks for event-driven architecture (no API polling)

Dropbox

OAuth 2.0 Authorization Code with PKCE

OAuth 2.0

Data scope: File metadata, folder structure, sharing permissions

PKCE-enforced authorization code flow — implicit grant disabled
Short-lived access tokens with offline refresh token for long-term connectivity
Refresh tokens treated as high-sensitivity credentials and stored in encrypted vault
Scoped permissions — no full-access requests; limited to required folder/file operations

Google Gemini (Vertex AI)

GCP Service Account / Workload Identity Federation

Service Account

Data scope: AI inference requests, model responses (ephemeral)

Workload Identity Federation eliminates service account key files — uses OIDC/SAML federation
Service account permissions restricted to specific Vertex AI endpoints and models
All API traffic remains within GCP private network when possible
GCP Organization Policies prevent unauthorized service account key creation

Google Workspace

OAuth 2.0 / Domain-Wide Delegation

OAuth 2.0

Data scope: Email metadata, calendar events, Drive files, Admin directory

Domain-Wide Delegation with granular OAuth scope restriction — only minimum required scopes
Service account keys stored in GCP Secret Manager with automated rotation
All DWD actions audited via Google Workspace Audit Logs exported to SIEM
GCP Organization Policies restrict who can create or upload service account keys

HubSpot

OAuth 2.0 (v3) / Private App Token

OAuth 2.0

Data scope: CRM contacts, deals, marketing events, engagement data

OAuth v3 endpoints for multi-account integrations with enhanced security features
Private App tokens for single-account use with mandatory 180-day rotation
Webhook signature validation (X-HubSpot-Signature-v3) with HMAC SHA-256
Scopes audited regularly — legacy API keys deprecated and not used

LinkedIn

OAuth 2.0 Authorization Code with PKCE

OAuth 2.0

Data scope: Company pages, ad campaigns, member profile data (authorized)

3-legged OAuth 2.0 with PKCE for phishing-resistant authorization flows
Client secrets stored server-side — never exposed in client-side code
Minimal scope requests (r_ads, w_member_social) per principle of least privilege
Unique state parameter for CSRF prevention; all calls over HTTPS with bearer tokens

Microsoft 365 (Graph API)

Microsoft Graph API / OAuth 2.0 Client Credentials

OAuth 2.0

Data scope: Email, calendar, Teams, OneDrive, user directory

Certificate-based client credentials flow — client secrets avoided where possible
Application permissions scoped to specific Graph API resources (e.g., Mail.Read, not Mail.ReadWrite.All)
Conditional Access policies enforced for service principal sign-ins
Sign-in logs monitored via Microsoft Entra for anomaly detection

OpenAI Codex

API Key with AI Gateway

API Key

Data scope: Code generation requests, model responses (ephemeral)

API keys centrally managed via enterprise secrets manager with automated rotation
All requests routed through AI Gateway for unified logging, rate limiting, and access control
Separate keys per environment with spend limits configured in OpenAI dashboard
Pre-commit hooks scan for accidentally committed API keys in source repositories

Salesforce

OAuth 2.0 JWT Bearer / External Client App

OAuth 2.0

Data scope: CRM data, opportunities, accounts, custom objects

JWT Bearer flow with RSA key pair — no client secrets transmitted; private key stored in KMS/HSM
External Client Apps preferred over legacy Connected Apps for API-first security model
Dedicated Integration User with minimum required permission sets — never admin accounts
IP allowlisting enforced to restrict API access to known Kanawai AI infrastructure IPs

Slack

OAuth 2.0 / Bot Token (xoxb-)

OAuth 2.0

Data scope: Channel messages, user profiles, workspace metadata

Bot token scopes (xoxb-) preferred over user token scopes for isolated, app-level access
Granular OAuth scopes — only minimum permissions requested and justified per feature
Slack App Approval workflow integration for enterprise workspace governance
Audit Logs API integration for SIEM monitoring of all app activity

Client Tenant Connectivity

Kanawai AI provides flexible, secure connectivity options for connecting to client-managed infrastructure, identity providers, and cloud tenants. Customers are responsible for provisioning and maintaining their API credentials through the Kanawai AI self-service portal.

Customer-Provided Authentication

Kanawai AI assumes that the client will provide authorized, authenticated credentials through one or more of the following mechanisms:

  • API credentials and secure tokens — OAuth 2.0 client credentials, API keys, or service account keys provisioned by the customer with scoped permissions.
  • Webhooks — customer-configured webhook endpoints with shared secret or HMAC signature verification for event-driven data exchange.
  • Identity Platform-as-a-Service — integration with enterprise identity platforms including Okta, MuleSoft, Apigee, and Google Cloud Application Integration for federated authentication and API management.

Self-Service Onboarding Portal

  • Customers can onboard new integrations, configure credentials, and manage API keys through the Kanawai AI self-service portal — no support tickets or manual provisioning required.
  • The portal provides guided setup workflows for each integration, including scope selection, credential validation, and connectivity testing.
  • All credential changes are logged with full audit trails, including who made the change, when, and from which IP address.

Customer Responsibility

The customer is solely responsible for maintaining and administrating API keys, secrets, certificates, and other authentication mechanisms used to connect Kanawai AI to their infrastructure. This includes:

  • Provisioning credentials with least-privilege permissions
  • Rotating credentials according to their organization's security policies
  • Revoking credentials immediately when they are no longer needed or may be compromised
  • Ensuring that all credentials are created within authorized, auditable systems