AWS2-SRC: Skill, Tool, And Connector Source Trust

Objective:

The scoped agentic workspace system should make the origin, integrity, approval, capability expectations, permission declarations, dependency chain, and update path of skills, tools, connectors, prompts, plugins, models, integrations, and helper scripts visible and controlled.

Primary layer: skill or skill-set source.

Typical owner: skill or skill-set source.

Applicability:

Applies when agents or runtimes can install, load, select, invoke, update, or trust reusable skills, tools, prompts, connectors, plugins, models, packages, scripts, integrations, supplier-provided components, or remote sources.

Level 1 Candidate Requirements

AWS2-SRC-L1-001: The scoped agentic workspace system MUST inventory the skills, tools, connectors, plugins, prompts, scripts, models, integrations, and other reusable action units that agents can invoke, install, load, or trust.

AWS2-SRC-L1-002: The scoped agentic workspace system MUST record the source, maintainer, publisher, supplier, repository, version, commit, package identifier, checksum, signature, or equivalent origin information for trusted reusable action units where available.

AWS2-SRC-L1-003: The scoped agentic workspace system MUST 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.

Level 2 Candidate Requirements

AWS2-SRC-L2-001: The scoped agentic workspace system MUST 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.

AWS2-SRC-L2-002: The scoped agentic workspace system MUST 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.

AWS2-SRC-L2-003: The scoped agentic workspace system SHOULD detect or document drift between approved reusable action-unit versions and the versions, dependencies, manifests, metadata, or permission declarations available to agents at runtime.

Level 3 Candidate Requirements

AWS2-SRC-L3-001: The scoped agentic workspace system MUST 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 MUST document any high-impact action unit that cannot be pinned or integrity-checked.

AWS2-SRC-L3-002: The scoped agentic workspace system MUST 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.

AWS2-SRC-L3-003: The scoped agentic workspace system SHOULD 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.

Minimum evidence examples:

• skill/tool/connector inventory
• source register
• publisher, supplier, or maintainer record
• capability or permission declaration
• version, commit, checksum, signature, or attestation records
• dependency graph or lockfile
• installation or update receipt
• review and approval record
• component or integration risk note
• validation report for high-impact reusable action units
• malicious-tool, drift, or rollback test record

Candidate source-trust profile language:

• For reusable action units distributed through registries, marketplaces, connector directories, package repositories, remote MCP servers, local skill folders, or supplier channels, the scoped system should preserve a local source-trust profile record rather than relying only on current marketplace state.
• A source-trust profile record should identify the action unit, source ecosystem, publisher, namespace, domain, repository, supplier, package, remote endpoint, or bundle artifact; record version, published timestamp, retrieval timestamp, and latest-known status where available; and preserve manifest, descriptor, checksum, signature, signer, attestation, or hash fields where available.
• A source-trust profile record should capture 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, and should record when those declarations are incomplete, unavailable, or not independently verified.
• A source-trust profile record should join external registry or marketplace signals with local review status: reviewer, review date, approval decision, target assurance level, approved runtime scope, claim limits, exception or compensating-control status, and owner for reassessment.
• A source-trust profile record should track update history, approved versus observed version, manifest/schema/permission drift, review expiration, retirement status, rollback or emergency-disable path, and any trigger that requires AWS2-GOV reassessment or AWS2-VAL retesting.

Mapping notes:

• The completed crosswalk treats AWS2-SRC as a candidate-control family shaped by source trust, skill safety, dependency and component risk, permission declaration, manifest, update-drift, supplier, and malicious-tool signals from OWASP AISVS, OWASP Agentic Skills Top 10, NIST AI 600-1, Five Eyes guidance, MITRE ATLAS, CSA MAESTRO, AIUC-1, and selected EU AI Act due-diligence signals.

Claim limits:

• Provenance evidence supports selected source-trust controls. It does not prove that the source is benign, that dependencies are vulnerability-free, that signatures or package mechanics are sufficient, that EU AI Act downstream due diligence is complete, that AISVS or AIUC-1 requirements are satisfied, or that any packaging system, registry listing, marketplace review, namespace verification, tool annotation, or connector directory satisfies the whole aws2 boundary.