Free Agentic AI Security Workshop Map your footprint, identify your highest-risk gaps, and leave with a customized security summary. Book a Workshop→
Start assessment

The Agentic AI Taxonomy, Part 9: Platform-Built: Low-Code and No-Code Agents

October 6, 2026 · Jason Garbis

White humanoid robot beside a network of connected workflow icons, illustrating platform-built agents that link apps and automate tasks

Summary
Platform-built agents are AI agents that business users create in no-code or low-code platforms like Microsoft Copilot Studio, Zapier, n8n, Make, Salesforce, and ServiceNow. They aren’t inherently less secure than code-based agents. But they’re so easy to build and publish that users make identity, data, and deployment decisions without realizing it, often with no security review. This article covers the risks across data, identity, authority, autonomy, management, and lifecycle. It also explains how security teams can enable citizen development safely with centralized guardrails. 

Welcome back to our series exploring the Numberline Agentic AI taxonomy, one category at a time. If you’re just joining us, links to the full series are at the end of this article.

Today, we’re making a deliberate shift. Everything we’ve covered so far has been vendor-built, meaning someone else designed the agent and you decided how to govern it. However, from here on, we’re in enterprise-built territory, where your own people create the agent. On our taxonomy diagram, we’re crossing from the purple categories into the peach ones.

Diagram comparing various types of agent infrastructure, categorized into vendor-built and enterprise-built, including sections for provider-hosted, SaaS-embedded, local access, platform-built, and custom-built agents.

Note that this shift is orthogonal to where the agent runs. The agents we’re discussing today are all deployed and operating inside a vendor’s environment, with access to your data. Deployment will get considerably more complicated with the custom agents we’ll be discussing in future articles.

So, here we are: Platform-built agents, which we define as agentic AI created by an enterprise customer and hosted within a vendor’s no-code or low-code platform. Examples include Microsoft’s Copilot Studio and Power Automate, Zapier, n8n, and Make among many others. Today’s category also includes the agent-building capabilities inside SaaS platforms like Salesforce and ServiceNow, which we flagged back in Part 6 and are finally returning to.

These platforms are highly approachable and appealing to non-technical users. Natural language configuration, visual flowchart designers, templates, and prebuilt connectors to every data source your enterprise runs. That’s good news for business productivity, and it’s why adoption moves fast. As shown in the image below, these are easy to understand, and easy to use. Perhaps too easy.

Flowchart illustrating the user creation process, detailing actions taken by an AI agent based on form submission, including verification of manager status and integration with various tools like Jira Software and Microsoft Entra ID.

Sample no-code agent flow. Source: n8n.io

The Decisions Nobody Knows They’re Making

Here’s what makes this category different from everything before it: in every previous category, security decisions were made by people who knew they were making them. A vendor’s engineers designed the agent’s permission model. Your own developers chose its authentication method. The decisions may have been wrong, but they were recognized as decisions.

That changes here. A business user selecting a connector from a dropdown is making an authorization decision. Choosing “share with everyone in my organization” is a deployment decision. Picking maker-provided credentials over end-user authentication is an identity architecture decision. None of those look like security decisions in the interface. They look like configuration steps between the user and a working agent, and the person clicking through them has no particular reason to think otherwise.

These platforms don’t remove software risk. They compress identity, data, tool, autonomy and publishing decisions into a UI that makes them look simple. A business user can connect data, add actions, and publish broadly in an afternoon, typically without source control, AppSec review, or a formal deployment pipeline.

But we shouldn’t aim to prevent citizen development. Instead, we need to recognize the situation for what it is: decentralized creation that needs centralized guardrails for identity, data, tools, deployment, monitoring and lifecycle ownership. Which means infosec needs the tooling, the time, and the political capital to put those guardrails in place.

Now that we’ve teed this up, let’s go through our six aspects.

Data

An agent on these platforms can combine knowledge bases, uploaded files, SaaS applications, databases, websites, email, and user prompts. Practically speaking, that’s an unlimited set of enterprise and public data.

The consequence worth pondering is that one agent gets a unified view across sources that were, are, and will continue to be governed separately. Your SharePoint permissions, your CRM sharing rules, and your ticketing system’s access model were each designed independently by different teams at different times. An agent reading from all three produces a view that no single governance decision ever authorized.

The exposures follow from there: overshared or stale data surfacing, data moving between business and consumer services, and sensitive content inadvertently reaching an external system. And, we need to be aware that indirect prompt injection becomes viable, since retrieved content and tool output arrive as untrusted input that the agent treats as context.

And finally, all of that analysis assumes you know the agent exists. Frequently you won’t. An employee can build an agent on a personal Zapier or Make account, connect it to corporate Slack or Google Workspace, set it running on a schedule, and never touch anything your enterprise administers. 

While we may be tempted to blame the user, this is actually the SaaS product working exactly as designed, for someone trying to get their job done faster. The platform’s governance stack may be excellent and entirely irrelevant, because your organization has no relationship with that deployment.

Controls

  • Platform data policies to assert controls, such as Microsoft’s Power Platform, which classifies connectors into business, non-business and blocked groups, and prevents agents from bridging across them
  • Access controls, sensitivity labels, retention and DLP on the underlying repositories
  • Restrictions limiting agents to approved sources, with sensitive sources blocked in unmanaged environments
  • Logging of sources accessed, destinations and transfers, within privacy and legal limits

Recommendations

  • Minimize each agent’s data access where possible, and review inherited access before publishing.
  • Treat retrieved external content and tool output as untrusted, and keep it separate from trusted instructions.
  • Test both direct and indirect prompt injection using realistic documents, email, tickets and web content.
  • Review sources periodically for stale, duplicate, overshared or overly sensitive data.
  • Find the agents you don’t know about. SaaS discovery tooling, expense reports and OAuth grant reviews in your identity provider are all reasonable starting points.

Identity

Whose identity does the agent use? There are three answers, and which of them your platform supports matters enormously.

User context, where the agent acts as the invoking user. This preserves existing authorization boundaries, which is its virtue. It also amplifies the speed and scale of what that user can already do, which is the familiar on-behalf-of amplification we’ve discussed throughout this series.

Maker-provided credentials, where the agent uses the builder’s credentials regardless of who invokes it. This is the riskiest of the three. Every user of the agent indirectly exercises the maker’s privileges, which is a confused-deputy path straight to oversharing. Microsoft warns about this directly in their own documentation.

Distinct agent identity, where the agent holds its own credentials. This gives the best separation and auditability, and it requires you to provision, review and retire that identity like any other privileged account.

Find out which model each of your platforms uses. Some platforms will support more than one, in which case someone is choosing, and if nobody chooses deliberately, the platform default decides.

Zooming out, there’s an important structural point underneath this worth understanding. Microsoft can give a Copilot Studio agent an identity in your Entra ID directory, where your conditional access policies and governance workflows already operate, because Microsoft owns your directory. Salesforce cannot do that. Neither can Zapier, ServiceNow, or Workday. Inherited governance is a structural privilege of the identity provider, available to roughly one vendor for one set of products, and only when Entra ID is your identity provider. For organizations running Okta or another IdP, even this arrangement is parallel.

Which means parallel governance is the default condition. For every platform you run that isn’t your IdP, agent governance lives in that platform’s console, enforced by that platform, logged in that platform’s audit trail. The practical question is how many parallel governance planes you’re willing to operate, and whether they can feed anything central. Agent identity standards and cross-vendor control planes are emerging to address exactly this, so they’re worth watching even if they’re not yet widely adopted. 

Controls

  • End-user authentication where downstream systems support delegation
  • Dedicated agent or service identities for autonomous execution, with reliance on a maker’s personal credentials prohibited
  • Least privilege, separating read, write, admin and external-communication permissions
  • Conditional access, secrets management, credential rotation and periodic access reviews
  • Audit logging that captures invoking user, agent identity, downstream identity and authorization decision

Recommendations

  • Choose the identity model explicitly at design time rather than inheriting the platform default, and ideally constrain end user choices.
  • Use user context for user-initiated tasks and non-human identities for autonomous workloads.
  • Require at least two accountable owners per agent, with documented succession.
  • Review effective permissions from the agent’s side, including inherited ones.

Authority

Once identity is settled, what may the agent actually do? Authority here is assembled from connectors, API actions, workflows, topics and sharing settings, which means it accumulates rather than being designed.

Three failure patterns show up repeatedly: a read-oriented agent quietly acquires write or delete functions. A broad web-access action bypasses the curated connector catalog entirely. And, very frequently, a narrow use case runs under an identity that can administer the whole tenant.

Those are excessive functionality and excessive permissions, two of the three root causes OWASP identifies under Excessive Agency. The third is excessive autonomy, which is next.

Controls

  • An approved tool and connector catalog, with ability to block general-purpose or high-risk actions unless authorized
  • Write, delete, export, financial, and administrative functions stripped by default
  • Permissions scoped to specific systems, records, fields, repositories and environments
  • Sensitive operations behind dedicated tools with stronger authorization, validation and logging
  • Rate, transaction, volume and destination limits

Recommendations

  • Use the smallest tool set that fits the stated purpose.
  • Prefer narrow actions over general web access or scripting capability.
  • Document why each connector and privileged function is needed.
  • Reassess authority whenever instructions, connectors, credentials, environments or use cases change.

Autonomy

These agents provide a wide range of possible autonomy, from reactive assistants answering questions to event-driven workers that select tools, take multiple steps, and run unsupervised. We need to expect that their level of autonomy and proactivity will expand over time; this is a clear trend among agentic AI providers.

Risk rises when untrusted content or an ambiguous goal becomes consequential action without anything in between. The chain to watch is untrusted content leading to a model decision, leading to a trusted connector, leading to an enterprise action. Each link is reasonable on its own and the sequence is not.

In these situations, independent checks and an observable audit trail increase in importance the more steps an agent takes, the longer it runs, and the harder its actions are to reverse.

Controls

  • Human approval for irreversible, financial, privileged, destructive, safety-relevant or externally visible actions
  • Stop conditions, maximum steps, retry limits, spend limits and timeouts
  • Deterministic validation outside the model for critical fields, destinations, amounts and authorization
  • A kill switch and safe fallback on tool failure, ambiguity or low confidence

Recommendations

  • Start read-only or recommend-only, and expand only after testing shows the need.
  • Use the lowest autonomy level that achieves the outcome.
  • Test full multi-step workflows with adversarial input, tool failures, approval bypass attempts and loops.
  • Prefer reversible actions and staged execution.

Management

This is where the category’s real problem lives, and it has two halves.

The first is the procurement path. Copilot Studio arrives inside a Power Platform tenant your IT organization already administers, which means the governance conversation happens with people who know the platform exists. This is the easy part.

Conversely, citizen development platforms such as Zapier, Make and n8n are frequently adopted bottom-up by a department that needed something done. Now, these are responsible vendors, and their enterprise governance capabilities are typically robust and well-thought-out within their higher Enterprise tiers. However, in many cases, the team that started using this platform on a lower plan eighteen months ago is not running the tier where the controls live, and in fact may not appear in your SaaS inventory at all.

So the question for each platform is not only whether it offers governance (which they often do). It’s whether the deployment you actually have is the one with the controls.

The second half is what we’d call the floor. A code-based agent gets diff history, attribution, and a gated deployment event whether or not the team is disciplined, because the tooling imposes it. A low-code agent gets none of those by default. The platforms do offer equivalents, such as managed environments, environment separation, deployment pipelines and production publishing restrictions. The controls that would restore an SDLC-equivalent floor exist. But they are often opt-in, they require someone to configure and operate them, and the person building these no-code agents is not that someone.

Maturity varies considerably across this category, which means your control strategy has to be per-platform. There is no uniform approach available. It also means governance capability now belongs in your vendor selection criteria, which it didn’t a year ago.

Controls

  • A central agent registry recording owner, purpose, environment, audience, identity, data, tools, autonomy and risk tier
  • Separate sandbox, development, test and production environments, with production publishing restricted
  • Authentication, authorization and security review before production or broad sharing
  • Monitoring of changes to instructions, tools, credentials, knowledge, audiences and channels
  • Correlation of platform logs with IdP, API gateway, DLP, SaaS and downstream telemetry

Recommendations

  • Use managed environments, approved templates and curated connectors to make the secure path the easy path.
  • Treat publishing and material sharing changes as deployment events.
  • Scale review depth to risk tier.
  • Give security, platform and business teams shared visibility rather than separate views.
  • Invest the time to understand the specific controls available in your platforms’ enterprise tiers, upgrade to that level, and actively enforce guidelines.

Lifecycle

Too often, agents outlive either their purpose or their makers. The long tail is copies, templates, test versions, stale credentials, abandoned connectors and forgotten channels.

Agent behavior also changes without a code release. A model update, a platform change, a connector’s API revision, or a shifted business process can alter what an agent does with nothing appearing in any change log.

And, orphaned agents in this category can sprout like proverbial mushrooms. For example, a department lead may change roles within the firm, leaving behind an agent that runs on a schedule under credentials they provided, producing output someone downstream still depends on. That’s the maker-credentials risk and the dependency problem arriving together.

A named owner and a single review aren’t sufficient. You need recurring evidence that the agent is still necessary, correctly scoped and safe, which means scheduled recertification of need, ownership, access and risk tier. Regular, validated governance is what closes this gap.

Controls

  • Durable business and technical ownership with succession rules
  • Versioning for instructions, knowledge configuration, tools, identity mappings and approval rules
  • Re-review after material changes to models, sources, connectors, permissions, audiences or autonomy
  • Scheduled recertifications
  • Retirement that disables triggers and channels, revokes credentials, removes integrations and preserves audit records

Recommendations

  • Define the whole lifecycle before publishing, not after.
  • Set expiry or review dates for pilots, temporary agents and elevated permissions.
  • Find and retire unused, duplicate, orphaned and test agents on a regular cycle.
  • Include model, platform, connector and process changes in your risk reviews.

Conclusion

Low-code and no-code agents will likely become one of the most common enterprise-built agent types, so get ready. They fit tools people already have, they pay back quickly, and they let domain experts automate work that would never have reached an engineering backlog.

And remember: these agents are not inherently less secure than code-based agents, but they are far easier to create, copy, connect and publish, so weak decisions scale faster.

That sentence is accurate, but shouldn’t make you complacent. Because it’s so much easier for non-technical users to stand up a no-code agent in an afternoon, the deployments you actually end up with will very likely be less secure, less well-managed and less visible than what an equivalent code-based agent would have produced. The floor is lower, and most deployments sit at the floor.

The encouraging part is that this is a configuration gap rather than a capability gap. The controls that raise the floor exist on these platforms today. Someone has to turn them on, operate them, and keep them current.

So, don’t stop citizen development. Make the approved path the easy path, and make it safe by default. Decentralized innovation inside centralized guardrails is an achievable model, and it’s considerably better than the alternative of finding out what your organization built after something goes wrong.

One last thought connecting this to where we’ve been in our earlier articles. GUI agents blur the line between a person and software, which costs you attribution, since you can no longer tell who did what. Low-code agents blur the line between a user and a developer, which costs you assurance, since the SDLC machinery that normally catches bad decisions isn’t in these new pathways.

Coming Soon: We dive into Custom-Built Agents, where deployment and hosting choices start to matter a great deal.

Questions? Want to Learn More?

If you’d like some guidance, join us for a free 30-minute Agentic AI Security Workshop. We’ll review the taxonomy with you and help you apply these recommendations to your enterprise.

Previous Articles in this series:

References and additional resources