Should organisations prioritise code-first or low-code agent builders?

Why This Matters for Security Teams

For agent builders, the real decision is not code-first versus low-code in the abstract. It is whether the platform can enforce identity, privilege, and policy with enough precision for an autonomous workload. An AI agent can chain tools, call APIs, and pursue a goal without a human step in the middle, so the security model must assume dynamic behaviour rather than a fixed workflow. That is why guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework matters here: both point teams toward runtime governance, not just build-time convenience.

Low-code builders can be efficient for bounded automations, but they often hide how tools are invoked, how secrets are handled, and whether the agent can exceed its intended scope. Code-first systems usually expose more of the control plane, which makes JIT credentialing, policy-as-code, and workload identity easier to implement consistently. The risk is especially sharp when secrets are long-lived or copied into connectors, because NHIs already suffer from weak visibility and excessive privilege. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which is a serious warning sign for any agent platform that abstracts identity management away. In practice, many security teams encounter agent privilege creep only after a workflow has already been abused, rather than through intentional design.

How It Works in Practice

The best choice depends on whether the platform can express intent-based authorisation and short-lived access at runtime. For code-first agent builders, teams can usually wire in CSA MAESTRO agentic AI threat modeling framework concepts more directly: the agent authenticates as a workload, requests narrowly scoped access, and receives a time-bound credential only for the task it is actually performing. That is where workload identity, OIDC-based federation, SPIFFE-style identity, and policy engines become practical rather than theoretical.

Low-code builders can still be safe when they support the same controls, but the burden is on the platform to prove it. Security teams should verify:

• Whether the agent gets a workload identity, not a shared service account.
• Whether secrets are issued per task and revoked automatically on completion.
• Whether policy is evaluated at request time using context, rather than static RBAC alone.
• Whether the platform supports logging of tool calls, approvals, and escalation attempts.

This is also where NHI hygiene becomes a hard requirement. NHIMG’s OWASP NHI Top 10 guidance and the Ultimate Guide to NHIs — 2025 Outlook and Predictions both reinforce the same operational point: if the agent can touch production systems, its identity lifecycle must be managed like a high-risk workload, not a demo sandbox. These controls tend to break down when low-code connectors hide token reuse, because the operator cannot easily enforce short TTLs, trace privilege boundaries, or revoke access per task.

Common Variations and Edge Cases

Tighter governance often increases build overhead, requiring organisations to balance developer speed against control transparency. That tradeoff is real, and current guidance suggests there is no universal standard for this yet. A small internal assistant with read-only access, no external tools, and no sensitive data may be acceptable in low-code if the platform offers strong isolation and clear approval gates. By contrast, an agent that can modify records, trigger payments, or reach across environments usually belongs in code-first territory where policy can be reviewed, tested, and versioned.

There are also edge cases where low-code is the safer choice, such as rapid prototyping with dummy data, provided production credentials never enter the environment. But once an agent has autonomous tool access, the question shifts from developer productivity to zero standing privilege, ephemeral secrets, and runtime enforcement. That is consistent with the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework, which both emphasise governance proportional to impact. NHIMG’s broader research on agent compromise, including the AI LLM hijack breach and the Moltbook AI agent keys breach, shows why convenience-first platforms are risky when they obscure where keys live and how they are reused.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise secrets rotation or agent approval workflows first?
• Should organisations prioritise secrets rotation or agent identity design first?