Google has updated the Agent Registry, a central catalog to register, discover, and govern AI agents, MCP servers, tools, endpoints, and standalone skills. According to the Nov. 6 release notes, standalone skills have reached general availability. It is critical to distinguish that while these skills are GA, the newly introduced security scanning and governance capabilities are available for use but are not separately labeled as GA. Furthermore, Customer-Managed Encryption Keys (CMEK) for skill payloads at rest remain in Preview.
The core function of these new controls is to bind a revision scan to specific download and default-revision policies, rather than to certify the absolute safety of a skill. The registry now provides an analytical layer that inspects uploaded content, including SKILL.md files, scripts, and supporting assets. The scan guide notes that the system evaluates code logic and semantic intent for risks like unauthorized data exfiltration, exposed credentials, or indirect prompt injection. Because the scanner utilizes LLMs, results are probabilistic and may include false positives or false negatives. Findings can be approximate or hallucinated, meaning developers must review and verify all output before initiating remediation.
When the scanner identifies a potential issue, it generates a read-only Finding resource. These resources contain the associated revision, severity level, the specific vulnerability or secret class identified, and affected file paths. In many cases, the system provides line numbers and explanatory details regarding the nature of the finding. However, because the underlying analysis is probabilistic, these path, line, and descriptive details may be approximate. This granularity provides a starting point for investigation, but the inherent uncertainty in LLM-based detection means that developers must manually validate the findings against the actual source code and logic before attempting any remediation or dismissing the alert.
The system’s blocking behavior is specific: the default ENABLED_BLOCKING policy prevents the download of any revision flagged with findings. Additionally, this policy prevents the promotion of any revision with findings—or any revision currently undergoing a pending scan—to the default revision status. Administrators may also select ENABLED_NONBLOCKING or DISABLED settings. These configurations are not retroactive; only revisions created after a policy change are scanned. Consequently, existing content remains unscanned unless a developer creates a new revision to trigger the processing engine.
Operational constraints also dictate the scope of these scans. When scanning is active, the system enforces a maximum 10 MB total uncompressed package size and a 1 MB limit per individual file. If a package exceeds these limits, revision creation may fail or return an UNSUPPORTED_FORMAT error. These limits are technical boundaries for the scanning engine rather than security features, and they define the operational envelope within which the registry functions.
Governance extends beyond individual scans through custom Organization Policy Service constraints. Organizations can enforce specific scanning behaviors, such as mandating ENABLED_BLOCKING, with optional Resource Manager tag exemptions. This allows for a tiered approach to agent governance, enabling policy enforcement at the organization or folder level. This structure keeps skill-level configuration separate from broader organizational requirements.
The administrative workflow relies on specific roles to manage these controls. The Agent Registry User is typically identified for configuring scans, while the Agent Registry API Admin is responsible for viewing and listing findings. The Organization Policy Administrator is required to enforce scanning at the organization or folder level. This documentation of roles describes functional responsibilities for these tasks without implying that these roles are exclusive or universally required for all registry operations.
Ultimately, these updates provide a documented control chain from revision scan to organization policy. While this framework offers visibility into skill assets, the current documentation directs developer review and does not report measured outcomes regarding the effectiveness or adoption of these controls across the registry. The system provides these mechanisms and operational limits as tools for administrators, but it does not establish comprehensive protection or cross-registry coverage.