When teams first start building with AI, the excitement is real—and so are the governance questions. Who can publish an agent? How are versions tracked? Can we enforce SSO everywhere? Where do the logs live, and how fast can security get them?

Below is a comprehensive guide to StackAI’s governance model, designed for teams that need speed without losing control.

The StackAI Governance Model (8 Layers)

1) Role-Based Access Control (RBAC) and Groups

StackAI offers four default roles: Admin, Editor, Viewer, User (end users of published interfaces only).

Admins can create groups (e.g., “Legal,” “HR,” “Capture Team”) and assign them to workspaces/projects for coarse-grained control. Directory groups can be synced so your existing RBAC maps into StackAI groups.

2) Workspace and Folder Access (Scope Control)

Easily create private group folders with specific allowlists. Only assigned users or groups can see what’s inside—others see nothing.

Easily view project owners and editors as well, by hovering over a project or in a list view. 

3) Project Controls (Edit, Lock, Versioning)

Creators can lock a project (only the owner edits; admins can override).

All changes made to projects can be tracked with version control and diffs, so you can see exactly who changed what and when, and roll back. You can easily see all previously published versions of a project; and versions can be tagged with a commit message to clarify what changes were made. Easily go back to a previous version if desired.

4) Interface-Level Security (How You Publish)

When you export an agent (advanced form, chatbot, Slackbot, etc.), you can:

• Enable one-click SSO on the interface editor
  
  

• Set a password for external collaborators.
  
  

• Restrict by allowed origins/URLs and even a user allowlist.

5) Global Governance and Admin Policy (Feature Access and Guardrails)

Org admins can set cross-cutting policy:

• Require SSO on all interfaces.
  
  

• Restrict who can publish, so that non-admins don't publish projects.

• Enable an approval/feature-flag workflow for changes, wherein users request for their project to be reviewed and published by admin.

• Allow/deny specific tools, connectors, and more through Feature Access (e.g., block Notion/Box across the org).

• Set usage limits (e.g., token caps) as a security throttle.

You can also build policy by group (e.g., “only Legal can access the Legal agents”).

6) Connection and Knowledge-Base Permissions

Connections (SharePoint, Dropbox, ServiceNow, etc.) are owned by their creator, with private details and credentials encrypted and hidden from others. Owners and admins can share a connection org-wide or limit it to specific users or groups.

Knowledge bases support the same allowlisting, so only authorized teams can reference sensitive content.

For SharePoint, connections respect the identity used:

• If you connect with your user ID, you’ll only see what you can access.
  
  

• If you connect via a service account, access is limited to that account’s scope.
  
  

• For end-user enforcement, enable “check end-user access” on the connection so users must authenticate to their own SharePoint before the workflow can read anything.

7) Production Analytics and Auditing

Downloadable project analytics show who ran what, when, with which models, token counts, latency, and per-step traces (inputs, KB hits, outputs). Builders can mask or disable logs when required, or limit visibility to the owner. For certain cases of external security tooling, StackAI can deliver scheduled exports and can post to a customer webhook (e.g., daily digests) for alerting pipelines.

8) Authentication and MFA

Organizations can use email/password (when enabled) or SSO (recommended). Enabling SSO means protecting any or all interfaces from access by members outside of your organization; further, SSO allows you to capture the email addresses of all users of your interfaces to easily keep track of who is using your workflows. You can also require SSO for all interfaces. By default, SSO users land as users until granted higher roles.

MFA is supported via common authenticators (Duo, Microsoft Authenticator, etc.).

SDLC in StackAI: From Dev to Prod, Without the Drift

StackAI’s recommended path:

1. Define roles and groups first. Map departments to groups; keep admin counts low.
   
   

2. Mirror environments by folder: Dev, Test, Prod workspaces with strict membership.
   
   

3. Lock projects during development; require feature-flag approval for publishing.
   
   

4. Name and compare versions (pull-request style). Keep the paper trail.
   
   

5. Enforce SSO on all published interfaces; apply origin allowlists where needed.
   
   

6. Restrict tools/connectors globally so builders can’t accidentally connect personal data sources.

The result? Multi-team collaboration with traceability, while production stays clean and auditable.

Why Governance Matters

• Security means visibility: Who changed what, when, and how it ran in production—down to KB hits.
  
  

• Builders move fast safely: Locking, versioning, approvals, and one-click SSO keep momentum without risk.
  
  

• Platform stays orderly: Global feature controls and tool allow/deny lists prevent accidental sprawl.
  
  

• Compliance is auditable: Clear run history, retention options, and export paths for SIEMs.

Governance shouldn’t slow you down. With StackAI, platform and security teams get eight layers of control—from SSO and RBAC to version diffs, analytics, and exportable logs—while builders keep shipping.

If your org needs enterprise governance with speed of deployment, StackAI has you covered.