Who is accountable when an AI agent makes a change through an enterprise connector?

Accountability stays with the authenticated human and the organisation’s existing controls. The agent acts under the user’s dashboard permissions, so access decisions, approval limits, and audit review remain the organisation’s responsibility. If a change is irreversible or production bound, teams should require explicit confirmation, logged action trails, and tight environment governance.

Why This Matters for Security Teams

When an AI agent changes data or configuration through an enterprise connector, accountability does not move to the model. It stays with the authenticated human, the owning team, and the organisation’s control environment. That distinction matters because agentic systems can act faster, combine tools, and reach further than a person would normally be allowed to do manually. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework treats this as an operational governance problem, not a philosophical one.

The practical risk is that enterprise connectors often inherit broad permissions from dashboards, service accounts, or delegated tokens, then execute changes with weak separation between request, approval, and execution. That makes the human operator the accountable party for intent, while the organisation remains responsible for access design, logging, approvals, and environment guardrails. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already acted beyond intended scope, which shows how quickly governance gaps become real incidents. In practice, many security teams discover this only after a connector has already changed production data, rather than through deliberate control testing.

How It Works in Practice

Accountability should be mapped to the control path, not to the software artefact. If a person authorises an AI agent to use a connector, that person remains accountable for the decision to initiate the action. The organisation remains accountable for whether the connector had appropriate entitlements, whether the agent was constrained by policy, and whether the resulting action was logged and reviewable. This is why enterprise teams are moving toward policy-as-code, approval workflows, and auditable execution boundaries, as reflected in CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix.

In mature environments, the workflow usually looks like this:

• The human authenticates to the enterprise application and explicitly requests the agent action.
• The agent inherits only the minimum connector scope needed for that task.
• Policy checks evaluate the request at runtime, including environment, data sensitivity, and change impact.
• High-risk actions require step-up approval or separate confirmation before execution.
• Every connector call is logged with the user, agent, target system, and outcome.

That model works best when the connector is tied to a defined business process, such as ticket updates or non-production data operations. It becomes much harder when the agent can chain multiple tools, trigger downstream automations, or act through long-lived delegated tokens, because attribution becomes less about one action and more about a sequence of decisions. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio and Replit AI Tool Database Deletion illustrate how quickly delegated access and tool execution can cross from assistance into uncontrolled change. These controls tend to break down when the connector has production write access and the approval chain is detached from the actual execution event because audit trails no longer prove who understood the full impact.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance faster agent execution against stronger change governance. That tradeoff is most visible when an agent is used for customer-facing work, incident response, or software delivery, where speed matters but mistakes are expensive. Current guidance suggests that irreversible or production-bound actions should not rely on default dashboard permissions alone; they should use explicit confirmation, time-bound authorisation, and environment-specific policy checks.

There is no universal standard for every edge case yet. For example, read-only retrieval through a connector may justify lighter oversight than a write action, but even read paths can leak sensitive context or trigger unsafe follow-on behaviour if the agent can chain outputs into other tools. Likewise, a human may remain accountable for an action they approved, but the organisation still carries responsibility if access reviews, segregation of duties, or logging were inadequate. The best-practice answer is evolving, but the direction is consistent across the NIST AI Risk Management Framework and NHIMG’s OWASP NHI Top 10: treat agent actions as governed business operations, not autonomous exceptions to accountability. The hardest cases are multi-agent workflows, where responsibility can be clear for the initiating user but blurred across several automated hops unless each step is separately authorised and traced.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who is accountable when an AI agent makes the wrong change?
• Who is accountable when an AI agent makes an unauthorised change?
• What makes agentic AI an NHI governance issue?