Who is accountable when a malicious skill exfiltrates code or credentials?

Why This Matters for Security Teams

When a malicious skill exfiltrates code or credentials, the failure is rarely just technical. It usually exposes a governance gap: who approved the skill, who allowed it to reach secrets, and who owned the workflow it lived in. That matters because agentic systems can act quickly, chain tools, and move data faster than human review cycles. OWASP’s Non-Human Identity Top 10 and NHIMG’s research on the Secret Sprawl Challenge both point to the same operational truth: unmanaged access paths turn ordinary workflow additions into incident paths.

Accountability also sits in the gap between static approvals and dynamic execution. A skill may be signed off as “safe” at deployment time, then later consume a token, read a repository, or call a downstream tool in a way nobody explicitly tested. In practice, many security teams encounter this only after code or secrets have already left the environment, rather than through intentional pre-deployment review.

How It Works in Practice

Operational accountability should be assigned on three layers: the approving organisation, the workflow owner, and the team that granted the agent its reachable tools. That structure matters because a malicious skill does not need broad access to cause damage. It only needs one path to a secret store, a repo, a build step, or a chat integration.

In mature environments, the control model is shifting from one-time permissioning to runtime governance. Current guidance suggests treating the skill as a workload with its own identity, not as a human user wearing automation clothing. That means using workload identity, short-lived secrets, and context-aware authorisation so the agent is only allowed to act within the specific task boundary. For runtime decisions, policy-as-code is the practical mechanism, evaluated at request time rather than as a static RBAC rule. NIST’s Digital Identity Guidelines remain useful for identity assurance concepts, but they do not by themselves solve autonomous tool use.

• Approve skills only with named business and technical owners.
• Issue ephemeral credentials per task, not shared long-lived secrets.
• Log which tool, repository, or vault path the skill can reach.
• Revoke access automatically when the task ends or the skill deviates.

NHIMG’s Ultimate Guide to NHIs - Static vs Dynamic Secrets reinforces the practical difference between enduring credentials and time-bound access: the shorter the credential lifetime, the smaller the blast radius when a skill turns malicious. These controls tend to break down when skills are embedded inside CI/CD pipelines with broad inherited permissions because the workflow itself becomes the privilege boundary.

Common Variations and Edge Cases

Tighter approval and revocation controls often increase operational overhead, requiring organisations to balance speed of deployment against traceability and blast-radius reduction. That tradeoff becomes sharper when teams use third-party skill marketplaces, shared agent frameworks, or self-modifying automation. In those cases, “who approved it?” is not always the same as “who can prove what it did.”

There is no universal standard for this yet, but current best practice is evolving toward explicit ownership records, per-skill risk reviews, and runtime containment for every tool the skill can touch. The hardest edge case is a skill introduced through a trusted workflow that later inherits more privilege than intended. NHIMG’s coverage of supply-chain style exposure, including the CI/CD pipeline exploitation case study, shows why approvals must include downstream tool reach, not just the original prompt or plugin.

For organisations comparing control models, the practical question is not whether the skill is “allowed” in the abstract. It is whether the approval record, secret scope, and revocation path are precise enough to survive a real incident. When they are not, accountability becomes shared by default, but incident response still needs a single named owner.

Related resources from NHI Mgmt Group

• Who is accountable for revoking machine credentials after an acquisition closes?
• Who is accountable when stolen credentials are used to drain customer accounts?
• Who is accountable when an AI agent moves from low privilege to financial credentials?
• Who is accountable when stolen pipeline credentials are used across cloud systems?