The instinct when a new artifact type appears is to reach for a new framework. In practice, most of what an auditor or a board will ask about AI artifacts maps onto controls your organisation already operates. The gap is usually not that the control is missing. It's that the control's scope was written before agent skills, MCP servers, and rules files existed, and nobody has revisited the wording since.

Third-party risk

Every mature program has a process for evaluating third-party code before it enters the environment. Agent skills are third-party code with an unusual delivery path: installed directly by a developer, often from an open marketplace, frequently without passing through procurement or any review gate at all.

The question worth asking internally is whether your existing third-party risk language actually covers an artifact a developer installs in thirty seconds from a public registry. In most cases the intent covers it and the wording doesn't, which is a documentation problem rather than a control-design problem, and considerably cheaper to fix.

Change management

Change management typically assumes that once something is reviewed and approved, it stays approved until someone deliberately changes it. Agent skills break that assumption. A skill can pass review and later behave differently because a remote MCP server changed its response or an upstream dependency updated silently, with no change event inside your organisation to trigger a re-review.

This is the single most common place where an existing control is technically satisfied and practically insufficient. Closing it usually means adding two things: hashing tool descriptions and dependency references at approval time, and treating any subsequent change as an event that invalidates the approval.

Most of the work here is scoping language, not new controls. The failure mode is an auditor accepting a control as satisfied because the artifact type was never named in it.

Access control

Agent skills execute with the permissions of whoever or whatever runs them, which in practice means a developer's local credentials or a service account in CI. Your access control policy almost certainly has something to say about what those identities may reach. What it likely doesn't say is that an autonomous, third-party artifact may act with them.

The practical translation is scoping: short-lived credentials, per-tool permission restriction, and an explicit position on whether agent skills may run in environments holding production credentials at all.

What to actually write down

Three additions cover most of the gap without inventing a new framework.

1. Name AI artifacts explicitly in the scope of third-party risk.

2. Define what constitutes a change requiring re-review, including upstream changes your organisation didn't initiate.

3. State which environments and identities these artifacts may execute under.

That's a scoping exercise measured in paragraphs, not a control framework measured in quarters.

FAQ

Do we need a separate AI-specific policy document? Usually not at first. Extending the scope of existing third-party risk, change management, and access control language covers most of the exposure and is far more likely to be maintained than a standalone document nobody revisits.

What will an auditor most likely ask about? In our experience the question that lands hardest is whether you can produce an inventory of AI artifacts running in your environment, in the same way you can for code dependencies. That's an evidence question, and it's difficult to answer well retroactively.

How does this relate to the frameworks specific to AI risk? They're complementary. Frameworks built for AI risk help you reason about model behaviour and system-level harms. The controls above are about the supply chain the artifacts arrive through, which is a distinct and more immediate exposure.

Related reading: "No CVE. No Hash. No IOC. Why AI Artifacts Break Vulnerability Management," "Trust Tiers: A Governance Framework for Agent Skill Allowlisting"