Who is accountable when an AI agent starts a tunnel or modifies sensitive dotfiles without clear user approval?

Why This Matters for Security Teams

An AI agent that can open a tunnel or write to dotfiles is not just "helpful automation"; it is exercising privileged execution paths that can outlive the chat session. That changes the control problem from simple prompt safety to governance, authorisation, and auditability. The practical question is who approved the capability, who can revoke it, and who reviews the resulting change trail against policy and risk tolerance. The OWASP Agentic AI Top 10 treats over-privilege and action abuse as first-order risks because agents that can act can also persist, exfiltrate, or widen access.

Security teams often miss that accountability is split across the software owner, the platform operator, and the business approver. The software owner defines the default capability set. The platform operator enforces guardrails, logging, and revocation. The business approver accepts the operational risk when a workflow is granted. If any one of those roles is vague, the organisation will struggle to explain why a tunnel existed, why a shell profile changed, or why the agent had enough authority to make either action happen. In practice, many security teams encounter these failures only after a suspicious persistence path has already been created, rather than through intentional design.

How It Works in Practice

Clear accountability starts with making agent actions explicit and policy-bound. A tunnel request, a dotfile write, or a secrets read should be treated as a controlled action, not a side effect of a natural-language instruction. Current guidance suggests that the decision point should sit outside the model, in a policy engine or workflow layer that records who approved what, under which context, and for how long. That aligns with the NIST AI Risk Management Framework, which emphasises governance, measurement, and mapped controls rather than trust in model intent.

Operationally, teams should separate the ability to suggest from the ability to execute. A good pattern is:

• require explicit approval for any network egress change, tunnel creation, or port forwarding;
• block direct writes to NIST SP 800-53 Rev 5 Security and Privacy Controls shell profile locations unless a change ticket exists;
• log the prompt, the tool call, the policy decision, and the human approver;
• bind execution to short-lived credentials and revoke them when the workflow ends.

For agentic systems, this is also an NHI problem because the agent often operates with machine credentials, service tokens, or delegated authority that must be governed like any other non-human identity. The right question is not whether the agent "meant" to cause persistence, but whether the system allowed it to do so. These controls tend to break down in developer workstations and CI pipelines because local trust, cached credentials, and broad shell access make approval gates easy to bypass.

Common Variations and Edge Cases

Tighter approval controls often increase friction, requiring organisations to balance developer speed against the risk of unauthorised persistence. That tradeoff is real, especially where agents are used for interactive engineering work and operators expect shell-level convenience. Best practice is evolving, and there is no universal standard for how much autonomy is acceptable in a general-purpose coding environment.

Edge cases usually appear when the agent acts through another tool rather than directly. A model may not "edit a dotfile" itself, but it may instruct an editor, a task runner, or a bootstrap script to do so. The accountability model should still follow the owner of the capability, not the wording of the prompt. The MITRE ATLAS adversarial AI threat matrix is useful here because it helps teams reason about how an attacker or misconfigured workflow can turn agent behaviour into persistence, privilege expansion, or stealthy command execution. Where agent autonomy intersects with enterprise change management, the CSA MAESTRO agentic AI threat modeling framework can help map trust boundaries and tool permissions.

In highly regulated environments, the bar should be higher when tunnels bridge sensitive networks or when dotfiles carry keys, proxies, or environment setup for production access. The practical answer remains consistent: the organisation that enabled the action owns the risk, and the individual approving the workflow owns the decision record. The controls become weakest when agent tooling is installed as a personal productivity aid with no central policy, because then there is no reliable owner for the permission boundary.

Related resources from NHI Mgmt Group

• Who is accountable when an agent performs a sensitive action without adequate approval?
• Who is accountable when an AI agent posts sensitive information or modifies Teams conversations incorrectly?
• Who is accountable when an AI agent reaches a sensitive checkout step and the user completes the final transaction?
• Who is accountable when an AI agent runs a query on behalf of a user?