Accountability usually sits with the organisation that approved the platform, defined the access model, and allowed the workflow to run. Security, IAM, data governance, and application owners all share responsibility for control design and oversight. In practice, teams should define ownership for permissions, logging, policy exceptions, and incident response before broad deployment.
Why This Matters for Security Teams
Enterprise copilots and low-code agents blur the line between assistance and action. Once a workflow can read mail, query data, write records, or call APIs, accountability is no longer just about who clicked approve. It becomes a control question: who defined the permission boundary, who reviewed the data paths, and who can prove the agent stayed inside its mandate? That distinction matters because agentic exposure often looks like ordinary business automation until sensitive data leaves the intended trust zone.
Current guidance suggests treating these systems as governed workloads rather than passive tools. The risk is visible in incidents such as CoPhish OAuth Token Theft via Copilot Studio and the broader patterns in The 52 NHI breaches Report. In practice, many security teams encounter accountability gaps only after a low-code workflow has already exfiltrated data or triggered an unsafe action, rather than through intentional design review.
How It Works in Practice
Accountability should be assigned across the control stack, not left to a single owner after the fact. The organisation that approved the platform is accountable for the risk decision. The team that defined the access model is accountable for least-privilege scoping. The workflow owner is accountable for business intent. Security and IAM are accountable for technical guardrails, while data governance owns classification, retention, and allowed sharing paths.
For copilots and low-code agents, practical governance usually includes:
- Named business ownership for each agent or workflow, with an explicit use case and data domain.
- Policy-as-code checks at runtime, so requests are evaluated against context rather than only static roles.
- JIT access and short-lived tokens for sensitive actions, with automatic revocation after task completion.
- Logging that captures prompt, tool call, data source, decision, and downstream action for auditability.
- Exception handling that requires documented approvals for broad connectors, external sharing, or write permissions.
That approach aligns with the runtime-focused direction described in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a warning sign for copilots that inherit broad delegated access. These controls tend to break down when one workflow spans multiple business domains because ownership, logging, and approval boundaries become fragmented across teams.
Common Variations and Edge Cases
Tighter governance often increases delivery overhead, requiring organisations to balance speed of automation against control depth. That tradeoff is especially visible when business teams want rapid low-code deployment but the data involved is regulated, highly sensitive, or cross-functional. Guidance is evolving, and there is no universal standard for who owns every failure mode yet.
Two edge cases matter most. First, delegated consumer-style copilots inside enterprise tenants can create shared responsibility confusion when platform defaults allow broad connector access. Second, autonomous agents may chain tools in ways no single owner anticipated, so a harmless prompt can become an unsafe sequence of read, transform, and write operations. In those cases, best practice is evolving toward explicit accountability maps, per-workflow approval records, and periodic review of connector scopes rather than one-time onboarding.
For threat modeling, CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix help teams reason about unsafe actions, chained abuse, and model-driven misuse. These controls are strongest where the agent’s scope is narrow and well-instrumented, and they break down in highly connected environments with unmanaged connectors and weak data classification.
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 | A01 | Covers unsafe agent actions and excessive tool access in copilot workflows. |
| CSA MAESTRO | A3 | Addresses threat modeling and control ownership for agentic systems. |
| NIST AI RMF | GOVERN | Accountability for AI outcomes is a core governance requirement. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials and rotation reduce blast radius for delegated access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to limiting copilot and agent misuse. |
Assign accountable owners, decision rights, and escalation paths for every copilot or low-code agent.
Related resources from NHI Mgmt Group
- Who is accountable for secure authorization when AI agents and MCP servers start accessing enterprise data?
- Who should be accountable for securing low-code AI projects and copilots?
- Who is accountable when a low-code app exposes sensitive data through weak authentication?
- Who is accountable when AI agents expose sensitive data through Jira MCP, and what controls should be in place?
