Low-Code and High-Code AI Agents Need Different Security Controls

By Daniel Okafor

Forrester reported in a 2024 market analysis that 87% of enterprise developers use low-code platforms for some development work. The finding concerns development generally, so it establishes the platforms’ reach without measuring AI agent adoption specifically. The analysis links deployment speed with security oversight as agents enter business systems.

What changes between low-code and high-code agents?

Low-code platforms assemble agents through visual interfaces and prebuilt connectors to business services. High-code development defines behavior through custom code, tool integrations and execution environments. Both give agents access to information and authority to act, but both require oversight of information access and permitted actions. The security burden shifts with where teams place control.

Low-code builders work within platform settings that govern sharing and connector access, so configuration decisions carry direct consequences. High-code teams own the software and execution environments that process instructions. They must set boundaries around files, credentials and external destinations.

The Cybersecurity and Infrastructure Security Agency (CISA) identifies expanded attack surface as additional entry points and privilege creep as accumulating access. Behavioral misalignment means departures from intended tasks. Obscure event records complicate investigations.

A widely used connector and an unrestricted command-line tool can create different versions of the same underlying failures because their access and execution paths differ.

Where does low-code access create exposure?

The analysis identifies low-code accessibility as a governance problem because agent creation reaches employees outside traditional development teams. Security oversight must extend to those builders so convenience does not outrun authorization.

Citizen developers may connect an agent to shared files or business applications without understanding their permissions, exposing sensitive information or enabling actions beyond the intended workflow. Broad sharing and unclear ownership compound that exposure. A central inventory becomes more valuable as adoption spreads across departments.

What safeguards fit low-code deployments?

Teams should review connector permissions against each agent’s assigned task and apply least privilege. A central inventory should record the owner and connected services for every deployment, with approval requirements for sensitive actions. These controls help identify unregistered agents and investigate inappropriate access.

Microsoft’s data-governance approach emphasizes controlled access to business information. Naveen Jangir, principal architect at Microsoft Digital, recommends that organizations “govern and protect it with appropriate access restrictions.” These controls let authorized users and AI capabilities use information within established permission boundaries and without unnecessary exposure. Connector policies make those restrictions part of daily development. Accountable ownership keeps exceptions visible.

Why do high-code agents require stronger boundaries?

The analysis warns that AI coding agents can produce changes faster than people can examine them. Controls must cover development and the environments where agents execute tasks. Custom systems can combine generated code with direct access to development tools.

Coding agents can encounter indirect prompt injection when external repositories contain adversary-supplied instructions. If an agent follows them while holding development-tool access, it may run unsafe commands or expose credentials, depending partly on the files, tools and external destinations its environment permits.

NVIDIA’s sandboxing guidance addresses credential exposure within that execution boundary. It says “sandbox environments should rely on explicit secret injection.” Agents should not inherit full environment credentials for tasks needing limited access. Teams should provision task-specific credentials and keep unrelated secrets outside the agent’s reach.

How should high-code pipelines be hardened?

Restricted environments should constrain file access and outbound connections by task. Teams should apply static application security testing to generated code. Independent reviewers should examine authorization decisions or business logic that automated checks may miss. Together, these layers address execution boundaries and software weaknesses.

Amazon Web Services recommends separating code generation from evaluation in its coding-agent control framework. AWS notes that “a separate session helps avoid self-confirmation bias.” Two sessions using the same model can retain the same blind spots. Where practical, teams can add a different reviewing model. Human evaluation can further test security-sensitive changes.

How can monitoring follow agents across systems?

Agents need a shared view of activity wherever low-code and high-code systems exchange information. Consider a low-code workflow that sends 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 permissions it used and the actions that followed.

Darktrace says organizations must inspect prompts and sessions alongside responses across enterprise generative AI tools. Its monitoring spans low-code and high-code development, software-as-a-service and secure access service edge environments. Darktrace argues that, with that visibility, “they can detect clever conversational prompt attacks and malicious chaining.”

Prompt visibility, session monitoring and identity oversight show how agents interact across connected tools. Security teams should examine how instructions change through connected sessions. They should test whether later actions remain consistent with the original authorization. They should consider the sensitivity of information retained for investigation.

Who owns an agent’s authority?

Each agent should have an accountable owner and a defined scope of permitted work. This rule applies regardless of development method. Governance should name who can approve scope changes. It should also name who can suspend an agent after unexpected behavior.

Research cited in the analysis says agents need authority that can be authenticated and audited. This links the person granting permission with the tasks an agent may undertake. Organizations can then check an action against its authorization.

Teams should maintain activity records connecting delegated permissions with tool use and outcomes. Periodic reviews should revisit permissions as capabilities change. They should remove completed-work access and confirm current ownership. Development and security teams can use those reviews to keep controls aligned with an agent’s approved purpose.

What changes as deployments expand?

Low-code deployments require platform permissions and connector governance. High-code deployments require execution boundaries, credential isolation and code review. Centralized monitoring and accountable ownership provide the common layer. As capabilities expand, teams should reassess safeguards with changes in tools and responsibilities, keeping each deployment’s permitted activities clear throughout its life cycle.