Accountability should sit with the software owner and the platform operator, because they decide what the agent may do by default. Teams need explicit approval workflows for tunnel creation, credential access, and writes to shell profile files. If those controls are missing, the organisation has accepted an execution path that can convert a coding assistant into a persistence mechanism.
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.
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, MITRE ATLAS 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 | Agent tool abuse and over-privilege directly map to this question. |
| NIST AI RMF | GOVERN | Accountability for agent actions depends on governance, roles, and oversight. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when agents can open tunnels or modify files. |
| MITRE ATLAS | ATLAS helps model how malicious or faulty agents create persistence and misuse tools. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Agents often act through machine identities and delegated credentials. |
Restrict tool execution and require approval for any action that changes access or persistence.
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?
