Who is accountable when a malicious agent skill causes data loss?

Why This Matters for Security Teams

When a malicious agent skill causes data loss, the failure is rarely the skill alone. The real issue is that the organisation trusted an autonomous tool chain to act inside an identity boundary that was too broad, too long-lived, or too hard to revoke. That creates a governance gap between endpoint control, identity governance, and security operations, which is exactly where accountability gets blurred.

This is not a theoretical edge case. Agentic systems can install tools, chain actions, and move from “helpful automation” to destructive execution faster than human review cycles can keep up. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same practical problem: trust without runtime control is not a control. In NHI Mgmt Group’s Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

In practice, many security teams discover accountability only after the agent has already deleted, exfiltrated, or overwritten data, rather than through intentional approval and revocation governance.

How It Works in Practice

Accountability should be assigned to the organisation function that allowed the skill to execute under trusted authority, not to the skill itself. In practice, that means the business owner of the agent, the platform team that enabled execution, and the security function that defined guardrails all share responsibility for prevention, approval, monitoring, and revocation. For autonomous systems, static role-based access is often too blunt because the agent’s next action may not be knowable at design time.

The operational pattern is shifting toward runtime controls. That includes intent-based authorisation, policy-as-code, and just-in-time credentialing so the agent gets only the minimum access needed for the specific task, then loses it automatically. Workload identity is the identity primitive here: cryptographic proof of what the agent is, combined with context about what it is trying to do. Standards and research such as CSA MAESTRO agentic AI threat modeling framework, OWASP Top 10 for Agentic Applications 2026, and MITRE ATLAS adversarial AI threat matrix all reinforce that autonomous behaviour must be governed at request time, not only at onboarding.

• Define a named owner for each agent skill, including approval and revocation authority.
• Issue short-lived credentials per task, not long-lived secrets embedded in workflows.
• Evaluate policy at runtime, with context such as data sensitivity, destination, and action type.
• Log tool use, file access, and privileged operations in a way that supports after-action review.
• Revoke access automatically when the task completes or when behaviour deviates from policy.

These controls tend to break down in loosely governed plugin ecosystems because install, update, and execution paths are often owned by different teams with no single revocation point.

Common Variations and Edge Cases

Tighter skill control often increases operational overhead, requiring organisations to balance faster automation against stronger review, testing, and rollback discipline. There is no universal standard for this yet, especially where agent skills are user-installed, marketplace-supplied, or delegated across teams.

One common edge case is shared accountability in platform models. If a central team publishes the agent runtime but a product team installs the skill, both may have partial responsibility, yet only one may have practical revocation power. Another is third-party or contractor-built skills, where supply chain ownership can become unclear. In those cases, the better question is not “who wrote the skill?” but “who had the authority to let it run, and who could have stopped it?”

For environment-specific risk patterns, Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio show how agent trust can be abused when token scope, consent, and revocation are weak. The practical takeaway is that accountability must be written into the control plane before the skill is approved, because post-incident blame is not a compensating control.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent installs a malicious skill?
• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who is accountable when a malicious MCP tool exfiltrates data through an agent?
• What should teams do when an agent can access sensitive tools or data?