Low-code AI governance gaps in Copilot Studio and Agentforce

At a glance

What this is: Openlayer argues that low-code AI governance gaps in Copilot Studio and Agentforce leave organisations with access controls but weak visibility into agent output quality, drift, and auditability.

Why it matters: This matters because IAM, AI governance, and compliance teams need evidence of what an agent did at inference time, not just who could build or connect it.

Context

Low-code AI builders move quickly, but governance does not automatically travel with that speed. When business users can configure agents, connect them to enterprise data, and deploy them without a baseline or review gate, the result is a control gap around risk classification, monitoring, and evidential traceability. In identity terms, the governance problem is not just who has access to configure the agent, but how the organisation proves what that agent was authorised to do after it started acting.

The central issue is behavioural governance, not deployment mechanics. Copilot Studio and Agentforce can cover access and data handling, but they do not natively close the loop on output quality, drift, or per-inference audit evidence. That leaves teams trying to govern AI systems whose runtime behaviour can change faster than their review process can catch up.

Key questions

Q: How should security teams govern business-built AI agents in low-code platforms?

A: Start with discovery, ownership, and access boundaries. Business-built agents should not reach regulated data or operational systems until they are inventoried, assigned to an accountable owner, and checked against policy. The key control is not just approval at creation, but a repeatable review of what the agent can access and do after it is deployed.

Q: Why do native Copilot Studio and Agentforce controls leave compliance gaps?

A: Because they mainly govern access and data handling, not output quality or evidential traceability. A platform can restrict who builds an agent and what connectors it uses, yet still fail to show whether the generated answer was grounded, drifted over time, or can be reconstructed for audit. That is a governance gap, not a deployment bug.

Q: What breaks when low-code AI agents are deployed without a baseline?

A: Behavioural drift becomes invisible. If an agent goes live without a validated reference point, teams cannot tell whether later output changes are normal variation or a regression introduced by prompt edits, source-data changes, or model updates. That makes detection, review, and compliance evidence far weaker than most organisations expect.

Q: What is the difference between AI governance frameworks and runtime guardrails for AI agents?

A: AI governance frameworks define the policies, standards, and oversight structure for how AI should be approved, monitored, and audited. Runtime guardrails operate inside the live system to constrain behavior in real time, such as limiting tool use, blocking unsafe actions, and enforcing access boundaries. Mature programs need both because policy without enforcement leaves gaps.

Technical breakdown

Why low-code AI agents need runtime governance

Low-code AI agents sit between traditional application workflows and model-driven behaviour. A builder can connect an agent to a CRM, a document store, or a workflow engine, but the resulting system still generates probabilistic output at runtime. That means the control point cannot stop at provisioning or connector approval. A meaningful governance model has to capture the prompt, retrieval context, generated response, and policy state at inference time. Without that, the organisation can know an agent was deployed, but not whether its output stayed inside the intended scope or drifted into unsafe behaviour after release.

Practical implication: govern low-code agents at inference time, not only at build time.

Where native platform controls stop

Native controls in low-code AI platforms usually cover access permissions, topic boundaries, and data-handling rules. Those controls matter, but they are not the same as behavioural assurance. They do not measure groundedness, hallucination rate, or response drift, and they rarely create an immutable record that links each output to the version, inputs, and policy state behind it. That leaves a gap between permissioning and proof. In regulated environments, that gap is where compliance evidence fails, because a system can be authorised and still produce output that is not defensible after the fact.

Practical implication: separate access governance from evidence of output quality and traceability.

Why cross-platform oversight becomes mandatory

Once organisations run low-code AI across more than one builder, governance fragments quickly. Different platforms expose different logs, different policy objects, and different monitoring primitives, so a threshold configured in one environment does not automatically mean the same thing in another. That creates inconsistent assurance across the estate. The right response is a shared governance layer that normalises risk classification, monitoring thresholds, and audit expectations across tools. In identity security terms, this is analogous to insisting on common policy and evidence requirements across multiple identity providers rather than trusting each platform’s native defaults.

Practical implication: standardise behavioural thresholds and audit requirements across all low-code AI platforms.

Threat narrative

Attacker objective: The practical objective is not theft of a single credential but uncontrolled decision influence through an agent whose behaviour cannot be evidenced or reliably challenged.

1. Entry occurs when a business user configures a low-code AI agent and connects it to enterprise systems without a pre-deployment behavioural baseline or formal risk review.
2. Credentialed access and connector permissions then allow the agent to retrieve data and generate responses within its configured scope, even if that scope is broader than intended.
3. Escalation happens when model updates, prompt changes, or source-data changes shift the agent’s behaviour while native controls fail to detect drift or output degradation.
4. Impact is a production agent that appears healthy operationally but produces hallucinated, non-defensible, or non-auditable outputs in regulated workflows.

Breaches seen in the wild

• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Low-code AI governance is now an identity-adjacent control problem, not just an AI policy problem. When business users can deploy agents that act on enterprise data, the question becomes who can authorise the system’s behaviour and who can prove that behaviour stayed within bounds. That moves the issue into governance for human access, workload access, and delegated decision-making. Practitioners should treat low-code AI as a governed runtime, not a convenience feature.

Behavioural evidence is the missing control plane. Access controls tell you who may configure an agent, but they do not tell you what the agent actually did with the data it was given. That gap matters because regulated use cases require traceability at the inference level, not just the deployment level. Teams need evidence that can survive audit, incident review, and model change.

Agent sprawl creates governance debt that is harder to unwind than traditional shadow IT. Once multiple departments have deployed low-code agents, every platform exposes a different log shape, baseline, and review path. That fragmentation makes policy enforcement inconsistent and makes post-hoc reconstruction expensive. The practitioner takeaway is that inventory and policy normalisation must precede scale, not follow it.

Named concept: behavioural traceability gap. This is the failure mode where organisations can see that an AI agent exists and can access data, but cannot reconstruct the input, output, and policy state for each inference. The gap becomes especially dangerous in regulated workflows because absence of evidence looks the same as absence of control.

Framework alignment is pointing toward convergence, not tool-by-tool exceptions. EU AI Act obligations, NIST AI RMF expectations, and AI management system discipline all assume the organisation can classify, monitor, and evidence deployed AI systems. Low-code builders do not remove that burden. Practitioners should align AI governance, audit, and identity controls around one common evidence model.

What this signals

Behavioural traceability gap: low-code AI creates a class of systems that can be deployed quickly but not necessarily evidenced cleanly. The practical risk is that audit teams inherit production agents with no reliable reconstruction of input, output, or policy state, so governance has to move upstream of deployment and downstream of each inference.

For identity and AI governance teams, the near-term priority is to treat low-code builders as part of the control surface. That means harmonising approval, logging, and monitoring expectations across platforms rather than accepting each tool’s native defaults as sufficient.

The article also points to a broader operating shift: if organisations cannot explain what an AI agent did at inference time, they do not really have controllable AI governance, only controllable access to AI creation.

For practitioners

• Define behavioural baselines before deployment Require each low-code AI agent to have a pre-release baseline for groundedness, scope adherence, and approved use cases before it can enter production.
• Centralise inference logging Capture prompt, retrieved context, generated output, policy state, and agent version for every inference so audit evidence can be reconstructed without manual correlation.
• Standardise risk classification across platforms Use one governance taxonomy for Copilot Studio, Agentforce, and similar builders so equivalent agents receive equivalent review, monitoring, and approval treatment.
• Set drift thresholds outside the builder Apply shared thresholds for response quality, grounding, and policy adherence at a governance layer rather than relying on each platform’s native settings.
• Inventory low-code agents as managed systems Track every deployed agent, its owner, data connections, and approval status so shadow deployments cannot accumulate across departments.

Key takeaways

• Low-code AI agents create a governance gap when access controls exist but runtime evidence does not, especially in production workflows that use enterprise data.
• The core weakness is behavioural, because output quality, drift, and traceability can remain outside native platform controls even when deployment looks authorised.
• Practitioners need a common evidence model, shared thresholds, and centralised inference logging if they want low-code AI to remain auditable after scale-up.

Key terms

• Low-Code AI Agent Development: Low-code AI agent development is the creation of AI agents through visual interfaces, prebuilt components, and minimal hand coding. It speeds delivery and broadens participation beyond professional developers, but it also requires stronger oversight because business users can unintentionally expose sensitive data or unsafe actions.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Inference-level audit trail: An inference-level audit trail records the prompt, response, model version, policy action, and downstream system calls for each AI interaction. It is the evidence layer that lets regulated organisations prove what happened at the moment the model or agent acted.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners who need stronger control over delegated and machine-mediated access. It helps identity, security, and governance teams build a common control language for systems that act on behalf of the organisation.