Accountability should sit with the security and identity governance functions, with clear ownership from application teams for what they build and connect. Security leaders need to define acceptable use, access policy, monitoring, and escalation paths. Business owners should not be left to self-assess risk without central controls, because AI copilots can move data and trigger actions at scale.
Why This Matters for Security Teams
Low-code AI projects and copilots often look like business productivity initiatives, but they create security obligations that are closer to privileged automation than ordinary app development. The risk is not just model output quality. It is data movement, token reuse, connector sprawl, and action execution across systems that were never designed for unsupervised software. NIST SP 800-53 Rev. 5 Security and Privacy Controls treats access control, audit, and system integrity as foundational, and that same logic applies when a copilot can read mailboxes, update records, or trigger workflows. In NHIMG research, the State of Secrets in AppSec shows how fast secrets risk becomes operational, with an average 27-day remediation window for leaked secrets. That gap is too long for AI-enabled automation. In practice, many security teams encounter misuse only after a copilot has already connected to sensitive systems or exposed tokens through a workflow that appeared harmless at design time.
How It Works in Practice
Accountability should be split by control plane, not by optimism. Security and identity governance own the policy framework, review requirements, logging, and escalation. Application teams own the specific low-code app, connector configuration, prompts, and data flows they introduce. Business owners approve the use case and the data the copilot may touch, but they should not be the final line of defence for privileged access. That division matters because copilots inherit identity from users, service accounts, or delegated OAuth grants, then act at machine speed.
A workable model usually includes:
- central approval for connectors, scopes, and high-risk actions
- just-in-time access for privileged tasks instead of standing entitlements
- workload identity and strong token hygiene for every automation path
- policy-as-code checks at request time, not just at project intake
- continuous logging of prompts, actions, and secret access events
For identity and access design, NIST SP 800-53 Rev. 5 Security and Privacy Controls remains the clearest baseline for accountability, and NHIMG research such as CoPhish OAuth Token Theft via Copilot Studio shows why OAuth delegation and token theft must be treated as first-class risks, not edge cases. The practical lesson is that a copilot should never inherit broader authority than the task requires, and approvals must be revocable at the same speed that the automation executes. These controls tend to break down when citizen developers can publish connectors directly into production because the organisation loses visibility before the first risky token is issued.
Common Variations and Edge Cases
Tighter governance often increases delivery friction, so organisations have to balance speed against the cost of review and logging. That tradeoff is especially visible in sandboxes, departmental copilots, and internal automation pilots, where teams want rapid experimentation but still need guardrails. Best practice is evolving, but current guidance suggests that experimental environments can tolerate broader access only if they are tightly segmented from production data and cannot reuse privileged tokens.
A few edge cases matter:
- if a copilot is read-only, accountability still includes data classification and egress controls
- if a low-code flow can send email, post to chat, or update CRM records, it should be treated as an action-capable workload
- if connectors bridge SaaS and on-prem systems, identity governance must cover both sides of the trust boundary
- if a business unit funds the project, that does not transfer security ownership away from central functions
The same caution applies to incidents involving exposed credentials, as seen in NHIMG coverage of the Schneider Electric credentials breach. In high-risk environments, the accountable model should be explicit: security defines the control requirements, application teams implement them, and business owners accept the residual risk only after those controls are verified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers agent misuse of tools and delegated actions in copilots. |
| CSA MAESTRO | M1 | Addresses governance for agentic systems and shared accountability. |
| NIST AI RMF | Defines governance and accountability expectations for AI risk management. | |
| NIST CSF 2.0 | PR.AA-01 | Identity and access accountability is central to secure copilot deployment. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret handling and credential governance for low-code automation. |
Limit tool scopes, log every action, and require runtime checks before a copilot can execute.
Related resources from NHI Mgmt Group
- Who is accountable for securing AI workflows when access spans multiple teams and platforms?
- Who is accountable when AI spend grows faster than revenue and there is no finance-grade metering?
- Who is accountable for secure authorization when AI agents and MCP servers start accessing enterprise data?
- Who should be accountable for moving identity security from tactical projects to a business programme?
