The platform citizen developers build agents on decides which controls exist at all, and on the category leader the governance layer is a paid tier, not a configuration choice.
What this category solves (and what you did before it)
It gives non-engineers a governed place to build agents. Before it, the same people built ungoverned automations in spreadsheets, RPA tools and personal chat sessions.
The category’s two ends behave so differently that treating them as one product class is the most common analytical error here. At one end sits a platform with an environment model, tenant data policies and a publish workflow. At the other sit consumer app-builders where one click publishes to a public subdomain with no staging, review gate or security check.
The finding that should change your budget
Platform-native governance on the leading enterprise platform is licensed, not configured. Managed Environments (carrying sharing limits, usage insights, per-environment data policies, solution-checker enforcement and pipelines) are an entitlement of standalone premium licences only, and once an environment is Managed, every active user in it must hold one. Environment groups, the only way to enforce rules across many environments at once, are premium and can contain managed environments only.
A firm running on the Power Platform capability seeded into its Microsoft 365 licences therefore cannot turn the governance layer on. It has to move its makers and their users to premium SKUs first. Price that before writing a policy that depends on it.
A related trap: the bundled Copilot Studio plan excludes generative orchestration, premium connectors, every non-Teams channel, and any environment other than Dataverse-for-Teams; trial licences can build but not publish. “We already have Copilot Studio with our M365 licence” and “we have Copilot Studio” are materially different products.
What actually differentiates products
The admin surface, which is fragmented. Governance on the leading platform is split across the Power Platform admin center, Purview (maker audit logs), Sentinel (agent-activity alerting) and the Microsoft 365 admin center. That is the vendor’s own architecture, not a criticism; budget for four consoles.
Connector control, and its exemptions. The classic model sorts connectors into Business, Non-business and Blocked with no flow between groups, suspending violating agents. Worth using, with four caveats the marketing omits: enforcement takes up to 24 hours in extreme cases rather than being instant; it works only on blockable connectors, not custom ones; trigger-level control is PowerShell-only; and connectors introduced since 2019 default to Non-business, so new platform capabilities land in the default bucket rather than blocked.
Default-deny is coming and has not arrived yet for agents. Advanced connector policies replace the three-group model with a strict allowlist: every connector and action blocked unless permitted, new connectors blocked automatically, entire MCP servers blockable. The vendor’s stated reason for abandoning the old model is that it “wasn’t deemed effective in policy management,” which is candid. But general availability is per maker portal, and as of the July 2026 documentation enforcement for Copilot Studio is runtime-only: a maker can build and publish an agent using a blocked connector and discover it at runtime. Custom and HTTP connectors are unsupported, so both policy systems run in parallel indefinitely; virtual connectors are never coming, and Copilot Studio’s own governance levers are virtual connectors, being spun into a third rule system that remains unbuilt. This platform lacks default-deny connector governance for agents; it is arriving, workload by workload.
Whether the publish gate gates. The pre-publish security scan checks three deviations from secure defaults (no authentication, maker-provided rather than end-user credentials, sharing with everyone) and then warns. The maker can publish anyway. Only an admin policy blocking the unauthenticated-chat connector turns that warning into a stop; see promotion gates.
Why makers turn the secure default off
The most useful mechanism on the page has nothing to do with careless staff. The secure authentication default confines an agent to the Teams and Microsoft 365 channel. To publish anywhere else and keep authentication, a maker must switch to manual authentication: an Entra app registration, a client secret or certificate, authorization and token URL templates, scopes, a scope delimiter. A citizen developer who wants an agent on the company website chooses between an afternoon of OAuth configuration and one radio button labelled “No authentication.”
Insecure defaults here are a usability gradient rather than an oversight. That puts the control in a tenant policy rather than in maker judgment or a warning dialog.
Three more things to check before you trust the platform
Sharing escalates privilege silently. Sharing an agent for collaborative authoring assigns the recipient the Environment Maker role if they lack it, so sharing one agent grants a colleague the right to build their own. Transcript-viewing permission is environment-scoped rather than agent-scoped, and the vendor’s recommended mitigation is a separate environment: governance by topology, not by permission.
The default retention posture is destructive. A preconfigured job permanently deletes transcripts older than 30 days; with SharePoint grounding the retained record keeps the question and source but marks the agent’s own answer redacted; some environment types keep none. Against three-, five- and six-year statutory floors that is a recordkeeping failure a firm buys its way out of; see comms archiving.
Audit logs export, but not the content. Administrative collection is on by default and events are retrievable through a management API, but the audit solution deliberately excludes interaction text, carrying only a thread identifier, and some channels are excluded without being enumerated.
The enterprise bar, applied
Certifications are broad, but the specific items sit outside the obvious place to look. The product’s compliance page says “SOC” without naming the report, so SOC 2 Type II goes unasserted there, and ISO/IEC 42001 is absent from its ISO table. The page carries a late-2024 date, unrevised through the entire agent build-out, still citing the 2013 revision of ISO 27001; a compliance page that stale is itself a finding. On the credit side, the vendor states flatly in its application card that it does not train foundation models on customer data.
Two items to raise in the meeting. The default model auto-upgrades periodically, as more capable models reach general availability, with retired models usable for a month. The model underneath a citizen-built agent changes without the maker touching anything. And the exit path leads nowhere off the platform: agents export as platform solutions between platform environments with no portable artifact, and they land in the default solution automatically, so the out-of-the-box artifact is the non-exportable one.
The strongest per-agent lever shipped is a cost lever: monthly credit limits with a hard stop that disables the agent. See cost controls.
Named examples: read the LICENSE file, not the badge
LangGraph and CrewAI, commonly listed as commercial, ship MIT-licensed cores with the commercial layers sold separately; one of those vendors’ certification status could not be verified at all: trust center an empty shell, security page a 404. n8n, routinely called open source, is source-available for internal business use only, publishes SOC 2 Type 2 but not ISO 27001, and its “fair-code” label is its own coinage maintained by its own founders. AutoGen is in maintenance mode; AutoGPT is dual-licensed, the part that matters under a non-compete licence.
Category maturity and the risk that actually bites
Incumbent-dominated, which turns the risk from vendor death into silent capability sprawl inside licences the firm already owns. Six of thirty flagship agent products in a 2026 index run at high autonomy on event triggers with no human in the loop, and the leading low-code platform is one. An admin must affirmatively block those triggers, the vendor’s stated rationale being to prevent exfiltration and unwanted consumption.
The durable lesson comes from that platform’s own history. Its agents were once publicly reachable and unauthenticated by default, demonstrated at scale with a purpose-built scanner in August 2024 and hardened by that November, with the caveat that the new default applied to newly created agents. Fourteen months later researchers still found tens of thousands of publicly discoverable agents, and legacy chatbots still default to no authentication. New defaults protect new artifacts; nobody re-runs the fleet. That is the argument for registry review, evidenced on the category leader rather than a startup.
At the consumer end, one popular app-builder’s 2026 incident let any free account read other users’ source code, credentials, chat histories and customer data for roughly ten weeks.
See also
- Three-zone architecture — the environment model these platforms should be configured to enforce.
- Promotion gates — the process the platform’s publish workflow has to carry, and mostly doesn’t.
- Shadow agents — what unmanaged builder licences produce.
- Quality debt and orphaned apps — the classic citizen-dev failure this category inherits.
- Secrets management — low-code exports leak credentials; the control must reach them.
- Enterprise AI assistant platforms — the chat-first neighbour category.