Access Profiles

​

Overview

• Reusable policy - Define a profile once (for example, “Engineering”) and apply it to every user in a role.
• Per-user enforcement - Each user gets an independent copy with isolated budget and rate-limit counters.
• Layered access - A user can hold several profiles at once. What they can reach adds up, and if one profile’s budget runs out another can cover their requests.
• Role auto-assignment - Attach profiles to a role and users gaining that role are provisioned automatically.
• Safe propagation - Edit the template, then push selected fields (budgets only, MCP only, and so on) to every user copy in one call.
• Managed virtual keys - Auto-issued keys are write-protected, so a user cannot weaken their own policy by editing the key directly.
• Govern user-created keys - Optionally bring every virtual key a member creates under the profile automatically, not just the auto-issued key.
• Audit and versioning - Every change to a profile is recorded with a full snapshot history.

​

How it works

​

Template, user copy, virtual key

1. Template - The Access Profile is the policy you author. Each policy lives once in the workspace.
2. How it is granted - A user gets a profile in one of three ways: you attach it to them by hand, their role grants it, or their identity provider attributes match a mapping rule. Bifrost remembers which, so removing one grant never disturbs the others.
3. User copy - Bifrost copies the template to the user, with its own budget and rate-limit counters. Each user’s usage is tracked separately, and a user can hold several profiles at once.
4. Virtual key - Bifrost issues a virtual key to the user. The key belongs to the user rather than to one profile, so it keeps working as their profiles change, and what it may do comes from whichever profiles they currently hold. It is locked against direct edits so the policy cannot be worked around.
5. Per-model limits - Per-model budgets set on the profile appear for each assigned user as their own read-only limit. See Model Limits.

​

Multiple profiles per user

​

Role auto-assignment

• Existing users in that role - Optionally provisioned at attach time.
• Users gaining the role later - Automatically provisioned the moment their role changes.

​

Managed virtual keys

​

Govern virtual keys created by members

• Off by default, and set per profile — flipping it on one profile does not affect others.
• Applies to identified users only. The creator must sign in with their own identity (SSO/SCIM). Keys created from the local admin account or a raw API key are left as ordinary standalone keys.
• Create-time only. Turning the toggle on does not sweep up keys a member already created. To bring an existing key under the profile, assign it to the user from the key’s edit sheet — it is adopted into their profile on assignment.

​

Automatic virtual key rotation

• If client.vk_rotation_cooldown is set (Config → Security), the previous value keeps authenticating until the cooldown expires, so callers have time to pick up the new key.
• Leaving it unset, empty, or 0 disables the grace period, so the previous value stops working immediately.

• A key is never rotated twice for one scheduled run. Rotating again would push the previous value out and end the cooldown early. Retries, resumed jobs, catch-up runs after downtime, and keys rotated manually after the schedule fired are all skipped for that run.
• Manual rotation still works. The manual endpoints stay available on managed keys; a key rotated manually inside the window is simply skipped by the scheduled run.
• Cluster-safe. Every node checks the schedule, but only one job is created per profile and due time, and rotated keys are gossiped to all nodes.
• Missed runs collapse into one. If the gateway was down past a due time, the next start performs a single catch-up rotation rather than one per missed period.
• Deactivated profiles pause. A deactivated profile is never rotated; reactivating it re-anchors an overdue schedule to now + interval so it does not fire immediately.

​

Configuration (Web UI)

​

Browse and create profiles

1. Navigate to Workspace -> Governance & Access Control -> Access Profiles.

2. Use Search or the active/inactive filter to narrow the list. Page size is 25.
3. Click Create Profile. The create sheet opens.

​

Fill in the basics

• Name - Required, unique, trimmed. Max 255 characters.
• Description - Optional, shown in the list view.

​

Configure provider access

• Allowed Models - Toggle All Models to allow every model, or pick specific models from the search-filtered list. An empty selection denies every model from that provider.
• Provider Budget - Add one or more budget lines. Each line has a max limit and a reset duration (1h, 1d, 1w, 1M, 1Q, 1Y). You can stack multiple lines with different durations (for example, a hard hourly cap plus a softer monthly cap). A quarterly line can also carry a fiscal quarter start - see Quarterly budgets.
• Maximum Tokens - Per-provider token rate limit.
• Maximum Requests - Per-provider request rate limit.
• Per-model budgets - Optionally cap individual models under this provider. These are separate from the provider budget above; each assigned user gets their own copy, counted separately. See Give one user a per-model budget.

​

Configure global budget and rate limits

​

Toggle calendar alignment

​

Toggle member-key governance

​

Schedule automatic key rotation

​

Configure MCP tool access

• Virtual MCPs - Multi-select existing Virtual MCPs to grant. Selected vMCPs appear as removable badges.
• MCP Servers - Multi-select MCP servers. Granting a server means “all tools from this server”.
• Individual Tool Overrides - Add specific tools with either include or exclude action. Use this for surgical adjustments that the group + server selection does not express.

​

Save and assign

• Set as default for new users - Auto-assign the profile when users gain this role.
• Apply to existing users with this role - Provision the profile to everyone who already holds the role.

​

Propagate changes

• Check the fields to propagate: Provider Configurations, Budgets, Rate Limit, Virtual MCPs, MCP Servers, MCP Tool Overrides. - Click Propagate to apply. The response reports how many users were updated, failed, or skipped.

​

Extend individual budgets for a user

Effective limit = Base budget + Override amount

# Add or replace an override
curl -X PUT "$BIFROST_URL/api/users/$USER_ID/access-profiles/$PROFILE_ID/budgets/$BUDGET_ID/override" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"amount": 100, "mode": "cycles", "cycles": 2}'

# Remove it
curl -X DELETE "$BIFROST_URL/api/users/$USER_ID/access-profiles/$PROFILE_ID/budgets/$BUDGET_ID/override" \
  -H "Authorization: Bearer $TOKEN"

​

Edit, duplicate, delete

• Edit - Opens the same form in edit mode.
• Duplicate - Opens the form pre-populated with the original; budgets and rate limits get fresh identifiers on save.
• Delete - Asks to confirm. Blocked if any users still hold a copy; detach role attachments or remove user assignments first.

​

What you can configure

• Provider access - For each LLM provider: an allow-all toggle or an explicit model allowlist, plus optional per-provider budgets and rate limits.
• Global budgets - Workspace-wide spend caps with reset durations of 1h, 1d, 1w, 1M, or 1Y. Multiple budget lines can stack so you can combine a hard short-window cap with a softer long-window cap.
• Global rate limits - Token and request caps with the same reset durations.
• Calendar alignment - When on, budgets and rate limits reset at the start of each calendar period (midnight UTC, week start, month start) instead of rolling from creation time. Applies to durations of one day or longer.
• Govern created keys - When on, every virtual key a member creates is adopted into the profile (same policy, attached to the user, profile-managed). Off by default. See Govern virtual keys created by members.
• MCP tool access - Reference Virtual MCPs, and give each MCP client a tool allowlist: every tool, none, or a named set.
• Automatic key rotation - An interval (1h to 365d, typically 30d) and optional first-run time. When due, a background job rotates every managed key, honouring client.vk_rotation_cooldown, and posts start/finish notifications. Off by default. See Automatic virtual key rotation.
• Tags - Up to 50 free-form tags for filtering and grouping in the UI.
• Active flag - Activate or deactivate without deleting; deactivated profiles are hidden from selection but user copies stay intact.

​

Examples

​

Auto-assign Engineering profile to the Engineer role

1. Create the profile through the UI or API with the desired provider configs, budgets, and MCP access.
2. From the Engineer role, attach the profile. Toggle “Apply to existing users” to backfill current members.
3. Bifrost issues a virtual key for every member of the Engineer role and continues to auto-issue for any user who later gains the role.

​

Force every key an Engineer creates onto the Engineering policy

1. Edit the Engineering profile and turn on Govern virtual keys created by members. Save.
2. From now on, whenever an Engineer (signed in via SSO) creates a virtual key, it is placed under the Engineering profile automatically - same providers, model whitelist, budgets, rate limits, and MCP access - attached to them and locked from direct edits.
3. To bring keys they created earlier under the policy too, open each key and assign it to the user; it is adopted into their profile on assignment.

​

Rotate every Engineering key monthly

1. Under Config → Security, set Cooldown After Virtual Key Rotation to something like 1h so callers have time to switch keys.
2. Edit the Engineering profile, set Automatic key rotation to Every 30 days, and optionally pick a First rotation such as the next maintenance window. Save.
3. When the run starts, a notification lists how many keys are rotating and until when the old values keep working; a second notification confirms how many rotated. The profile’s Next Rotation moves 30 days past the run.

{
	"access_profiles": [
		{
			"name": "Engineering",
			"auto_rotation_interval": "30d",
			"provider_configs": [{ "provider_name": "openai", "allow_all_models": true }]
		}
	]
}

​

Raise the monthly budget without resetting accumulated usage

1. Edit the template and set the new monthly budget.
2. Open the propagate dialog. Check only Budgets.
3. Click Propagate. The new budget is pushed to every assigned user; each user’s current month-to-date usage is preserved (default behavior).

​

Tighten MCP access only

1. Edit the template and replace the Virtual MCP reference.
2. Open the propagate dialog. Check Virtual MCPs, MCP Servers, and MCP Tool Overrides. Leave budgets and rate limits unchecked.
3. Click Propagate. Budgets and rate limits are not touched; only MCP access changes flow through.

​

Give one user an individual per-model budget

1. Navigate to Budget & Limits → Model Limits and click Add Model Limit.
2. Select a Provider and Model Name, set Scope to User, and pick the target user.
3. Add one or more budget lines and any rate limits. Click Create Limit.

curl -X POST "http://localhost:8080/api/governance/model-configs" \
  -H "Content-Type: application/json" \
  -d '{
    "model_name": "claude-opus-4-8",
    "provider": "anthropic",
    "scope": "user",
    "scope_id": "<user-id>",
    "budgets": [
      { "max_limit": 20.00, "reset_duration": "1M" }
    ]
  }'

​

Next steps

• Projects - Scope access and spend to a piece of work rather than to a person, chosen per request.
• Data Access Control - Scope which profiles each operator can see.
• RBAC - Define the roles that profiles auto-attach to.
• Virtual Keys - Understand the underlying virtual key concept.
• Virtual MCPs - Bundle MCP tools for reuse inside profiles.
• Model Limits - How a profile’s per-model budgets surface as per-user limits.
• Audit Logs - Cross-reference profile changes with downstream impact.