Skip to main content1. Description
Bud AI Foundry’s User Management and Role-Based Access Control (RBAC) system is designed for enterprises rolling out GenAI across multiple teams, projects, and applications.
As GenAI moves from POCs into production, access control becomes a governance and risk problem, not just a technical one:
- Who can deploy or change models?
- Who can see sensitive data or logs?
- How do we stop “experiment” endpoints from becoming shadow production?
- How do we give Sales/HR/Support safe AI tools without exposing infra?
Bud AI Foundry addresses these challenges with:
- A multi-level RBAC hierarchy (Super Admin → Admins → Teams → End users),
- Project and task-level access control for teams like HR, Sales, DevOps, etc.,
- API-level governance and quotas for internal and public endpoints,
- A developer dashboard for internal devs and app teams,
- And centralized IAM with SSO and enterprise security (MFA, audit logging, directory integration, standards-based protocols).
The result: fast GenAI adoption across the organization, with the level of control your security, risk, and compliance teams expect.
2. USPs (Unique Selling Propositions)
1. Enterprise-grade multi-level RBAC
Model your real org hierarchy: Super Admins, specialized Admins (Infra, Models, Evaluations, Routes), project teams (HR, Sales, DevOps), and non-technical consumers - all with clearly scoped access.
2. Project and task-level granularity
Control access not just at the platform level, but per project (team) and task (infra/model/evaluation/route/etc.), ensuring isolation between teams and workloads.
3. API-level security and governance
Classify APIs as internal or public, manage API keys, rate limits, quotas, and costs per client, team, or app - so embedded GenAI features remain secure and auditable.
4. Unified experience for all personas
- Platform & Security teams: centralized policy, IAM, SSO, auditing.
- Developers: OpenAI-style dev dashboard with safe self-serve APIs
- Business users: curated chat-based experiences and playgrounds.
5. Centralized IAM, security, and analytics
Supports SSO, user federation with LDAP / Active Directory, and identity brokering with third-party IdPs, using OpenID Connect, OAuth 2.0, and SAML 2.0.
MFA, strong password policies, brute-force detection, signed JWTs, and detailed audit logs support regulatory frameworks such as GDPR and HIPAA, as well as internal governance requirements.
Fine-grained analytics per client/department/project: tokens consumed, costs incurred, quotas, and plans - so you can implement chargeback/showback models for GenAI usage.
3. Features
3.1 Multi-level RBAC Hierarchy
3.1.1 Super Admin
- Highest-privilege role with organization-wide control.
- Configures:
- Identity and SSO settings,
- Global policies and guardrails,
- Creation and assignment of specialized Admin roles,
- Default roles and access templates.
3.1.2 Admin-level roles
Controlled by Super Admin, Admins can be specialized per module or capability, for example:
- Infra Admin - clusters, runtimes, scaling policies.
- Model Admin - onboarding models, model catalogs, versioning.
- Evaluation Admin - benchmarks, evaluation suites, quality checks.
- Routes/Orchestration Admin - flows, routing, and agents.
- User & Project Admin - manages users, roles, and project assignments.
Admins can be scoped at:
- Module level (e.g., only infra, only models),
- Task level (e.g., view-only vs manage permissions),
- Project (Team) level (e.g., only HR project, only Sales project).
This supports separation of duties and alignment with internal operating models.
3.2 Project Teams & Task-level Access
- Create Projects (Teams) like:
- HR
- Sales
- DevOps
- Customer Support
- Product / Ops
- Assign users to projects and define:
- Which models, agents, and routes they can see/use,
- Which evaluations or datasets are visible,
- Whether they can view, configure, or manage resources.
Within a project, you can define task-level permissions, for example:
- Sales leads: can view usage dashboards and reports.
- Sales reps: can only use chat assistants.
- A technical owner: can configure prompts, routes, and model selections.
3.3 End User Types & Dashboards
3.3.1 Admin users
- Manage operational aspects like:
- Cluster & infrastructure management,
- Model onboarding & lifecycle,
- User and project management,
- Evaluation and benchmark configuration,
- API and route configuration.
- Permissions can be view-only or manage per module.
3.3.2 Client / Consumer users
Ideal for:
- External customers consuming your GenAI models/agents, or
- Internal departments/projects consuming GenAI services.
For Client users, the platform provides:
- A dedicated dashboard to:
- Access assigned models and agents,
- Track usage (tokens, requests),
- Monitor cost, quotas, and billing cycle.
- For non-technical users, access via:
- Chat-based interfaces, or
- The Bud Playground with curated assistants.
Bud AI Foundry exposes detailed analytics per client:
- Tokens consumed,
- Total cost incurred,
- Billing plan details,
- Token and cost quotas (configurable),
- Billing cycles.
3.4 Developer / End-user Dev Dashboard
- OpenAI-like developer dashboard for internal devs and application teams.
- Key capabilities:
- Discover approved models, routes, and agents.
- Create and manage APIs on top of these models.
- Configure prompts, parameters, evaluation hooks, and routing logic.
- Monitor performance, usage, and latency.
This enables self-service for developers, within a governed environment defined by Super Admins and Admins.
3.5 API-level Access & Governance
For every deployed model, route, or agent:
- Define who can generate API keys.
- Specify which teams, services, or apps can call the API.
- Set rate limits, quotas, and cost ceilings per API key or client.
- Classify APIs as:
- Internal APIs - restricted to internal services/teams.
- Public APIs - available to broader app developers or external customers (if configured).
All API usage is attributed to:
- A team/project,
- A client, and
- A user or API key,
enabling full auditability and chargeback.
Refer to the [Observability guide] for deeper analytics and diagnostics coverage across users/projects etc.
3.6 Centralized IAM & SSO
Bud AI Foundry integrates with a centralized IAM layer and supports Single Sign-On:
- Users authenticate once via your corporate IdP.
- Based on role mappings and attributes, they get access to:
- Admin console (if applicable),
- Developer dashboard,
- Client dashboards,
- Chat and playground experiences.
Key IAM capabilities:
- Central user lifecycle management (provisioning/deprovisioning).
- Centralized policy application and review.
- Reduced operational overhead and fewer fragmented accounts.
3.7 Security & Compliance Features
- Multi-Factor Authentication (MFA).
- Strong password policies and configurable lockout thresholds.
- Brute-force attack detection and throttling.
- JWT-based secure token management for sessions and API access.
- Fine-grained access control down to resource and action level.
- Comprehensive audit logging for:
- Logins and authentication events,
- Model and deployment changes,
- API key creations/rotations,
- Permission changes and role assignments.
These capabilities support compliance and audit requirements such as GDPR, HIPAA, and internal security policies.
3.8 Standards Compliance & IDP Integrations
- Supports OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0.
- Integrates with:
- Enterprise directories like LDAP and Microsoft Active Directory via user federation,
- Third-party identity providers (Okta, Azure AD, Google Workspace, etc.) via identity brokering.
This ensures Bud AI Foundry fits seamlessly into your existing identity landscape.
4. How-to Guides
4.1 Accessing the User Management Module
- Log in to your Bud AI Foundry dashboard using SSO or your credentials.
- Click on your profile/avatar in the top-right corner.
- Select “User Management” from the menu.
- If you are an Admin or Super Admin, you’ll see user lists, roles, and access settings.
4.2 Adding a New Admin User with Scoped Access
- Go to User Management, click “Add User”.
- Enter the user’s name and email address.
- Under Role, select the appropriate base role (e.g., Admin, Developer, DevOps).
- Under User Type, choose Admin.
- Configure module-level permissions:
- For each module (e.g., Models, Infrastructure, Evaluations, Routes, User Management):
- Select View for read-only access, or
- Select Manage for full operational control.
- Optionally, scope the user to specific Projects (Teams):
- Assign them to HR, Sales, DevOps, or other relevant projects.
- Within each project, specify which components they can see/manage.
- Click “Save”.
- The user will receive an invitation email. Once accepted, they can sign in and operate within the permissions you defined.
4.3 Adding a Client / Consumer User and Configuring Quotas
- In User Management, click “Add User.”
- Enter the name and email.
- Assign an appropriate Role (e.g., Client, Business User), if configured.
- Set User Type = Client.
- Select which projects or services this client can access:
- Specific models, routes, or agents,
- Specific chat assistants or playground spaces.
- Go to the Client Settings / Analytics section for that user:
- Define token quotas (e.g., monthly token limit).
- Set cost limits and billing plans.
- Configure billing cycle (e.g., monthly).
- Click “Save.”
- The client can now:
- Log into their client dashboard,
- View usage and costs,
- Access their assigned assistants via chat or playground.
4.4 Creating and Managing Project-level Teams
- Navigate to Projects / Teams in the admin console.
- Click “Create Project / Team”.
- Name the project, e.g., “HR Assistants”, “Sales Copilot”, or “DevOps Automations”.
- Assign Project Owners (Admins or technical leads).
- Attach:
- Relevant models and agents,
- Specific datasets, evaluations, or routes.
- Add users to the project and define their project roles:
- For example:
- HR Lead - View analytics + manage assistants,
- HR Partners - Use chat assistants only,
- Data Scientist - manage prompts and evaluations.
- Save the configuration.
- Project-level isolation is now enforced: users only see what their project access allows.
4.5 Managing API Access: Internal vs Public
- Go to the APIs / Routes section in the dashboard.
- Select a deployed model, route, or agent.
- Under Access Type, choose:
- Internal - restricts usage to internal services and teams.
- Public - exposes the API to broader developer audiences (internal or external) as configured.
- Configure API keys:
- Generate keys for specific teams, apps, or clients.
- Label them clearly (e.g., sales-copilot-prod, hr-portal-staging).
- Set rate limits and quotas per key:
- Max requests/second,
- Monthly token limits,
- Optional cost caps.
- Save changes.
- Distribute API keys through your secure internal process (never hard-code into public repos).
4.6 Integrating Bud AI Foundry with Your Identity Provider
Note: Exact steps vary by IdP (Okta, Azure AD, etc.), but the flow is broadly similar.
- In Bud AI Foundry, go to Identity & Access / SSO Settings.
- Choose the protocol your IdP supports:
- OIDC, OAuth 2.0, or SAML 2.0.
- In your IdP:
- Create a new application/integration for Bud AI Foundry.
- Configure redirect URIs and logout URLs as provided by Bud.
- Set up user attributes and group claims (e.g., email, name, role, department).
- Copy the IdP configuration back into Bud AI Foundry:
- Client ID, Client Secret (if applicable), Issuer URL, Certificates/Metadata.
- Map IdP groups/attributes to Bud AI Foundry roles and projects:
- e.g., group:platform-admins → Super Admin / Admin,
- group:sales → Sales project user.
- Enable the integration and test:
- Perform a test login with a pilot user.
- Confirm that the expected role and project assignments are applied.
- Roll out to wider user groups once validated.
4.7 Modifying Permissions or Offboarding Users
- Go to User Management.
- Search for the user by name or email.
- Open their profile.
- To modify access:
- Adjust role, user type, module-level permissions, or project assignments.
- Click Save.
- To offboard:
- Remove sensitive roles and project access.
- Optionally disable the user or remove them from your IdP group.
- Revoke associated API keys if applicable.
- Confirm that their access is removed by viewing their current roles and projects.
5. FAQ
A. Bud AI Foundry goes beyond simple “admin/user” roles. It supports a multi-level hierarchy (Super Admin → Admins → Teams → End users), with module, task, project, and API-level controls, plus IAM/SSO and enterprise integrations. It’s built for full-scale enterprise GenAI rollouts, not just single-team experimentation.
A. Yes. You can create Projects (Teams) like HR, Sales, DevOps, Customer Support, etc., and assign users, roles, models, and agents to each. Access is isolated at the project level, with additional task-level granularity inside each project.
A. Non-technical users are typically assigned Client / Consumer roles and interact through:
- Chat-based assistants integrated into their tools, or
- The Bud Playground, where they can safely use curated AI experiences without dealing with prompts, models, or infra.
A. Roles come with predefined access profiles that align with common responsibilities, and you can further restrict permissions to specific modules, projects, and tasks. View/manage distinctions, project scoping, and API-level controls all support a least-privilege model.
Q5. Can I see who changed what and when?
A. Yes. Bud AI Foundry maintains comprehensive audit logs covering:
- Authentication events,
- Model and deployment changes,
- API key operations,
- Permission, role, and project changes.
These logs support internal audits and external compliance reviews.
Q6. How does Bud AI Foundry integrate with our existing SSO and directory?
A. The platform supports:
- OIDC, OAuth 2.0, and SAML 2.0 for SSO,
- User federation with LDAP and Microsoft Active Directory,
- Identity brokering for third-party IdPs like Okta, Azure AD, and Google Workspace.
Users sign in with their existing corporate identities and receive roles based on group/attribute mappings.
Q7. Can we limit API usage for specific clients or apps?
A. Yes. You can:
- Issue API keys per client/application,
- Set rate limits, token quotas, and cost caps,
- Classify APIs as internal or public,
- Attribute usage and cost to specific keys, teams, or clients for chargeback.
Q8. How does the system support compliance frameworks like GDPR or HIPAA?
A. Key features that support compliance include:
- MFA, strong password policies, and brute-force detection,
- Role-based least-privilege access,
- Centralized IAM and SSO with secure token handling (JWT),
- Detailed audit logs for access and configuration changes,
- Ability to separate projects and control which data each project can access.
These capabilities help you implement and demonstrate appropriate controls to auditors and regulators.
Q9. What happens if we want to change a user’s role or move them between teams?
A. You can update a user’s role, user type, and project assignments directly from User Management. Changes take effect immediately, and their access is updated without needing new accounts or separate logins.
Q10. Can external customers get their own dashboards?
A. Yes. External customers can be configured as Client users with:
- Their own dashboards,
- Usage visibility (tokens, costs),
- Quotas, plans, and billing cycles,
- Access only to the models/agents you expose to them.
This enables you to offer GenAI as a managed capability to your customers while maintaining full control and observability.