Who is accountable when an AI agent acts on instructions from a third-party skill update?

Why This Matters for Security Teams

A third-party skill update can change what an AI agent is allowed to do without changing the business owner’s intent. That creates a familiar but easily missed accountability problem: the risk is not only in the content of the update, but in the persistent trust path that lets mutable instructions execute. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to governance, traceability, and human oversight as core obligations when AI systems can act autonomously.

For security teams, the practical issue is that agent behaviour often spans product, platform, identity, and vendor boundaries. If a third party can update a skill, prompt, policy file, or tool description, the organisation must already know who approves that change, how it is validated, and who can disable it. That is especially important where the agent can reach secrets, internal APIs, or privileged workflows, because the skill update may become an indirect control plane for access.

In practice, many security teams encounter the accountability gap only after an unexpected action has already been authorised through a trusted update path, rather than through intentional design of that trust boundary.

How It Works in Practice

Accountability is usually shared, but not equally. The organisation that deploys and operates the agent remains accountable for the risk it accepts, even when a third party supplies the update. The skill publisher may be responsible for the quality of the instruction set, but the operator is responsible for whether the instruction set is allowed to execute in the first place. This is the same logic that underpins identity governance: delegated authority does not remove the duty to define, constrain, and review that authority.

Operationally, security teams should treat the update channel as a governed trust path. That means deciding whether the update is signed, reviewed, sandboxed, or blocked entirely; whether changes require approval before activation; and whether the agent is allowed to inherit privileges from the caller, the platform, or a machine identity. Where the agent can invoke tools, the question becomes one of non-human identity governance as much as AI governance, which is why the OWASP Non-Human Identity Top 10 is relevant alongside AI controls.

• Define who can approve a mutable skill update and who can revoke it.
• Require provenance checks for the source, version, and signing status of the update.
• Separate the ability to publish a skill from the ability to enable it in production.
• Limit the agent’s tool access so a malicious or erroneous update cannot expand privilege silently.
• Log the update event, the approver, the active identity, and the actions taken after activation.

That control set maps well to baseline security expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where change control, access enforcement, and auditability are concerned. These controls tend to break down when updates are pulled dynamically into production agents that can execute tools before human review is possible.

Common Variations and Edge Cases

Tighter approval and validation often increases operational overhead, requiring organisations to balance speed of skill iteration against the risk of unauthorised instruction changes. That tradeoff becomes sharper when the skill update is meant to support customer-facing automation, rapid product experimentation, or delegated operations across many tenants.

There is no universal standard for this yet, so current guidance suggests using risk tiering rather than a single approval model. Low-risk skills may be allowed with pre-approved templates and monitoring, while high-risk updates that can trigger payments, data movement, credential use, or administrative actions should require explicit review. The most sensitive cases are those where a skill update can alter the agent’s access path without changing the underlying system owner, because that can make accountability ambiguous even when logging exists.

For threat modelling, the relevant concern is not only whether the update was malicious, but whether it was trusted too broadly. The MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework both support this view by focusing attention on attack paths, trust relationships, and control bypass. Where third-party skills can access secrets, tickets, code, or operational tooling, organisations should also review whether those skills are effectively acting as non-human identities with standing authority.

That is the point where governance fails in the real world: the update is treated as content, while it is actually a control decision about who may act through the agent.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent acts outside its intended scope?
• Who is accountable when an AI agent installs a malicious skill?
• Who is accountable when an AI agent acts after the user is offline?
• Who is accountable when sensitive data is retained in a third-party AI tool?