Who is accountable when an autonomous worker changes access or gathers evidence incorrectly?

Accountability sits with the organisation that granted the permissions and defined the control plane, not with the agent as a separate operator. The practical test is whether policy, logging, and approval boundaries were designed to constrain software that can complete work without handoff.

Why This Matters for Security Teams

When an autonomous worker changes access or gathers evidence incorrectly, the failure is usually not “the agent made a bad choice” so much as the control plane allowed an untrusted workflow to act with too much authority. Accountability therefore stays with the organisation that designed the permissions, logging, and approval path. That is the same pattern behind the high prevalence of NHI misuse described in the Ultimate Guide to NHIs, where excessive privilege and weak rotation create persistent exposure.

For autonomous workers, the real risk is that a single task can chain tools, read evidence, modify access, and leave only partial telemetry behind. Current guidance from NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points to governance, traceability, and bounded authority as the practical answer, not after-the-fact blame. In practice, many security teams discover the accountable owner only after an agent has already changed production access or collected evidence outside the intended scope.

How It Works in Practice

Accountability should be assigned to the organisation that approved the agent’s scope, not to the software entity itself. That means the business owner, control owner, and platform team must define what the worker can do, when it can do it, and how every action is recorded. For autonomous systems, static role assignments are often too blunt because the agent’s behaviour is goal-driven and context-sensitive rather than fixed.

Practical governance usually combines four controls:

• Intent-based authorisation, where a request is approved based on the task being attempted, not just the identity presenting a token.
• Just-in-time access, so the agent receives short-lived rights only for the current task and loses them automatically after completion.
• Workload identity, so the system proves what the agent is through cryptographic identity, rather than relying on a long-lived shared secret.
• Real-time policy evaluation, so policy-as-code can decide at request time whether the action matches the declared scope and evidence-handling rules.

That operating model aligns with the patterns discussed in CSA MAESTRO agentic AI threat modeling framework and the agentic risk framing in OWASP NHI Top 10. If the agent is allowed to gather evidence, the organisation must also define what counts as evidence, where it may be stored, and who can approve downstream access changes. These controls tend to break down when the agent is embedded in legacy admin tooling because the tooling cannot express task-scoped approvals or short-lived privilege.

Common Variations and Edge Cases

Tighter control over autonomous workers often increases operational overhead, requiring organisations to balance speed against traceability. That tradeoff becomes visible when security teams want fast remediation but also need provable boundaries for access changes and evidence collection.

There is no universal standard for this yet, so best practice is evolving. Some organisations treat the agent as a privileged workload and route every sensitive action through a human approver. Others use policy engines to allow low-risk actions automatically while forcing step-up approval for access grants, exports, or evidence capture. The right answer depends on blast radius, regulatory exposure, and how much the agent can infer from surrounding context.

One useful rule is to separate the agent’s execution authority from its decision authority. If the worker can recommend a change but not apply it directly, accountability is easier to enforce. If it can both decide and execute, then logs, approvals, and rollback controls must be stronger. The NHI pattern remains the same: short-lived credentials, visible ownership, and revocation on completion, reinforced by the operational lessons in 52 NHI Breaches Analysis and the risk signals in AI LLM hijack breach. When agents operate across multiple tools with partial observability, accountability becomes shared across control owners, but the organisation still owns the outcome.

Related resources from NHI Mgmt Group

• Who is accountable when an autonomous corporate actor changes infrastructure or access?
• Who is accountable when multi-cloud access reviews miss excessive permissions?
• Who is accountable when unnecessary access remains in place?
• Who is accountable when compliance evidence is incomplete during market entry?