In 2025 the OWASP GenAI Security Project kept Prompt Injection at the top of its Top 10 for LLM Applications for a second consecutive edition, and substantially expanded LLM06, Excessive Agency — the risk of an agent taking an unintended, consequential action because it was granted excess functionality, excess permissions, or excess autonomy. That risk gets sharper the moment agent-building moves out of engineering and into low-code and no-code platforms, where a sales-ops analyst or support-team lead can drag-and-drop an agent, point it at a CRM or ticketing connector, and publish it in an afternoon — with no security review in the loop by design. A well-documented precedent for what "convenient defaults" cost at scale already exists outside the agent world: Microsoft Power Pages sites, misconfigured with permissive anonymous- and authenticated-user roles, exposed more than 1.1 million NHS-linked employee records in one disclosed case flagged by AppOmni's research team and covered by outlets including SecurityWeek and The Register starting in 2024. Agent builders inherit the same shape of risk — a shared service-account credential wired to a powerful connector, no column- or action-level scoping, no approval step before a consequential write — except now the "misconfiguration" is an agent deciding, on its own, to send the email or update the record. This piece walks through why the gap exists and what a platform-level enforcement checklist should cover.
What makes low-code agent builders a distinct guardrail problem?
Low-code agent builders are a distinct guardrail problem because the people building agents are, by design, not the people who would normally be accountable for access control. A traditional application gets a permissions model reviewed at code review or architecture sign-off; a low-code agent flow gets built by a business user selecting a connector from a picklist, and the platform typically authenticates that connector with the maker's own credentials or a shared service account rather than a scoped, per-agent identity. The result is that the agent inherits whatever access the underlying account has — often far more than the specific task needs — and the platform has no natural checkpoint where a security team would even see the new agent exist, let alone review what it can touch. This is structurally different from a developer requesting a new API key through a ticket: the low-code flow is optimized to remove exactly that kind of friction, which is also what removes the guardrail.
What does OWASP's 2025 LLM Top 10 say about excessive agency?
OWASP's GenAI Security Project describes Excessive Agency (LLM06) as harm that results from an LLM-based system being able to call functions, or use tools, in ways that go beyond what a task actually requires — broken into excess functionality (tools available that the task doesn't need), excess permissions (tools scoped more broadly than necessary, such as a database credential with write access when only read is needed), and excess autonomy (the system acting without a human checkpoint on consequential steps). The recommended mitigations are concrete and map directly onto platform controls: apply least-privilege scoping to every tool and connector an agent can call, filter and validate both inputs to and outputs from tool calls, require human approval gates before high-risk or irreversible actions execute, and run adversarial testing against the agent's tool-use paths rather than only its conversational outputs. None of those mitigations assume the person building the agent is security-literate — they assume the platform enforces them regardless of who built the agent, which is precisely the gap low-code builders tend to leave open.
What did the Power Pages misconfigurations teach us about low-code default exposure?
The Power Pages misconfigurations, researched by AppOmni and reported publicly from 2024 onward by SecurityWeek, The Register, CyberScoop, the Cloud Security Alliance, and Infosecurity Magazine, are a citation-grade case study in how a low-code platform's convenience defaults become silent over-exposure at scale. The recurring root causes AppOmni documented were not exotic: table and API configurations exposing far more columns than the page's UI displayed, "Anonymous Users" or "Authenticated Users" role assignments left at permissive defaults, open self-registration flows that let external identity providers grant users elevated table access, and an absence of column-level security to restrict which fields a given role could actually read. One disclosed case exposed more than 1.1 million NHS-linked employee records this way. The direct analogy to agent builders: a connector wired with broad default scope, a role default nobody revisited before publishing, and no field- or action-level restriction is the same failure mode — the medium changes from a public data table to an agent invoking a tool, but the governance gap is identical.
Where do low-code agent builders typically fail to enforce least privilege?
Low-code agent builders typically fail to enforce least privilege in three recurring places. First, connector authentication: many platforms authenticate an agent's calls to email, CRM, ticketing, or file-storage systems using the maker's personal credentials or a shared service account rather than issuing the agent its own scoped identity, so the agent can do anything that account can do. Second, action granularity: builders commonly expose a connector's full action surface (read, write, delete, send) to the agent even when the flow only needs one verb, because scoping the picklist down to just the needed actions is extra configuration a non-security user has no prompt to do. Third, approval gates: consequential actions — sending an external email, modifying a financial record, closing a ticket — routinely execute automatically once a flow is published, with no built-in checkpoint distinguishing a read-only lookup from an irreversible write, which is exactly the excess-autonomy failure OWASP calls out.
What should a platform-level control checklist cover?
A platform-level checklist for agentic low-code guardrails should enforce controls the builder can't skip, rather than relying on the builder to opt in:
- Per-agent, per-connector scoped credentials — no agent inherits a maker's personal or a shared service-account's full permission set by default.
- Action-level allow-lists on every connector (read vs. write vs. delete vs. send) instead of exposing a connector's full verb set.
- Mandatory approval gates on a defined class of high-risk actions (external sends, financial writes, record deletion, permission changes) before execution, not just before publish.
- Centralized inventory of every agent and every tool/connector it can call, visible to security teams independent of who built it.
- Signed, queryable audit trail of every tool call an agent makes, including inputs and the identity the call executed under.
- Anomaly and risk scoring per agent, so a spike in call volume or an unusual connector combination surfaces before it becomes an incident.
- Adversarial testing of the agent's tool-use paths — not just its chat responses — before a builder is allowed to publish to production users.
How Safeguard Helps
Safeguard's guardrail engine gives security teams the enforcement points that low-code agent builders don't build in on their own. Policies defined as YAML evaluate against SBOM, permission, and provenance data with BLOCK, WARN, or AUTO_FIX effects, and every decision produces a signed audit record — the same enforcement model documented for CI, registry, and admission control can be pointed at agent and connector inventory, closing the review gap that Power Pages-style incidents exposed at the data layer. Safeguard Guard maintains an explicit inventory of MCP servers and the agents calling them, with each agent carrying a running risk score and anomaly score and supporting direct lifecycle actions — block, unblock, or quarantine — the moment a connector combination looks wrong, independent of whether the agent was built by an engineer or a business user in a low-code canvas. And Safeguard's own autonomous agent capability inside Griffin AI Search is a worked example of bounding autonomy honestly: actions execute only within a same-origin browser boundary, every session is capped at 30 actions or 60 seconds, and explicit per-session consent is required before anything runs — the kind of hard ceiling a low-code agent builder's own guardrail checklist should hold every published agent to.