skillhub/docs/PRIVACY_AND_DATA_GOVERNANCE.md

Privacy and Data Governance Policy

Last updated: August 18, 2026

Purpose and scope

SkillHub is open-source software for publishing, reviewing, discovering, and installing reusable agent skill packages. This document describes the project's privacy and data-governance expectations and the controls available to people who operate SkillHub instances.

The SkillHub maintainers publish source code and project infrastructure. They do not operate or control every independently hosted instance. The organization or person operating an instance determines why and how personal data is processed in that environment and is responsible for publishing an instance-specific privacy notice, selecting lawful processing grounds, handling data-subject requests, and complying with applicable law.

The public SkillHub service also publishes an in-product privacy notice. This project document supplements that notice for source-code reviewers and self-hosted operators. It is not legal advice and does not certify that every deployment is automatically compliant with any law.

Applicable law

Privacy and data-protection obligations depend on the operator's legal entity, where the instance and its users are located, the people it serves, the data in skill packages, and the infrastructure and integrations selected by the operator.

Before processing personal data, each operator must:

• identify and document the domestic and international laws that apply;
• determine and record the lawful basis for each material processing purpose;
• complete any required privacy, child-safety, security, or transfer assessment;
• reflect those obligations in notices, contracts, procedures, and configuration; and
• avoid or redesign processing that cannot be operated lawfully.

Open-source availability and configurable controls support implementation. They do not replace an operator's legal analysis or operational responsibilities.

Data the software can process

The exact data depends on the authentication, storage, email, observability, scanner, and deployment options selected by the operator. A SkillHub instance can process:

• account and identity data, such as username, email address, avatar, OAuth provider identifiers, account status, platform roles, and namespace membership;
• authentication and security data, such as session identifiers, password hashes, API token metadata, login events, IP addresses, device or browser information, and password-reset records;
• skill package content, including SKILL.md, scripts, documentation, images, examples, license files, archives, and version metadata;
• collaboration and governance data, such as namespaces, reviews, review comments, promotion requests, reports, ratings, stars, notifications, and audit records;
• usage and operational data, such as searches, downloads, request identifiers, timestamps, errors, metrics, traces, application logs, and security findings; and
• configuration and connection data for object storage, identity providers, email, monitoring, and optional scanning services.

A skill package, review comment, profile, log entry, or security report can contain personal, confidential, or authentication data even when a field is not labelled as personal data. Operators and publishers must classify data according to its actual content and use.

Roles and responsibilities

For an independently operated instance, the instance operator normally decides the purposes and means of processing and must document its role under applicable law. Publishers and namespace administrators are responsible for the content they upload and the access decisions they make. External identity, storage, email, monitoring, and scanner providers may process data under their own terms and assigned roles.

The upstream SkillHub maintainers generally cannot access, correct, export, or delete data held by an independently operated instance. Requests concerning an instance must go to the operator identified in that instance's privacy notice.

Purpose limitation and data minimization

Data should be collected only when needed to authenticate users, enforce access rules, publish and distribute skill packages, operate review and governance workflows, secure and troubleshoot the instance, and meet documented legal duties.

Operators, administrators, and publishers should:

• avoid placing secrets or unnecessary personal data in skill packages, README files, examples, namespace profiles, reviews, or report details;
• use pseudonymous or organization-scoped identifiers where practical;
• configure the shortest retention and least visibility needed for each purpose;
• redact sensitive values before sending packages or findings to an external scanner, model, log sink, or support channel;
• restrict privileged roles and review them regularly; and
• document the source, purpose, recipients, lawful basis, and retention period for each material category of personal data.

Storage, access, and isolation

SkillHub supports authenticated access, platform and namespace RBAC, public, namespace-only and private visibility, audit logs, hashed API tokens, PostgreSQL, Redis, and local or S3-compatible object storage. These capabilities are building blocks, not a secure deployment by themselves.

Operators are responsible for:

• disabling development authentication and replacing example credentials before exposing an instance;
• using HTTPS for external traffic and protected networks for internal services;
• applying least-privilege roles to users, services, databases, caches, and object stores;
• encrypting sensitive data and backups according to their threat model and legal obligations;
• storing secrets in an appropriate secrets manager rather than source code, skill packages, client-side configuration, or logs;
• testing namespace and object-storage isolation for their configuration;
• restricting and monitoring access to packages, audit data, logs, traces, backups, and security findings; and
• applying supported security updates and maintaining a recovery process.

External services and international transfers

OAuth providers, S3-compatible storage, email services, monitoring systems, mirrors, and optional scanner integrations can receive data from a SkillHub instance. An operator that enables an external service must assess its privacy and security terms, hosting locations, retention, subprocessors, training-data rules, and cross-border transfer mechanism.

The optional scanner can process uploaded skill archives and findings. If an operator enables an external or LLM-backed scanner, that disclosure must be covered by the instance's privacy notice and data-flow review. A service does not become private merely because SkillHub can integrate with it.

Retention, deletion, and portability

The open-source project does not impose one retention period on independently operated instances. Each operator must publish periods that are no longer than necessary for its purposes and legal duties.

A deletion process should cover account and namespace records, package objects, reviews, reports, ratings, notifications, security findings, caches, audit records, logs, traces, exports, and backups. Where immediate backup deletion is not practical, deleted data should be isolated from normal use and expire under a documented schedule. Operators must also account for copies already disclosed to external providers or downloaded by authorized users.

Operators should provide authenticated channels for access, correction, deletion, restriction, objection, and portability requests where applicable. Requests should be verified, recorded, completed within legally required time limits, and denied only on a documented basis.

Skill packages can be downloaded as archives and installed through the CLI. Public APIs expose package and metadata workflows. Operators should separately document which instance records can be imported or exported, their non-proprietary formats, version compatibility, and any PII excluded from an export.

Security and incident handling

Security vulnerabilities in the upstream project must be reported under the public iFLYTEK organization security policy and its detailed community security policy. Send vulnerability details privately to security@iflytek.com, not in a public issue.

Instance operators remain responsible for monitoring their environments, maintaining an incident-response plan, preserving proportionate evidence, rotating affected credentials, applying fixes, and notifying users or authorities where required.

Project and instance contacts

• Report an upstream security vulnerability privately to security@iflytek.com.
• Send questions about this project policy to ifly_opensource@iflytek.com. Do not include personal data or confidential incident details in a public GitHub issue.
• Contact the operator named in an instance's privacy notice for data-subject requests or incidents involving that instance.

Governance and changes

Privacy-impacting changes should be reviewed for data minimization, access and namespace boundaries, package visibility, external disclosures, retention, logging, deletion, and portability. Material changes to this document are made through the repository's public review process, and the file history records them.