87% of Enterprise Developers Use Low-Code. That Is the Agent Security Problem

Forrester reported in a 2024 market analysis that 87% of enterprise developers use low-code platforms for some development work. That figure, cited in a new Unite.AI analysis of agent security, explains why cybersecurity strategies now have to diverge depending on whether an AI agent (an autonomous system that performs tasks with limited supervision) was assembled on a visual platform or written as custom code.

The analysis argues that security responsibilities sit in different places in each approach. Low-code builders work within platform settings that govern sharing and connector access, which makes configuration decisions especially important. High-code teams take greater responsibility for the software and environments that execute agent instructions, including boundaries around files and credentials.

What Risks Do Both Approaches Share?

The Cybersecurity and Infrastructure Security Agency (CISA) identifies several agentic AI risks that the analysis treats as a useful framework for both development styles:

• Expanded attack surface — additional entry points created by agent deployments
• Privilege creep — the gradual accumulation of access beyond what a task requires
• Behavioral misalignment — departures from an agent's intended tasks
• Obscure event records — logging gaps that complicate investigation

A widely used connector and an unrestricted command-line tool can create different versions of the same problems, the analysis notes. The stakes are straightforward: as organizations put AI agents to work across business systems, development speed and security oversight become closely connected.

Where Do Low-Code Environments Fall Short?

Low-code accessibility brings agent creation within reach of employees outside traditional development teams. That reach is exactly the vulnerability. Citizen developers may connect an agent to shared files or business applications without fully understanding the agent's permissions, and access granted through those connections can expose sensitive information or enable actions beyond the intended workflow.

Broad sharing and unclear ownership compound that exposure. The scale of adoption also makes consistent oversight across departments difficult — though the Forrester figure carries a caveat the analysis itself flags: the 87% finding concerns development generally, so it establishes the platforms' reach without measuring AI agent adoption specifically.

How Can Low-Code Agent Security Be Strengthened?

The analysis prescribes concrete fixes:

• Review connector permissions against each agent's assigned task and apply least-privilege access (granting only the minimum permissions a task requires)
• Maintain a central inventory recording the owner and connected services for every deployment
• Require approval for sensitive actions

The inventory gives security teams a basis for identifying unregistered agents and investigating inappropriate access. Microsoft's data-governance approach supplies a supporting principle. Naveen Jangir, principal architect at Microsoft Digital, recommends that organizations "govern and protect it with appropriate access restrictions." Those controls allow authorized users and AI capabilities to use business information without unnecessary exposure within established permission boundaries. Connector policies paired with accountable ownership can make those restrictions part of everyday development.

What Makes High-Code Development Different?

When teams use AI coding agents to build custom systems, generated changes can arrive faster than people can examine them. High-code security therefore requires controls over both the development process and the environments where agents execute tasks.

The distinctive threat is indirect prompt injection (adversary-supplied instructions hidden in content an agent reads). Coding agents may encounter such instructions when reading external repositories. If an agent follows them while holding development-tool access, it may run unsafe commands or expose credentials. The consequences depend partly on which files, tools and external destinations its execution environment permits it to reach.

NVIDIA's sandboxing guidance addresses credential exposure within that execution boundary. It states that "sandbox environments should rely on explicit secret injection" to limit access to credentials. Agents should not inherit full environment credentials when their tasks require only limited access; teams should provision credentials for the specific task and keep unrelated secrets outside the agent's reach.

How Can High-Code Pipelines Be Hardened?

The analysis lists several layers of defense:

• Restricted execution environments that constrain file access and outbound connections according to the task
• Static application security testing (automated scanning of code for vulnerabilities) applied to generated code
• Independent reviewers examining authorization decisions or business logic that automated checks may miss

Amazon Web Services recommends separating code generation from evaluation in its framework for coding-agent controls, noting that "a separate session helps avoid self-confirmation bias." The analysis adds a caveat of its own: two sessions using the same model can carry the same underlying blind spots during review. Where practical, a different reviewing model and human evaluation of security-sensitive changes can add further scrutiny.

Why Does Security Need to Span Both Approaches?

AI security needs a shared view of activity wherever agents exchange information. A low-code workflow might send content to a custom-built agent, which then calls another business service. Reviewing each component separately can leave security teams without the context needed to understand the full sequence.

The AI security experts at Darktrace argue that organizations must inspect prompts and sessions alongside responses across enterprise generative AI tools and both development approaches. Its perspective also covers software-as-a-service and secure access service edge (a network security model that connects users to applications) environments. With that visibility, organizations gain context so that "they can detect clever conversational prompt attacks and malicious chaining" — sequences of agent actions combined to produce unauthorized effects.

Darktrace's view supports a broader strategy because prompt visibility, session monitoring and identity oversight help teams understand how agents interact across connected tools. Security teams should examine how instructions change through connected sessions and whether subsequent actions remain consistent with the original authorization. They should also weigh the sensitivity of any information retained for investigation.

What Does Long-Term Governance Require?

Each agent should have an accountable owner and a defined scope of permitted work, regardless of its development method. Governance should also identify who can approve changes to that scope and who can suspend activity when an agent behaves unexpectedly.

Research on agent governance cited in the analysis suggests that agents need authority that can be authenticated and audited to support that accountability. This approach connects the person granting permission with the tasks an agent may undertake, so organizations can check any action against that authorization.

Teams should maintain activity records that connect delegated permissions with tool use and outcomes. Periodic reviews should revisit those permissions as capabilities change, remove access left over from completed work and confirm that ownership remains current. The takeaway in plain words: an agent's permitted activities should stay clear throughout its life cycle, not just at deployment.

What Comes Next for Agent Security?

The analysis closes with a divided prescription. Low-code development calls for careful platform permissions and connector governance; high-code development requires close attention to custom execution environments and code review. Centralized monitoring and consistent accountability provide the common foundation for overseeing how agents access information and act across connected business systems. As capabilities expand, developers should reassess safeguards alongside changes to agent tools and responsibilities — a reminder that neither approach's security posture is finished on the day an agent ships.