Family Guides
AWOSS-SRC: Skill, Tool, And Connector Source Trust
Reusable agent components deserve the same kind of scrutiny teams already give to code, packages, and infrastructure dependencies. AWOSS-SRC makes the source, version, permission profile, dependencies, and update path visible.
That includes skills, tools, connectors, plugins, prompt packs, model components, scripts, packages, integrations, and supplier-provided components. For each one, reviewers need to know who made it, which version is approved, what it can do, and what happens when it changes or becomes unsafe.
A workflow that looked reviewed yesterday can drift quickly. A connector may change its permission model, a tool may start making hidden external calls, a package dependency may move, a prompt pack may introduce unsafe instructions, or a supplier component may become unsupported. Source-trust evidence keeps those action units visible, reviewed, versioned, and removable.
What This Family Covers
In scope:
- Skills, tools, connectors, plugins, prompts, scripts, models, packages, integrations, supplier-provided components, remote sources, and other reusable action units that agents can invoke, install, load, update, or trust.
- Source, maintainer, publisher, supplier, repository, version, commit, package identifier, checksum, signature, attestation, or equivalent origin information where available.
- Declared and observed permissions, sensitive capabilities, high-impact actions, protected-context access, workspace-state changes, external system calls, and dependency-chain expansion.
- Review before introducing or updating trusted reusable action units that can affect production systems, credentials, sensitive data, external communications, code execution, or workspace boundaries.
- Provenance records for approved reusable action units, including review status, declared permissions, known high-impact capabilities, dependency state, update channel, and retirement path where applicable.
- Drift between approved versions, manifests, metadata, dependencies, permission declarations, and what is actually available to agents at runtime.
- Stronger integrity controls for high-impact reusable action units, including pinned commits, lockfiles, checksums, signatures, attestations, controlled release channels, or independent source review where practical.
- Review or testing for unsafe capabilities, ambiguous permissions, prompt-injection exposure, hidden external calls, dangerous default behavior, malicious-tool patterns, and dependency risks.
- Rollback or retirement paths for trusted reusable action units that become compromised, unsafe, unsupported, unexpectedly changed, or inconsistent with the approved boundary.
Out of scope:
- Deciding which systems, resources, data sources, and workflows belong in the scoped system. That belongs mostly to
AWOSS-SCP. - Enforcing runtime allow, deny, approval, interruption, rollback, or budget decisions for individual actions. That belongs mostly to
AWOSS-RUN. - Filesystem, repository, browser, sandbox, network, and endpoint boundaries. Those belong mostly to
AWOSS-WSB. - Prompt, memory, retrieval, tool-output, and instruction-source boundaries. Those belong mostly to
AWOSS-CTX, though reusable action units may introduce context risks. - Secret, credential, and sensitive-data handling by itself. That belongs mostly to
AWOSS-SEC, though source trust should identify action units that request sensitive access. - Complete log-retention and traceability design. That belongs mostly to
AWOSS-LOG, though source approvals and update receipts should be retained. - Full supplier assurance, vulnerability management, legal due diligence, or external certification of vendors.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization knows which reusable action units agents can use, where those units came from, and what sensitive or high-impact capabilities they may request. | Source trust cannot be reviewed until the reusable pieces, origins, permissions, and dependency signals are visible. | Action-unit inventory, source register, publisher or maintainer records, permission declarations, dependency manifest. |
| Level 2 | Production use requires review before high-impact introduction or update, keeps provenance records, and checks whether runtime versions drift from approved versions. | Production agent activity needs repeatable approval and provenance, not only a list of tools or connectors. | Introduction or update review, approved provenance record, version or commit record, update receipt, drift comparison. |
| Level 3 | High-impact reusable action units use stronger integrity controls, receive deeper safety review or testing, and have rollback or retirement paths. | High-impact environments need evidence that important components are difficult to swap silently, reviewed for unsafe behavior, and removable when trust changes. | Lockfile, checksum, signature, attestation, independent source review, malicious-tool test, rollback or retirement exercise. |
Candidate Source-Trust Profile Language
Current registries, marketplaces, connector directories, package repositories, remote MCP servers, local skill folders, and supplier channels expose useful source-trust signals, but those signals are uneven. A reviewed directory listing, namespace check, tool annotation, OAuth scope, package version, or hash can help with evidence, but none of those signals by itself proves that a trusted action unit is safe for the whole scoped workspace.
For AWOSS-SRC, a practical source-trust profile is a local evidence packet that joins external source signals with organization-controlled review records. It should be treated as support for review, not as certification or marketplace endorsement.
Useful fields include:
- Action-unit identifier, type, source ecosystem, runtime availability, owner, and intended scoped use.
- Publisher, namespace, domain, repository, supplier, package, remote endpoint, bundle artifact, registry listing, and review or verification status.
- Version, published timestamp, retrieval timestamp, latest-known status, manifest or descriptor reference, hash, signature, signer, attestation, or checksum where available.
- Declared tools, tool schemas, read-only, write, destructive, open-world, sensitive-data, protected-context, external-call, OAuth-scope, token-class, and dependency signals where available.
- Local reviewer, review date, approval decision, target assurance level, approved runtime scope, claim limits, exception status, and reassessment owner.
- Update history, approved versus observed version, manifest/schema/permission drift, review expiration, retirement status, rollback or emergency-disable path, and validation or governance trigger.
The important design point is the join: registry metadata, marketplace review, tool annotations, package hashes, and app permissions should be connected to the local approval and runtime state that the organization actually relies on.
Candidate Controls
AWOSS-SRC-L1-001: Reusable Action-Unit Inventory Level 1
Requirement summary
Inventory the skills, tools, connectors, plugins, prompts, scripts, models, integrations, and other reusable action units that agents can invoke, install, load, or trust.
Why it exists
Agents do not act only through the model. They act through reusable units that may read files, call systems, run code, fetch context, send data, change records, or influence decisions. A business cannot review source risk if it does not know which reusable action units are available.
Why this level
This belongs at Level 1 because visibility is the foundation. The inventory does not prove the action units are safe; it gives reviewers the list they need before origin records, approval gates, drift checks, and source reviews can be meaningful.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Reusable action-unit inventory | Runtime platform owner or skill-set source owner | Before production use and after adding or removing action units | Skills, tools, connectors, plugins, prompts, scripts, models, packages, integrations, and remote sources available to agents | Identifies available units; does not prove their source, safety, or runtime enforcement. |
| Runtime tool and connector export | Runtime platform owner | Before review and after runtime configuration changes | Tool names, connector names, enabled state, version or package reference where available, and runtime availability | Shows what the runtime exposes; does not prove every hidden dependency or supplier component is listed. |
| Component owner map | Organization or governance owner with source owner input | Before production use and after ownership changes | Owner or maintainer role for each trusted action unit or action-unit group | Supports accountability; does not prove technical control or supplier reliability. |
AWOSS-SRC-L1-002: Origin Information Record Level 1
Requirement summary
Record the source, maintainer, publisher, supplier, repository, version, commit, package identifier, checksum, signature, or equivalent origin information for trusted reusable action units where available.
Why it exists
A name alone is not enough. Reviewers need to know whether the action unit came from an internal repository, a supplier, a public package registry, a browser extension, a remote connector marketplace, a copied script, or an unmanaged local folder. Origin records also help later update review, compromise response, and claim limits.
Why this level
This belongs at Level 1 because origin information is basic source-trust evidence. The requirement is intentionally flexible because not every source provides signatures, checksums, attestations, or package metadata.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Source register | Skill-set source owner or runtime platform owner | Before trust is granted and after source changes | Source URL or location, repository, maintainer, publisher, supplier, package identifier, version, commit, checksum, signature, or equivalent origin data where available | Supports origin review; does not prove the source is benign or uncompromised. |
| Publisher, supplier, or maintainer record | Organization or governance owner with procurement or source owner input | Before enabling supplier or third-party components and during periodic review | Supplier name, maintainer role, support status, contact path, trust basis, and review date where applicable | Supports due-diligence review; does not prove legal compliance or supplier security. |
| Version, commit, checksum, or signature record | Skill-set source owner | Before production use and after approved updates | The specific version, commit, package release, checksum, signature, or equivalent identifier that was reviewed | Identifies reviewed material; does not prove dependency integrity unless dependency state is also reviewed. |
AWOSS-SRC-L1-003: Capability And Dependency Signal Classification Level 1
Requirement summary
Identify whether reusable action units can perform high-impact actions, request sensitive capabilities, access protected context, change workspace state, call external systems, or expand their effective dependency chain.
Why it exists
A text-formatting helper, a production database connector, a shell wrapper, and a supplier-hosted agent plugin carry different risks. The source-trust review should identify action units that request sensitive access, change state, transmit externally, depend on broad package chains, or influence high-impact decisions.
Why this level
This belongs at Level 1 because reviewers need a risk signal before they can decide which action units require production review, stronger integrity controls, runtime approval gates, or deeper validation.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Permission or capability declaration | Skill-set source owner or runtime platform owner | Before production use and after permission changes | Requested permissions, protected context access, external calls, state changes, execution capability, and high-impact action classes | Shows declared or observed capability; does not prove the declaration is complete. |
| Dependency manifest or dependency graph | Skill-set source owner | Before trust is granted and after dependency changes | Direct and important transitive dependencies, package versions, lockfile state, and unmanaged dependency gaps | Supports dependency review; does not prove dependencies are vulnerability-free. |
| High-impact capability tag review | Governance owner with runtime and source owner input | Before enabling high-impact action units and during periodic review | Which action units can affect production, credentials, sensitive data, external communications, code execution, workspace boundaries, or protected context | Supports risk classification; does not prove runtime gates are enforced. |
AWOSS-SRC-L2-001: Introduction And Update Review Level 2
Requirement summary
Require review before introducing or updating trusted reusable action units that can affect production systems, credentials, sensitive data, external communications, code execution, or workspace boundaries, or that materially change requested permissions, dependencies, source, ownership, or update channel.
Why it exists
Most source-trust failures appear during change. A previously acceptable connector may request broader permissions, a script may add a network call, a dependency may change maintainers, or an update channel may move from pinned releases to live remote code. Production systems need a deliberate review before these changes become trusted.
Why this level
This belongs at Level 2 because managed production use needs repeatable review gates before high-impact introduction or update. Level 1 identifies action units and risk signals; Level 2 expects review before trusting risky changes.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Introduction or update review record | Skill-set source owner with governance or runtime owner approval | Before production enablement or approved update | Action unit, proposed version or source, requested capabilities, affected systems, reviewer, decision, conditions, and date | Supports review of a selected change; does not prove the review found every unsafe behavior. |
| Material-change summary | Skill-set source owner or supplier | Before approving updates that change permissions, dependencies, source, owner, or update channel | What changed, why it matters, affected permissions or dependencies, and rollback considerations | Supports change review; does not prove the supplier summary is complete. |
| Approval receipt for high-impact action unit | Evidence or audit owner with source owner input | During approval and review sampling | Reviewer, approval status, scope, version, expiration or next-review date, and any conditions for production use | Supports approval traceability; does not prove runtime policy only allows approved units. |
AWOSS-SRC-L2-002: Approved Provenance Record Level 2
Requirement summary
Maintain provenance records for approved reusable action units, including source, version or commit, dependency state, publisher or supplier status, reviewer or approval status, declared permissions, known high-impact capabilities, and update or retirement path where applicable.
Why it exists
An approval decision becomes hard to audit if the evidence is scattered across a package registry, a ticket, a runtime settings page, and a memory of who reviewed it. A provenance record pulls the essential facts together so a reviewer can answer: what exactly was trusted, why, by whom, with which permissions, and how will it be updated or retired?
Why this level
This belongs at Level 2 because production use needs durable provenance records for approved action units, not only one-time review notes or ad hoc origin details.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Approved provenance record | Skill-set source owner or evidence owner | Before production use and after approved changes | Source, version or commit, dependency state, supplier or publisher status, approval status, permissions, high-impact capabilities, and update or retirement path | Supports provenance review; does not prove the action unit is safe or legally sufficient. |
| Permission manifest tied to approved version | Skill-set source owner or runtime platform owner | Before production use and after permission changes | Declared permissions and sensitive capabilities associated with the approved version or source | Supports permission review; does not prove hidden behavior is absent. |
| Update or retirement path record | Skill-set source owner with runtime owner input | Before production use and after lifecycle changes | How updates are reviewed, how retirement happens, and who can disable or replace the trusted action unit | Supports lifecycle review; does not prove the path has been tested. |
AWOSS-SRC-L2-003: Runtime Drift Check Level 2
Requirement summary
Detect or document drift between approved reusable action-unit versions and the versions, dependencies, manifests, metadata, or permission declarations available to agents at runtime.
Why it exists
A source register can say one thing while the runtime loads another. Drift can happen through automatic updates, dependency resolution, marketplace changes, local edits, configuration changes, remote manifests, or supplier metadata changes. Reviewers need to see whether the runtime still matches the approved source-trust record.
Why this level
This belongs at Level 2 because managed production use should have a repeatable way to compare approval records against runtime availability, or at minimum document known drift and its owner.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Approved-versus-runtime comparison | Runtime platform owner or evidence owner | During operation, before review, and after runtime updates | Approved versions, runtime-loaded versions, dependency state, manifest metadata, permission declarations, and differences | Supports drift review; does not prove every dynamic remote behavior is captured. |
| Lockfile or dependency resolution check | Skill-set source owner | Before release, after dependency updates, and during periodic review | Whether runtime dependencies match approved lockfiles, package versions, hashes, or resolution records | Supports dependency drift review; does not prove packages are vulnerability-free. |
| Drift exception record | Governance owner with source owner input | When drift is detected or accepted | Difference, impact, owner, rationale, expiry, remediation plan, and whether production use is limited | Makes drift visible; does not make the drift safe or acceptable. |
AWOSS-SRC-L3-001: Stronger Integrity Controls For High-Impact Units Level 3
Requirement summary
Use stronger integrity controls for high-impact reusable action units, such as pinned commits, lockfiles, checksums, signatures, attestations, controlled release channels, or independent source review where practical, and document any high-impact action unit that cannot be pinned or integrity-checked.
Why it exists
High-impact action units should be harder to replace silently. If an agent can use a connector that touches production, a script that executes commands, or a tool that exports sensitive data, the organization needs stronger evidence that the reviewed material is the material being used.
Why this level
This belongs at Level 3 because it adds stronger assurance for high-impact units. It may require package mechanics, release controls, independent review, or supplier support that are not always practical for basic or early production use.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Pinned commit, lockfile, checksum, signature, or attestation record | Skill-set source owner | Before production use and after approved high-impact updates | Exact reviewed material, dependency state, integrity marker, signing or attestation status, and verification date | Supports integrity review; does not prove the code is benign or vulnerability-free. |
| Controlled release channel configuration | Skill-set source owner or runtime platform owner | Before high-impact production use and after release-channel changes | Approved release channel, update gate, who can publish, who can approve, and how runtime receives updates | Supports change-control review; does not prove supplier systems are fully secure. |
| Unpinnable or unverifiable component exception | Governance owner with source owner input | Before accepting a high-impact unit that cannot be pinned or integrity-checked | Component, missing integrity mechanism, impact, compensating controls, owner, expiry, and review cadence | Documents a limitation; does not convert unverifiable source into high-assurance evidence. |
AWOSS-SRC-L3-002: High-Impact Source Safety Review Level 3
Requirement summary
Test or review high-impact reusable action units for unsafe capabilities, ambiguous permissions, prompt-injection exposure, hidden external calls, dangerous default behavior, malicious-tool patterns, or dependency risks before production use.
Why it exists
Origin records and signatures can identify what was received, but they do not prove behavior is safe. High-impact action units need review for the ways agent tools can fail: unclear permissions, broad defaults, external calls hidden behind ordinary functions, prompt injection in tool output or prompt packs, malicious command behavior, and risky dependencies.
Why this level
This belongs at Level 3 because it asks for deeper technical review or testing before production use. It is stronger than simply recording provenance or approval status.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| High-impact action-unit review report | Evidence or audit owner with source owner input | Before production use and after material changes | Review method, tested capabilities, permission findings, hidden-call checks, dangerous defaults, dependency risks, findings, and remediation | Supports source safety review; does not prove all unsafe behavior or supply-chain compromise is absent. |
| Malicious-tool or unsafe-capability test record | Validation owner or evidence owner | Before high-impact production use and during recurring validation | Test scenarios for malicious tool behavior, prompt-injection exposure, ambiguous permission handling, hidden external calls, and blocked or remediated outcomes | Supports selected scenario coverage; does not prove all attack patterns are covered. |
| Dependency risk scan or review | Skill-set source owner or validation owner | Before production use and after dependency changes | Important dependencies, known vulnerability signals, maintainer or package risk notes, license or support concerns where relevant, and remediation decisions | Supports dependency-risk review; does not prove complete vulnerability management or legal sufficiency. |
AWOSS-SRC-L3-003: Rollback Or Retirement Path Level 3
Requirement summary
Maintain a rollback or retirement path for trusted reusable action units that become compromised, unsafe, unsupported, unexpectedly changed, or inconsistent with the approved boundary, including a way to disable or replace affected versions where practical.
Why it exists
Trust can change quickly. A package maintainer can disappear, a supplier can ship a breaking change, a connector can expand permissions, or a tool can be found to leak sensitive data. High-impact environments need a practical way to stop using a trusted action unit without improvising during an incident.
Why this level
This belongs at Level 3 because rollback and retirement require operational readiness beyond initial review. The stronger expectation is not just to know a component is risky, but to disable, replace, or revert it where practical.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Rollback or retirement procedure | Skill-set source owner with runtime owner input | Before high-impact production use and after lifecycle changes | How to disable, replace, roll back, or retire trusted action units, who owns the decision, and what workflows are affected | Supports readiness review; does not prove rollback will succeed under every dependency or supplier failure. |
| Disable or replacement test record | Runtime platform owner or validation owner | During controlled testing and after major runtime or source changes | Tested steps for disabling, replacing, or reverting an affected high-impact action unit and observed side effects | Supports operational assurance; does not prove all production paths were exercised. |
| Compromised or unsupported component response record | Evidence or governance owner | After a source-trust incident, supplier change, or unsupported-component discovery | Trigger, affected action units, runtime exposure, decision, containment, replacement, user impact, and follow-up review | Supports incident and lifecycle review; does not prove no residual exposure remains. |
External Mapping Notes
The completed crosswalk treats AWOSS-SRC as one of the clearest agentic-workspace gaps where threat catalogues, emerging assurance work, and governance frameworks can become candidate source-trust controls.
Relevant signals include:
- EU AI Act official sources: supplier inventory and documentation request records can support selected due-diligence evidence, but only within legal claim limits.
- OWASP AISVS: supply-chain and testable source-control language maps to source records, version pins, and dependency manifests, while AISVS
v0.1remains an incubator-status input rather than a final assurance anchor. - AIUC-1: MCP, third-party risk, identity/access, and update signals support third-party review, source approval, and update receipt thinking, but do not create certificate equivalence.
- OWASP Agentic Skills Top 10: malicious skills, supply chain, manifests, metadata, and update drift strongly inform candidate controls around publisher records, signatures, pinned versions, scans, and permission declarations.
- Registry and marketplace manifest-support snapshot: current MCP, connector, app, and Copilot extension ecosystems expose useful but incomplete source signals such as namespace ownership, review status, tool annotations, install permissions, OAuth scopes, hashes, versions, and publisher verification;
AWOSS-SRCshould join those signals with local review, runtime scope, drift, and retirement records rather than treating directory state as complete assurance. - CSA MAESTRO: compromised frameworks, backdoors, and supply-chain attacks inform threat modeling and dependency review, but MAESTRO does not define signing or provenance requirements.
- NIST AI RMF 1.0 and NIST AI 600-1: third-party software, data, supply-chain, value-chain, and component-integration risk support supplier inventories, dependency-risk notes, component inventories, and integration risk notes.
- Five Eyes guidance on careful adoption of agentic AI services: tools, data sources, components, and integrations as attack surfaces support tool approval records and integration risk assessments.
- MITRE ATLAS: AI supply-chain compromise and poisoned agent tools support provenance checks and malicious-tool simulations, but ATLAS is threat input, not a signing specification.
Formal Standard Link
Use this guide with the formal AWOSS-SRC candidate requirements. If the guide and the standard draft disagree, the standard draft controls.