Who is accountable when a poisoned agent skill steals credentials or changes memory?

Who Owns the Full Blast Radius When a Skill Is Poisoned?

Accountability belongs with the function that can govern the entire path from publishing the skill to granting it runtime authority and cleaning up after compromise. If one team approves registry content, another grants permissions, and a third handles recovery, the risk is split across handoffs and no one is truly accountable for the outcome.

That is why this question is not just about authorship of the skill itself. A poisoned skill becomes dangerous when it can inherit trust, reach credentials, or persist changes in memory, so ownership has to follow the control point that can constrain all three.

When agent skill are treated as governed extensions of the agent runtime, the right owner is usually the platform or security function that can coordinate registration rules, permission boundaries, and rollback. The developers who wrote the skill still own code quality, but they do not own the full operational risk unless they also control approval, access, and recovery.

Why Registry Governance, Permission Design, and Recovery Must Be One Accountability Chain

A skill registry is not just a catalogue. It is a trust boundary, because approval decisions determine which capabilities can enter the environment and which dependencies they can inherit. If the registry says a skill is approved but the permission model is vague, the approval is incomplete even if the code looks safe.

Permission design is the second half of that same decision. Skills that can read secrets, call tools, or write memory need explicit limits on scope, duration, and context, otherwise the person approving the skill cannot honestly claim to control its blast radius. The relevant principle is least privilege applied to the skill, not just to the human reviewer.

Recovery closes the loop. If a poisoned skill can steal credentials or alter memory, the accountable owner must be able to revoke access, invalidate the compromised path, and verify that the malicious state is gone. Without that authority, the organisation has governance in name only, because it cannot complete the response.

Why Splitting Approval, Runtime Access, and Persistence Creates Gaps

Poisoned skills often exploit boundary confusion. A reviewer may approve the skill package, a separate platform team may allow execution, and an operations team may assume memory or token hygiene is someone else’s problem. That division makes it easy for each group to believe the control failed elsewhere.

The practical failure mode is simple: the skill is safe at review time, but unsafe once it is chained to live credentials or retained context. If runtime access and persistence are managed separately, the organisation can end up with an authorised skill that still has enough reach to exfiltrate secrets or leave malicious state behind.

This is why accountability should be assigned to the team that can govern the whole chain, not a narrow slice of it. Ownership should track the control plane, because that is the only place where approval, privilege, and recovery can be made consistent.

What a Real Ownership Model Looks Like in Practice

Good ownership uses a single accountable team with cross-functional inputs, not a committee that diffuses blame. That team should define which skills may be registered, what permissions they may inherit, how memory changes are reviewed or reset, and what the incident path looks like if a skill behaves maliciously.

When choosing that owner, ask one question: who can actually prevent the harmful sequence, not just document it after the fact? If the answer cannot revoke access, bound tool use, and restore a clean state, it is not the right owner for accountability.

As skills scale across many agents or environments, the ownership model matters more, not less. A local exception may be survivable, but repeated exceptions quickly turn into an unmanaged trust layer that can be abused at scale.

Risk and Threat Considerations

Poisoned agent skills create a combined access and persistence risk. If the skill can obtain credentials, it may move beyond a single task and into downstream systems; if it can rewrite memory, it may alter future decisions long after the original invocation is over.

Failure mechanism: Responsibility is split across registry approval, permission assignment, and recovery, so no single team can stop the attack path end to end. That gap lets a malicious skill inherit trust, abuse granted authority, and leave persistent state that survives the initial review.

Impact: The organisation can lose both confidentiality and control, because stolen credentials enable broader access while poisoned memory can distort later agent behaviour and incident analysis. Recovery also becomes slower and less reliable when no one owns revocation, cleanup, and post-incident verification together.

Practitioner Guidance

What to prioritise: Assign one accountable owner for registry governance, permission policy, and incident recovery before expanding the skill catalogue. If those controls live in different teams, require an explicit operating model that names who can deny publication, who can constrain runtime access, and who can force cleanup.

What to verify: The owner should be able to show that approved skills cannot silently gain broader access through inheritance, reuse, or memory persistence. If a team cannot explain how it would revoke access and restore trust after compromise, it does not yet own the risk.

Practitioner takeaway: Accountability should follow the control of the blast radius, not the authorship of the code. In poisoned-skill scenarios, the right owner is the team that can govern approval, privilege, and recovery as one linked security decision.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent exposes credentials or changes identity state?
• Who is accountable when a poisoned dependency steals cloud and GitLab credentials?
• Who is accountable when a poisoned extension steals publishing or cloud credentials?
• Why is single-provider AI agent governance not enough for enterprise security?