Designing team and role structures for an AI platform

How you structure teams and roles in ManyLayers determines who can use which models, what they can spend, which connectors they have access to, and what visibility they have into usage data. Getting this structure right at the start is much easier than reorganizing after teams have built workflows around a misconfigured setup.

This guide covers the ManyLayers access control model, common organizational patterns, and the configuration steps to implement them.

Understanding the ManyLayers access control model

ManyLayers organizes access control across three layers:

Platform layer — workspace-wide settings, provider credentials, gateway configuration, billing, and audit logs. Platform administrators have full access. Most users should not be platform administrators.

Team layer — a team groups users and applies shared policies: model allowlists, budget caps, rate limits, and connector access. Every user belongs to at least one team. A user can belong to multiple teams and inherits the union of their policies.

Key layer — API keys belong to a team (not a user) and inherit the team’s policies. Keys can have additional restrictions layered on top: a lower rate limit than the team’s cap, a subset of the team’s allowed models, or an expiry date.

Step 1: Map your organizational structure to teams

Start by listing your AI-using groups before touching the platform. Answer:

1. Which groups have different compliance requirements? (Legal, finance, HR may need data residency or stricter PII policies.)
2. Which groups have meaningfully different cost envelopes? (A research team that experiments may need a different budget than a production support team.)
3. Which groups should see each other’s usage data? (Teams can typically see their own usage; only platform admins should see cross-team aggregate data.)
4. Which groups use different models or connectors? (Data science may need access to self-hosted experimental models that customer support should not see.)

Common team structures in enterprise deployments:

Functional model — one team per business function: Engineering, Product, Sales, HR, Legal. Budget and model access is set at the function level. Works well for organizations where AI usage is distributed across many functions with distinct needs.

Platform + product teams model — a central AI platform team that has elevated access and manages shared infrastructure, plus product teams that are consumers. The platform team handles provider credentials and gateway configuration; product teams operate within the policies the platform team sets.

Data classification model — teams are defined by data sensitivity tier rather than org chart. All teams handling sensitive data belong to a “restricted” team configuration; others belong to “standard.” This model works when compliance drives team structure more than organizational hierarchy.

Step 2: Define roles for each team

Navigate to Platform Settings → Teams → [Team] → Roles. ManyLayers ships with four built-in roles:

Role	Scope
Platform Admin	Full platform access including billing, audit logs, provider credentials
Team Admin	Manage team membership, view team usage, manage team keys
Member	Use AI features within team policies; view own usage
Viewer	Read-only access to team workspaces and knowledge bases

For most deployments, the built-in roles are sufficient. If your organization needs custom role definitions (for example, a “Budget Reviewer” role that can see cost data but not conversation content), contact support to enable custom role configuration.

Assign roles conservatively. Platform Admin should be held by no more than 2–3 people. Team Admin is appropriate for the team lead or the person responsible for managing the team’s AI usage.

Step 3: Configure model allowlists and denied lists

Navigate to Platform Settings → Teams → [Team] → Models.

Set an allowlist of models the team can use:

{
  "allowed_models": [
    "openai/gpt-4o-mini",
    "anthropic/claude-haiku-3-5",
    "anthropic/claude-sonnet-4-5"
  ],
  "denied_models": [
    "openai/o3",
    "anthropic/claude-opus-4-5"
  ]
}

Think about allowlists from a cost-management and compliance perspective:

• Most teams don’t need the most expensive models for their standard use cases.
• Teams handling sensitive data should be restricted to models whose provider agreements cover that data classification.
• Self-hosted model access can be restricted to teams that have a compliance requirement for it.

Step 4: Set budget policies

Navigate to Platform Settings → Teams → [Team] → Budget.

Configure four fields for each team:

• monthly_budget_usd: the nominal spend ceiling for the calendar month.
• alert_threshold: the fraction of the budget that triggers a notification (recommend 0.75).
• hard_cap: whether to block requests once the budget is exhausted. Set true for experimental teams; set false for production-critical teams where availability matters more than strict cost control.
• rollover: whether unused budget carries to the next month. Useful for teams with seasonal patterns.

Run the gateway without hard caps for 4–6 weeks before enabling enforcement. Use the analytics data to set initial caps at 150% of observed baseline spend. After two billing cycles, tighten to 120%.

Step 5: Create and scope API keys

Navigate to Platform Settings → Teams → [Team] → Keys → New Key.

Each key inherits the team’s policies by default. Add restrictions:

• Rate limit override: a key used by a background batch job should have a lower rate limit than the team’s cap so it can’t starve interactive usage.
• Model subset: a key for a specific application can be further restricted to only the models that application uses.
• Expiry date: short-lived keys for external contractors or time-limited integrations.

Name keys descriptively: marketing-content-tool, support-chatbot-prod, data-pipeline-nightly. Avoid generic names like key1 or test — when you’re debugging a production incident, you need to know immediately which application generated which request.

Step 6: Set up SSO and SCIM provisioning

For teams of more than 20 people, manual user management doesn’t scale. ManyLayers supports SAML 2.0 SSO and SCIM 2.0 for automated provisioning.

Navigate to Platform Settings → Authentication → SSO to configure your identity provider. Once SSO is active, users authenticate through your IdP — no separate ManyLayers credentials to manage.

Navigate to Platform Settings → Authentication → SCIM to configure automated provisioning. SCIM maps your directory groups to ManyLayers teams automatically: when a user joins the “Engineering” group in your directory, they’re added to the Engineering team in ManyLayers. When they leave the group, they’re removed.

SCIM provisioning is the highest-leverage administrative setup you can do. Manual team membership management is error-prone; SCIM makes offboarding immediate and complete.

Checklist

• Org structure mapped to teams before touching the platform
• Team definitions reviewed against compliance requirements
• Platform Admin role held by 2–3 people maximum
• Model allowlists configured per team
• Budget policies set with alert thresholds
• API keys named descriptively and scoped to specific applications
• Expiry dates set on contractor and temporary keys
• SSO configured if team size exceeds 20
• SCIM provisioning configured and tested with a pilot group

Common mistakes to avoid

Using shared API keys across teams. This collapses the audit trail and makes cost attribution impossible. Every team needs its own keys.

Granting Platform Admin broadly. Platform Admin has access to all provider credentials and the full audit log. Limit it tightly.

Setting hard caps before you know baseline spend. A hard cap set too low blocks legitimate production traffic. Establish baselines first.

Skipping SCIM. Organizations that don’t automate provisioning end up with stale team membership — departed employees still active, new hires waiting weeks for access.