Security
Security, authentication and authorization details from source.
Security
BondingAI AIOS is designed with security, compliance, and governance at its core. To safely scale GAI adoption across an enterprise, the platform applies zero-trust principles, automates enforcement, and embeds governance into every layer—from data to AI models to user interactions.
Security is implemented through infrastructure as code, policy-as-code, and data access automation, ensuring consistent controls across multi-cloud environments, AI agents, and business domains.
Core Security Principles for BondingAI AIOS
| Principle | Description |
| Authoritative Identity Source | Enforce a single source of identity (e.g., enterprise IAM/SSO) across all AI components to reduce misconfigurations and access gaps |
| Automated Security & Auditing | Automate access provisioning, logging, guardrails, and model usage auditing to enforce compliance and reduce human error |
| Least Privilege by Default | Grant only the access required for each user, agent, or domain to operate—minimizing exposure across AI actions and data services |
| Role-Based & Simplified Permissions | Leverage built-in roles, policies, and domain scopes—avoid custom per-user configs to reduce complexity and increase governance clarity |
| Clear Boundaries & Enforceable Rules | Organize agents, data, and models by function and domain to enforce separation, simplify lineage, and manage risk effectively |
Identity and Access Architecture Decision
For the enterprise authentication and authorization model decision (including WorkOS data boundaries and compliance posture), see Identity and Access Architecture (WorkOS).
Network
Authentication and Authorization
BondingAI AIOS uses a hybrid authentication model to ensure that only verified users, services, and applications interact with its AI components. This model is based on the OAuth 2.0 framework, enterprise identity providers like Microsoft Entra ID, and token-based authentication. This approach enables centralized governance, robust access control, and flexible integration.
Architecture Diagram
The diagram represents the authentication and authorization flow within the BondingAI ecosystem, from external identity providers to internal services.
-
External Identity Providers (Authentication Providers): At the top, entities like Microsoft Entra ID, Google, and Okta act as external identity sources. They are responsible for authenticating users and services, providing the initial credentials to the system.
-
IAM Service: The central section, shaded in green, represents BondingAI's Identity and Access Management (IAM) service.
-
Keycloak: Functions as an authentication and authorization intermediary, receiving requests from external providers. It interacts with the Keycloak Database to manage sessions and configurations.
-
Authentication and Authorization: The Authentication and Authorization modules validate user credentials and permissions, respectively. They consult the IAM Database for profile information and access policies.
-
API: This component, labeled as API (Component: custom FastAPI), is the entry point for internal communication, managing the data flow between the authentication and authorization modules and the API Gateway.
-
Request Flow:
-
API Gateway: This central component acts as a unified entry point for all requests, routing them to the appropriate services.
-
BondingAI Platform:
-
Frontend and Backend: The platform is divided into the BondingAI Platform Frontend (access request) and BondingAI Platform Backend (resource service), which communicate through the API Gateway.
-
BondingAI AIOS: The diagram shows additional BondingAI AIOS Frontend and Backend components that interact with the API Gateway, representing the core AI services.
-
Connections and Flows: The arrows indicate data flow and communication:
-
"Authentication & Authorization" → API Gateway: Successful authentication and authorization allow requests to pass to the Gateway.
-
"Access Platform" and "Request Resource" → API Gateway: Front-end applications and back-end services request access or resources through the Gateway.
Key Authentication Principles
| Principle | Description |
| OAuth 2.0-Centric Architecture | BondingAI uses OAuth 2.0 as its primary framework to issue and validate access tokens for users, agents, and services. This supports secure delegation, consent-based access, and scoped permissions. |
| Single Source of Identity | Microsoft Entra ID (or equivalent) is used as the authoritative identity provider, managing SSO, MFA, and Conditional Access policies. All authentication flows integrate with the enterprise directory. |
| Token-Based Authentication | BondingAI services use OAuth 2.0 tokens (access/refresh) and JWTs for authentication between front-end apps, AI agents, APIs, and backend services. |
| Role-Based Access Control (RBAC) | Authentication is linked to RBAC and ABAC (attribute-based) policies. Permissions are scoped by domain, role, and resource type (e.g., sales data, finance agent). |
| Managed Identities for Services | When hosted on Azure, BondingAI services authenticate using Managed Identities, eliminating secret management for inter-service communication. |
| Service Principals for Applications | External applications and connectors authenticate to BondingAI via registered service principals and scoped OAuth credentials. |
| Secret Management | Access keys and client secrets are securely stored and rotated using enterprise vault solutions (e.g., Azure Key Vault or HashiCorp Vault). |
Authentication Scenarios in BondingAI AIOS
| Scenario | Authentication Method | Use Case |
| User to AIOS Portal | OAuth 2.0 + Microsoft Entra ID (SSO, MFA) | A business user logs into BondingAI to use a Sales Agent or create a custom workflow |
| Agent to Service | OAuth 2.0 token exchange | An AI agent requests data from the CRM connector or submits a query to the xLLM pipeline |
| Service to Service | Managed Identity / OAuth client credentials | Internal services (e.g., observability, orchestrator, memory store) communicate securely |
| External App to AIOS API | OAuth 2.0 + Service Principal | A third-party application (e.g., a customer portal) sends requests to BondingAI via a secured API |
Authentication
Authentication is a core pillar of BondingAI AIOS, ensuring that only verified users, services, and applications can interact with enterprise AI components. To support secure, scalable, and auditable access across diverse enterprise environments, BondingAI leverages a hybrid authentication model based on:
- OAuth 2.0 Authorization Framework
- Enterprise Identity Providers (e.g., Microsoft Entra ID / Azure AD)
- Token-based service and application authentication
This approach enables centralized identity governance, robust access control, and flexible integration across business systems, agents, and cloud services.
Key Authentication Principles
| Principle | Description |
| OAuth 2.0-Centric Architecture | BondingAI uses OAuth 2.0 as its primary framework to issue and validate access tokens for users, agents, and services. This supports secure delegation, consent-based access, and scoped permissions. |
| Single Source of Identity | Microsoft Entra ID (or equivalent) is used as the authoritative identity provider, managing SSO, MFA, and Conditional Access policies. All authentication flows integrate with the enterprise directory. |
| Token-Based Authentication | BondingAI services use OAuth 2.0 tokens (access/refresh) and JWTs for authentication between front-end apps, AI agents, APIs, and backend services. |
| Role-Based Access Control (RBAC) | Authentication is linked to RBAC and ABAC (attribute-based) policies. Permissions are scoped by domain, role, and resource type (e.g., sales data, finance agent). |
| Managed Identities for Services | When hosted on Azure, BondingAI services authenticate using Managed Identities, eliminating secret management for inter-service communication. |
| Service Principals for Applications | External applications and connectors authenticate to BondingAI via registered service principals and scoped OAuth credentials. |
| Secret Management | Access keys and client secrets are securely stored and rotated using enterprise vault solutions (e.g., Azure Key Vault or HashiCorp Vault). |
Authentication Scenarios in BondingAI AIOS
| Scenario | Authentication Method | Use Case |
| User to AIOS Portal | OAuth 2.0 + Microsoft Entra ID (SSO, MFA) | A business user logs into BondingAI to use a Sales Agent or create a custom workflow |
| Agent to Service | OAuth 2.0 token exchange | An AI agent requests data from the CRM connector or submits a query to the xLLM pipeline |
| Service to Service | Managed Identity / OAuth client credentials | Internal services (e.g., observability, orchestrator, memory store) communicate securely |
| External App to AIOS API | OAuth 2.0 + Service Principal | A third-party application (e.g., a customer portal) sends requests to BondingAI via a secured API |