Gumloop Enterprise (Select Plan): how do we enable SSO/SCIM, RBAC, audit logs, and retention rules?

“Can we lock Gumloop down behind Okta, enforce RBAC, and actually see what our agents are doing in production?”

Yes—and on the Enterprise (Select) plan, you get the full governance stack: SSO/SCIM, role-based access control, audit logs, and custom data retention rules. This guide walks through what’s included and how to enable each control, so your agents can run across Slack, Jira, Salesforce, and your data warehouse without becoming a security blind spot.

Quick Answer: On the Gumloop Enterprise (Select) plan, you enable SSO/SCIM, RBAC, audit logs, and retention rules from the Admin Dashboard. Your team connects your IdP (e.g., Okta) for SSO and SCIM, configures roles and permissions, turns on organization-wide audit logging, and sets custom data retention policies that match your compliance requirements.

Why This Matters

Once Gumloop is powering Support Agents, CRM Agents, and Data Analysis Agents across your stack, you’ve effectively introduced a new layer of production infrastructure. That layer needs the same controls as everything else in your environment: centralized identity (SSO/SCIM), least-privilege access (RBAC), traceability (audit logs), and data lifecycle governance (retention rules and Zero Data Retention).

Without these, automation stalls at “cool demo” status. With them, you can roll out agents to non-technical teams at scale and still answer questions like “who ran what, when, and against which systems?” with confidence.

Key Benefits:

• Centralized identity & access: Use SSO and SCIM with your existing IdP (e.g., Okta) so admins don’t manage yet another user directory.
• Production-grade governance: RBAC, audit logs, and usage analytics give you granular control and visibility across agents, workflows, and tools.
• Compliance-ready data handling: Custom data retention rules and Zero Data Retention (ZDR) agreements keep AI usage aligned with SOC 2 Type II, GDPR, and your internal policies.

Core Concepts & Key Points

Concept	Definition	Why it's important
SSO & SCIM	Single Sign-On and automated user provisioning via your identity provider (e.g., Okta)	Centralizes auth, reduces manual user management, and ensures joiner/mover/leaver flows apply to Gumloop automatically
RBAC	Role-Based Access Control for agents, workflows, and admin capabilities	Enforces least-privilege access, separates builder vs. consumer permissions, and prevents misconfigurations at scale
Audit Logs & Retention Rules	Tamper-resistant logs of admin/user actions plus configurable data retention periods	Delivers traceability for security/compliance and ensures data isn’t kept longer than policy allows

How It Works (Step-by-Step)

At a high level, enabling SSO/SCIM, RBAC, audit logs, and retention rules on Gumloop Enterprise (Select) looks like this:

1. Your IT / security admin connects your IdP to Gumloop and turns on SSO.
2. SCIM is configured so users and groups are provisioned/deprovisioned automatically.
3. An org admin assigns roles and permissions to teams, builders, and viewers.
4. Audit logs and data retention rules are configured in the Admin Dashboard.
5. Gumstack (optional) can be deployed in Gumloop’s cloud or your VPC to extend observability across MCP servers and tool calls.

Below is the step-by-step breakdown.

1. Enable SSO with your IdP

SSO is what keeps Gumloop aligned with your existing authentication policies.

What you need:

• Enterprise (Select) plan
• Admin access in Gumloop
• Admin access to your IdP (e.g., Okta)

Steps (high-level flow):

1. Open the Admin Dashboard

   • Log into Gumloop with an admin account.
   • Navigate to Admin → Security (or SSO & Identity in some org configurations).

2. Create a new SSO integration

   • Select your IdP (e.g., Okta).
   • Gumloop will supply SAML/OIDC metadata, including:
     • Assertion Consumer Service (ACS) URL
     • Entity ID / Audience URI
     • (Optional) Logout URL and NameID format

3. Configure the app in your IdP

   • In Okta (example):
     • Add a SAML 2.0 application.
     • Paste the ACS URL and Entity ID from Gumloop.
     • Map attributes like email, firstName, lastName to Gumloop’s fields.
   • Set the app to Assigned groups only to control who gets access.

4. Test SSO

   • From Gumloop’s SSO setup, hit Test Connection.
   • Confirm you can sign in via your IdP and land in your Gumloop tenant.

5. Enforce SSO (optional but recommended)

   • Once tested, flip the toggle to Require SSO for your organization.
   • Local password logins are disabled for non-admin users, aligning Gumloop with your IdP policies (MFA, conditional access, etc.).

Gumloop supports “SSO and SCIM with your IdP” and “Single Sign-On” with providers like Okta. This is designed to plug directly into your existing identity system of record.

2. Enable SCIM for automated provisioning

SCIM keeps your Gumloop user base in sync with reality: when someone leaves the company or changes teams, their access changes automatically.

Steps (high-level flow):

1. Enable SCIM in Gumloop

   • In the Admin Dashboard → Security or Identity, locate SCIM/SAML Support.
   • Generate a SCIM endpoint URL and Bearer token.

2. Configure SCIM in your IdP

   • In Okta (example):
     • Go to your Gumloop SSO app.
     • Turn on Provisioning → “To App.”
     • Add the SCIM endpoint URL and token from Gumloop.
   • Map fields:
     • userName → Email
     • name.givenName / name.familyName
     • Group assignments → Gumloop roles or teams (depending on your mapping strategy).

3. Test provisioning

   • Assign a test user/group to the Gumloop app in your IdP.
   • Confirm:
     • The user appears in Gumloop.
     • Removing them or unassigning the app in your IdP deprovisions access in Gumloop.

4. Roll out to production groups

   • Map your real org groups (e.g., “Support,” “Sales Ops,” “Data”) to the appropriate access inside Gumloop.
   • This is where you’ll align SCIM group assignment with Gumloop RBAC (next section).

3. Configure Role-Based Access Control (RBAC)

Once SSO/SCIM are wired up, RBAC is how you enforce least privilege across agents, workflows, and data.

What RBAC covers on Enterprise (Select):

• Role Based Access Control at the org level
• Admin Dashboard capabilities
• Team-level access to agents and Workflows
• Coordination with SCIM groups to auto-assign roles

Typical role design (example):

• Org Admins: Security/IT; manage SSO/SCIM, retention, Gumstack, audit logs.
• Builders: Ops/RevOps/Support Engineering; create and modify agents and Workflows.
• Consumers: Support reps, AEs, managers; run agents (via Slack, Web, etc.) but can’t edit underlying logic.

Steps (high-level flow):

1. Open Roles in Admin Dashboard

   • Admin → Roles & Access (naming may vary by release).
   • Review default org roles and any existing custom roles.

2. Define or adjust roles

   • For each role, configure:
     • Agent permissions: create/edit/delete vs. run-only.
     • Workflow permissions: build/modify vs. execute.
     • Integration access: which tools this role can connect/use (Slack, Jira, Salesforce, warehouses, etc.).
     • Admin capabilities: who can change SSO, SCIM, retention, or Gumstack settings.

3. Map SCIM groups to roles

   • In Gumloop, link specific roles to specific SCIM groups (e.g., okta_group_Support_Builders → “Support Builder” role).
   • This ensures new joiners automatically get the correct permissions based on their IdP groups.

4. Test least privilege

   • Log in as a “Consumer” role and verify:
     • They can run Support Agents in Slack or web UI.
     • They cannot edit Workflows, change data sources, or modify security settings.

This is where you make sure that “understanding a task should be the only prerequisite to automating it” applies to builders—but you still keep control over who can wire up privileged systems and credentials.

4. Turn on and use Audit Logs

Audit logs are your record of what’s actually happening: who created a Support Agent, who changed a Workflow that touches Snowflake, who updated retention rules, and when.

On Enterprise (Select), you get:

• Audit Logs via the Admin Dashboard
• Team Usage & Analytics (plus a Usage Analytics Agent if configured)
• Gumstack (optional) for deeper tool-call visibility and MCP-level tracing

Steps (high-level flow):

1. Access Audit Logs

   • Admin → Audit Logs.
   • You’ll see a time-ordered list of events such as:
     • User logins (via SSO)
     • Agent/Workflow creations and edits
     • Integration connections/changes
     • Security setting changes (SSO, SCIM, retention rules)
     • Scheduled task creations/edits

2. Filter and search

   • Filter by:
     • User
     • Action type (e.g., “Workflow Updated,” “Retention Policy Changed”)
     • Resource (specific agent/workflow)
     • Time window
   • Export logs (if enabled) for SIEM ingestion or security reviews.

3. Integrate with Gumstack (optional)

   • If you’re using Gumstack:
     • Track every MCP client and server.
     • Trace every tool call through a single logging and analytics layer.
     • Run Gumstack on Gumloop’s infrastructure or inside your own VPC.
   • This is where you get deep observability: every tool call your agents make across Jira, Zendesk, Salesforce, Snowflake, and more is traceable.

Audit logs are what let your security team say, “Yes, we can see who did what,” when Gumloop is touching core systems.

5. Set Custom Data Retention Rules

Data retention is often the gating factor for AI adoption in regulated environments. Gumloop gives you granular control on Enterprise (Select), plus a Zero Data Retention stance at the platform level.

From the docs and trust posture:

• Custom Data Retention Rules at the org level
• Zero Data Retention: Gumloop never uses customer data to train AI models
• Zero Data Retention (ZDR) agreements and DPAs with third-party models
• SOC 2 Type II Certified and GDPR compliant

Steps (high-level flow):

1. Open Data Retention settings

   • Admin → Data Retention or Security & Compliance (label may vary).
   • You’ll see default retention windows for:
     • Workflow run logs
     • Agent run logs
     • Input/output content
     • Integration metadata

2. Configure your retention policy

   • Set retention windows by category (example):
     • Agent/Workflow logs: 90 days
     • Content payloads: 30 days
     • System metadata: 365 days
   • Align these with your internal policies and any regulatory requirements.

3. Apply and document

   • Save settings and document them as part of your internal AI governance runbook.
   • If required, confirm ZDR and DPAs with your legal/security team (Gumloop provides this via its Zero Data Retention and GDPR-compliant commitments).

4. Coordinate with Gumstack (if used)

   • If you run Gumstack in your VPC, ensure its retention settings align with your Gumloop policy.
   • This gives you end-to-end control over how long tool-call logs and analytics are kept.

6. Choose where Gumstack runs (cloud or your VPC)

For some teams, governance requirements go beyond application-level controls—you also need to decide where the observability and MCP infrastructure runs.

With Gumstack you can:

• Run in Gumloop’s secure infrastructure, or
• Run inside your own VPC

This matters when:

• You want all AI-related logging to stay within your network boundary.
• You’re consolidating security logging behind your own controls.
• You need to satisfy strict data residency or infrastructure policies.

Configuration is handled in partnership with Gumloop’s team, typically during Enterprise onboarding.

Common Mistakes to Avoid

• Leaving SSO optional after testing:
  If you don’t enforce SSO, users may still create local passwords and bypass your IdP policies. After validation, enable “Require SSO” org-wide.

• Treating SCIM as “nice-to-have”:
  Manual user provisioning inevitably falls behind. Connect SCIM so joiner/mover/leaver flows in your IdP automatically apply to Gumloop roles and team access.

• Not aligning RBAC with tooling sensitivity:
  Don’t give every builder access to every integration. Segment agents and Workflows touching high-risk systems (e.g., production data warehouses, finance systems) under dedicated roles and SCIM groups.

• Ignoring audit logs until an incident:
  Turn on and monitor audit logs early. Use them during normal operations so they’re familiar when you actually need them.

• Setting “infinite” retention by default:
  Over-long retention might feel convenient but increases risk and compliance friction. Start from your policy (e.g., 90 days for detailed logs) and only extend where justified.

Real-World Example

Here’s what this looks like in a company that actually uses Gumloop to run support and sales automation in production:

“We want Support Agents and CRM Agents running across Slack, Zendesk, and Salesforce—but security wants SSO with Okta, full RBAC, audit logs, and strict data retention before we roll beyond the pilot.”

How they set it up:

1. SSO & SCIM with Okta

   • Security creates a Gumloop app in Okta with SAML SSO and SCIM enabled.
   • Groups like Gumloop_Admins, Gumloop_Builders, and Gumloop_Consumers are defined in Okta.
   • SSO is enforced so everyone signs into Gumloop with Okta SSO (MFA, conditional access, etc.).

2. RBAC wired to groups

   • Admins map Gumloop_Admins → Org Admin; Gumloop_Builders → Builder; Gumloop_Consumers → Consumer.
   • Support builders can create Workflows that call Zendesk and Jira; consumers can only trigger those agents from Slack.

3. Audit logs and Gumstack

   • Audit logs are enabled; security integrates exports into their SIEM.
   • Gumstack runs in the company’s VPC, tracing every MCP tool call from agents to Zendesk, Jira, and Salesforce.

4. Retention rules for logs & payloads

   • Detailed run logs are retained for 90 days.
   • Message payloads from Slack and email are retained for 30 days.
   • System metadata is retained for 1 year for compliance and analytics.

Once this is in place, Support can freely tag @Gumloop in Slack to triage issues and create tickets in Zendesk and Jira; Sales can rely on CRM Agents to keep Salesforce clean. Security, meanwhile, can answer: who ran these automations, what they did, and how long the data sticks around.

Pro Tip: Before onboarding your first team beyond a pilot, sit down with security and explicitly map: which SCIM groups map to which Gumloop roles, which integrations each role can touch, and what retention windows you’ll set for logs and payloads. You’ll avoid rework and unblock future agent use cases much faster.

Summary

On the Gumloop Enterprise (Select) plan, enabling SSO/SCIM, RBAC, audit logs, and data retention rules turns Gumloop from an interesting “AI experiment” into a governed piece of production infrastructure.

• SSO/SCIM plug Gumloop directly into your IdP so identity is centralized and automated.
• RBAC ensures only the right builders and admins can wire agents into sensitive systems.
• Audit logs and Gumstack give you end-to-end traceability across agents, Workflows, and tool calls.
• Custom data retention rules and Zero Data Retention commitments align AI usage with SOC 2 Type II, GDPR, and your internal policies.

Once these are configured, you can confidently roll out Support Agents, CRM Agents, Data Analysis Agents, and more—knowing the work is not just automated, but also secure, observable, and compliant.

Next Step

Get Started