Admin controls: a census of 145 listings

A designated Admin User provisions users and holds organisation-level configuration, and CRM access is constrained by granular read and write permissions the customer sets.

Source retrieved 2026-09-23

Constraints on agent behaviour are set when the Toolkit is deployed and roles are allocated by hand across web, mobile and desktop clients; no administrative policy console or enforced rule set is documented.

Source retrieved 2026-09-27

Admins assign four role levels and decide which tools are active, and Ada advises scoping credentials and gating write tools behind Playbooks.

Source retrieved 2026-10-06

Constraining the agent is the firm's central selling point: scoped identity, data and tool access with approval gates on consequential actions, designed into every build.

Source retrieved 2026-10-04

A mandatory sandbox wraps every tool with allow lists, deny lists and per-tool validators, and the policy is snapshotted so later callers cannot widen it.

Source retrieved 2026-10-04

JWT scopes gate every endpoint per agent and per tool, with roles assigned in the control plane and guardrails at runtime.

Source retrieved 2026-09-02

Constraint is the product: the Agent Governance Engine executes only the procedures your team writes and approves, presents only configured options, and each intent is set to none, human-in-the-loop or fully agentic.

Source retrieved 2026-09-23

Admins alone control stored credentials in Vault, which constrains which integrations can act, but no documented policy screen limits which actions an agent may call.

Source retrieved 2026-10-03

Behaviour can be constrained per machine or per repo, disabling shell-command suggestions, auto-commits or git entirely, plus .aiderignore and a checked-in YAML config, but there is no org-level console enforcing policy across users.

Source retrieved 2026-09-09

Role-based access control with Write, Read, Restricted and None privilege levels per feature lets an admin decide who may touch intents, fulfilments, integrations and data sources, and guardrails bound agent behaviour.

Source retrieved 2026-09-24

Roles are granular and constrain what the agent and its users may do: admins set account-wide sending limits, recently-contacted thresholds, unsubscribe enforcement and LinkedIn sending windows, and can build custom roles scoping every object by ownership.

Source retrieved 2026-09-10

Central administrative control arrives with the Google Cloud path; on individual plans the allow/deny/ask rules live in a user-editable settings file, and the vendor says admin URL allowlists are not yet honored.

Source retrieved 2026-09-10

Spend can be constrained per subscription by choosing a HARD-limit plan that blocks calls at quota, but no role-based admin policy over what a key or agent may call is published.

Source retrieved 2026-10-03

An owner constrains the agent directly: workspace-scoped keys, per-tool allowlists, masked previews by default and Member versus Manager roles, with per-user feature grants for the assistant and verifier.

Source retrieved 2026-09-26

Access control is designed into the systems Arsum builds, applying the user's own access rules before data reaches a result or the model, but no Arsum admin console is offered.

Source retrieved 2026-10-03

Three built-in roles plus custom roles under Access controls, with members walled out of team, billing and Ava configuration, layered on top of per-campaign approval, banned-phrase and DNC constraints.

Source retrieved 2026-09-10

Access is governed by fixed policies made of path-scoped roles attached to seven predefined user groups, so an admin can hold a user or API client to read-only or billing-only rights.

Source retrieved 2026-09-24

A repo-committed settings file denies tools or specific shell commands on every cloud agent; Enterprise adds granular access controls and enforced budgets.

Source retrieved 2026-09-02

Constraints are developer-level: the runtime enforces identity and privacy boundaries, code executes in a Docker sandbox, and an approval callback can gate each execution. There is no admin console or policy engine.

Source retrieved 2026-09-02

The agent is constrained by facts an admin approves - which services, prices, rules and answers it may use - plus per-source permission levels that decide who may edit those settings at all.

Source retrieved 2026-09-11

Role-based access control and tenant isolation are described for the chatbot workspaces they deliver, but nothing states that an administrator can constrain what a delivered agent is allowed to do.

Source retrieved 2026-09-11

Admins constrain agent behaviour with time-based and continuous rails plus role-based access, but only Enterprise gets custom rails.

Source retrieved 2026-09-11

Admins can force a deploy provider, lock site visibility, block GitHub, Stripe or Supabase and bar personal workspaces, but only from the Teams plan upward.

Source retrieved 2026-09-11

The Policy Agent gates every interaction against business rules, and inputs can be sandboxed with topics blocked outright; role-based access control, per-agent access control and trusted-domain restriction need Team or higher.

Source retrieved 2026-09-02

An operator gets tenant isolation between client workspaces and usage-based billing controls to cap spend, but no policy engine constraining which actions or tools an agent may use is documented.

Source retrieved 2026-09-13

Admin roles and project access govern the dashboard only; what a session may do is set per session in code, not by policy.

Source retrieved 2026-09-02

Roles are Admin and Member only: an admin controls the org, invitations and members, not what an agent is permitted to do at runtime.

Source retrieved 2026-09-02

The embedding app sets allow/deny rules, a permission mode and PreToolUse hooks; organization-managed settings can override a subagent's bypassPermissions.

Source retrieved 2026-09-02

Managed and server-managed settings pin permission rules, model allowlists, telemetry and login method, and local settings cannot override them.

Source retrieved 2026-09-02

Admins push remote configuration that constrains the agent itself: which providers and models are allowed, whether YOLO mode runs, and which MCP servers may be installed or added.

Source retrieved 2026-09-12

Admins choose what happens past the review limit, set spending caps and seat modes, and scope which repositories and connections CodeRabbit may touch; custom RBAC is Enterprise.

Source retrieved 2026-09-15

requirements.toml pins approval policy, sandbox modes, permission profiles, allowed MCP servers and web-search mode; available on every plan including API-key use.

Source retrieved 2026-09-02

API tokens carry per-scope permissions and agents obey configured handoff rules, but no admin console policy controls over what agents may do are documented.

Source retrieved 2026-09-05

Admins constrain both people and agent: role-based permissions govern who sees what, and the Safe Action Framework decides which actions the AI may take unattended.

Source retrieved 2026-09-12

Admins constrain agents at build time through escalation policies, compliance boundaries and a pre-built or custom guardrail library, with supervisory models enforcing policy in parallel and role-based access control for platform users.

Source retrieved 2026-09-13

Admins get feature-level roles plus entity permissions over individual automations, env vars, LLM connections and repos, but the pricing table lists RBAC as Enterprise-only.

Source retrieved 2026-09-13

Teams admins enforce Privacy Mode, team rules and sandbox mode; repository blocklists, model/MCP access controls and auto-run, browser and network controls are Enterprise-only.

Source retrieved 2026-09-02

Admins constrain the agent two ways: role-based platform permissions, and AOP guardrails that gate refunds, escalations and brand voice.

Source retrieved 2026-09-14

Role-based control exists over the account, not over the agent: owner, admin and member roles plus scoped API keys govern who may read usage, create keys or change billing. What the agent itself may say or call is bounded by your prompt and function definitions, with no admin-side policy engine documented.

Source retrieved 2026-09-02

Admins bind network, MCP, git and GitHub-token restrictions to an org, an automation or a single session; enterprises can enforce them as a floor.

Source retrieved 2026-09-02

Admins cap terminal auto-execution, set command allow/deny lists, restrict models by model or provider, gate MCP, deploys and the local agent, and push MDM policies to machines.

Source retrieved 2026-09-03

Four built-in roles on Cloud gate who can build versus only use published apps; Enterprise adds workflow-level RBAC and SCIM.

Source retrieved 2026-09-02

Admins cap which models and reasoning efforts members may select at workspace, group or member level, set personal and programmatic spend limits, and restrict tools to named skills.

Source retrieved 2026-10-01

Guardrails constrain what an agent may say and per-tool approval constrains what it may do, but Guardrails is in Alpha and enabling MCP servers is not restricted to admins.

Source retrieved 2026-09-02

Admin powers cover membership, seats, usage visibility and what happens to a departing member's work; nothing published lets an admin constrain what the agent may do or which sources it may reach.

Source retrieved 2026-09-14

An admin can constrain machine access precisely through per-key scopes, revocation and OAuth consent, but no policy controls over what human members may do are documented.

Source retrieved 2026-10-03

Org-managed settings cap autonomy and restrict models, MCP servers, commands and network; listed from Business upward, with full controls on Enterprise.

Source retrieved 2026-09-02

An administrator constrains the agent directly — restricting which fields Fin may read, renaming internal values, controlling integration permissions through OAuth, and masking card numbers automatically.

Source retrieved 2026-09-18

Admin and Member roles separate billing and team control from use, and admins set per-key credit limits; stricter endpoint and IP locks are Enterprise.

Source retrieved 2026-09-24

Admins gate what the agent may touch org-wide and per member - connectors disabled, read-only or full access, public chat sharing, Google Drive import, personal API keys and which model providers are used.

Source retrieved 2026-09-14

Admins gate access with IAM roles, set the project release channel and manage GitHub review config across repositories, but the agent's own tool allow/deny lists live in each developer's settings.json.

Source retrieved 2026-09-02

Team admins can only govern connectors and roles org-wide, while restricting which agents and models a member may use is an Enterprise capability negotiated in the Order Form.

Source retrieved 2026-09-15

Organisation and enterprise owners gate features, models, third-party agents, MCP servers and paid usage; enterprise settings override organisation ones. Individual plans have no admin layer.

Source retrieved 2026-09-02

Admins gate model access, agent sharing scope and monthly spend by department, user or agent, and can disable premium models entirely.

Source retrieved 2026-09-02

Constraints exist but they are code, not a console: a plugin registered once on the runner applies its checks globally to every agent, tool and model call, and a developer must write it.

Source retrieved 2026-09-15

An administrator can pin an allowlist URL through GOOSE_ALLOWLIST so only approved MCP servers install, and can force approval modes and per-tool permissions through the config file.

Source retrieved 2026-09-16

Whoever runs the deployment constrains the agent through config and environment variables, but there is no admin console, role separation or policy enforced above the operator.

Source retrieved 2026-09-16

Pro limits connector guardrails to a single agent's scope; org-wide policies, role-based access and model access control are Enterprise-only rows in the same table.

Source retrieved 2026-09-30

An account owner constrains each agent individually, choosing which integrations it may use and which knowledge and custom-API tools it can call. No admin role, user management, or organisation-wide policy layer is documented.

Source retrieved 2026-09-10

Organisation policy that local devices cannot weaken is a Team-tier feature; free and Solo users govern only their own machine.

Source retrieved 2026-09-29

Admins control whether AI answers reach customers at all and scope them with trigger conditions, and role-based access is described for the private deployment; no general policy-engine documentation was found.

Source retrieved 2026-09-24

Constraints are real but local and per-user: a strategy fixes which tools exist and what is auto-approved in a turn, and each MCP server takes an allowlist or denylist, yet there is no organisation-level console enforcing policy across users.

Source retrieved 2026-09-17

Admins get three fixed roles, can force team two-factor authentication and can restrict which tables and columns the agent may see through filtered schemas, but the pricing table reserves roles and permissions for team tiers.

Source retrieved 2026-09-17

A developer can constrain the agent locally through the allowlist file on any tier, but organisation-wide policy such as company MCP rules is an enterprise capability.

Source retrieved 2026-09-18

Admins constrain behaviour through roles and permissions, system instructions, transfer rules and the data scope shared with ChatGPT, but the vendor documents no policy engine, approval workflow or spend control.

Source retrieved 2026-09-26

Teams gets data-privacy controls on models and providers; allowlists, RBAC and policy enforcement are Enterprise.

Source retrieved 2026-09-02

Admins cap model spend and request rates through the gateway on every plan and set monthly compute ceilings on Engine; fine-grained role and tag policies need Enterprise.

Source retrieved 2026-09-18

An admin can cap external users at viewer, editor or admin from a JWT claim and block their API keys, but the docs state this deny-only ceiling is explicitly not full role-based access control.

Source retrieved 2026-09-25

Workspace RBAC and tag-based ABAC are Enterprise-only; other plans default every user to Admin. Gateway cost controls, rate limiting and PII redaction are checked on all three plans.

Source retrieved 2026-09-02

Real constraints exist on what the agent may do — spend estimates, a confirmation threshold, a per-call lead ceiling, daily caps and sending windows — but they are account-owner settings, with no admin console or roles published.

Source retrieved 2026-09-18

Identity and access management lets an administrator decide who may use the platform and what they may do there; constraints on the agent's own behaviour are set through conversation flows and transfer rules, not a documented policy engine.

Source retrieved 2026-09-09

Org roles gate who reaches an agent; what the agent may run is set per machine or project, not centrally by an admin.

Source retrieved 2026-09-02

Admins toggle meeting recording, email drafting and triaging workspace-wide, set per-member credit limits, choose which channels and folders Lindy may draw on, and decide which integrations write without asking.

Source retrieved 2026-09-19

Three dashboard roles only, and the role-based access row on the plan matrix is No for Build and Ship, Yes from Scale. Agent capability is bounded in code, not by console policy.

Source retrieved 2026-09-02

Constraints are enumerated concretely: least-privilege roles, tool allowlists, approval gates and spending limits, plus token-budget and latency caps set per agent in the runtime.

Source retrieved 2026-09-09

Team owners and super admins get an admin dashboard with access control and, once SSO is on, a security policy choosing how members may join; no published control constrains what the agent itself may do.

Source retrieved 2026-09-19

RBAC restricts read/write/execute/delete per resource in Studio and on the API, but SSO and RBAC in production are Enterprise Edition features requiring a licence.

Source retrieved 2026-09-02

Administrators constrain the agent directly: routing rules, workflow policies, identity controls and deterministic logic gate every action, and Agent Designer controls which systems the agent may act in.

Source retrieved 2026-09-25

Constraints are real but developer-set in code, not an admin console: per-tool approval, regex shell allow and deny lists, and FIDES policy middleware that blocks a sensitive tool before it runs.

Source retrieved 2026-09-19

Restricting which models and third-party services a workspace may reach, and controlling access per user, are ticked only in the Business column and crossed for Individual.

Source retrieved 2026-09-20

Administrators configure roles and per-role permissions, assign groups, and set a data scope of self only, partial or all, plus a conversation capacity per member.

Source retrieved 2026-10-03

Admins constrain agents with launch permissions, role-based access on each asset, connectors closed by default, and policy validators that gate every action.

Source retrieved 2026-09-20

Administrators can validate and apply managed defaults and policy documents and point the agent at a centrally administered hooks file, on top of per-session permission profiles.

Source retrieved 2026-09-20

RBAC at instance and project level (project roles on all Cloud plans, custom roles on Enterprise), plus instance policies to enforce 2FA and block specific nodes.

Source retrieved 2026-09-02

Systems they deliver ship with a back-office layer where an operations admin changes users, permissions, rules and exceptions without going through engineering.

Source retrieved 2026-09-26

Real per-user controls exist only for reseller accounts, which can switch dashboard menus on or off per client and cap their concurrency; ordinary team plans have no documented roles or permission settings, and agent limits are set per agent instead.

Source retrieved 2026-09-09

Constraints are real but developer-defined in code — approval rules, guardrails and tool filters, plus network policy on hosted shell containers — rather than an administrator console governing what a fleet of agents may do.

Source retrieved 2026-09-20

Admins constrain the agent per project: model allowlists or denylists, role-based permissions on /v1/realtime requests, IP allowlists and data-retention settings.

Source retrieved 2026-09-02

Tool profiles, allow and deny lists, per-agent restrictions, sandbox rules and exec allowlists constrain what the agent may call, and the policy is applied before the model sees a tool.

Source retrieved 2026-09-21

Config-level permission rules constrain tools and paths, and an enterprise central config can force one gateway and disable other providers.

Source retrieved 2026-09-21

Admins constrain the agent's reach: which secrets, tools and domains it may touch, plus enforced default LLMs and spending caps.

Source retrieved 2026-09-21

User management arrives with Enterprise Pro; role-based access control and custom roles sit in the custom-priced governance tier and the comparison table marks that row 'Contract required'.

Source retrieved 2026-09-02

Owners restrict what agents may do for whom: access groups decide which deployments a user reaches, each user gets a usage budget, and users can be banned by email or IP.

Source retrieved 2026-09-09

Constraints are agreed per process as human checkpoints and a completion rule rather than enforced through any admin console or policy setting the vendor describes.

Source retrieved 2026-10-03

Fifteen navigation areas each set to None, Read or Edit, expandable to individual items, over an Admin/Member account role.

Source retrieved 2026-09-02

Constraints are developer-level rather than an org admin console: guardrail capabilities screen prompts, tool calls and outputs, and the Shell capability supports allowlists, denylists and credential stripping.

Source retrieved 2026-09-21

Administrators constrain the agent in Agent Studio through guardrails and rules of engagement that govern which buyers it engages and how it behaves, alongside onboarding and evaluation controls.

Source retrieved 2026-09-22

Per-connection approval gates and spend/usage limits are available broadly, but role-based and fine-grained access control are gated to Enterprise on the vendor's own tier table.

Source retrieved 2026-09-22

Real constraint on what builders and Agent may do — private-only publishing, banned exports, pinned geography — is an Enterprise settings pane.

Source retrieved 2026-09-22

Admin, Developer and Member roles constrain who can edit agents, see raw transcripts or change limits, but the pricing comparison marks role-based access control as an Enterprise capability rather than a pay-as-you-go one.

Source retrieved 2026-09-23

An admin can switch individual skills off, cap the order value the agent may cancel and refund, restrict escalation to business hours, and block callers outright, all from the dashboard.

Source retrieved 2026-09-09

Org-wide defaults, permission sets and field-level access bound what users and their agents may touch, and agents inherit the acting user's clearance - but Role-Based Access Control and User & Team Management are dashed for Individual and ticked from Teams up.

Source retrieved 2026-09-03

Role-based access control is promised only in the enterprise custom scope; the smaller packages describe guardrails agreed with the agency before launch rather than controls an admin can change.

Source retrieved 2026-09-28

Admins author the agent's topics, actions and guardrails; the Trust Layer additionally masks PII/PCI and filters toxic output, and agent data access honours existing permissions and sharing rules.

Source retrieved 2026-09-03

Daily action limits, working hours, approval controls for sensitive actions and automatic cooldowns are all configurable and shipped on both plans.

Source retrieved 2026-09-25

Admins constrain the agent through autonomy modes, per-capability holds, protected page rules and a daily spend ceiling, with destructive actions reserved to admins.

Source retrieved 2026-10-03

Administrators constrain the agent through goals, guardrails, topic filters and human sign-off points defined before anything reaches customers.

Source retrieved 2026-09-26

Enterprise Access Control groups restrict which model providers and block types users may run, enforced in the executor; not available below Enterprise.

Source retrieved 2026-09-03

The sipgate account separates admin from restricted users, which governs configuration rights, not a policy engine limiting what the agent may do mid-call.

Source retrieved 2026-09-03

Owners control who is in an organization and creators can keep bots private, but no published control constrains what the agent itself may read, call or do.

Source retrieved 2026-10-03

An owner can constrain the agent's script, escalation rules and collected fields, and workspaces distinguish Admin from Member, but no policy engine or per-tool permission control is documented.

Source retrieved 2026-09-26

Per-agent switches gate email, Slack, enrichment and table writes, Proposal mode stages every CRM change for review, and admins choose which CRM objects the agent may touch.

Source retrieved 2026-09-15

Admins constrain the agents centrally: enable or disable individual LLMs, apps and tools, force org API keys, restrict who may publish and require SSO on interfaces.

Source retrieved 2026-09-09

Agency admins grant or revoke per-subaccount permissions for actions, agent types, editor options and integrations.

Source retrieved 2026-09-03

Admins set organization rules, tool grants, model access, content filters and spending caps, and can disable task automation for the whole organization.

Source retrieved 2026-10-03

Limits on what an agent may do are set by TecAdRise during design and operations; buyers receive outputs and connectors rather than builder access, so they cannot change policy themselves.

Source retrieved 2026-09-12

Every agent is constrained at setup by guardrails and escalation rules, but the administrative controls that decide who may change them - RBAC, region pinning, retention controls - are listed as Enterprise-plan lines.

Source retrieved 2026-09-16

Owners constrain people through CRUD permission groups and constrain the agent by which tools, integrations and MCP servers are attached, but Telnyx warns that not all V2 services are exposed to organization permissions.

Source retrieved 2026-09-09

Role-based access over credential handling is described as an Enterprise governance capability; no self-serve policy controls are published.

Source retrieved 2026-09-03

Admins get Automation Ops governance policies that can override an agent's model settings, plus custom roles and access policies, but both rows carry an em dash on the Basic tier and start at Standard.

Source retrieved 2026-09-03

Enterprise adds an admin dashboard and member management on Team, but no page describes constraining what the agent itself may do.

Source retrieved 2026-09-26

Admins alone control billing, Plays and exclusion settings that stop agents touching named companies, but team management itself starts at Pro.

Source retrieved 2026-09-27

Per-tool rejection conditions withhold an action, API keys are scoped to specific origins and assistants, and prompt guardrails override other instructions.

Source retrieved 2026-09-03

An administrator constrains each agent individually — which capabilities, which file spaces at which read or write level, which connections — and can require approval for sensitive steps.

Source retrieved 2026-09-27

The owner can constrain the agent tightly through risk tolerances, trust rules and per-context thresholds, but the vendor states there is no admin panel above the individual user.

Source retrieved 2026-09-27

The owner controls which lines each teammate may touch and keeps billing and business settings to themselves, and can force review of every AI reply — but there is no policy engine beyond those switches.

Source retrieved 2026-09-22

Tenants configure agent call settings and their own recording and transcript retention, but no role-based permission model or policy engine for authorised users is documented.

Source retrieved 2026-09-03

Constraint is real but coarse: role-based workspace access and restricted administrative access are documented in the DPA, and the customer controls scripts, booking rules and escalation, yet no granular admin policy console or permission matrix is published.

Source retrieved 2026-10-03

Advanced role-based access control with IP restrictions and configurable retention.

Source retrieved 2026-09-03

Admins set org-wide autonomy per action type plus regex command allowlists and denylists, and can lock users out of overriding them. On Free most settings are fixed; configurability starts at Business and is complete on Enterprise.

Source retrieved 2026-09-03

Constraints are local, not organisational: a policy engine bounds paths to the project root and forces approval prompts, but no central admin console exists.

Source retrieved 2026-09-21

Business admins can disable hosted models by model, turn off edit predictions and lock data sharing, but the controls do not reach BYOK, gateways, local models, external agents or extensions.

Source retrieved 2026-09-29

Admins cap how much of the shared pool each user may burn, choose which repositories agents can index and read, and can restrict repository access to named emails.

Source retrieved 2026-09-09

Reasoning controls on every plan, automated QA scoring of each interaction, and Enterprise approval workflows.

Source retrieved 2026-09-03

Constraints exist but are machine-local, not centrally administered: a packaged agent can enforce tool permissions, and flags or settings restrict the tool list and confine paths to one directory.

Source retrieved 2026-09-28

Constraints are engineered into each delivered system (role-based access, action confirmation, rate limits) rather than exposed as an admin console the buyer configures themselves.

Source retrieved 2026-09-25